Definisi Kompatibilitas Android 9

1. Pengantar

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

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

Seperti yang digunakan dalam dokumen ini, “pengimplementasikan perangkat” atau “implementasi” adalah orang atau organisasi yang mengembangkan solusi hardware/software yang menjalankan Android 9. "Implementasi perangkat" atau "implementasi" adalah solusi perangkat keras/perangkat lunak yang dikembangkan.

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

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

Karena alasan ini, Proyek Open Source Android adalah referensi dan implementasi pilihan Android. Pengimplementasi perangkat SANGAT DIREKOMENDASIKAN untuk mendasarkan implementasi mereka sebaik mungkin pada kode sumber “upstream” yang tersedia dari Project Open Source Android. Meskipun beberapa komponen secara hipotetis dapat diganti dengan implementasi alternatif, SANGAT DIREKOMENDASIKAN untuk tidak mengikuti praktik ini, karena lulus pengujian software akan menjadi jauh lebih sulit. Pelaksana 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 resource yang ditautkan dalam dokumen ini berasal secara langsung atau tidak langsung dari Android SDK dan secara fungsional akan identik dengan informasi dalam dokumentasi SDK tersebut. Jika Definisi Kompatibilitas atau Compatibility Test Suite ini tidak sesuai dengan dokumentasi SDK, dokumentasi SDK akan dianggap otoritatif. Setiap detail teknis yang diberikan dalam referensi tertaut di seluruh dokumen ini dianggap dengan penyertaan sebagai bagian dari Definisi Kompatibilitas ini.

1.1 Struktur Dokumen

1.1.1. Persyaratan menurut Jenis Perangkat

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

Semua persyaratan lainnya, yang secara universal berlaku untuk implementasi perangkat Android apa pun, tercantum di bagian setelah Bagian 2. Persyaratan ini disebut sebagai "Persyaratan Inti" dalam dokumen ini.

1.1.2. ID Persyaratan

ID persyaratan ditetapkan untuk persyaratan HARUS.

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

Setiap ID didefinisikan sebagai berikut:

• ID Jenis Perangkat (lihat selengkapnya di 2. Jenis Perangkat)
  • C: Inti (Persyaratan yang diterapkan pada implementasi perangkat Android apa pun)
  • H: Perangkat Genggam Android
  • T: Perangkat Android Television
  • J: Implementasi Android Automotive
  • Tab: Implementasi Tablet Android
• ID kondisi
  • Jika persyaratannya tidak kondisional, ID ini ditetapkan sebagai 0.
  • Jika persyaratan bersifat bersyarat, 1 ditetapkan untuk kondisi pertama dan angka akan bertambah sebesar 1 di bagian dan jenis perangkat yang sama.
• ID Persyaratan
  • ID ini dimulai dari 1 dan bertambah 1 dalam bagian dan kondisi yang sama.

1.1.3 ID Persyaratan di Pasal 2

ID Persyaratan di Bagian 2 diawali dengan ID bagian yang sesuai dan 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 Proyek 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 mapan.

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 memenuhi semua persyaratan di bagian lain dari Definisi Kompatibilitas ini.

2.1 Konfigurasi Perangkat

Untuk mengetahui perbedaan utama dalam konfigurasi hardware berdasarkan jenis perangkat, lihat persyaratan khusus perangkat yang ada di bagian ini.

2.2. Persyaratan Perangkat Genggam

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

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

• Memiliki sumber listrik yang dapat memudahkan mobilitas, seperti baterai.
• Memiliki ukuran layar diagonal fisik dalam kisaran 2,5 hingga 8 inci.

Persyaratan tambahan di bagian selanjutnya 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 minimal 2,5 inci dalam ukuran diagonal fisik.
• [7.1.1.3/H-SR] SANGAT DIREKOMENDASIKAN untuk memberi pengguna kemampuan mengubah ukuran layar.(Kepadatan Layar)

Jika penerapan perangkat genggam mengklaim dukungan untuk rentang dinamis tinggi yang ditampilkan melalui Configuration.isScreenHdr() , implementasi 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 luar perangkat Android (mis. 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 DIREKOMENDASIKAN 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 DIREKOMENDASIKAN untuk menyertakan akselerometer 3 sumbu.

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

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

Jika implementasi perangkat genggam menyertakan giroskop, implementasi tersebut:

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

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

• [7.3.8/H] SEHARUSNYA menyertakan sensor kedekatan.

Implementasi perangkat genggam:

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

Jika implementasi Perangkat genggam menyertakan koneksi berkuota, implementasi tersebut:

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

Implementasi perangkat genggam:

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

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

• [7.6.1/H-1-1] Memori yang tersedia untuk kernel dan userspace HARUS minimal 416 MB jika tampilan default menggunakan resolusi framebuffer hingga qHD (mis. FWVGA).

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

• [7.6.1/H-3-1] Memori yang tersedia untuk kernel dan userspace HARUS minimal 896 MB jika tampilan default menggunakan resolusi framebuffer hingga FHD (mis. WSXGA+).

• [7.6.1/H-4-1] Memori yang tersedia untuk kernel dan userspace HARUS minimal 1344 MB jika tampilan default menggunakan resolusi framebuffer hingga QHD (mis. QWXGA).

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

• [7.6.1/H-5-1] Memori yang tersedia untuk kernel dan userspace HARUS minimal 816 MB jika tampilan default menggunakan resolusi framebuffer hingga qHD (mis. FWVGA).

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

• [7.6.1/H-7-1] Memori yang tersedia untuk kernel dan userspace HARUS minimal 1.280 MB jika layar default menggunakan resolusi framebuffer hingga FHD (mis. WSXGA+).

• [7.6.1/H-8-1] Memori yang tersedia untuk kernel dan userspace HARUS minimal 1824 MB jika tampilan default menggunakan resolusi framebuffer hingga QHD (mis. QWXGA).

Perhatikan bahwa "memori yang tersedia untuk kernel dan userspace" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah dikhususkan untuk komponen hardware seperti radio, video, dan seterusnya 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 userspace, implementasi tersebut:

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

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

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

Implementasi perangkat genggam:

• [7.6.2/H-0-1] TIDAK BOLEH menyediakan penyimpanan bersama untuk aplikasi yang berukuran 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, implementasi tersebut:

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

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 untuk mode tersebut, mereka:

• [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 mengimplementasikan 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 AAC MPEG-4 (AAC LC)
• [5.1.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
• [5.1.1/H-0-5] AAC ELD (Peningkatan AAC penundaan rendah)

Implementasi perangkat genggam HARUS mendukung decoding 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] AVC H.264
• [5,2/H-0-2] VP8

Implementasi perangkat genggam HARUS mendukung decoding video berikut:

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

2.2.3. Software

Implementasi perangkat genggam:

• [3.2.3.1/H-0-1] HARUS memiliki aplikasi yang menangani intent ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, dan ACTION_CREATE_DOCUMENT seperti yang dijelaskan dalam dokumen SDK, dan memberikan kemampuan pengguna untuk mengakses data penyedia dokumen dengan menggunakan DocumentsProvider API.
• [3.4.1/H-0-1] HARUS memberikan 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 DIREKOMENDASIKAN untuk mengimplementasikan peluncur default yang mendukung penyematan pintasan, widget, dan widgetFeatures dalam aplikasi.
• [3.8.1/H-SR] SANGAT DIREKOMENDASIKAN untuk menerapkan peluncur default yang menyediakan akses cepat ke pintasan tambahan yang disediakan oleh aplikasi pihak ketiga melalui ShortcutManager API.
• [3.8.1/H-SR] SANGAT DIREKOMENDASIKAN untuk menyertakan aplikasi peluncur default yang menampilkan badge untuk ikon aplikasi.
• [3.8.2/H-SR] SANGAT DIREKOMENDASIKAN 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 multimedia.
• [3.8.3/H-0-3] HARUS mendukung notifikasi peringatan dini.
• [3.8.3/H-0-4] HARUS menyertakan menu notifikasi, yang memberi pengguna kemampuan untuk mengontrol secara langsung (misalnya, membalas, menunda, menutup, memblokir) notifikasi melalui kemampuan pengguna seperti tombol tindakan atau panel kontrol seperti yang diimplementasikan dalam 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 DIREKOMENDASIKAN untuk menampilkan pilihan pertama yang disediakan melalui RemoteInput.Builder setChoices() di menu notifikasi tanpa interaksi pengguna tambahan.
• [3.8.3/H-SR] SANGAT DIREKOMENDASIKAN untuk menampilkan semua pilihan yang disediakan melalui RemoteInput.Builder setChoices() di menu notifikasi ketika pengguna meluaskan semua notifikasi di menu notifikasi.
• [3.8.4/H-SR] SANGAT DIREKOMENDASIKAN untuk menerapkan asisten di perangkat guna menangani tindakan Bantuan.

Jika implementasi Perangkat genggam mendukung tindakan Assist, implementasi tersebut:

• [3.8.4/H-SR] SANGAT DIREKOMENDASIKAN untuk menggunakan tekan lama tombol HOME sebagai interaksi yang ditentukan 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, implementasi 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 mengimplementasikan berbagai kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK.
• [3.9/H-1-2] HARUS mendeklarasikan dukungan profil terkelola melalui tombol fitur android.software.managed_users, kecuali jika perangkat dikonfigurasikan sehingga akan 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 DIREKOMENDASIKAN untuk melakukan pramuat layanan aksesibilitas di perangkat yang sebanding dengan atau melebihi fungsi Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech bawaan) 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 DIREKOMENDASIKAN untuk menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat.
• [3.13/H-SR] SANGAT DIREKOMENDASIKAN 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 Kekuatan

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

Implementasi perangkat genggam:

• [8.2/H-0-1] HARUS memastikan performa penulisan berurutan setidaknya 5 MB/dtk.
• [8.2/H-0-2] HARUS memastikan performa penulisan acak setidaknya 0,5 MB/dtk.
• [8.2/H-0-3] HARUS memastikan performa baca berurutan setidaknya 15 MB/dtk.
• [8.2/H-0-4] HARUS memastikan performa baca acak setidaknya 3,5 MB/dtk.

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

• [8.3/H-1-1] HARUS memberikan kemampuan pengguna untuk mengaktifkan dan menonaktifkan fitur penghemat baterai.
• [8.3/H-1-2] HARUS memberikan kemampuan kepada 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 pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu, seperti yang didokumentasikan di situs Proyek Open Source Android.
• [8.4/H-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).
• [8.4/H-0-3] HARUS melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui implementasi modul kernel uid_cputime.
• [8.4/H-0-4] HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.
• [8.4/H] HARUS dikaitkan dengan komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.

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

• [8.4/H-1-1] HARUS mengikuti intent android.intent.action.POWER_USAGE_SUMMARY dan menampilkan menu setelan yang menunjukkan penggunaan daya ini.

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, implementasi tersebut:

• [9.11/H-1-1] HARUS mengizinkan pengguna untuk 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 untuk autentikasi utama yang dijelaskan dalam 9.11.1 Secure Lock Screen. AOSP memenuhi persyaratan sebagai mode kunci total.

2.3. Persyaratan Televisi

Perangkat Android Televisi mengacu pada penerapan perangkat Android yang merupakan antarmuka hiburan untuk menonton media digital, film, game, aplikasi, dan/atau TV live bagi pengguna yang duduk sekitar sepuluh kaki dari jarak jauh ("antarmuka pengguna yang santai" atau "antarmuka pengguna 10 kaki").

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

• Telah menyediakan mekanisme untuk mengontrol antarmuka pengguna yang dirender pada layar dari jarak jauh, yang mungkin berjarak sepuluh kaki dari pengguna.
• Memiliki tampilan layar tersemat 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 selanjutnya ini khusus untuk implementasi perangkat Android Television.

2.3.1. Hardware

Implementasi perangkat televisi:

• [7.2.2/T-0-1] HARUS mendukung D-pad.
• [7.2.3/T-0-1] HARUS menyediakan 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 tombol fitur android.hardware.gamepad.
• [7.2.7/T] HARUS menyediakan remote control yang dapat digunakan pengguna untuk mengakses input navigasi non-sentuh dan tombol navigasi inti.

Jika implementasi perangkat Televisi menyertakan giroskop, implementasi tersebut:

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

Implementasi perangkat televisi:

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

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

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

Jika implementasi perangkat TV adalah 32-bit:

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

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

Jika implementasi perangkat TV adalah 64-bit:

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

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

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

Implementasi perangkat televisi:

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

2.3.2. Multimedia

Implementasi perangkat televisi HARUS mendukung format encoding audio berikut:

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

Implementasi perangkat televisi HARUS mendukung format encoding video berikut:

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

Implementasi perangkat televisi:

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

Penerapan perangkat televisi HARUS mendukung format decoding video berikut:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] AVC H.264
• [5.3.5/T-0-3] HEVC H.265
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9

Implementasi perangkat televisi SANGAT DIREKOMENDASIKAN untuk mendukung format decoding video berikut:

• [5.3.1/T-SR] MPEG-2

Implementasi perangkat televisi HARUS mendukung dekode H.264, sebagaimana diperinci dalam Bagian 5.3.4, pada kecepatan frame dan resolusi video standar hingga dan termasuk:

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

Implementasi perangkat televisi dengan decoder hardware H.265 HARUS mendukung decoding H.265, sebagaimana diperinci dalam Pasal 5.3.5, pada kecepatan frame dan resolusi video standar hingga dan termasuk:

• [5.3.5.4/T-1-1] HD 1080p dengan 60 frame per detik dengan Profil Utama Level 4.1

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

• [5.3.5.5/T-2-1] HARUS mendukung profil decoding UHD pada 60 frame per detik dengan profil Paket Utama Main10 Level 5.

Implementasi perangkat televisi HARUS mendukung dekode VP8, sebagaimana diperinci dalam Bagian 5.3.6, pada kecepatan frame dan resolusi video standar hingga dan termasuk:

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

Implementasi perangkat televisi dengan decoder hardware VP9 HARUS mendukung decoding VP9, sebagaimana diperinci dalam 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 decoder hardware VP9 mendukung decoding VP9 dan profil decoding UHD, implementasi 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 DIREKOMENDASIKAN untuk mendukung profil decoding UHD pada 60 frame per detik dengan profil 2 (kedalaman warna 10 bit).

Implementasi perangkat televisi:

• [5.5.3/T-0-1] HARUS menyertakan dukungan untuk Volume Master sistem dan pelemahan volume output audio digital pada output yang didukung, kecuali untuk output passthrough audio terkompresi (jika tidak ada decoding audio yang dilakukan pada perangkat).
• [5.8/T-0-1] HARUS menyetel 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 DIREKOMENDASIKAN untuk menyediakan pemilih kecepatan refresh HDMI yang dapat dikonfigurasi oleh pengguna untuk semua layar berkabel.
• [5.8/T-SR] SANGAT DIREKOMENDASIKAN untuk mendukung decoding streaming aman secara bersamaan. Setidaknya, decoding dua streaming secara simultan SANGAT DIREKOMENDASIKAN.
• [5.8] SEHARUSNYA menyetel kecepatan refresh mode output HDMI ke 50 Hz atau 60 Hz, bergantung pada kecepatan refresh video di wilayah tempat perangkat dijual untuk semua layar berkabel.

Jika implementasi perangkat Televisi mendukung decoding UHD dan memiliki dukungan untuk layar eksternal, implementasi 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, implementasi tersebut:

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

2.3.3. Software

Implementasi perangkat televisi:

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

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

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

Implementasi perangkat televisi:

• [3.8.14/T-SR] SANGAT DIREKOMENDASIKAN 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 DIREKOMENDASIKAN untuk melakukan pramuat layanan aksesibilitas di perangkat yang sebanding dengan atau melebihi fungsi Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech bawaan) seperti yang disediakan dalam project open source Talkback.

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

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

Implementasi perangkat televisi:

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

2.3.4. Performa dan Kekuatan

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

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

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

Implementasi 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 pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu, seperti yang didokumentasikan di situs Proyek Open Source Android.
• [8.4/T-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).
• [8.4/T-0-3] HARUS melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui implementasi modul kernel uid_cputime.
• [8.4/T] HARUS dikaitkan dengan 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 Tontonan

Perangkat Android Watch mengacu pada implementasi perangkat Android yang dimaksudkan untuk dikenakan pada badan, mungkin di pergelangan tangan.

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

• Memiliki layar dengan panjang diagonal fisik dalam kisaran 1,1 hingga 2,5 inci.
• Memiliki mekanisme yang disediakan untuk dikenakan pada tubuh.

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

2.4.1. Hardware

Implementasi perangkat smartwatch:

• [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 menyediakan fungsi Beranda bagi pengguna, dan fungsi Kembali, kecuali jika berada dalam UI_MODE_TYPE_WATCH.

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

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

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

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

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

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

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

2.4.2. Multimedia

Tidak ada persyaratan tambahan.

2.4.3. Software

Implementasi perangkat smartwatch:

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

Implementasi perangkat smartwatch:

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

Implementasi perangkat smartwatch yang mendeklarasikan tombol fitur android.hardware.audio.output:

• [3.10/W-1-1] HARUS mendukung layanan aksesibilitas pihak ketiga.
• [3.10/W-SR] SANGAT DIREKOMENDASIKAN untuk melakukan pramuat layanan aksesibilitas di perangkat yang sebanding dengan atau melebihi fungsi Tombol Akses dan TalkBack (untuk bahasa yang didukung oleh mesin Text-to-speech bawaan) seperti yang disediakan dalam project open source Talkback.

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

• [3.11/W-SR] SANGAT DIREKOMENDASIKAN 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 Kekuatan

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

• [8.3/W-SR] SANGAT DIREKOMENDASIKAN untuk memberikan kemampuan kepada pengguna agar dapat menampilkan semua aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.
• [8.3/W-SR] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan pengguna guna mengaktifkan dan menonaktifkan fitur penghemat baterai.

Implementasi perangkat smartwatch:

• [8.4/W-0-1] HARUS menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu, seperti yang didokumentasikan di situs Proyek Open Source Android.
• [8.4/W-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).
• [8.4/W-0-3] HARUS melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui implementasi modul kernel uid_cputime.
• [8.4/W-0-4] HARUS menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.
• [8.4/W] HARUS dikaitkan dengan 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 seluruh sistem dan/atau fungsi infotainmen.

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

• Disematkan sebagai bagian dari, atau dapat dicocokkan dengan, kendaraan otomotif.
• Menggunakan layar di baris kursi pengemudi sebagai tampilan utama.

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

2.5.1. Hardware

Implementasi perangkat otomotif:

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

• [7.1.1.1/A-0-2] HARUS memiliki tata letak ukuran layar minimal 750 dp x 480 dp.

• [7.2.3/A-0-1] HARUS menyediakan fungsi Beranda dan MUNGKIN 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 DIREKOMENDASIKAN untuk menyertakan akselerometer 3 sumbu.

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

• [7.3.1/A-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 100 Hz.
• [7.3.1/A-1-2] HARUS mematuhi sistem koordinat sensor mobil Android.

Jika implementasi perangkat Automotive menyertakan giroskop, implementasi tersebut:

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

Implementasi perangkat otomotif:

• [7.3.11/A-0-1] HARUS menyediakan roda gigi saat ini sebagai SENSOR_TYPE_GEAR.

Implementasi perangkat otomotif:

• [7.3.11.2/A-0-1] HARUS mendukung mode siang/malam yang ditetapkan 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 ditetapkan oleh SENSOR_TYPE_CAR_SPEED.

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

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

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

• [7.4.3/A-SR] SANGAT DIREKOMENDASIKAN untuk mendukung Message Access Profile (MAP).

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

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

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

Implementasi perangkat otomotif:

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

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

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

Jika implementasi perangkat Automotive adalah 32-bit:

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

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

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

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

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

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

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

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

Jika implementasi perangkat Automotive adalah 64-bit:

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

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

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

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

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

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

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

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

Perhatikan bahwa "memori yang tersedia untuk kernel dan userspace" di atas mengacu pada ruang memori yang disediakan selain memori yang sudah dikhususkan untuk komponen hardware seperti radio, video, dan seterusnya 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 (Peningkatan AAC penundaan rendah)

Implementasi perangkat otomotif HARUS mendukung encoding video berikut:

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

Implementasi perangkat otomotif HARUS mendukung decoding video berikut:

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

Implementasi perangkat otomotif SANGAT DIREKOMENDASIKAN untuk mendukung decoding video berikut:

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

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 memberikan 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 Disarankan untuk menerapkan asisten di perangkat guna menangani tindakan Bantuan.

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

Jika implementasi perangkat Automotive menyertakan tombol push-to-talk, implementasi tersebut:

• [3.8.4/A-1-1] HARUS menggunakan penekanan singkat pada tombol push-to-talk sebagai interaksi yang ditentukan 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 API media seperti yang dijelaskan di bagian 3.14.

2.5.4. Performa dan Kekuatan

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 kepada 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 UID setiap proses agar statistik tersedia bagi 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 menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu, seperti yang didokumentasikan di situs Proyek Open Source Android.
• [8.4/A-0-2] HARUS melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).
• [8.4/A-0-3] HARUS melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui implementasi modul kernel uid_cputime.
• [8.4/A] HARUS dikaitkan dengan 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 ke developer aplikasi.

2.5.5. Model Keamanan

Jika implementasi perangkat Automotive mendukung beberapa pengguna, implementasi perangkat tersebut:

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

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

• [9.9.2/A-1-1] HARUS mendukung enkripsi per kunci autentikasi khusus pengguna. Enkripsi Berbasis File (FBE) adalah salah satu cara untuk melakukannya.

Implementasi perangkat otomotif:

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

2.6. Persyaratan Tablet

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

• Biasanya digunakan dengan berpegangan di kedua tangan.
• Tidak memiliki konfigurasi laptop konvensional atau konvertibel.
• Setiap penerapan keyboard fisik yang digunakan dengan perangkat HARUS terhubung melalui koneksi standar.
• Memiliki sumber listrik yang menyediakan 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 oleh dan * pada bagian tersebut dan dicantumkan sebagai referensi di bagian ini.

2.4.1. Hardware

Ukuran Layar

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

Memori dan Penyimpanan Minimum (Bagian 7.6.1)

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

Mode periferal USB (Bagian 7.7.1)

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

• [7.7.1/Tab] MUNGKIN menerapkan Android Open Accessory API (AOA).

Mode Virtual Reality (Bagian 7.9.1)

Performa Tinggi Virtual Reality (Bagian 7.9.2)

Persyaratan virtual reality tidak berlaku untuk tablet.

3. Software

3.1. Kompatibilitas API Terkelola

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

Implementasi perangkat:

• [C-0-1] HARUS memberikan penerapan lengkap, termasuk semua perilaku yang didokumentasikan, dari API terdokumentasi apa pun yang diekspos oleh Android SDK atau API apa pun yang dilengkapi 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 apa pun, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang didokumentasikan, atau menyertakan tanpa pengoperasian, kecuali jika secara khusus diizinkan oleh Definisi Kompatibilitas ini.

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

• [C-0-5] HARUS membatasi penggunaan penggunaan API tersembunyi oleh aplikasi pihak ketiga, yang didefinisikan sebagai API dalam namespace Android yang didekorasi dengan anotasi @hidden, tetapi tidak dengan @SystemAPI atau @TestApi, seperti yang dijelaskan dalam dokumen SDK dan mengirimkannya dengan setiap dan setiap API tersembunyi pada daftar terbatas 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 demikian:

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

3.1.1. Ekstensi Android

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

• [C-0-1] Implementasi perangkat Android HARUS melakukan pramuat 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, menjalankan API level 24 HARUS menyertakan setidaknya versi 1.

3.1.2. Library Android

Karena penghentian klien HTTP Apache, implementasi perangkat:

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

3.2.1. Izin

• [C-0-1] Pengimplementasi perangkat HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan di Halaman referensi izin. Perlu diperhatikan bahwa pasal 9 mencantumkan persyaratan tambahan terkait model keamanan Android.

3.2.2 Parameter Build

Android API menyertakan sejumlah konstanta di class android.os.Build yang dimaksudkan untuk menjelaskan 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 saat ini dijalankan, dalam format yang dapat dibaca manusia. Kolom ini HARUS memiliki salah satu nilai string yang ditentukan di 9.
VERSION.SDK	Versi sistem Android yang saat ini dijalankan, 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 saat ini dijalankan, 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 pengimplementasi perangkat yang menentukan build spesifik dari sistem Android yang saat ini dijalankan, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build berbeda yang disediakan bagi pengguna akhir. Penggunaan kolom ini biasanya untuk menunjukkan nomor build atau ID perubahan kontrol sumber yang digunakan untuk membuat build. Tidak ada persyaratan untuk format khusus kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong ("").
PAPAN	Nilai yang dipilih oleh implementasi perangkat yang mengidentifikasi hardware internal tertentu yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kolom ini dapat digunakan untuk menunjukkan revisi spesifik dari board yang menjalankan 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 sebagaimana diketahui oleh pengguna akhir. HARUS dalam format yang dapat dibaca manusia dan HARUS mewakili produsen perangkat atau merek perusahaan tempat perangkat dipasarkan. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
DIDUKUNG_ABI	Nama kumpulan petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
SUPPORTED_32_BIT_ABIS	Nama kumpulan petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
SUPPORTED_64_BIT_ABIS	Nama kumpulan petunjuk kedua (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
ABI_CPU	Nama kumpulan petunjuk (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
CPU_ABI2	Nama kumpulan petunjuk kedua (jenis CPU + konvensi ABI) kode native. Lihat bagian 3.3. Kompatibilitas Native API.
PERANGKAT	Nilai yang dipilih oleh pengimplementasikan 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 pakai produk.
CETAK JARI	String yang mengidentifikasi build ini secara unik. Harus dapat dibaca oleh manusia. URL HARUS mengikuti {i>template<i} 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 berisi 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 perangkat keras (dari baris perintah {i>kernel<i} atau {i>/proc<i}. Harus dapat dibaca oleh manusia. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9_-]+$”.
HOST	String yang secara unik mengidentifikasi host tempat build dibuat, dalam format yang dapat dibaca manusia. Tidak ada persyaratan untuk format khusus kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong ("").
ID	ID yang dipilih oleh pengimplementasikan perangkat untuk merujuk pada rilis tertentu, dalam format yang dapat dibaca manusia. Kolom ini boleh sama dengan android.os.Build.VERSION.INCREMENTAL, tetapi SEHARUSNYA menjadi nilai yang cukup berarti bagi pengguna akhir agar dapat membedakan berbagai 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 tentang format tertentu kolom ini, kecuali bahwa format ini TIDAK BOLEH berupa null atau string kosong (""). Kolom ini TIDAK BOLEH berubah selama masa pakai produk.
MODEL	Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama perangkat seperti yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama perangkat ini dipasarkan dan dijual kepada pengguna akhir. Tidak ada persyaratan tentang format tertentu kolom ini, kecuali bahwa format ini TIDAK BOLEH berupa null atau string kosong (""). Kolom ini TIDAK BOLEH berubah selama masa pakai produk.
PRODUK	Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama pengembangan atau nama kode produk tertentu (SKU) yang HARUS unik dalam merek yang sama. HARUS dapat dibaca manusia, tetapi tidak dimaksudkan untuk dilihat oleh pengguna akhir. Nilai 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 pakai produk.
SERI	HARUS menampilkan "UNKNOWN".
TAG	Daftar tag yang dipisahkan koma yang dipilih oleh penerapan perangkat yang akan lebih membedakan build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi penandatanganan platform Android umum: kunci rilis, kunci dev, kunci pengujian.
WAKTU	Nilai yang mewakili stempel waktu saat build terjadi.
TYPE	Nilai yang dipilih oleh pengimplementasi perangkat yang menentukan konfigurasi runtime build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android umum: user, userdebug, atau eng.
PENGGUNA	Nama atau ID pengguna pengguna (atau pengguna otomatis) yang membuat build. Tidak ada persyaratan untuk format khusus kolom ini, kecuali bahwa format tersebut TIDAK BOLEH berupa null atau string kosong ("").
PATCH_KEAMANAN	Nilai yang menunjukkan level patch keamanan build. Tanda ini HARUS menunjukkan bahwa build tersebut tidak rentan terhadap masalah apa pun yang dijelaskan melalui Buletin Keamanan Publik Android yang ditetapkan. Nilai ini HARUS dalam format [YYYY-MM-DD], yang cocok dengan string yang ditentukan dan didokumentasikan di Android Public Security Bulletin atau dalam Android Security Advisory, misalnya "2015-11-01".
OS_BASIS	Nilai yang mewakili parameter FINGERPRINT build yang identik dengan build ini, kecuali untuk patch yang disediakan dalam Android Public Security Bulletin. Aplikasi HARUS melaporkan nilai yang benar dan jika build tersebut tidak ada, laporkan string kosong ("").
BOOTLOADER	Nilai yang dipilih oleh pengimplementasi perangkat yang mengidentifikasi versi bootloader internal tertentu yang digunakan pada 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 (menjadi atau menampilkan) nilai yang dipilih oleh pengimplementasi perangkat yang mengidentifikasi versi radio/modem internal spesifik yang digunakan di perangkat, dalam format yang dapat dibaca manusia. Jika perangkat tidak memiliki radio/modem internal, perangkat HARUS menampilkan NULL. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler “^[a-zA-Z0-9._-,]+$”.
getSerial()	HARUS (atau mengembalikan) nomor seri hardware, yang HARUS tersedia dan unik di seluruh perangkat dengan MODEL dan MANUFACTURER 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 fungsionalitas dari komponen Android lainnya. Project upstream Android menyertakan daftar aplikasi yang dianggap sebagai aplikasi Android inti, yang mengimplementasikan beberapa pola intent untuk melakukan tindakan umum.

• [C-0-1] Implementasi perangkat HARUS melakukan pramuat 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
  • Penelusuran Global
  • Launcher
  • 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, untuk diganti oleh aplikasi pihak ketiga. Implementasi open source Android upstream mengizinkan hal ini secara default.

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

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

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

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

• [C-0-4] HARUS mencoba memvalidasi filter intent apa pun dengan melakukan 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 memvalidasi filter intent selama penginstalan aplikasi dan menyetel 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 berhasil diverifikasi, tetapi filter URI kandidat lainnya gagal dalam verifikasi. Jika penerapan perangkat melakukannya, penerapan tersebut HARUS memberikan penggantian pola per URI yang sesuai kepada pengguna di menu setelan.
• HARUS memberi pengguna kontrol Link Aplikasi per aplikasi di Setelan sebagai berikut:
  • [C-0-6] Pengguna HARUS dapat mengganti secara menyeluruh perilaku link aplikasi default untuk aplikasi: selalu terbuka, selalu bertanya, atau tidak pernah terbuka, yang harus berlaku untuk semua filter intent URI kandidat secara merata.
  • [C-0-7] Pengguna HARUS dapat melihat daftar filter intent URI kandidat.
  • Implementasi perangkat MUNGKIN memberi pengguna kemampuan untuk mengganti filter intent URI kandidat tertentu yang berhasil diverifikasi, berdasarkan filter per intent.
  • [C-0-8] Implementasi perangkat HARUS memberi pengguna kemampuan untuk melihat dan mengganti filter intent URI kandidat tertentu jika implementasi perangkat memungkinkan beberapa filter intent URI kandidat berhasil verifikasi sementara beberapa yang lain bisa gagal.

3.2.3.3. Namespace Intent

• [C-0-1] Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola intent siaran atau intent baru menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android. atau com.android..
• [C-0-2] Pengimplementasikan perangkat TIDAK BOLEH menyertakan komponen Android yang mematuhi pola intent siaran atau intent baru apa pun menggunakan ACTION, CATEGORY, atau string kunci lainnya dalam ruang paket milik organisasi lain.
• [C-0-3] Pengimplementasikan 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 MUNGKIN menyertakan pola intent menggunakan namespace yang jelas dan jelas terkait dengan organisasinya sendiri. Larangan ini serupa dengan yang ditetapkan untuk class bahasa Java di bagian 3.6.

3.2.3.4. Intent Siaran

Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan intent tertentu guna memberi tahu mereka tentang perubahan dalam 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 pasal 3.5 karena batasan untuk aplikasi latar belakang juga dijelaskan dalam dokumentasi SDK.

3.2.3.5. Setelan Aplikasi Default

Android menyertakan setelan yang memberi pengguna cara mudah untuk memilih aplikasi default, misalnya 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 ini.

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

• [C-1-1] HARUS mematuhi intent android.settings.HOME_SETTINGS untuk menampilkan menu setelan aplikasi default untuk Layar Utama.

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

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

• [C-2-2] HARUS mematuhi intent android.telecom.action.CHANGE_DEFAULT_DIALER untuk menampilkan dialog yang 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 untuk mengonfigurasi ConnectionServices yang terkait dengan PhoneAccounts, serta PhoneAccount default yang akan digunakan penyedia layanan telekomunikasi untuk melakukan panggilan keluar. Implementasi AOSP memenuhi persyaratan ini dengan menyertakan menu "Opsi Menelepon" dalam menu setelan "Panggilan".

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

• [C-3-1] HARUS mematuhi intent android.settings.NFC_PAYMENT_SETTINGS untuk menampilkan menu setelan aplikasi default untuk Tempel dan Bayar.

Jika implementasi perangkat mendukung VoiceInteractionService dan memiliki lebih dari satu aplikasi yang menggunakan API ini terinstal dalam satu waktu, implementasi tersebut:

• [C-4-1] HARUS mematuhi intent android.settings.ACTION_VOICE_INPUT_SETTINGS untuk menampilkan menu setelan aplikasi default untuk bantuan dan input suara.

3.2.4 Aktivitas di tampilan sekunder

Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal pada tampilan sekunder, implementasi tersebut:

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

Jika implementasi perangkat memungkinkan peluncuran Aktivitas Android normal pada tampilan sekunder serta tampilan 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 tampilan sekunder.

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

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

3.3. Kompatibilitas Native API

Kompatibilitas kode native sulit dilakukan. Karena alasan ini, pengimplementasi perangkat adalah:

• [SR] SANGAT DIREKOMENDASIKAN 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 mendefinisikan sejumlah Antarmuka Biner Aplikasi (ABI) dalam Android NDK.

Implementasi perangkat:

• [C-0-1] HARUS kompatibel dengan satu atau beberapa ABI yang ditetapkan dan mengimplementasikan kompatibilitas dengan Android NDK.
• [C-0-2] HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode native, menggunakan semantik standar Java Native Interface (JNI).
• [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 secara akurat Antarmuka Biner Aplikasi (ABI) native yang didukung perangkat, melalui parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, dan android.os.Build.SUPPORTED_64_BIT_ABIS, masing-masing daftar ABI yang dipisahkan koma yang diurutkan dari yang paling banyak ke yang paling tidak disukai.

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

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

  • [C-0-7] HARUS menyediakan semua library berikut, 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 (penaut dinamis)
  • libEGL.so (pengelolaan platform OpenGL native)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • {i>libjnigraphics.so<i}
  • liblog (logging Android)
  • libmediandk.so (dukungan API media native)
  • libm (perpustakaan matematika)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
  • libOpenSLES.so (Dukungan audio OpenSL ES 1.0.1)
  • libRS.so
  • mdpi++ (Dukungan minimal untuk C++)
  • libvulkan.so (Vulkan)
  • libz (Kompresi zlib)
  • Antarmuka JNI

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

• [C-0-9] HARUS mencantumkan library non-AOSP tambahan yang 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 dalam AOSP sebagai library sistem, untuk aplikasi pihak ketiga yang menargetkan API level 24 atau yang lebih tinggi, jika sudah dicadangkan.
• [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 rinci persyaratan untuk kapan implementasi penuh dari setiap fungsi yang sesuai diharapkan.
• [C-0-12] HARUS mengekspor simbol fungsi untuk simbol fungsi Vulkan 1.0 inti, 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 rinci persyaratan untuk kapan implementasi penuh dari setiap fungsi yang sesuai diharapkan.
• HARUS dibuat menggunakan kode sumber dan file header yang tersedia di Project Open Source Android upstream

Perhatikan bahwa rilis Android mendatang mungkin 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, penerapan tersebut:

• [C-2-1] HARUS menyertakan baris berikut di /proc/cpuinfo, dan TIDAK BOLEH mengubah nilai di perangkat yang sama, meskipun nilai tersebut 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 (mis., "8" untuk perangkat ARMv8).

• [C-2-2] HARUS selalu menyediakan operasi berikut, bahkan jika ABI diimplementasikan pada arsitektur ARMv8, baik melalui dukungan CPU native atau melalui emulasi perangkat lunak:

  • Petunjuk SWP dan SWPB.
  • SETEND.
  • Operasi barrier 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 android.webkit.Webview API lengkap, 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, seperti 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) MUNGKIN kosong, tetapi jika tidak kosong, string tersebut HARUS memiliki nilai yang sama dengan android.os.Build.MODEL.
  • "Build/$(BUILD)" MUNGKIN dihilangkan, tetapi jika ada, string $(BUILD) HARUS sama dengan nilai untuk android.os.Build.ID.
  • Nilai string $(CHROMIUM_VER) HARUS merupakan versi Chromium di Project Open Source Android upstream.
  • Penerapan perangkat MUNGKIN menghilangkan Seluler dalam string agen pengguna.

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

3.4.2 Kompatibilitas Browser

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

• [C-1-1] HARUS mendukung setiap API berikut yang terkait dengan HTML5:
  • operasi offline/cache aplikasi
  • Tag<video>
  • geolokasi
• [C-1-2] HARUS mendukung webstorage API HTML5/W3C dan SEHARUSNYA mendukung TensorFlow API HTML5/W3C. Perhatikan bahwa karena badan standar pengembangan web bertransisi untuk mendukung IndexedDB daripada webstorage, IndexedDB diharapkan menjadi komponen yang diperlukan dalam versi Android yang akan datang.
• DAPAT mengirimkan string agen pengguna kustom dalam aplikasi Browser mandiri.
• HARUS mengimplementasikan dukungan untuk HTML5 sebanyak mungkin di aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream atau penggantian pihak ketiga).

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

• [C-2-1] HARUS tetap mendukung pola niat publik sebagaimana 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 terinstal, kecuali jika aplikasi tersebut dibatasi seperti yang dijelaskan dalam Pasal 3.5.1.
• [C-0-10] TIDAK BOLEH menerapkan pendekatan pemberian izin yang memastikan kompatibilitas perilaku API hanya untuk aplikasi yang dipilih oleh pengimplementasi perangkat.

Perilaku setiap jenis API (terkelola, lunak, native, dan web) harus konsisten dengan implementasi pilihan Project Open Source Android upstream. Beberapa area kompatibilitas tertentu adalah:

• [C-0-1] Perangkat TIDAK BOLEH mengubah perilaku atau semantik intent standar.
• [C-0-2] Perangkat TIDAK BOLEH mengubah semantik siklus proses atau 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 diberlakukan pada aplikasi latar belakang. Lebih khususnya, untuk aplikasi latar belakang:
  • [C-0-4] Aplikasi harus berhenti mengeksekusi callback yang didaftarkan oleh aplikasi untuk menerima output dari GnssMeasurement dan GnssNavigationMessage.
  • [C-0-5], modul harus membatasi frekuensi update yang disediakan untuk aplikasi melalui class LocationManager API 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 ada 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 dalam daftar yang diizinkan sementara untuk menangani tugas yang terlihat oleh pengguna.
  • [C-0-8] jika aplikasi menargetkan API level 25 atau lebih tinggi, aplikasi HARUS melepaskan wakelock yang ditahan aplikasi.
• [C-0-9] Perangkat HARUS menampilkan penyedia keamanan berikut sebagai tujuh nilai array pertama dari metode Security.getProviders(), dalam urutan tertentu dan dengan nama yang diberikan (seperti yang ditampilkan oleh Provider.getName()) dan class, kecuali jika aplikasi telah mengubah daftar melalui insertProviderAt() atau removeProvider(). Perangkat MUNGKIN 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. AndroidKeyStoreBCSolution - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. SM - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

Daftar di atas tidak lengkap. Compatibility Test Suite (CTS) menguji sebagian besar platform untuk mengetahui kompatibilitas perilaku, tetapi tidak semuanya. Adalah tanggung jawab pengimplementasi untuk memastikan kompatibilitas perilaku dengan Project Open Source Android. Karena alasan ini, pengimplementasi perangkat HARUS menggunakan kode sumber yang tersedia melalui Proyek Open Source Android jika memungkinkan, daripada menerapkan kembali bagian penting dari sistem.

3.5.1 Pembatasan Latar Belakang

Jika implementasi perangkat mengimplementasikan pembatasan aplikasi yang disertakan dalam AOSP atau memperluas pembatasan aplikasi, pembatasan tersebut:

• [C-SR] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan pengguna yang memungkinkan pengguna 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 pembatasan secara otomatis tanpa bukti perilaku kesehatan sistem yang buruk, tetapi MUNGKIN menerapkan pembatasan pada aplikasi setelah mendeteksi perilaku kesehatan sistem yang buruk seperti wakelock bermasalah, layanan berjalan lama, dan kriteria lainnya. Kriteria ini DAPAT ditentukan oleh penerapan perangkat, tetapi HARUS terkait dengan dampak aplikasi terhadap kondisi sistem. Kriteria lain yang tidak sepenuhnya terkait dengan kesehatan sistem, seperti kurangnya popularitas aplikasi di pasar, TIDAK BOLEH digunakan sebagai kriteria.
• [C-1-4] HARUS tidak menerapkan pembatasan aplikasi secara otomatis untuk aplikasi saat pengguna menonaktifkan pembatasan aplikasi secara manual, dan MUNGKIN 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 atas yang secara eksplisit digunakan oleh pengguna.
• [C-1-8] HARUS menangguhkan pembatasan pada aplikasi yang menjadi aplikasi latar depan teratas jika pengguna secara eksplisit mulai menggunakan aplikasi yang sebelumnya dibatasi.

3.6. Namespace API

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

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

Artinya, mereka:

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

Pengimplementasi perangkat DAPAT memodifikasi implementasi yang mendasari API, tetapi modifikasi seperti ini:

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

Namun, pengimplementasi perangkat DAPAT menambahkan API kustom di luar namespace Android standar, sedangkan API kustom:

• [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 HARUS menambahkan API ke namespace perusahaan lain.
• [C-0-6] HARUS dikemas dalam library bersama Android sehingga hanya aplikasi yang secara eksplisit menggunakannya (melalui mekanisme <uses-library>) yang terpengaruh oleh peningkatan penggunaan memori API tersebut.

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

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

3,7 Kompatibilitas Runtime

Implementasi perangkat:

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

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

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

• HARUS menjalankan uji 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 ditetapkan di bawah ini dianggap sebagai nilai minimum dan implementasi perangkat DAPAT mengalokasikan lebih banyak memori per aplikasi.

Tata Letak Layar	Kepadatan Layar	Memori Aplikasi Minimum
Smartwatch Android	120 dpi (ldpi)	32MB
	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
large	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 yang menggantikan peluncur perangkat (layar utama).

Jika implementasi perangkat memungkinkan aplikasi pihak ketiga menggantikan layar utama perangkat, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan fitur platform android.software.home_screen.
• [C-1-2] HARUS menampilkan objek AdaptiveIconDrawable jika 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, implementasi tersebut:

• [C-2-1] HARUS melaporkan true untuk ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] HARUS memiliki kemampuan pengguna untuk menanyakan kepada pengguna sebelum menambahkan pintasan yang diminta oleh aplikasi melalui metode ShortcutManager.requestPinShortcut() API.
• [C-2-3] HARUS mendukung pintasan yang disematkan serta pintasan dinamis dan statis seperti yang didokumentasikan di halaman Pintasan Aplikasi.

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

• [C-3-1] HARUS melaporkan false untuk ShortcutManager.isRequestPinShortcutSupported().

Jika penerapan perangkat menerapkan peluncur default yang menyediakan akses cepat ke pintasan tambahan yang disediakan oleh aplikasi pihak ketiga melalui ShortcutManager API:

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

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

• [C-5-1] HARUS mematuhi metode API NotificationChannel.setShowBadge(). Dengan kata lain, tampilkan kemampuan visual yang terkait dengan ikon aplikasi jika nilainya ditetapkan sebagai true, dan jangan tampilkan skema badge ikon aplikasi apa pun saat semua saluran notifikasi aplikasi telah menetapkan nilai sebagai false.
• BOLEH mengganti badge ikon aplikasi dengan skema badge eksklusif jika aplikasi pihak ketiga menunjukkan dukungan skema badge eksklusif melalui penggunaan API eksklusif, tetapi HARUS menggunakan referensi dan nilai yang diberikan melalui API badge notifikasi yang dijelaskan di 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 terkait yang memungkinkan aplikasi menampilkan “AppWidget” kepada pengguna akhir.

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

• [C-1-1] HARUS mendeklarasikan dukungan untuk fitur platform android.software.app_widgets.
• [C-1-2] HARUS menyertakan dukungan bawaan untuk AppWidgets dan mengekspos kemampuan antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus AppWidgets secara langsung di dalam Peluncur.
• [C-1-3] HARUS mampu merender widget yang berukuran 4 x 4 dalam ukuran grid standar. Lihat Pedoman Desain Widget Aplikasi di dokumentasi Android SDK untuk mengetahui detailnya.
• MUNGKIN mendukung widget aplikasi di layar kunci.

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

• [C-2-1] HARUS melaporkan true untuk AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] HARUS memiliki kemampuan pengguna untuk menanyakan kepada pengguna sebelum menambahkan pintasan yang diminta oleh aplikasi melalui metode AppWidgetManager.requestPinAppWidget() API.

3.8.3 Notifikasi

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

3.8.3.1 Presentasi Notifikasi

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

• [C-1-1] HARUS mendukung notifikasi yang menggunakan fitur hardware, seperti dijelaskan dalam dokumentasi SDK, dan sejauh mungkin dengan hardware implementasi perangkat. Misalnya, jika implementasi perangkat menyertakan vibrator, implementasi tersebut HARUS mengimplementasikan API getaran dengan benar. Jika implementasi perangkat tidak memiliki hardware, API terkait HARUS diimplementasikan sebagai tanpa pengoperasian. Perilaku ini dijelaskan lebih lanjut di bagian 7.
• [C-1-2] HARUS merender dengan benar semua resource (ikon, file animasi, dsb.) yang disediakan dalam API, atau dalam panduan gaya ikon Status/Panel Sistem, meskipun resource tersebut MUNGKIN memberikan pengalaman pengguna alternatif untuk notifikasi dibandingkan dengan yang disediakan oleh implementasi Open Source Android referensi.
• [C-1-3] HARUS mematuhi dan menerapkan dengan benar perilaku yang dijelaskan untuk API dalam mengupdate, menghapus, dan mengelompokkan notifikasi.
• [C-1-4] HARUS memberikan perilaku lengkap NotificationChannel API yang didokumentasikan dalam SDK.
• [C-1-5] HARUS menyediakan affordance pengguna untuk memblokir dan memodifikasi notifikasi aplikasi pihak ketiga tertentu per setiap saluran dan level paket aplikasi.
• [C-1-6] HARUS juga menyediakan affordance pengguna untuk menampilkan saluran notifikasi yang dihapus.
• [C-1-7] HARUS merender dengan benar semua resource (gambar, stiker, ikon, dll.) yang diberikan melalui Notification.MessagingStyle bersama teks notifikasi tanpa interaksi pengguna tambahan. Misalnya, HARUS menampilkan semua resource termasuk ikon yang disediakan melalui android.app.Person dalam percakapan grup yang disetel melalui setGroup Conversation.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk secara otomatis menampilkan kemampuan pengguna untuk memblokir notifikasi aplikasi pihak ketiga tertentu per setiap saluran dan level paket aplikasi setelah pengguna menutup notifikasi tersebut beberapa kali.
• SEHARUSNYA mendukung notifikasi yang beragam.
• HARUS menyajikan beberapa notifikasi dengan prioritas yang lebih tinggi sebagai notifikasi pendahuluan.
• SEHARUSNYA memiliki kemampuan pengguna untuk menunda notifikasi.
• MUNGKIN hanya mengelola visibilitas dan waktu kapan aplikasi pihak ketiga dapat memberi tahu pengguna tentang peristiwa penting untuk mengurangi masalah keamanan seperti gangguan bagi 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 menyajikan setiap elemen resource (mis. ikon, judul, dan teks ringkasan) yang ditentukan dalam class Notification.Style API dan subclass-nya.

Jika implementasi perangkat mendukung notifikasi pendahuluan:

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

3.8.3.2. Layanan Pendengar Notifikasi

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

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

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

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

• [C-2-1] HARUS mencerminkan status notifikasi yang ditunda 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 aplikasi tersebut berasal dari layanan latar depan/persisten.

3.8.3.3. DND (Jangan Ganggu)

Jika implementasi perangkat mendukung fitur DND, implementasi tersebut:

• [C-1-1] HARUS menerapkan aktivitas yang akan merespons intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, yang HARUS berupa aktivitas yang memungkinkan pengguna memberikan atau menolak akses aplikasi ke konfigurasi kebijakan DND untuk implementasi dengan UI_MODE_TYPE_NORMAL.
• [C-1-2] HARUS, karena 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 aturan yang dibuat pengguna dan yang telah ditentukan sebelumnya.
• [C-1-3] HARUS mengikuti nilai suppressedVisualEffects yang diteruskan di NotificationManager.Policy dan jika aplikasi telah menyetel salah satu flag SUPPRESSED_Effect_SCREEN_OFF atau SUPPRESSED_Effect_SCREEN_ON, tindakan ini SEHARUS menunjukkan kepada pengguna bahwa efek visual disembunyikan di menu setelan DND.

3.8.4. Telusuri

Android menyertakan API yang memungkinkan developer menggabungkan penelusuran ke dalam aplikasi mereka dan mengekspos data aplikasi mereka ke dalam penelusuran sistem global. Secara umum, fungsi ini terdiri atas satu antarmuka pengguna untuk 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 aplikasinya sendiri dan memungkinkan developer memberikan hasil ke antarmuka pengguna penelusuran global umum.

• Implementasi perangkat Android SEHARUSNYA menyertakan penelusuran global, satu antarmuka pengguna penelusuran bersama, yang dapat digunakan di seluruh sistem untuk 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 aplikasi ini dijalankan dalam mode penelusuran global.

Jika tidak ada aplikasi pihak ketiga yang menggunakan penelusuran global:

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

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

Jika implementasi perangkat mendukung tindakan Assist, implementasi tersebut:

• [C-2-1] HARUS menunjukkan dengan jelas kepada pengguna akhir ketika konteks dibagikan, dengan:
  • Setiap kali aplikasi bantuan mengakses konteks, menampilkan cahaya putih di sekitar tepi layar yang memenuhi atau melebihi durasi dan kecerahan implementasi Project Open Source Android.
  • Untuk aplikasi bantuan bawaan, memberikan kemampuan pengguna kurang dari dua navigasi dari input suara default dan menu setelan aplikasi asisten, dan hanya membagikan konteks ketika aplikasi bantuan secara eksplisit dipanggil oleh pengguna melalui frasa pengaktif atau input tombol navigasi bantuan.
• [C-2-2] Interaksi yang ditetapkan untuk meluncurkan aplikasi bantuan seperti yang dijelaskan di bagian 7.2.3 HARUS meluncurkan aplikasi bantuan yang dipilih pengguna, dengan kata lain aplikasi yang menerapkan VoiceInteractionService, atau aktivitas yang menangani intent ACTION_ASSIST.

3.8.5. Pemberitahuan dan Toast

Aplikasi dapat menggunakan Toast API untuk menampilkan string non-modal pendek kepada pengguna akhir yang menghilang setelah beberapa waktu, 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 menyediakan affordance pengguna untuk memblokir aplikasi agar tidak menampilkan jendela pemberitahuan yang menggunakan TYPE_APPLICATION_OVERLAY . Implementasi AOSP memenuhi persyaratan ini dengan memiliki kontrol di menu notifikasi.

• [C-1-2] HARUS mematuhi Toast API dan menampilkan Toast dari aplikasi kepada pengguna akhir dengan 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 kelompok tema “Holo” dan "Material" sebagai kumpulan gaya yang ditentukan untuk digunakan developer aplikasi jika 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 apa pun yang diekspos ke aplikasi.
• [C-1-2] HARUS mendukung jenis tema “Material” dan TIDAK BOLEH mengubah atribut tema Material atau asetnya yang diekspos ke aplikasi.

Android juga menyertakan kelompok tema “Default Perangkat” sebagai serangkaian gaya yang ditentukan untuk digunakan oleh developer aplikasi jika ingin menyesuaikan tampilan dan nuansa tema perangkat seperti yang ditetapkan oleh pengimplementasikan perangkat.

• Implementasi perangkat DAPAT mengubah Atribut tema default Perangkat yang diekspos ke aplikasi.

Android mendukung tema varian dengan kolom sistem transparan, yang memungkinkan developer aplikasi mengisi area di belakang status dan menu navigasi dengan konten aplikasi mereka. Untuk memungkinkan 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 tersebut menunjukkan status bermasalah atau aplikasi meminta status bar lampu menggunakan flag SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
• [C-2-2] Implementasi perangkat Android HARUS mengubah warna ikon status sistem menjadi hitam (untuk detailnya, lihat R.style) saat aplikasi meminta status bar lampu.

3.8.7. Wallpaper Animasi

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

Hardware dianggap mampu menjalankan wallpaper animasi dengan andal jika dapat menjalankan semua wallpaper animasi, tanpa batasan fungsinya, pada kecepatan frame yang wajar tanpa efek buruk pada aplikasi lain. Jika batasan hardware menyebabkan wallpaper dan/atau aplikasi error, tidak berfungsi, mengonsumsi CPU atau daya baterai yang berlebihan, atau berjalan pada kecepatan frame yang sangat rendah, hardware dianggap tidak dapat menjalankan wallpaper animasi. Sebagai contoh, beberapa wallpaper animasi mungkin menggunakan konteks OpenGL 2.0 atau 3.x untuk merender kontennya. Wallpaper animasi tidak akan berjalan dengan andal pada hardware yang tidak mendukung beberapa konteks OpenGL karena penggunaan wallpaper animasi dari konteks OpenGL mungkin bertentangan dengan aplikasi lain yang juga menggunakan konteks OpenGL.

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

Jika implementasi perangkat menerapkan wallpaper animasi, implementasi tersebut:

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

3.8.8. Pengalihan Aktivitas

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

Implementasi perangkat termasuk tombol navigasi fungsi terbaru seperti yang dijelaskan di 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 setidaknya hingga 7 aktivitas yang ditampilkan.
• Setidaknya HARUS menampilkan judul 4 aktivitas sekaligus.
• [C-1-2] HARUS menerapkan perilaku penyematan ke layar dan memberikan menu setelan kepada pengguna untuk mengaktifkan/menonaktifkan fitur.
• HARUS menampilkan warna sorotan, ikon, judul layar dalam terbaru.
• SEHARUSNYA menampilkan kemampuan penutup ("x") tetapi MUNGKIN menundanya hingga pengguna berinteraksi dengan layar.
• HARUS terapkan pintasan untuk beralih dengan mudah ke aktivitas sebelumnya.
• HARUS memicu tindakan beralih cepat antara dua aplikasi yang terakhir 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 konten terbaru yang berafiliasi sebagai kelompok yang bergerak bersama.
• [SR] SANGAT DIREKOMENDASIKAN untuk menggunakan antarmuka pengguna Android upstream (atau antarmuka berbasis thumbnail serupa) bagi layar ringkasan.

3.8.9. Pengelolaan Input

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

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

• [C-1-1] HARUS mendeklarasikan fitur platform android.software.input_methods dan mendukung IME API seperti yang dijelaskan dalam dokumentasi SDK Android.
• [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:

• [C-2-1] HARUS menerapkan sepenuhnya API AutofillService dan AutofillManager serta mematuhi intent android.settings.REQUEST_SET_AUTOFILL_SERVICE untuk menampilkan menu setelan aplikasi default guna mengaktifkan dan menonaktifkan isi otomatis serta mengubah layanan isi otomatis default bagi pengguna.

3.8.10. Kontrol Media Layar Kunci

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

3.8.11. Screensaver (sebelumnya Dreams)

Android menyertakan dukungan untuk screensaver interaktif, yang sebelumnya disebut sebagai Dreams. Screensaver memungkinkan pengguna berinteraksi dengan aplikasi saat perangkat yang terhubung ke sumber daya tidak ada aktivitas atau dipasang ke dok di dok meja. Perangkat Android Watch MUNGKIN mengimplementasikan screensaver, tetapi jenis implementasi perangkat lainnya HARUS menyertakan dukungan untuk screensaver dan menyediakan opsi setelan bagi pengguna untuk mengonfigurasi screensaver sebagai respons terhadap intent android.settings.DREAM_SETTINGS.

3.8.12. Lokasi

Jika implementasi perangkat menyertakan sensor perangkat keras (mis. GPS) yang mampu memberikan koordinat lokasi, sensor tersebut

• [C-1-2] HARUS menampilkan status lokasi saat ini di menu Lokasi dalam Setelan.
• [C-1-3] TIDAK BOLEH menampilkan mode lokasi di menu Lokasi dalam Setelan.

3.8.13. Unicode dan Font

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

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

• [C-1-1] HARUS mampu merender karakter emoji ini dalam glyph warna.
• [C-1-2] HARUS menyertakan dukungan untuk:
  • Font Roboto 2 dengan bobot yang berbeda—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-kondensasi, sans-serif-kondensasi-light untuk bahasa yang tersedia pada perangkat.
  • Cakupan Unicode 7.0 lengkap dari Latin, Yunani, dan Cyrillic, termasuk rentang Latin Extended A, B, C, dan D, dan semua glyph dalam blok simbol mata uang Unicode 7.0.
• HARUS mendukung warna kulit dan beragam emoji keluarga 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 sekaligus, implementasi tersebut:

• [C-1-1] HARUS mengimplementasikan mode multi-aplikasi tersebut sesuai dengan perilaku aplikasi dan API yang dijelaskan dalam dokumentasi dukungan mode multi-aplikasi Android SDK dan penuhi persyaratan berikut:
• [C-1-2] Aplikasi dapat menunjukkan apakah aplikasi dapat beroperasi dalam mode multi-aplikasi di file AndroidManifest.xml, baik secara eksplisit melalui menyetel atribut android:resizeableActivity ke true atau secara implisit dengan menetapkan 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 menyetel atribut android:resizeableActivity ini MUNGKIN 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.
• Penerapan perangkat dengan ukuran layar xlarge SEHARUSNYA mendukung mode bentuk bebas.

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

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

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 jika aplikasi sedang: * 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 dalam SystemUI-nya seperti yang ditentukan oleh aktivitas PIP saat ini melalui setActions() API.
• [C-3-3] HARUS mendukung rasio aspek yang lebih besar dari atau sama dengan 1:2,39 dan kurang dari atau sama dengan 2,39:1, seperti yang ditentukan oleh aktivitas PIP melalui setAspectRatio() API.
• [C-3-4] HARUS menggunakan KeyEvent.KEYCODE_WINDOW untuk mengontrol jendela PIP; jika mode PIP tidak diterapkan, tombol HARUS tersedia untuk aktivitas latar depan.
• [C-3-5] HARUS menyediakan affordance pengguna untuk memblokir aplikasi agar tidak ditampilkan dalam mode PIP; implementasi AOSP memenuhi persyaratan ini dengan memiliki kontrol di menu 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 jika Configuration.uiMode dikonfigurasi sebagai UI_MODE_TYPE_TELEVISION.

3.8.15. Potongan Layar

Android mendukung Potongan Tampilan 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 potongan.
• [C-1-2] TIDAK BOLEH memiliki lebih dari satu potongan per tepi.
• [C-1-3] HARUS mematuhi tanda potongan layar yang ditetapkan oleh aplikasi melalui WindowManager.LayoutParams API seperti yang dijelaskan di SDK.
• [C-1-4] HARUS melaporkan nilai yang benar untuk semua metrik potongan yang ditentukan di DisplayCutout API.

3,9. Administrasi Perangkat

Android menyertakan fitur yang memungkinkan aplikasi sadar keamanan untuk menjalankan fungsi administrasi perangkat pada tingkat sistem, seperti menerapkan kebijakan sandi atau melakukan penghapusan total dari 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 sebagaimana dijelaskan di bagian 3.9.1 dan bagian 3.9.1.1.

3.9.1 Penyediaan Perangkat

3.9.1.1 Penyediaan pemilik perangkat

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

• [C-1-1] HARUS mendukung pendaftaran Klien Kebijakan Perangkat (DPC) sebagai aplikasi Pemilik Perangkat seperti yang dijelaskan di bawah:
  • Jika implementasi perangkat belum memiliki data pengguna yang dikonfigurasi, implementasi tersebut:
    • [C-1-3] HARUS melaporkan true untuk DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] HARUS mendaftarkan aplikasi DPC sebagai aplikasi Pemilik Perangkat sebagai respons terhadap tindakan intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] HARUS mendaftarkan aplikasi DPC sebagai aplikasi Pemilik Perangkat jika perangkat mendeklarasikan dukungan Komunikasi Nirkabel Jarak Dekat (NFC) melalui tombol fitur android.hardware.nfc dan menerima pesan NFC yang berisi data dengan jenis MIME MIME_TYPE_PROVISIONING_NFC.
  • Jika implementasi perangkat memiliki data pengguna, implementasi tersebut:
    • [C-1-6] HARUS melaporkan false untuk DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] HARUS mendaftarkan aplikasi DPC sebagai Aplikasi Pemilik Perangkat lagi.
• [C-1-2] HARUS mewajibkan beberapa tindakan afirmatif selama proses penyediaan untuk mengizinkan aplikasi ditetapkan sebagai Pemilik Perangkat. Izin dapat diperoleh melalui tindakan pengguna atau cara terprogram selama penyediaan, tetapi TIDAK BOLEH di-hard code atau mencegah penggunaan aplikasi Pemilik Perangkat lain.

Jika penerapan 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 "setara dengan Pemilik Perangkat" dengan "Pemilik Perangkat" standar seperti yang dikenali oleh API Device disusupi Android standar, aplikasi tersebut:

• [C-2-1] HARUS memiliki proses untuk memverifikasi bahwa aplikasi tertentu yang dipromosikan adalah milik solusi pengelolaan perangkat perusahaan yang sah dan sudah dikonfigurasi dalam solusi eksklusif agar memiliki hak yang setara sebagai "Pemilik Perangkat".
• [C-2-2] HARUS menampilkan pengungkapan izin Pemilik Perangkat AOSP yang sama dengan alur yang dimulai oleh android.app.action.PROVISION_MANAGED_DEVICE sebelum mendaftarkan aplikasi DPC sebagai "Pemilik Perangkat".
• MUNGKIN 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] Proses penyediaan profil terkelola (alur yang dimulai oleh android.app.action.PROVISION_MANAGED_PROFILE) pengalaman pengguna HARUS selaras dengan implementasi AOSP.

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

  • Ikon yang konsisten atau kemampuan pengguna lainnya (misalnya ikon info AOSP upstream) untuk mewakili saat setelan tertentu dibatasi oleh Device Admin.
  • Pesan penjelasan singkat, sebagaimana 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 pembuatan satu profil dan hanya satu profil terkelola.
• [C-1-3] HARUS menggunakan badge ikon (mirip dengan badge kerja upstream AOSP) untuk mewakili aplikasi dan widget terkelola serta elemen UI dengan badge lainnya seperti Terbaru & Notifikasi.
• [C-1-4] HARUS menampilkan ikon notifikasi (mirip dengan badge kerja upstream AOSP) untuk menunjukkan kapan 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 ada profil terkelola, HARUS menunjukkan kemampuan visual dalam 'Chooser' Intent agar pengguna dapat meneruskan intent dari profil terkelola ke pengguna utama atau sebaliknya, jika diaktifkan oleh Pengontrol Kebijakan Perangkat.
• [C-1-7] Jika ada profil terkelola, HARUS menampilkan kemampuan pengguna berikut untuk pengguna utama dan profil terkelola:
  • Pencatatan terpisah untuk baterai, lokasi, data seluler, dan penggunaan penyimpanan untuk pengguna utama dan profil terkelola.
  • Pengelolaan independen atas Aplikasi VPN yang diinstal dalam pengguna utama atau profil terkelola.
  • Pengelolaan independen atas aplikasi yang diinstal dalam pengguna utama atau profil terkelola.
  • Pengelolaan akun secara independen dalam pengguna utama atau profil terkelola.
• [C-1-8] HARUS memastikan aplikasi telepon, kontak, dan pesan yang sudah diinstal sebelumnya dapat mencari dan mencari informasi penelepon dari profil terkelola (jika ada) beserta informasi dari profil utama, jika Pengontrol Kebijakan Perangkat mengizinkannya.
• [C-1-9] HARUS memastikan bahwa profil tersebut memenuhi semua persyaratan keamanan yang berlaku untuk perangkat dengan beberapa pengguna yang diaktifkan (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 di profil terkelola.
  • Penerapan perangkat HARUS mematuhi intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD dan menampilkan antarmuka untuk mengonfigurasi kredensial layar kunci yang 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 berlaku hanya untuk kredensial layar kunci profil terkelola, kecuali jika dipanggil pada instance DevicePolicyManager yang ditampilkan oleh getParentProfileInstance.
• Jika kontak dari profil terkelola ditampilkan di log panggilan bawaan, UI dalam panggilan, notifikasi panggilan yang sedang berlangsung dan panggilan yang terlewat, aplikasi kontak dan pesan, kontak tersebut SEHARUSNYA diberi badge dengan badge yang sama dengan 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 multi-pengguna saat isLogoutEnabled menampilkan true. Kemampuan pengguna HARUS dapat diakses dari layar kunci tanpa membuka kunci perangkat.

3.10. Aksesibilitas

Android menyediakan lapisan aksesibilitas yang membantu pengguna difabel untuk membuka perangkat 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, respons haptik, dan navigasi trackball/d-pad.

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

• [C-1-1] HARUS menyediakan implementasi framework aksesibilitas Android seperti yang dijelaskan dalam dokumentasi SDK API aksesibilitas.
• [C-1-2] HARUS menghasilkan peristiwa aksesibilitas dan mengirim AccessibilityEvent yang sesuai ke semua implementasi AccessibilityService yang 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 bawaan.
• [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 SEHARUSNYA menyediakan affordance pengguna untuk mengontrol layanan aksesibilitas ini.

Jika implementasi perangkat menyertakan layanan aksesibilitas bawaan, implementasi 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 langsung bagi pengguna untuk mengaktifkan layanan aksesibilitas yang relevan, serta opsi untuk menyesuaikan ukuran font, ukuran layar, 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:

• [C-1-1] HARUS mendukung API framework Android TTS.

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

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

3.12. Framework Input TV

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

Jika implementasi perangkat mendukung TIF, implementasi tersebut:

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

3.13. Setelan Cepat

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

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 secara otomatis dari aplikasi pihak ketiga langsung ke Setelan Cepat.
• [C-1-3] HARUS menampilkan semua kartu yang ditambahkan pengguna dari aplikasi pihak ketiga bersama 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:

• [C-1-1] HARUS menampilkan ikon MediaItem dan ikon notifikasi tanpa diubah.
• [C-1-2] HARUS menampilkan item tersebut seperti yang dijelaskan oleh MediaSession, misalnya, metadata, ikon, gambar.
• [C-1-3] HARUS menampilkan judul aplikasi.
• [C-1-4] HARUS memiliki panel samping atau mekanisme lain untuk menampilkan hierarki MediaBrowser dan memberikan kemampuan pengguna untuk hierarki MediaBrowser.
• [C-1-5] HARUS mempertimbangkan mengetuk dua kali KEYCODE_HEADSETHOOK atau KEYCODE_MEDIA_PLAY_PAUSE sebagai KEYCODE_MEDIA_NEXT untuk MediaSession.Callback#onMediaButtonEvent.

3.15. Aplikasi Instan

Implementasi perangkat HARUS memenuhi persyaratan berikut:

• [C-0-1] Aplikasi Instan hanya HARUS diberi izin dengan android:protectionLevel yang disetel ke "instant".
• [C-0-2] Aplikasi Instan TIDAK BOLEH berinteraksi dengan aplikasi terinstal melalui intent implisit kecuali jika salah satu kondisi berikut terpenuhi:
  • Filter pola intent komponen terekspos dan memiliki CATEGORY_BROWSABLE
  • Tindakan adalah salah satu dari ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE
  • Target secara eksplisit diekspos dengan android:visibleToInstantApps
• [C-0-3] Aplikasi Instan TIDAK BOLEH berinteraksi secara eksplisit dengan aplikasi terinstal, kecuali jika komponen diekspos melalui android:visibleToInstantApps.
• [C-0-4] Aplikasi yang Diinstal TIDAK BOLEH melihat detail tentang Aplikasi Instan pada perangkat kecuali Aplikasi Instan secara eksplisit terhubung ke aplikasi yang diinstal.

3.16. Penyandingan Perangkat Pendamping

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

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

• [C-1-1] HARUS mendeklarasikan tombol fitur FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] HARUS memastikan API dalam paket android.companion diterapkan sepenuhnya.
• [C-1-3] HARUS memberikan kemampuan kepada pengguna untuk memilih/mengonfirmasi perangkat pendamping yang tersedia dan dapat digunakan.

3.17. Aplikasi Berat

Jika implementasi perangkat mendeklarasikan fitur FEATURE_CANT_SAVE_STATE, implementasi tersebut:

• [C-1-1] HARUS memiliki satu aplikasi terinstal saja yang menentukan cantSaveState yang berjalan di sistem dalam satu waktu. Jika pengguna keluar dari aplikasi tersebut tanpa keluar secara eksplisit (misalnya dengan menekan layar utama sambil meninggalkan aktivitas aktif sistem, bukan menekan kembali tanpa aktivitas aktif tersisa di sistem), implementasi perangkat HARUS memprioritaskan aplikasi tersebut di RAM seperti yang dilakukan untuk hal-hal lain yang diharapkan tetap berjalan, seperti layanan latar depan. Meskipun aplikasi semacam itu berjalan di latar belakang, sistem masih dapat menerapkan fitur pengelolaan daya ke aplikasi tersebut, seperti membatasi akses CPU dan jaringan.
• [C-1-2] HARUS menyediakan affordance 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 lain 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 SDK Android resmi.
• Karena persyaratan di atas mungkin sulit, implementasi perangkat DIREKOMENDASIKAN 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, serta penandatanganan JAR.
• [C-0-3] TIDAK BOLEH memperluas format .apk, Android Manifest, Dalvik bytecode, atau RenderScript dengan cara sedemikian rupa sehingga akan mencegah file tersebut diinstal dan berjalan dengan benar pada perangkat lain yang kompatibel.

• [C-0-4] TIDAK BOLEH mengizinkan aplikasi selain "installer data" saat ini agar paket dapat meng-uninstal aplikasi secara otomatis tanpa konfirmasi pengguna, seperti yang didokumentasikan di SDK untuk izin DELETE_PACKAGE. Satu-satunya pengecualian adalah aplikasi pemverifikasi 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:

  • ID ini HARUS mendeklarasikan izin REQUEST_INSTALL_PACKAGES atau memiliki android:targetSdkVersion yang ditetapkan ke 24 atau lebih rendah.
  • Aplikasi HARUS diberi izin oleh pengguna untuk menginstal aplikasi dari sumber tidak dikenal.

• HARUS menyediakan kemampuan pengguna untuk memberikan/mencabut izin menginstal aplikasi dari sumber tidak dikenal per aplikasi, tetapi MUNGKIN memilih untuk menerapkannya sebagai tanpa pengoperasian dan menampilkan RESULT_CANCELED untuk startActivityForResult(), jika implementasi perangkat tidak ingin memungkinkan pengguna memiliki pilihan ini. Namun, meskipun dalam kasus tersebut, pernyataan tersebut HARUS menunjukkan kepada pengguna alasan mengapa tidak ada pilihan semacam itu.

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

• HARUS menyediakan kemampuan pengguna untuk memilih meng-uninstal atau meluncurkan aplikasi pada dialog peringatan.

5. Kompatibilitas Multimedia

Implementasi perangkat:

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

Implementasi perangkat:

• HARUS menargetkan latensi codec minimum, dengan kata lain,
  • TIDAK BOLEH menggunakan dan menyimpan buffer input dan menampilkan buffer input hanya sekali diproses.
  • TIDAK BOLEH menyimpan buffer hasil dekode lebih lama dari yang ditentukan oleh standar (misalnya SPS).
  • TIDAK BOLEH berpegang pada buffer yang dienkode, lebih lama dari yang dibutuhkan oleh struktur GOP.

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

Harap diperhatikan bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan apa pun bahwa codec ini bebas dari paten pihak ketiga. Mereka yang berniat menggunakan kode sumber ini dalam produk perangkat keras atau perangkat lunak disarankan bahwa penerapan kode ini, termasuk dalam perangkat lunak sumber terbuka atau perangkat bersama, 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 dekode format audio berikut:

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

Jika implementasi perangkat mendukung decoding 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] Decoding HARUS dilakukan tanpa downmixing (misalnya stream 5.0 AAC harus didekode ke lima channel PCM, stream 5.1 AAC harus didekode ke enam channel PCM).
• [C-2-2] Metadata rentang dinamis HARUS seperti yang ditentukan dalam "Dynamic Range Control (DRC)" dalam ISO/IEC 14496-3, dan kunci DRC android.media.MediaFormat untuk mengonfigurasi perilaku terkait rentang dinamis dari dekoder audio. Kunci DRC AAC diperkenalkan di API 21, dan adalah: 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 DRC dan Loudness HARUS ditafsirkan dan diterapkan sesuai dengan Profil Kontrol Rentang Dinamis DRC MPEG-D DRC Level 1.
• [C-3-2] Decoder HARUS berperilaku sesuai dengan konfigurasi yang disetel dengan kunci android.media.MediaFormat berikut: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL dan KEY_AAC_DRC_EFFECT_TYPE.

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

• Mungkin mendukung kontrol kenyaringan dan rentang dinamis menggunakan 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 AKAN 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) ADTS AAC mentah (.aac, ADIF tidak didukung) MPEG-TS (.ts, tidak dapat dicari)
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+ yang ditingkatkan)	Dukungan untuk konten mono/stereo/5.0/5.1 dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
AAC ELD (AAC yang ditingkatkan dengan delay rendah)	Dukungan untuk konten mono/stereo dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
Amerika Serikat (ASC)	Dukungan untuk konten mono/stereo dengan frekuensi pengambilan sampel standar dari 7,35 hingga 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 hingga 12,2 kbps dengan sampel @ 8 kHz	3GPP (.3gp)
AMR-WB	9 kecepatan 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 hingga 44,1 kHz DIREKOMENDASIKAN pada perangkat dengan output 44,1 kHz, karena downsampler 48 hingga 44,1 kHz tidak menyertakan filter low-pass). 16-bit DIREKOMENDASIKAN; tidak ada dither yang diterapkan untuk 24-bit.	Khusus FLAC (.flac)
MP3	Konstan Mono/Stereo 8-320 Kbps (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	Ketik 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 (kecepatan hingga batas hardware). Perangkat HARUS mendukung frekuensi pengambilan sampel 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)
Mentah		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Gambar, Koleksi gambar, Urutan gambar	HEIF (.heif), HEIC (.heic)

5.1.7 Codec Video

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

Jika implementasi perangkat menyertakan dekoder video atau encoder:

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

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

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 refresh intra 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 yang Didukung/ Format Container
H.263		3GPP (.3gp) MPEG-4 (.mp4)
AVC H.264	Lihat bagian 5.2 dan 5.3 untuk mengetahui detailnya	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, hanya audio AAC, tidak dapat dicari, 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 bagian 5.2 dan 5.3 untuk mengetahui detailnya	WebM (.webm) Matroska (.mkv)
VP9	Lihat bagian 5.3 untuk mengetahui detailnya	WebM (.webm) Matroska (.mkv)

5.2. Encoding Video

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

• SEHARUSNYA TIDAK, pada dua jendela geser, lebih dari ~15% di atas kecepatan bit antara interval intraframe (I-frame).
• TIDAK BOLEH lebih dari ~100% di atas kecepatan bit pada jendela 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 tombol fitur android.hardware.camera.any, implementasi tersebut:

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

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

• [C-2-1] HARUS mendukung kecepatan bit yang dapat dikonfigurasi secara dinamis.
• HARUS mendukung kecepatan frame variabel, di mana encoder video HARUS menentukan durasi frame instan berdasarkan stempel waktu buffer input, dan mengalokasikan bucket bit-nya berdasarkan durasi 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 implementasi perangkat mendukung codec H.264, implementasi tersebut:

• [C-1-1] HARUS mendukung Profil Dasar Pengukuran Level 3. Namun, dukungan untuk ASO (Pemesanan Slice Arbitrer), FMO (Pengurutan Macroblock Fleksibel), dan RS (Slice Redundan) bersifat OPSIONAL. Selain itu, untuk mempertahankan kompatibilitas dengan perangkat Android lain, DIREKOMENDASIKAN bahwa ASO, FMO, dan RS tidak digunakan untuk Profil Dasar Pengukuran oleh encoder.
• [C-1-2] HARUS mendukung profil encoding video SD (Definisi Standar) di tabel berikut.
• HARUS mendukung Profil Utama Level 4.
• HARUS mendukung profil encoding video HD (Definisi Tinggi) seperti yang ditunjukkan dalam tabel berikut.

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

• [C-2-1] HARUS mendukung profil encoding dalam tabel berikut.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p	HD 1080p
Resolusi video	320x240 piksel	720x480 piksel	1280 x 720 px	1920 x 1080 px
Frekuensi gambar video	20 fps	30 fps	30 fps	30 fps
Kecepatan bit video	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

Jika implementasi perangkat mendukung codec VP8, implementasi tersebut:

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

Jika implementasi perangkat melaporkan dukungan encoding VP8 untuk video resolusi 720p atau 1080p melalui media API, 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, implementasi tersebut:

• HARUS mendukung penulisan file Matroska WebM.

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 streaming yang sama untuk semua codec VP8, VP9, H.264, dan H.265 secara real time dan hingga resolusi maksimum yang didukung oleh setiap codec pada perangkat.

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

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

5.3.1 MPEG-2

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

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

5.3.2 H.263

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

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

5.3.3. MPEG-4

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

• [C-1-1] HARUS mendukung Simple Profile Level 3.

5.3.4. H.264

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

• [C-1-1] HARUS mendukung Profil Utama Level 3.1 dan Profil Dasar Pengukuran. Dukungan untuk ASO (Pemesanan Slice Arbitrer), FMO (Pengurutan Macroblock Fleksibel), dan RS (Slice Redundan) bersifat OPSIONAL.
• [C-1-2] HARUS mampu mendekode video dengan profil SD (Definisi Standar) yang tercantum dalam tabel berikut dan dienkode dengan Profil Dasar Pengukuran dan Profil Utama Level 3.1 (termasuk 720p30).
• HARUS mampu mendekode video dengan profil HD (Definisi Tinggi) seperti yang ditunjukkan dalam tabel berikut.

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

• [C-2-1] HARUS mendukung profil decoding video HD 720p 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	320x240 piksel	720x480 piksel	1280 x 720 px	1920 x 1080 px
Frekuensi gambar video	30 fps	30 fps	60 fps	30 fps (60 fps^Televisi)
Kecepatan bit video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

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

• [C-1-1] HARUS mendukung tingkat Utama Profil Utama Level 3 dan 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 ditunjukkan dalam tabel berikut jika terdapat decoder hardware.

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

• [C-2-1] Implementasi perangkat HARUS mendukung setidaknya satu decoding H.265 atau VP9 untuk profil 720, 1080 dan UHD.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p	HD 1080p	UHD
Resolusi video	352 x 288 piksel	720x480 piksel	1280 x 720 px	1920 x 1080 px	3840x2160 piksel
Frekuensi gambar video	30 fps	30 fps	30 fps	30/60 fps (60 fps^Televisi dengan decoding 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, implementasi 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 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 fps^Televisi)	30 (60 fps^Televisi)
Kecepatan bit video	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

Jika implementasi perangkat mendukung codec VP9, implementasi tersebut:

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

Jika implementasi perangkat mendukung codec VP9 dan decoder hardware:

• [C-2-1] HARUS mendukung profil decoding HD seperti yang ditunjukkan 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 satu decoding 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	3840x2160 piksel
Frekuensi gambar video	30 fps	30 fps	30 fps	30 fps (60 fps^Televisi 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 SEHARUSNYA sejak Android 4.3, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi HARUS. Perangkat Android baru dan lama SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan yang tercantum sebagai SEHARUSNYA, 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 pengambilan sampel: 8000, 11025, 16000, 44100 Hz
  • Saluran: Mono

• [C-1-2] HARUS mengambil sampel dengan frekuensi sampel di atas tanpa up-sampling.

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

• HARUS mengizinkan pengambilan kualitas radio AM dan DVD dari konten audio mentah, yang memiliki karakteristik berikut:

  • Format: PCM Linear, 16-bit
  • Frekuensi pengambilan sampel: 22050, 48000 Hz
  • Saluran: Stereo

Jika implementasi perangkat memungkinkan pengambilan kualitas radio AM dan DVD dari konten audio mentah, implementasi tersebut:

• [C-2-1] HARUS menangkap tanpa up-sampling pada rasio apa pun yang lebih tinggi dari 16000:22050 atau 44100:48000.
• [C-2-2] HARUS menyertakan filter anti-aliasing yang sesuai untuk setiap up-sampling atau down-sampling.

5.4.2. Ambil foto 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 di salah satu frekuensi pengambilan sampel, 44100 dan 48000.
• [C-1-2] Secara default, HARUS menonaktifkan pemrosesan audio pengurangan bising saat merekam streaming audio dari sumber audio AudioSource.VOICE_RECOGNITION.
• [C-1-3] Secara default, HARUS menonaktifkan semua kontrol penguatan otomatis saat merekam streaming audio dari sumber audio AudioSource.VOICE_RECOGNITION.
• HARUS merekam streaming audio pengenalan suara dengan karakteristik amplitudo rata-rata versus frekuensi: khususnya, ±3 dB, dari 100 Hz hingga 4000 Hz.
• HARUS merekam streaming audio pengenalan suara dengan sensitivitas input diatur sedemikian rupa sehingga sumber level daya suara (SPL) 90 dB pada 1000 Hz menghasilkan RMS 2500 untuk sampel 16-bit.
• HARUS merekam streaming audio pengenalan suara sehingga tingkat amplitudo PCM secara linear melacak perubahan SPL input minimal dalam rentang 30 dB dari -18 dB hingga +12 dB hingga 90 dB SPL di mikrofon.
• HARUS merekam streaming audio pengenalan suara dengan total distorsi harmonik (THD) kurang dari 1% untuk 1 kHz pada level input SPL 90 dB di mikrofon.

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

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

5.4.3. Ambil untuk Mengubah Rute Pemutaran

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

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

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

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

5.5. Pemutaran Audio

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

5.5.1 Pemutaran Audio Raw

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

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

  • Format: PCM Linear, 16-bit, 8-bit, float
  • Saluran: Konfigurasi multisaluran, Stereo, Mono yang valid dengan maksimal 8 saluran
  • Frekuensi pengambilan sampel (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:

  • Frekuensi pengambilan sampel: 24000, 48000

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 implementasi visualizer API, 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:

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

5.6. Latensi Audio

Latensi audio adalah tunda waktu saat sinyal audio melewati sistem. Banyak kelas aplikasi yang mengandalkan latensi pendek untuk mencapai efek suara real-time.

Untuk tujuan bagian ini, gunakan definisi berikut:

• latensi output. Interval antara saat aplikasi menulis frame data berkode PCM dan saat suara yang sesuai disajikan ke lingkungan pada transduser atau sinyal pada perangkat meninggalkan perangkat melalui port dan dapat diamati secara eksternal.
• latensi cold output. Latensi output untuk frame pertama, saat sistem output audio tidak ada aktivitas dan dimatikan sebelum permintaan dibuat.
• latensi output berkelanjutan. Latensi output untuk frame berikutnya, setelah perangkat memutar audio.
• latensi input. Interval antara saat suara disajikan oleh lingkungan ke perangkat pada transduser atau sinyal di perangkat, memasuki perangkat melalui port dan saat aplikasi membaca frame yang sesuai dari data berkode PCM.
• kehilangan input. Bagian awal sinyal input yang tidak dapat digunakan atau tidak tersedia.
• latensi input cold. 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 menangkap audio.
• cold output jitter. Variabilitas di antara pengukuran terpisah dari nilai latensi output cold.
• cold input jitter. 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 buffer. Periode buffer memberikan waktu bagi aplikasi untuk memproses sinyal dan waktu bagi aplikasi untuk mengurangi perbedaan fase antara stream input dan output.
• API antrean buffer OpenSL ES PCM. Kumpulan OpenSL ES API terkait PCM dalam Android NDK.
• API audio native AAudio. Kumpulan AAudio API dalam Android NDK.
• Stempel waktu. Pasangan yang terdiri dari posisi frame relatif dalam sebuah streaming dan estimasi waktu saat frame tersebut masuk atau keluar dari pipeline pemrosesan audio di endpoint terkait. Lihat juga AudioTimestamp.

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

• [C-SR] Latensi output dingin 100 milidetik atau kurang
• [C-SR] Latensi output terus-menerus selama 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 OpenSL ES PCM dan API audio native AAudio, untuk latensi output berkelanjutan dan latensi output cold pada setidaknya satu perangkat output audio yang didukung, yaitu:

• [C-SR] SANGAT DIREKOMENDASIKAN untuk melaporkan audio latensi rendah dengan mendeklarasikan tombol fitur android.hardware.audio.low_latency.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan audio latensi rendah melalui AAudio API.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk memastikan bahwa untuk aliran data yang menampilkan AAUDIO_PERFORMANCE_MODE_LOW_LATENCY dari AAudioStream_getPerformanceMode(), nilai yang ditampilkan oleh AAudioStream_getFramesPerBurst() kurang dari atau sama dengan nilai yang ditampilkan oleh android.media.AudioManager.getProperty(String) untuk kunci properti AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

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

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

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

• [C-SR] Latensi input cold 100 md atau kurang.
• [C-SR] Latensi input terus-menerus selama 30 milidetik atau kurang.
• [C-SR] Latensi bolak-balik terus-menerus selama 50 milidetik atau kurang.
• [C-SR] Meminimalkan jitter input dingin.
• [C-SR] Batasi error dalam stempel waktu input, seperti yang ditampilkan oleh AudioRecord.getTimestamp atau AAudioStream_getTimestamp, ke +/- 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 decoder 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 Media Segment Format di bawah melalui protokol draf HTTP Live Streaming, Versi 7.

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

Format Segmen Media

Format segmen	Referensi	Dukungan codec yang diperlukan
Aliran Transpor MPEG-2	ISO 13818	Codec video: AVC H264 MPEG-4 SP MPEG-2 Lihat bagian 5.1.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 penyesuaian frame ADTS dan tag ID3	ISO 13818-7	Lihat bagian 5.1.1 untuk mengetahui detail tentang AAC dan variannya
WebVTT	WebVTT

RTSP (RTP, SDP)

Nama profil	Referensi	Dukungan codec yang diperlukan
AVC H264	RFC 6184	Lihat bagian 5.1.3 untuk mengetahui detail tentang AVC H264
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 detail tentang MPEG-4 SP
mpeg4-generik	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 yang Aman

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

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

Jika implementasi perangkat mendeklarasikan dukungan untuk Display.FLAG_SECURE dan mendukung protokol layar nirkabel, implementasi tersebut:

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

Jika implementasi perangkat mendeklarasikan dukungan untuk Display.FLAG_SECURE dan mendukung layar eksternal berkabel, 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 penerapan perangkat melaporkan dukungan untuk fitur android.software.midi melalui class android.content.pm.PackageManager, penerapan tersebut:

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

  • Mode host USB, bagian 7.7
  • Mode periferal USB, bagian 7.7
  • MIDI melalui Bluetooth LE yang bertindak dalam peran sentral, bagian 7.4.3

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

5.10. Audio Profesional

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

• [C-1-1] HARUS melaporkan dukungan untuk fitur android.hardware.audio.low_latency.
• [C-1-2] HARUS memiliki latensi audio bolak-balik berkelanjutan, seperti yang ditetapkan di bagian 5.6 Latensi Audio, HARUS 20 milidetik atau kurang dan HARUS 10 milidetik atau kurang pada 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 persyaratan latensi dan audio USB menggunakan antrean buffer PCM OpenSL ES dan API audio native AAudio.
• [SR] SANGAT DIREKOMENDASIKAN 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 gubernur CPU)
  • Beban stabil: NONAKTIF
• HARUS minimalkan ketidakakuratan jam audio dan penyimpangan relatif terhadap waktu standar.
• HARUS meminimalkan penyimpangan jam audio relatif terhadap CLOCK_MONOTONIC CPU saat keduanya aktif.
• HARUS minimalkan latensi audio pada transduser di perangkat.
• HARUS minimalkan latensi audio melalui audio digital USB.
• HARUS mendokumentasikan pengukuran latensi audio pada semua jalur.
• SEHARUSNYA meminimalkan jitter dalam waktu entri callback penyelesaian buffer audio, karena hal ini akan memengaruhi persentase bandwidth CPU penuh yang dapat digunakan oleh callback.
• HARUS menyediakan underrun audio (output) atau overrun (input) dalam penggunaan normal pada latensi yang dilaporkan.
• HARUS menyediakan nol perbedaan latensi antar-saluran.
• HARUS meminimalkan latensi rata-rata MIDI pada semua transpor.
• HARUS meminimalkan variabilitas latensi MIDI di bawah beban (jitter) pada semua transpor.
• HARUS memberikan stempel waktu MIDI yang akurat pada semua transpor.
• HARUS minimalkan derau sinyal audio pada transduser di perangkat, termasuk periode segera setelah cold start.
• SEHARUSNYA tidak menyediakan perbedaan jam audio antara sisi input dan output dari titik akhir yang sesuai, jika keduanya aktif. Contoh titik akhir yang sesuai mencakup mikrofon dan speaker di perangkat, atau input dan output colokan audio.
• HARUS menangani callback penyelesaian buffer audio untuk sisi input dan output titik akhir yang sesuai pada thread yang sama saat keduanya aktif, dan masukkan callback output segera setelah ditampilkan dari callback input. Atau jika tidak memungkinkan untuk menangani callback pada thread yang sama, maka masukkan callback output segera setelah memasukkan callback input untuk mengizinkan aplikasi memiliki waktu yang konsisten dari sisi input dan output.
• HARUS minimalkan perbedaan fase antara buffering audio HAL untuk sisi input dan output dari titik akhir yang terkait.
• HARUS minimalkan latensi sentuh.
• HARUS meminimalkan variabilitas latensi sentuh saat terjadi 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:

• [SR] SANGAT DIREKOMENDASIKAN untuk melaporkan dukungan fitur android.hardware.audio.pro melalui class android.content.pm.PackageManager.

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

• [C-2-1] HARUS memiliki latensi audio bolak-balik berkelanjutan sebesar 20 milidetik atau kurang melalui jalur colokan audio.
• [SR] SANGAT DIREKOMENDASIKAN untuk mematuhi bagian Spesifikasi perangkat seluler (colokan) pada Spesifikasi Headset Audio Berkabel (v1.1).
• Latensi audio bolak-balik berkelanjutan HARUS 10 milidetik atau kurang melalui jalur colokan audio.

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

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

Jika implementasi perangkat menyertakan port HDMI, implementasi tersebut:

• [C-4-1] HARUS mendukung output dalam stereo dan delapan saluran pada kedalaman 20-bit atau 24-bit dan 192 kHz tanpa kehilangan kedalaman bit atau resampling, setidaknya dalam satu konfigurasi.

5.11. Ambil untuk Belum Diproses

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

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

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

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

• [C-1-3] HARUS menunjukkan tingkat 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 tingkat amplitudo dalam rentang frekuensi tinggi: khususnya dari ±30 dB dari 7000 Hz hingga 22 KHz dibandingkan dengan rentang frekuensi menengah untuk masing-masing mikrofon yang digunakan untuk merekam sumber audio yang tidak diproses.

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

• [C-1-6] HARUS memiliki rasio sinyal-ke-noise (SNR) pada 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 self noise yang setara, A-weighted).

• [C-1-7] HARUS memiliki total distorsi harmonik (THD) kurang dari 1% untuk 1 kHZ pada tingkat input SPL 90 dB pada setiap mikrofon yang digunakan untuk merekam sumber audio yang belum diproses.

• HARUS tidak memiliki pemrosesan sinyal lainnya (mis. Kontrol Penguatan Otomatis, Filter Tingkat Tinggi, atau Pembatalan Echo) di jalur selain pengganda level untuk membawa level ke rentang yang diinginkan. Dengan kata lain:

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

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

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

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

6. Kompatibilitas Opsi dan Developer Tools

6.1. Developer Tools

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 dalam AOSP, yang dapat digunakan oleh developer aplikasi, termasuk dumpsys dan cmd stats.
  • [C-0-3] TIDAK BOLEH mengubah format atau isi peristiwa sistem perangkat (Batterystats , diskstats, sidik jari, graphicsstats, netstats, notifikasi, procstats) yang dicatat melalui perintah dumpsys.
  • [C-0-10] HARUS merekam, tanpa menghapus, dan membuat peristiwa berikut dapat diakses dan tersedia untuk perintah shell cmd stats dan class StatsManager System API.
    • ActivityForegroundStateDiubah
    • Anomali Terdeteksi
    • AppBreadcrumbDilaporkan
    • AppCrashTerjadi
    • AppStartTerjadi
    • TingkatBateraiDiubah
    • BatterySaverModeStateDiubah
    • BleScanResultReceived
    • BleScanStateDiubah
    • PengisianStateDiubah
    • DeviceIdleModeStateDiubah
    • ForegroundServiceStateDiubah
    • GpsScanStateDiubah
    • JobStateDiubah
    • PluggedStateDiubah
    • DijadwalkanJobStateDiubah
    • Status Layar Diubah
    • SyncStateDiubah
    • Real-Time Berlalu Sistem
    • {i>UidProcessStateDiubah<i}
    • WakelockStateDiubah
    • WakeupAlarm Terjadi
    • WifiLockStateDiubah
    • WifiMulticastLockStateDiubah
    • WifiScanStateDiubah
  • [C-0-4] HARUS menonaktifkan daemon adb sisi perangkat secara default dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Android Debug Bridge.
  • [C-0-5] HARUS mendukung adb aman. Android menyertakan dukungan untuk adb aman. adb aman memungkinkan adb pada host terautentikasi yang dikenal.

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

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

• Layanan Pemantau Debug Dalvik (ddms)

  • [C-0-7] HARUS mendukung semua fitur ddms seperti yang didokumentasikan dalam Android SDK. Karena ddms menggunakan adb, dukungan untuk ddms SEHARUSNYA tidak aktif secara default, 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 oleh aplikasi.
• SysTrace
  • [C-0-9] HARUS mendukung alat systrace seperti yang didokumentasikan di 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 tombol fitur android.hardware.vulkan.version, implementasi tersebut:

• [C-1-1] HARUS menyediakan affordance bagi developer aplikasi untuk mengaktifkan/menonaktifkan lapisan debug GPU.
• [C-1-2] HARUS, saat lapisan debug GPU diaktifkan, menghitung lapisan dalam library yang disediakan oleh alat eksternal (yaitu bukan bagian dari platform atau paket aplikasi) yang ditemukan dalam 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 Settings > About Device > Build Number.
• [C-0-2] HARUS menyembunyikan Opsi Developer secara default.
• [C-0-3] HARUS menyediakan mekanisme yang jelas yang tidak memberikan perlakuan istimewa kepada satu aplikasi pihak ketiga, bukan aplikasi lain untuk mengaktifkan Opsi Developer. HARUS menyediakan dokumen atau situs yang dapat dilihat oleh publik, yang menjelaskan cara mengaktifkan Opsi Developer. Dokumen atau situs ini HARUS bisa ditautkan dari dokumen Android SDK.
• SEHARUSNYA ada notifikasi visual berkelanjutan kepada pengguna saat Opsi Developer diaktifkan dan keamanan pengguna harus menjadi perhatian.
• MUNGKIN membatasi akses ke menu Opsi Developer untuk sementara, dengan menyembunyikan atau menonaktifkan menu secara visual, untuk mencegah gangguan bagi skenario yang mengkhawatirkan keselamatan pengguna.

7. Kompatibilitas Perangkat Keras

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

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

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

• [C-0-2] Definisi class lengkap (sebagaimana didokumentasikan oleh SDK) untuk API komponen HARUS tetap ditampilkan.
• [C-0-3] Perilaku API HARUS diimplementasikan sebagai tanpa pengoperasian dengan cara yang wajar.
• [C-0-4] Metode API HARUS menampilkan nilai null jika diizinkan oleh dokumentasi SDK.
• [C-0-5] Metode API HARUS menampilkan implementasi class tanpa pengoperasian, yang mana 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] Penerapan 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 saat persyaratan ini berlaku adalah API telepon: Bahkan pada perangkat non-ponsel, API ini harus diimplementasikan sebagai tanpa pengoperasian yang wajar.

7.1. Tampilan dan Grafis

Android menyertakan fasilitas yang otomatis menyesuaikan aset aplikasi dan tata letak UI secara tepat untuk perangkat guna memastikan bahwa 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 didefinisikan sebagai berikut:

• ukuran diagonal fisik. Jarak antara dua sudut yang berlawanan dari bagian layar yang terang dalam inci.
• titik per inci (dpi). Jumlah piksel yang dicakup oleh rentang horizontal atau vertikal linear 1”. Jika nilai dpi dicantumkan, dpi horizontal dan vertikal harus berada dalam rentang tersebut.
• rasio aspek. Rasio piksel dari dimensi yang lebih panjang terhadap dimensi layar yang lebih pendek. Misalnya, tampilan 480x854 piksel akan menjadi 854/480 = 1,779, atau kira-kira “16:9”.
• piksel kepadatan mandiri (dp). Unit piksel virtual dinormalkan ke layar 160 dpi, yang dihitung sebagai: piksel = dps * (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 membuat kueri 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, penerapan perangkat HARUS melaporkan dimensi layar piksel kepadatan mandiri (dp) logis yang benar seperti di bawah ini:

  • Perangkat dengan Configuration.uiMode yang ditetapkan sebagai nilai selain UI_MODE_TYPE_WATCH, dan melaporkan ukuran small untuk Configuration.screenLayout, HARUS memiliki minimal 426 dp x 320 dp.
  • Perangkat yang melaporkan ukuran normal untuk Configuration.screenLayout, HARUS memiliki minimal 480 dp x 320 dp.
  • Perangkat yang melaporkan ukuran large untuk Configuration.screenLayout, HARUS memiliki minimal 640 dp x 480 dp.
  • Perangkat yang melaporkan ukuran xlarge untuk Configuration.screenLayout, HARUS memiliki minimal 960 dp x 720 dp.

• [C-0-2] HARUS memenuhi dengan benar dukungan yang dinyatakan aplikasi untuk ukuran layar melalui atribut <supports-screens> di AndroidManifest.xml, seperti yang dijelaskan di dokumentasi Android SDK.

• MUNGKIN memiliki layar dengan sudut membulat.

Jika implementasi perangkat mendukung UI_MODE_TYPE_NORMAL dan menyertakan layar dengan sudut membulat, implementasi 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 tampilan layar fisik, rasio aspek layar tampilan logis tempat aplikasi pihak ketiga dirender, seperti yang dapat diperoleh 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 (sekitar 16:9), kecuali jika aplikasi dapat dianggap siap untuk diperluas lebih lama dengan memenuhi salah satu kondisi berikut:

  • Aplikasi telah menyatakan bahwa aplikasi mendukung rasio aspek layar yang lebih besar melalui nilai metadata android.max_aspect.
  • Aplikasi mendeklarasikan bahwa aplikasi dapat diubah ukurannya 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] Penerapan perangkat dengan Configuration.uiMode yang ditetapkan sebagai UI_MODE_TYPE_WATCH HARUS memiliki nilai rasio aspek yang ditetapkan 1,0 (1:1).

7.1.1.3. Kepadatan Layar

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

• [C-0-1] Secara default, implementasi perangkat HARUS melaporkan salah satu kepadatan framework Android logis berikut melalui DENSITY_DEVICE_STABLE API, dan nilai ini TIDAK BOLEH berubah kapan saja; namun, perangkat DAPAT melaporkan kepadatan arbitrer yang berbeda sesuai dengan perubahan konfigurasi tampilan yang dibuat oleh pengguna (misalnya, ukuran layar) 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 ukuran minimum yang didukung. Jika kepadatan framework Android standar yang secara numerik paling dekat dengan kepadatan fisik menghasilkan ukuran layar yang lebih kecil dari ukuran layar terkecil yang kompatibel dan didukung (lebar 320 dp), implementasi perangkat SEHARUS melaporkan kepadatan framework Android standar terendah berikutnya.

Jika ada affordance untuk mengubah ukuran layar perangkat:

• [C-1-1] Ukuran layar TIDAK BOLEH diskalakan lebih besar dari 1,5 kali kepadatan native atau menghasilkan dimensi layar minimum efektif yang lebih kecil dari 320 dp (setara dengan penentu resource sw320dp), mana saja yang lebih dulu.
• [C-1-2] Ukuran tampilan TIDAK BOLEH diskalakan lebih kecil dari 0,85 kali kepadatan native.
• Untuk memastikan kegunaan yang baik dan ukuran font yang konsisten, DIREKOMENDASIKAN untuk menyediakan penskalaan opsi Tampilan Native berikut (sekaligus mematuhi batas yang ditentukan di atas)
• Kecil: 0,85x
• Default: 1x (Skala tampilan native)
• Besar: 1,15x
• Lebih besar: 1,3x
• Terbesar 1,45x

7.1.2. Metrik Display

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

• [C-1-1] HARUS melaporkan nilai yang benar untuk semua metrik tampilan yang ditentukan di android.util.DisplayMetrics API.

Jika implementasi perangkat tidak menyertakan output video atau layar tersemat, 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 setidaknya satu orientasi yang didukung. Misalnya, perangkat dengan layar lanskap orientasi tetap, seperti televisi atau laptop, SEHARUSNYA hanya 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 untuk orientasi layar potret atau lanskap. Artinya, perangkat harus mengikuti permintaan aplikasi untuk orientasi layar tertentu.
• [C-1-2] TIDAK BOLEH mengubah kepadatan atau ukuran layar yang dilaporkan saat mengubah orientasi.
• MUNGKIN memilih orientasi potret atau lanskap sebagai default.

7.1.4. Akselerasi Grafis 2D dan 3D

7.1.4.1 OpenGL ES

Implementasi perangkat:

• [C-0-1] HARUS mengidentifikasi dengan benar versi OpenGL ES yang didukung (1.1, 2.0, 3.0, 3.1, 3.2) melalui API yang dikelola (seperti melalui 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 tercakup dan dijelaskan dalam dokumentasi Android SDK.
• [SR] SANGAT DIREKOMENDASIKAN 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 ekstensi OpenGL ES lain melalui API yang dikelola OpenGL ES dan API native lain yang telah mereka terapkan, 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 DIREKOMENDASIKAN untuk mendukung EGL_KHR_partial_update.
• HARUS melaporkan secara akurat melalui metode getString(), format kompresi tekstur apa pun yang didukungnya, yang biasanya spesifik per vendor.

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

• [C-3-1] HARUS mengekspor simbol fungsi yang sesuai untuk versi ini 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 Paket Ekstensi Android OpenGL ES secara keseluruhan.

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

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

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

• [C-6-1] juga HARUS mendukung ekstensi EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

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

Jika implementasi perangkat mendukung OpenGL ES 3.1, implementasi tersebut:

• [SR] SANGAT DIREKOMENDASIKAN untuk menyertakan dukungan bagi 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 tombol fitur android.hardware.vulkan.level dan android.hardware.vulkan.version.
• [C-1-2] HARUS menghitung, setidaknya satu VkPhysicalDevice untuk API native Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] HARUS menerapkan sepenuhnya API Vulkan 1.0 untuk setiap VkPhysicalDevice yang dienumerasi.
• [C-1-4] HARUS menghitung lapisan, yang terdapat dalam library native yang diberi nama libVkLayer*.so dalam 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 tersebut memiliki atribut android:debuggable yang ditetapkan sebagai true.
• [C-1-6] HARUS melaporkan semua string ekstensi yang didukungnya melalui API native Vulkan , dan sebaliknya TIDAK BOLEH melaporkan string ekstensi yang tidak didukung dengan benar.
• [C-1-7] HARUS mendukung ekstensi VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, dan VK_KHR_inkremental_present.

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

• [C-2-1] TIDAK BOLEH mendeklarasikan tanda 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 semafor eksternal dan jenis handle SYNC_FD.
• [SR] SANGAT DIREKOMENDASIKAN 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 menyetel 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 dengan akselerasi 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 Wide-gamut

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

• [C-1-1] HARUS memiliki layar dengan kalibrasi warna.
• [C-1-2] HARUS memiliki tampilan yang gamutnya mencakup gamut warna sRGB seluruhnya di ruang CIE 1931 xyY.
• [C-1-3] HARUS memiliki layar yang gamutnya memiliki area minimal 90% dari DCI-P3 di ruang CIE 1931 xyY.
• [C-1-4] HARUS mendukung OpenGL ES 3.1 atau 3.2 dan melaporkannya dengan benar.
• [C-1-5] HARUS mengiklankan dukungan untuk 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 DIREKOMENDASIKAN untuk mendukung GL_EXT_sRGB.

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

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

7.1.5. Mode Kompatibilitas Aplikasi Lama

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

7.1.6. Teknologi Layar

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

Implementasi perangkat:

• [C-0-1] HARUS mendukung layar yang mampu merender grafis berwarna 16-bit.
• HARUS dukung layar yang mampu menampilkan grafis berwarna 24-bit.
• [C-0-2] HARUS mendukung layar yang mampu merender animasi.
• [C-0-3] HARUS menggunakan teknologi tampilan 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 tampilan sekunder guna mengaktifkan kemampuan berbagi media dan API developer untuk mengakses tampilan eksternal.

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

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

7.2. Perangkat Input

Implementasi perangkat:

• [C-0-1] HARUS menyertakan mekanisme input, seperti layar sentuh atau navigasi non-sentuh, untuk menavigasi antar-elemen UI.

7.2.1. Keyboard

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

• [C-1-1] HARUS mendeklarasikan tombol fitur android.software.input_methods.
• [C-1-2] HARUS mengimplementasikan Input Management Framework sepenuhnya
• [C-1-3] HARUS punya keyboard software bawaan.

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

7.2.2. Navigasi Non-sentuh

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

Implementasi perangkat:

• [C-0-1] HARUS melaporkan nilai yang benar untuk android.content.res.Configuration.navigation.

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

• [C-1-1] HARUS menyediakan mekanisme antarmuka pengguna alternatif yang wajar untuk pemilihan dan pengeditan teks, kompatibel dengan Input Management Engine. 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 yang biasanya disediakan melalui interaksi dengan tombol fisik khusus atau bagian layar sentuh yang berbeda, sangat penting bagi 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 disetel dengan ACTION=MAIN dan CATEGORY=LAUNCHER atau CATEGORY=LEANBACK_LAUNCHER untuk implementasi perangkat Televisi. Fungsi Beranda SEHARUSNYA menjadi mekanisme untuk kemampuan pengguna ini.
• HARUS menyediakan tombol untuk fungsi Recents dan Back.

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

• [C-1-1] HARUS dapat diakses dengan satu tindakan (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 tercetak pada tombol, menampilkan ikon software di bagian menu navigasi layar, atau memandu pengguna melalui alur demo langkah demi langkah yang dipandu selama proses penyiapan siap pakai adalah contoh indikasi tersebut.

Implementasi perangkat:

• [SR] SANGAT DIREKOMENDASIKAN untuk tidak menyediakan mekanisme input untuk fungsi Menu karena tidak digunakan lagi dan digantikan oleh panel tindakan sejak Android 4.0.

Jika implementasi perangkat menyediakan fungsi Menu, implementasi tersebut:

• [C-2-1] HARUS menampilkan tombol tindakan tambahan bila pop-up menu tindakan tambahan tidak kosong dan panel tindakan terlihat.
• [C-2-2] TIDAK BOLEH memodifikasi posisi pop-up tindakan tambahan yang ditampilkan dengan memilih tombol tambahan dalam panel tindakan, tetapi MUNGKIN merender pop-up tindakan tambahan pada posisi yang dimodifikasi pada layar ketika 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 saat targetSdkVersion kurang dari 10, baik dengan tombol fisik, tombol software, atau gestur. Fungsi Menu ini harus dapat diakses kecuali jika disembunyikan bersama dengan fungsi navigasi lainnya.

Jika penerapan perangkat menyediakan fungsi Bantuan, penerapan 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 DIREKOMENDASIKAN untuk menggunakan fungsi tekan lama pada fungsi HOME sebagai interaksi yang ditentukan ini.

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

• [C-5-1] Tombol navigasi HARUS menggunakan bagian layar yang berbeda, tidak tersedia untuk aplikasi, dan TIDAK BOLEH mengaburkan atau mengganggu bagian layar yang tersedia untuk aplikasi.
• [C-5-2] HARUS menyediakan sebagian tampilan untuk aplikasi yang memenuhi persyaratan yang dijelaskan dalam pasal 7.1.1.
• [C-5-3] HARUS mematuhi flag 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. Penerapan perangkat berbasis layar sentuh dikaitkan dengan tampilan sedemikian rupa sehingga pengguna memiliki kesan memanipulasi item di layar secara langsung. Karena pengguna langsung menyentuh layar, sistem tidak memerlukan kemampuan tambahan untuk menunjukkan objek yang sedang dimanipulasi.

Implementasi perangkat:

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

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

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

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

• [C-2-1] HARUS melaporkan tombol 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) dan memenuhi persyaratan sentuh palsu di bagian 7.2.5, implementasi tersebut:

• [C-3-1] TIDAK BOLEH melaporkan tombol fitur apa pun yang dimulai dengan android.hardware.touchscreen dan HARUS melaporkan hanya android.hardware.faketouch.

7.2.5. Input Sentuhan Palsu

Antarmuka sentuh palsu menyediakan sistem input pengguna yang mendekati subset kemampuan layar sentuh. Misalnya, mouse atau remote control yang menggerakkan kursor pada layar mendekati sentuhan, tetapi mengharuskan pengguna untuk terlebih dahulu menunjuk atau memfokuskan kemudian mengklik. Banyak perangkat input seperti mouse, trackpad, air mouse berbasis giroskop, gyro-pointer, joystick, dan trackpad multi-sentuh dapat mendukung interaksi sentuh palsu. Android menyertakan konstanta fitur android.hardware.faketouch, yang sesuai dengan perangkat input non-sentuh (berbasis pointer) dengan fidelitas tinggi seperti mouse atau trackpad yang dapat secara memadai mengemulasi input berbasis sentuh (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 tombol 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 di lokasi pointer dan menampilkan pointer visual di layar.
• [C-1-2] HARUS melaporkan peristiwa sentuh dengan kode tindakan yang menentukan perubahan status yang terjadi pada pointer yang turun atau naik di layar.
• [C-1-3] HARUS mendukung pointer ke bawah dan ke atas pada objek di layar, yang memungkinkan pengguna mengemulasikan ketukan pada objek di layar.
• [C-1-4] HARUS mendukung pointer ke bawah, pointer ke atas, mengarahkan kursor ke bawah, lalu mengarahkan ke atas di tempat yang sama pada suatu objek di layar dalam batas waktu, yang memungkinkan pengguna untuk mengemulasikan ketukan dua kali pada suatu objek di layar.
• [C-1-5] HARUS mendukung pointer ke bawah pada titik arbitrer di layar, pointer bergerak ke titik arbitrer lainnya di layar, diikuti dengan pointer ke atas, yang memungkinkan pengguna untuk mengemulasikan gestur sentuh.
• [C-1-6] HARUS mendukung pointer ke bawah kemudian memungkinkan pengguna untuk dengan cepat memindahkan objek ke posisi yang berbeda pada layar dan kemudian pointer ke atas di layar, yang memungkinkan pengguna untuk melemparkan sebuah objek di layar.
• [C-1-7] HARUS melaporkan TOUCHSCREEN_NOTOUCH untuk kolom Configuration.touchscreen API.

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 lebih 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 5 yang berbeda (melacak tangan jari) atau lebih banyak input pointer sepenuhnya secara independen.

7.2.6. Dukungan Pengontrol Game

7.2.6.1. Pemetaan Tombol

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

• [C-1-1] HARUS memiliki {i>controller<i} atau kapal dengan {i>controller<i} terpisah di dalam kotak, yang akan menyediakan sarana untuk memasukkan semua peristiwa yang tercantum dalam tabel di bawah ini.
• [C-1-2] HARUS mampu memetakan peristiwa HID ke konstanta view.InputEvent Android terkaitnya seperti yang tercantum dalam tabel di bawah. Implementasi Android upstream menyertakan implementasi untuk pengontrol game yang memenuhi persyaratan ini.

Tombol	Penggunaan HID^2	Tombol Android
J^1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B^1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X^1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y^1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad atas^1 D-pad bawah^1	0x01 0x0039^3	AXIS_HAT_Y^4
D-pad kiri1 D-pad kanan^1	0x01 0x0039^3	AXIS_HAT_X^4
Tombol bahu kiri^1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Tombol bahu kanan^1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Klik stik kiri^1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Klik stik kanan^1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Beranda^1	0x0c 0x0223	KEYCODE_HOME (3)
Kembali^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

Kontrol Analog^1	Penggunaan HID	Tombol Android
Pemicu Kiri	Info tambahan 0x02 0x00C5	AXIS_LTRIGGER
Pemicu Kanan	0x02 0x00C4	AXIS_RTRIGGER
Joystick Kiri	0x01 0x0030 0x01 0x0031	AXIS_X 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 untuk perangkat tertentu.

7.3. Sensor

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

Implementasi perangkat:

• [C-0-1] HARUS melaporkan ada atau tidaknya sensor secara akurat per class android.content.pm.PackageManager.
• [C-0-2] HARUS menampilkan daftar akurat sensor yang didukung melalui SensorManager.getSensorList() dan metode serupa.
• [C-0-3] HARUS berperilaku wajar untuk semua API sensor lainnya (misalnya, dengan menampilkan true atau false yang sesuai saat aplikasi mencoba mendaftarkan pemroses, bukan 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, implementasi tersebut:

• [C-1-1] HARUS melaporkan semua pengukuran sensor menggunakan nilai (metrik) Sistem Satuan Internasional yang relevan untuk setiap jenis sensor seperti yang ditetapkan 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 sebesar 5 md + 2 * sample_time saat prosesor aplikasi aktif. Penundaan ini tidak termasuk penundaan pemfilteran.
• [C-1-3] HARUS melaporkan sampel sensor pertama dalam waktu 400 milidetik + 2 * sample_time sensor yang diaktifkan. Sampel ini boleh memiliki akurasi 0.

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

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

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

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

Daftar di atas tidak komprehensif; perilaku Android SDK yang didokumentasikan dan Dokumentasi Open Source Android tentang sensor dianggap otoritatif.

Beberapa jenis sensor bersifat komposit, artinya sensor tersebut dapat diambil dari data yang disediakan oleh satu atau beberapa sensor lainnya. (Contohnya termasuk sensor orientasi dan sensor akselerasi linear.)

Implementasi perangkat:

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

Jika implementasi perangkat menyertakan sensor komposit, implementasi 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, implementasi tersebut:

• [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 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 API Android.
• [C-1-4] HARUS mampu mengukur dari jatuh bebas sampai empat kali gravitasi(4g) atau lebih pada setiap sumbu.
• [C-1-5] HARUS memiliki resolusi minimal 12-bit.
• [C-1-6] HARUS memiliki standar deviasi tidak lebih dari 0,05 m/s^, di mana standar deviasi harus dihitung per sumbu pada sampel yang dikumpulkan selama periode minimal 3 detik pada frekuensi pengambilan sampel tercepat.
• [SR] DIREKOMENDASIKAN untuk mengimplementasikan sensor komposit TYPE_SIGNIFICANT_MOTION.
• [SR] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor TYPE_ACCELEROMETER_UNCALIBRATED jika kalibrasi akselerometer online tersedia.
• HARUS menerapkan sensor gabungan 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 karakteristiknya berubah selama siklus proses dan diberi kompensasi, serta mempertahankan parameter kompensasi setelah perangkat dimulai ulang.
• HARUS diberi kompensasi suhu.
• SEHARUSNYA juga 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 akan diterapkan:

• [C-2-1] Jumlah konsumsi daya mereka HARUS selalu kurang dari 4 mW.
• Setiap perangkat harus 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, implementasi tersebut:

• [C-3-1] HARUS menerapkan sensor komposit TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.
• HARUS menerapkan sensor komposit TYPE_GAME_ROTATION_VECTOR.
• [SR] Perangkat Android baru dan yang sudah ada SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor TYPE_GAME_ROTATION_VECTOR.

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

• [C-4-1] HARUS mengimplementasikan sensor komposit TYPE_ROTATION_VECTOR.

7.3.2. Magnetometer

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

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

• [C-1-1] HARUS mengimplementasikan sensor TYPE_MAGNETIC_FIELD.
• [C-1-2] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 10 Hz dan HARUS melaporkan peristiwa hingga setidaknya 50 Hz.
• [C-1-3] HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam API Android.
• [C-1-4] HARUS mampu 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 SEHARUSNYA memiliki nilai di bawah 200 μT, dengan menempatkan magnetometer jauh dari medan magnet dinamis (diinduksi arus) dan statis (diinduksi magnet).
• [C-1-6] HARUS memiliki resolusi yang sama atau lebih padat dari 0,6 μT.
• [C-1-7] HARUS mendukung kalibrasi online dan kompensasi bias iron keras, serta mempertahankan parameter kompensasi di antara perangkat dimulai ulang.
• [C-1-8] HARUS menerapkan kompensasi besi lunak—kalibrasi dapat dilakukan baik saat digunakan maupun selama produksi perangkat.
• [C-1-9] HARUS memiliki standar deviasi, dihitung per sumbu pada sampel yang dikumpulkan selama minimal 3 detik pada frekuensi sampling tercepat, tidak lebih besar dari 1,5 μT; HARUS memiliki standar deviasi tidak lebih besar dari 0,5 μT.
• HARUS menerapkan sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] Perangkat Android baru dan yang sudah ada SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor TYPE_MAGNETIC_FIELD_UNCALIBRATED.

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

• [C-2-1] HARUS mengimplementasikan sensor komposit TYPE_ROTATION_VECTOR.

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

• DAPAT menerapkan sensor TYPE_GEOMAGNETIC_ROTATION_VECTOR.

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

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

7.3.3. GPS

Implementasi perangkat:

• HARUS menyertakan penerima GPS/GNSS.

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

• [C-1-1] HARUS mendukung output lokasi pada kecepatan minimal 1 Hz jika diminta melalui LocationManager#requestLocationUpdate.
• [C-1-2] HARUS dapat menentukan lokasi dalam kondisi langit terbuka (sinyal kuat, multipath dapat diabaikan, HDOP < 2) dalam 10 detik (waktu cepat untuk perbaikan pertama), saat terhubung ke koneksi internet kecepatan data 0,5 Mbps atau lebih cepat. Persyaratan ini biasanya dipenuhi dengan penggunaan beberapa bentuk teknik GPS/GNSS Terbantu atau Prediksi untuk meminimalkan waktu penguncian GPS/GNSS (Data Bantuan mencakup Waktu Referensi, Lokasi Referensi, dan Ephemeris/Jam Satelit).
  • [C-1-6] Setelah membuat perhitungan lokasi seperti itu, implementasi perangkat HARUS menentukan lokasinya, di langit terbuka, dalam waktu 5 detik, saat permintaan lokasi di-restart, hingga satu jam setelah perhitungan lokasi awal, bahkan ketika permintaan selanjutnya dibuat tanpa koneksi data, dan/atau setelah siklus daya.

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

  • [C-1-3] HARUS dapat menentukan lokasi dalam jarak 20 meter, dan kecepatan dalam jarak 0,5 meter per detik, setidaknya 95% dari waktu.
  • [C-1-4] HARUS melacak dan melaporkan secara bersamaan melalui GnssStatus.Callback, setidaknya 8 satelit dari satu konstelasi.
  • HARUS dapat melacak setidaknya 24 satelit secara bersamaan, dari berbagai rasi bintang (misalnya GPS + setidaknya salah satu dari Glonass, Beidou, Galileo).
  • [C-1-5] HARUS melaporkan pembuatan teknologi GNSS melalui API pengujian 'getGnssYearOfHardware'.
  • [SR] Terus memberikan output lokasi GPS/GNSS normal selama panggilan telepon darurat.
  • [SR] Melaporkan pengukuran GNSS dari semua rasi bintang yang dilacak (seperti yang dilaporkan dalam pesan GnssStatus), kecuali SBAS.
  • [SR] Melaporkan AGC, dan Frekuensi pengukuran GNSS.
  • [SR] Melaporkan semua perkiraan akurasi (termasuk Bearing, Kecepatan, dan Vertikal) sebagai bagian dari setiap lokasi GPS/GNSS.
  • [SR] SANGAT DIREKOMENDASIKAN 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 tersebut ke aplikasi melalui tombol fitur android.hardware.location.gps dan LocationManager.getGnssYearOfHardware() Test API melaporkan tahun "2016" atau yang lebih baru, implementasi 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 tingkat pseudorange GNSS, bahwa, dalam kondisi langit terbuka setelah menentukan lokasi, sementara stasioner atau bergerak dengan percepatan kurang dari 0,2 meter per detik kuadrat, cukup untuk menghitung posisi dalam jarak 20 meter, dan kecepatan dalam jarak 0,2 meter per detik, setidaknya 95% dari waktu.

Jika implementasi perangkat menyertakan penerima GPS/GNSS dan melaporkan kemampuan tersebut ke aplikasi melalui tombol fitur android.hardware.location.gps dan LocationManager.getGnssYearOfHardware() Test API melaporkan tahun "2017" atau yang lebih baru, implementasi 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 perkiraan akurasi (termasuk Bearing, Kecepatan, dan Vertikal) sebagai bagian dari setiap lokasi GPS/GNSS.

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

• [C-4-1] HARUS terus memberikan output GPS/GNSS normal ke aplikasi selama panggilan sesi darurat yang dimulai pada Mobile Station-based (MS-Based).
• [C-4-2] HARUS melaporkan posisi dan pengukuran ke GNSS Location Provider API.

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, implementasi tersebut:

• [C-1-1] HARUS dapat melaporkan peristiwa hingga frekuensi setidaknya 50 Hz.
• [C-1-2] HARUS mengimplementasikan sensor TYPE_GYROSCOPE dan SEHARUSNYA juga mengimplementasikan sensor TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-3] HARUS mampu mengukur perubahan orientasi hingga 1.000 derajat per detik.
• [C-1-4] HARUS memiliki resolusi 12-bit atau lebih dan SEHARUSNYA memiliki resolusi 16-bit atau lebih.
• [C-1-5] HARUS diberi kompensasi suhu.
• [C-1-6] HARUS dikalibrasi dan diberi kompensasi saat digunakan, dan mempertahankan parameter kompensasi antara reboot perangkat.
• [C-1-7] HARUS memiliki varians tidak lebih besar dari 1e-7 rad^2 / s^2 per Hz (varian per Hz, atau rad^2 / s). Varian boleh bervariasi dengan frekuensi sampling, tetapi HARUS dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varians giroskop pada frekuensi sampling 1 Hz, seharusnya tidak lebih besar dari 1e-7 rad^2/s^2.
• [SR] Perangkat Android baru dan yang sudah ada SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor SENSOR_TYPE_GYROSCOPE_UNCALIBRATED.
• [SR] Error kalibrasi SANGAT DIREKOMENDASIKAN untuk kurang dari 0,01 rad/dtk ketika perangkat diam pada suhu kamar.
• HARUS melaporkan peristiwa hingga minimal 200 Hz.

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

• [C-2-1] HARUS mengimplementasikan sensor komposit TYPE_ROTATION_VECTOR.

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

• [C-3-1] HARUS menerapkan sensor komposit TYPE_GRAVITY dan TYPE_LINEAR_ACCELERATION.
• [SR] Perangkat Android baru dan yang sudah ada SANGAT DIREKOMENDASIKAN untuk mengimplementasikan sensor TYPE_GAME_ROTATION_VECTOR.
• HARUS menerapkan sensor komposit 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 event pada 5 Hz atau lebih.
• [C-1-3] HARUS diberi kompensasi suhu.
• [SR] SANGAT DIREKOMENDASIKAN untuk dapat melaporkan pengukuran tekanan dalam kisaran 300hPa hingga 1100hPa.
• HARUS memiliki akurasi 1hPa.
• HARUS memiliki akurasi relatif 0.12hPa di atas rentang 20hPa (setara dengan ~ 1 m akurasi lebih dari ~ 200 m perubahan di permukaan laut).

7.3.6. Thermometer

Implementasi perangkat: * MUNGKIN mencakup termometer sekitar (sensor suhu). * MUNGKIN, tetapi TIDAK BOLEH menyertakan sensor suhu CPU.

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

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

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

7.3.7. Fotometer

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

7.3.8. Sensor Kedekatan

• Implementasi perangkat MUNGKIN mencakup sensor kedekatan.

Jika implementasi perangkat menyertakan sensor kedekatan, implementasi tersebut:

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

7.3.9. Sensor Fidelitas Tinggi

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

• [C-1-1] HARUS mengidentifikasi kemampuan melalui tombol 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 setidaknya -8g dan +8g, SEHARUSNYA memiliki rentang pengukuran antara setidaknya -16g dan +16g.
  • HARUS memiliki resolusi pengukuran minimal 2048 LSB/g.
  • HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.
  • HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi; SEHARUSNYA mendukung SensorDirectChannel RATE_VERY_FAST.
  • HARUS memiliki derau pengukuran yang tidak di atas 400 μg/✓Hz.
  • HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 3000 peristiwa sensor.
  • HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 3 mW.
  • [C-SR] SANGAT DIREKOMENDASIKAN untuk memiliki bandwidth pengukuran 3 dB minimal 80% dari frekuensi Nyquist, dan spektrum white noise dalam bandwidth ini.
  • HARUS memiliki akselerasi acak yang kurang dari 30 μg ✓Hz yang diuji pada suhu kamar.
  • HARUS memiliki perubahan bias vs. suhu ≤ +/- 1 mg/°C.
  • HARUS memiliki garis non-linearitas terbaik ≤ 0,5%, dan perubahan sensitivitas vs. suhu ≤ 0,03%/C °.
  • HARUS memiliki sensitivitas lintas sumbu < 2,5 % dan variasi sensitivitas sumbu < 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 dp.
  • HARUS memiliki resolusi pengukuran minimal 16 LSB/dp.
  • HARUS memiliki frekuensi pengukuran minimum 12,5 Hz atau lebih rendah.
  • HARUS memiliki frekuensi pengukuran maksimum 400 Hz atau lebih tinggi; SEHARUSNYA mendukung SensorDirectChannel RATE_VERY_FAST.
  • HARUS memiliki derau pengukuran yang tidak di atas 0,014 °/s/{4}Hz.
  • [C-SR] SANGAT DIREKOMENDASIKAN untuk memiliki bandwidth pengukuran 3 dB minimal 80% dari frekuensi Nyquist, dan spektrum white noise dalam bandwidth ini.
  • HARUS memiliki kecepatan berjalan acak kurang dari 0,001 °/s }Hz yang diuji pada suhu kamar.
  • HARUS memiliki perubahan bias vs. suhu ≤ +/- 0,05 °/ s / °C.
  • HARUS memiliki perubahan sensitivitas vs. suhu ≤ 0,02% / °C.
  • HARUS memiliki garis non-linearitas terbaik ≤ 0,2%.
  • SEHARUSNYA memiliki kepadatan kebisingan ≤ 0,007 °/s/✓Hz.
  • HARUS memiliki kesalahan kalibrasi kurang dari 0,002 rad/dtk dalam rentang suhu 10 ~ 40 °C ketika perangkat diam.
  • HARUS memiliki sensitivitas g kurang dari 0,1 °/dtk/g.
  • HARUS memiliki sensitivitas lintas sumbu < 4,0 % dan variasi sensitivitas lintas sumbu < 0,3% dalam rentang suhu pengoperasian 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 yang tidak di atas 0,5 uT.

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

  • HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 600 peristiwa sensor.
  • [C-SR] SANGAT DIREKOMENDASIKAN untuk memiliki spektrum white noise dari 1 Hz hingga minimal 10 Hz saat kecepatan laporan 50 Hz atau lebih tinggi.

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

  • HARUS memiliki rentang pengukuran minimal antara 300 dan 1100 hPa.
  • HARUS memiliki resolusi pengukuran minimal 80 LSB/hPa.
  • HARUS memiliki frekuensi pengukuran minimum 1 Hz atau lebih rendah.
  • HARUS memiliki frekuensi pengukuran maksimum 10 Hz atau lebih tinggi.
  • HARUS memiliki derau pengukuran yang tidak lebih dari 2 Pa/✓Hz.
  • HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 300 peristiwa sensor.
  • HARUS memiliki konsumsi daya pengelompokan tidak lebih buruk dari 2 mW.
• [C-2-8] HARUS memiliki sensor TYPE_GAME_ROTATION_VECTOR yang:
  • HARUS mengimplementasikan bentuk non-bangun dari sensor ini dengan kemampuan buffering minimal 300 peristiwa sensor.
  • HARUS memiliki konsumsi daya pengelompokan 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 mengimplementasikan bentuk non-bangun dari 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 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 untuk peristiwa fisik yang sama yang dilaporkan oleh Akselerometer, Giroskop, dan Magnetometer HARUS dalam waktu 2,5 milidetik satu sama lain. Stempel waktu peristiwa untuk peristiwa fisik yang sama yang dilaporkan oleh Akselerometer dan Giroskop HARUS dalam waktu 0,25 milidetik satu sama lain.
• [C-2-14] HARUS memiliki stempel waktu peristiwa sensor Giroskop pada basis waktu yang sama dengan subsistem kamera dan dalam waktu 1 milidetik error.
• [C-2-15] HARUS mengirimkan sampel ke aplikasi dalam waktu 5 milidetik sejak data tersedia pada salah satu sensor fisik di atas ke aplikasi.
• [C-2-16] TIDAK BOLEH memiliki konsumsi daya yang lebih tinggi dari 0,5 mW saat perangkat statis dan 2,0 mW saat perangkat bergerak jika kombinasi apa pun dari sensor berikut diaktifkan:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] MUNGKIN memiliki sensor TYPE_PROXIMITY, tetapi jika ada, HARUS memiliki kemampuan buffer minimum 100 peristiwa sensor.

Perhatikan bahwa semua persyaratan konsumsi daya di bagian ini tidak mencakup konsumsi daya Prosesor Aplikasi. Jumlah ini mencakup daya yang diambil oleh seluruh rantai sensor—sensor, sirkuit pendukung, sistem pemrosesan sensor khusus, dll.

Jika implementasi perangkat menyertakan dukungan sensor langsung, implementasi tersebut:

• [C-3-1] HARUS mendeklarasikan dengan benar dukungan jenis saluran langsung dan tingkat rasio laporan langsung melalui API isDirectChannelTypeSupported dan getHighestDirectReportRateLevel.
• [C-3-2] HARUS mendukung setidaknya salah satu dari dua jenis saluran langsung sensor untuk semua sensor yang mendeklarasikan dukungan untuk saluran langsung sensor.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• HARUS mendukung pelaporan peristiwa melalui saluran langsung sensor untuk sensor utama (varian non-bangun) dari jenis berikut:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Sensor Biometrik

7.3.10.1. Sensor Sidik Jari

Jika implementasi perangkat menyertakan layar kunci yang aman, implementasi 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 API yang sesuai sepenuhnya seperti yang dijelaskan dalam dokumentasi Android SDK.
• [C-1-3] HARUS memiliki tingkat penerimaan palsu tidak lebih tinggi dari 0,002%.
• [SR] SANGAT DIREKOMENDASIKAN untuk memiliki tingkat penerimaan spoofing dan penipu tidak lebih tinggi dari 7%.
• [C-1-4] HARUS mengungkapkan bahwa mode ini mungkin kurang aman dibandingkan dengan PIN, pola, atau kata sandi yang kuat dan menyebutkan dengan jelas risiko pengaktifannya, jika tingkat penerimaan spoofing dan penipu lebih tinggi dari 7%.
• [C-1-5] Upaya pembatasan kapasitas HARUS dilakukan setidaknya selama 30 detik setelah lima kali uji coba palsu untuk verifikasi sidik jari.
• [C-1-6] HARUS memiliki implementasi keystore yang didukung perangkat keras, dan melakukan pencocokan sidik jari di Trusted Execution Environment (TEE) atau pada chip dengan saluran yang aman ke TEE.
• [C-1-7] HARUS memiliki semua data sidik jari yang dapat diidentifikasi dan diotentikasi 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 Proyek Open Source Android.
• [C-1-8] HARUS mencegah penambahan sidik jari tanpa terlebih dahulu membuat rantai kepercayaan dengan meminta pengguna mengonfirmasi sudah 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 mengaktifkan aplikasi pihak ketiga untuk membedakan di antara masing-masing sidik jari.
• [C-1-10] HARUS mematuhi tanda Device terafiliasi.KEYGUARD_DISABLE_FINGERPRINT.
• [C-1-11] Saat diupgrade dari versi yang lebih lama dari Android 6.0, data sidik jari harus dimigrasikan secara aman untuk memenuhi persyaratan di atas atau dihapus.
• [C-1-12] HARUS menghapus sepenuhnya semua data sidik jari yang dapat diidentifikasi untuk pengguna saat akun pengguna tersebut dihapus (termasuk melalui reset ke setelan pabrik).
• [C-1-13] HARUS mengizinkan akses yang tidak terenkripsi ke data sidik jari yang dapat diidentifikasi atau data apa pun yang berasal darinya (seperti embedding) ke Pemroses Aplikasi.
• [SR] SANGAT DIREKOMENDASIKAN untuk memiliki rasio penolakan palsu kurang dari 10%, seperti yang diukur di perangkat.
• [SR] SANGAT DIREKOMENDASIKAN untuk memiliki latensi di bawah 1 detik, yang diukur dari saat sensor sidik jari disentuh hingga layar terbuka 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 berbasis sidik jari dan menyediakannya untuk aplikasi pihak ketiga, sensor tersebut:

• [C-1-1] HARUS memiliki tingkat penerimaan palsu tidak lebih tinggi dari 0,002%.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk memiliki tingkat penerimaan spoofing dan penipu tidak lebih tinggi dari 7%.
• [C-1-2] HARUS mengungkapkan bahwa mode ini mungkin kurang aman dibandingkan dengan PIN, pola, atau kata sandi yang kuat dan menyebutkan dengan jelas risiko pengaktifannya, jika tingkat penerimaan spoofing dan penipu lebih tinggi dari 7%.
• [C-1-3] PERCOBAAN batas kapasitas minimal 30 detik setelah lima uji coba palsu untuk verifikasi biometrik - di mana uji coba palsu adalah uji coba dengan kualitas tangkapan yang memadai (ACQUIRED_GOOD) yang tidak cocok dengan biometrik yang terdaftar
• [C-1-4] HARUS memiliki implementasi keystore yang didukung perangkat keras, dan melakukan pencocokan biometrik di TEE atau di chip dengan saluran yang 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 Proyek Open Source Android.
• [C-1-6] HARUS mencegah penambahan biometrik baru tanpa terlebih dahulu membuat rantai kepercayaan dengan meminta pengguna mengonfirmasi sudah 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 mengaktifkan aplikasi pihak ketiga untuk membedakan antara pendaftaran biometrik.
• [C-1-8] HARUS mematuhi masing-masing tanda 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 tersebut dihapus (termasuk melalui reset ke setelan pabrik).
• [C-1-10] HARUS tidak mengizinkan akses yang tidak terenkripsi ke data biometrik yang dapat diidentifikasi atau data apa pun yang berasal darinya (seperti embedding) ke Prosesor Aplikasi di luar konteks TEE.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk memiliki rasio penolakan palsu kurang dari 10%, seperti yang diukur di perangkat.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk memiliki latensi di bawah 1 detik, yang diukur dari saat biometrik terdeteksi, hingga layar tidak terkunci, 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 untuk perangkat tertentu.

7.3.11.2. Mode Siang/Malam

Lihat Bagian 2.5.1 untuk mengetahui persyaratan untuk perangkat tertentu.

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 untuk perangkat tertentu.

7.3.11.5. Rem Parkir

Lihat Bagian 2.5.1 untuk mengetahui persyaratan untuk perangkat tertentu.

7.3.12. Sensor Pose

Implementasi perangkat:

• MUNGKIN mendukung sensor pose dengan 6 derajat kebebasan.

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

• [C-1-1] HARUS menerapkan dan melaporkan 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 berkaitan dengan melakukan panggilan suara dan mengirim pesan SMS melalui jaringan GSM atau CDMA. Meskipun panggilan suara ini mungkin atau mungkin tidak dialihkan, panggilan tersebut untuk tujuan Android yang dianggap independen dari konektivitas data apa pun yang mungkin diimplementasikan menggunakan jaringan yang sama. Dengan kata lain, API dan fungsi "telepon" Android secara khusus merujuk ke 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 aplikasi tersebut menggunakan jaringan seluler untuk konektivitas data.

• Android MUNGKIN digunakan pada perangkat yang tidak termasuk hardware telepon. Artinya, Android kompatibel dengan perangkat selain ponsel.

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

• [C-1-1] HARUS mendeklarasikan tombol fitur android.hardware.telephony dan 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 telepon, implementasi tersebut:

• [C-2-1] HARUS mengimplementasikan API lengkap sebagai tanpa pengoperasian.

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 dihentikan 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 telepon untuk pesan yang diblokir.
• [C-1-6] HARUS mengimplementasikan UI pengelolaan angka yang diblokir, yang dibuka dengan intent yang ditampilkan oleh metode TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] TIDAK BOLEH mengizinkan pengguna sekunder untuk melihat atau mengedit nomor yang diblokir di perangkat karena platform Android mengasumsikan pengguna utama memiliki kontrol penuh atas layanan telepon, satu instance, pada perangkat. Semua UI terkait pemblokiran HARUS disembunyikan untuk pengguna sekunder dan daftar yang diblokir HARUS tetap dipatuhi.
• HARUS migrasikan nomor yang diblokir ke penyedia saat perangkat diupdate ke Android 7.0.

7.4.1.2. API Telekomunikasi

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

• [C-1-1] HARUS mendukung ConnectionService API 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 dalam panggilan yang dilakukan oleh aplikasi pihak ketiga yang tidak mendukung fitur pembekuan yang ditentukan melalui CAPABILITY_SUPPORT_HOLD.

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

  Implementasi AOSP memenuhi persyaratan ini dengan notifikasi pendahuluan yang menunjukkan kepada pengguna bahwa menjawab sebuah panggilan masuk akan menyebabkan panggilan lainnya terputus.

• [C-SR] SANGAT DIREKOMENDASIKAN untuk melakukan pramuat aplikasi telepon default yang menampilkan entri log panggilan dan nama aplikasi pihak ketiga dalam log panggilannya saat aplikasi pihak ketiga menyetel kunci tambahan EXTRA_LOG_SELF_MANAGED_CALLS pada PhoneAccount-nya ke true.

• [C-SR] SANGAT DIREKOMENDASIKAN untuk menangani peristiwa KEYCODE_MEDIA_PLAY_PAUSE dan KEYCODE_HEADSETHOOK headset audio untuk android.telecom API seperti di bawah ini:
  • Panggil Connection.onDisconnect() saat penekanan singkat peristiwa tombol terdeteksi selama panggilan yang sedang berlangsung.
  • Panggil Connection.onAnswer() saat penekanan singkat peristiwa tombol terdeteksi selama panggilan masuk.
  • Panggil Connection.onReject() jika penekanan lama peristiwa tombol terdeteksi selama panggilan masuk.
  • Alihkan status nonaktif CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementasi perangkat:

• HARUS menyertakan dukungan untuk satu atau beberapa bentuk 802.11.

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

• [C-1-1] HARUS mengimplementasikan Android API yang sesuai.
• [C-1-2] HARUS melaporkan tombol fitur hardware android.hardware.wifi.
• [C-1-3] HARUS mengimplementasikan multicast API seperti yang dijelaskan dalam dokumentasi SDK.
• [C-1-4] HARUS mendukung multicast DNS (mDNS) dan TIDAK BOLEH memfilter paket mDNS (224.0.0.251) kapan pun operasinya, termasuk:
  • Bahkan saat layar tidak dalam status aktif.
  • Untuk implementasi perangkat Android Televisi, bahkan saat dalam status daya standby.
• [C-1-5] TIDAK BOLEH memperlakukan panggilan metode API WifiManager.enableNetwork() sebagai indikasi yang memadai untuk mengganti Network yang sedang aktif dan digunakan secara default untuk traffic aplikasi dan ditampilkan oleh metode ConnectivityManager API seperti getActiveNetwork dan registerDefaultNetworkCallback. Dengan kata lain, mereka MUNGKIN hanya menonaktifkan akses Internet yang disediakan oleh penyedia jaringan lainnya (misalnya data seluler) jika mereka berhasil memvalidasi bahwa jaringan Wi-Fi menyediakan akses Internet.
• [C-SR] SANGAT DIREKOMENDASIKAN saat metode ConnectivityManager.reportNetworkConnectivity() API dipanggil, untuk mengevaluasi kembali 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 DIREKOMENDASIKAN untuk mengacak alamat MAC sumber dan nomor urut frame permintaan pemeriksaan, sekali di awal setiap pemindaian, sementara STA terputus.
  • Setiap kelompok frame permintaan pemeriksaan yang terdiri dari satu pemindaian harus menggunakan satu alamat MAC yang konsisten (TIDAK BOLEH mengacak alamat MAC di tengah proses pemindaian).
  • Nomor urut permintaan penyelidikan harus melakukan iterasi seperti biasa (secara berurutan) di antara permintaan pemeriksaan dalam pemindaian.
  • Nomor urut permintaan penyelidikan harus melakukan pengacakan antara permintaan pemeriksaan terakhir dari pemindaian dan permintaan penyelidikan pertama dari pemindaian berikutnya.
• [C-SR] SANGAT DIREKOMENDASIKAN, meskipun STA tidak terhubung, untuk mengizinkan hanya elemen berikut dalam frame permintaan pemeriksaan:
  • Kumpulan Parameter SSID (0)
  • Kumpulan Parameter DS (3)

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

• [C-2-1] HARUS memberikan kemampuan pengguna untuk mengaktifkan/menonaktifkan nilai yang dibaca melalui metode API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implementasi perangkat:

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

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

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

7.4.2.2. Pengaturan Wi-Fi Tunneled Direct Link

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Wi-Fi Tunneled Direct Link Setup (TDLS) seperti yang dijelaskan dalam Dokumentasi Android SDK.

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

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

7.4.2.3. Wi-Fi Aware

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Wi-Fi Aware.

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

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

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

• [C-2-1] HARUS menerapkan API penemuan kontekstual: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm , dan onServiceDiscovered DalamRange.

7.4.2.4. Passpoint Wi-Fi

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Passpoint Wi-Fi.

Jika implementasi perangkat menyertakan dukungan untuk Passpoint Wi-Fi, implementasi 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 Seleksi Jaringan, seperti Layanan Iklan Generik (GAS) dan Protokol Kueri Jaringan Akses (ANQP).

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

• [C-2-1] Implementasi WifiManager API terkait Passpoint HARUS menampilkan UnsupportedOperationException.

7.4.2.5. Lokasi Wi-Fi (Waktu Round Trip Wi-Fi - RTT)

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Lokasi Wi-Fi.

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

• [C-1-1] HARUS mengimplementasikan WifiRttManager API seperti yang dijelaskan dalam dokumentasi SDK.
• [C-1-2] HARUS mendeklarasikan tombol fitur android.hardware.wifi.rtt.
• [C-1-3] HARUS mengacak alamat MAC sumber untuk setiap burst RTT yang dijalankan sementara antarmuka Wi-Fi tempat RTT dijalankan tidak terkait dengan Titik Akses.

7.4.3. Bluetooth

Jika implementasi perangkat mendukung profil Audio Bluetooth, implementasi tersebut:

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

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

• HARUS mendukung setidaknya 5 total perangkat terhubung.

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

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

Android menyertakan dukungan untuk Bluetooth dan Bluetooth Energi Rendah.

Jika implementasi perangkat menyertakan dukungan untuk Bluetooth dan Bluetooth 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. yang sesuai untuk perangkat.

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

• [C-3-1] HARUS mendeklarasikan fitur hardware android.hardware.bluetooth_le.
• [C-3-2] HARUS mengaktifkan Bluetooth API berbasis GATT (profil atribut umum) 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 ScanFilter API telah diterapkan.
• [C-3-4] HARUS melaporkan nilai yang benar untuk BluetoothAdapter.isMultipleAdvertisementSupported() guna menunjukkan apakah Iklan Hemat Energi didukung atau tidak.
• HARUS mendukung pemindahan logika pemfilteran ke chipset Bluetooth saat menerapkan ScanFilter API.
• HARUS mendukung pemindahan beban pemindaian batch ke chipset Bluetooth.

• HARUS mendukung multi-iklan dengan minimal 4 slot.

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

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

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

7.4.4. Komunikasi Nirkabel Jarak Dekat

Implementasi perangkat:

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

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

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

• [SR] SANGAT DIREKOMENDASIKAN agar mampu membaca dan menulis pesan NDEF serta data mentah melalui standar NFC berikut. Perhatikan bahwa meskipun standar NFC dinyatakan sebagai SANGAT DIREKOMENDASIKAN, Compatibility Definition untuk versi mendatang direncanakan untuk mengubahnya menjadi HARUS. Standar ini bersifat opsional dalam versi ini, tetapi akan diwajibkan pada versi mendatang. Perangkat lama dan baru yang menjalankan versi Android ini sangat dianjurkan untuk memenuhi persyaratan tersebut sekarang agar dapat melakukan upgrade ke rilis platform mendatang.

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

  • ISO 18092
  • LLCP 1.2 (ditentukan oleh Forum NFC)
  • SDP 1.0 (ditentukan oleh Forum NFC)
  • Protokol Push NDEF
  • SNEP 1.0 (ditentukan oleh Forum NFC)
• [C-1-4] HARUS menyertakan dukungan untuk Android Beam dan SEHARUSNYA mengaktifkan Android Beam secara default.
• [C-1-5] HARUS dapat mengirim dan menerima menggunakan Android Beam, jika Android Beam diaktifkan atau mode P2p NFC eksklusif lainnya diaktifkan.
• [C-1-6] HARUS mengimplementasikan server default SNEP. Pesan NDEF 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 P2P NDEF keluar ke server SNEP default saat Android Beam diaktifkan. Jika tidak ada server SNEP default yang ditemukan, klien HARUS mencoba untuk mengirim ke server NPP.
• [C-1-10] HARUS mengizinkan aktivitas latar depan untuk menetapkan pesan NDEF P2P keluar menggunakan android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback, dan android.nfc.NfcAdapter.enableForegroundNdefPush.
• HARUS menggunakan gestur atau konfirmasi di layar, seperti 'Sentuh untuk Melakukan Beam', sebelum mengirim pesan P2P NDEF keluar.
• [C-1-11] HARUS mendukung pengalihan Koneksi NFC ke Bluetooth jika perangkat mendukung Profil Dorong 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 Forum NFC. Implementasi tersebut HARUS menerapkan layanan LLCP penyerahan dengan nama layanan “urn:nfc:sn:handover” untuk menukar permintaan pengalihan/kumpulan data pilihan melalui NFC, dan HARUS menggunakan Profil Dorong Objek Bluetooth untuk transfer data Bluetooth yang sebenarnya. Untuk alasan lama (agar tetap kompatibel dengan perangkat Android 4.1), penerapan HARUS tetap menerima permintaan SNEP GET untuk menukar data pilihan/permintaan serah terima melalui NFC. Namun, penerapan itu sendiri TIDAK BOLEH mengirim permintaan SNEP GET untuk melakukan pengalihan koneksi.
• [C-1-13] HARUS polling semua teknologi yang didukung saat dalam mode penemuan NFC.
• HARUS berada dalam mode penemuan NFC saat perangkat aktif dengan layar aktif dan layar kunci tidak terkunci.
• HARUS mampu membaca kode batang dan URL (jika dienkode) produk Thinfilm NFC Barcode.

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

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

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

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

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

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

Jika implementasi perangkat mencakup 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, mereka:

• [C-4-1] HARUS mengimplementasikan Android API yang sesuai seperti yang didokumentasikan oleh Android SDK.
• [C-4-2] HARUS melaporkan com.nxp.mifare fitur 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 lebih bentuk jaringan data. Secara khusus, implementasi perangkat HARUS menyertakan dukungan untuk setidaknya satu standar data yang mampu mencapai 200 Kbit/dtk atau lebih besar. Contoh teknologi yang memenuhi persyaratan ini mencakup EDGE, HSPA, EV-DO, 802.11g, Ethernet, dan Bluetooth PAN.
• SEHARUSNYA juga menyertakan dukungan untuk setidaknya satu standar data nirkabel yang umum, seperti 802.11 (Wi-Fi), jika standar jaringan fisik (seperti Ethernet) adalah koneksi data utama.
• MUNGKIN mengimplementasikan lebih dari satu bentuk konektivitas data.
• [C-0-2] HARUS menyertakan stack jaringan IPv6 dan mendukung komunikasi IPv6 menggunakan API yang dikelola, 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 dapat diandalkan seperti IPv4, misalnya:
  • [C-0-4] HARUS mempertahankan konektivitas IPv6 dalam mode istirahat.
  • [C-0-5] Pembatasan kapasitas TIDAK BOLEH menyebabkan perangkat kehilangan konektivitas IPv6 pada jaringan IPv6 yang sesuai dengan yang menggunakan masa aktif RA minimal 180 detik.
• [C-0-6] HARUS menyediakan aplikasi pihak ketiga dengan konektivitas IPv6 langsung ke jaringan ketika terhubung ke jaringan IPv6, tanpa bentuk alamat atau terjemahan port apa pun yang terjadi secara lokal pada perangkat. Baik API terkelola, seperti Socket#getLocalAddress atau Socket#getLocalPort) maupun NDK API seperti getsockname() atau IPV6_PKTINFO HARUS menampilkan alamat IP dan port yang benar-benar 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, implementasi tersebut:

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

Jika implementasi perangkat mendukung Ethernet, implementasi tersebut:

• [C-2-1] HARUS mendukung operasi dual-stack pada Ethernet.

Jika implementasi perangkat mendukung data Seluler, implementasi tersebut:

• HARUS mendukung operasi IPv6 (IPv6-saja dan mungkin dual-stack) pada seluler.

Jika implementasi perangkat mendukung lebih dari satu jenis jaringan (misalnya, Wi-Fi dan data seluler), perangkat tersebut:

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

7.4.6. Setelan Sinkronisasi

Implementasi perangkat:

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

7.4.7. Penghemat Data

Jika implementasi perangkat menyertakan koneksi berkuota, implementasi tersebut adalah:

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

Jika implementasi perangkat menyediakan mode penghemat data, implementasi tersebut:

• [C-1-1] HARUS mendukung semua API di class ConnectivityManager seperti yang dijelaskan dalam dokumentasi SDK
• [C-1-2] HARUS menyediakan antarmuka pengguna di setelan, yang menangani intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, sehingga pengguna dapat menambahkan aplikasi ke atau menghapus aplikasi dari daftar yang diizinkan.

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

7.4.8. Elemen Pengaman

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

• [C-1-1] HARUS menghitung pembaca Elemen Aman yang tersedia saat metode android.se.omapi.SEService.getReaders() dipanggil.

7.5. Kamera

Jika implementasi perangkat menyertakan setidaknya satu kamera, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan tombol fitur android.hardware.camera.any.
• [C-1-2] HARUS memungkinkan bagi aplikasi untuk secara bersamaan mengalokasikan 3 bitmap RGBA_8888 sama dengan ukuran gambar yang dihasilkan oleh sensor kamera resolusi terbesar pada perangkat, saat kamera terbuka untuk tujuan pratinjau dasar dan masih menangkap.

7.5.1. Kamera Belakang

Kamera belakang adalah kamera yang terletak di sisi perangkat berlawanan dengan layar; yaitu, kamera merekam pemandangan di sisi jauh perangkat, seperti kamera tradisional.

Implementasi perangkat:

• HARUS dilengkapi dengan kamera belakang.

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

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

Jika kamera menyertakan flash:

• [C-2-1] lampu flash TIDAK BOLEH menyala saat instance android.hardware.Camera.PreviewCallback telah terdaftar di platform pratinjau Kamera, kecuali 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 membuat gambar pengguna, seperti untuk konferensi video dan aplikasi serupa.

Implementasi perangkat:

• Mungkin menyertakan kamera depan.

Jika implementasi perangkat menyertakan setidaknya satu kamera depan, implementasi tersebut:

• [C-1-1] HARUS melaporkan tombol fitur android.hardware.camera.any dan android.hardware.camera.front.
• [C-1-2] HARUS memiliki resolusi minimal VGA (640x480 piksel).
• [C-1-3] TIDAK BOLEH menggunakan kamera depan sebagai default untuk Camera API dan TIDAK BOLEH mengonfigurasi API untuk memperlakukan kamera depan sebagai kamera belakang default, meskipun itu adalah satu-satunya kamera pada perangkat.
• [C-1-4] Pratinjau kamera HARUS dicerminkan secara horizontal sesuai dengan orientasi yang ditentukan oleh aplikasi saat aplikasi saat ini secara eksplisit meminta agar tampilan 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 streaming video atau gambar diam akhir yang diambil dan dikembalikan ke callback aplikasi atau ditujukan untuk penyimpanan media.
• [C-1-6] HARUS mencerminkan gambar yang ditampilkan oleh tampilan pos 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 di bagian 7.5.1.

Jika implementasi perangkat dapat dirotasi oleh pengguna (seperti secara otomatis melalui akselerometer atau secara manual melalui input pengguna):

• [C-2-1] Pratinjau kamera HARUS dicerminkan secara horizontal sesuai dengan orientasi perangkat saat ini.

7.5.3. Kamera Eksternal

Implementasi perangkat:

• Mungkin mencakup dukungan untuk kamera eksternal yang tidak selalu terhubung.

Jika implementasi perangkat menyertakan dukungan untuk kamera eksternal, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan tombol fitur platform android.hardware.camera.external dan android.hardware camera.any.
• [C-1-2] HARUS mendukung USB Video Class (UVC 1.0 atau lebih tinggi) jika kamera eksternal terhubung melalui port host USB.
• [C-1-3] HARUS lulus uji 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 mengaktifkan transfer streaming berkualitas tinggi yang tidak dienkode (yaitu streaming gambar mentah atau yang dikompresi secara terpisah).
• MUNGKIN mendukung beberapa kamera.
• Mungkin mendukung encoding video berbasis kamera.

Jika encoding video berbasis kamera didukung:

• [C-2-1] Streaming yang tidak dienkode / MJPEG secara bersamaan (resolusi QVGA atau lebih besar) HARUS dapat diakses oleh implementasi perangkat.

7.5.4. Perilaku Camera API

Android menyertakan dua paket API untuk mengakses kamera. API android.hardware.camera2 yang lebih baru mengekspos kontrol kamera tingkat rendah ke aplikasi, termasuk alur burst/streaming nol salinan yang efisien serta kontrol eksposur, penguatan, keseimbangan white balance, konversi warna, denoise, penajaman, dan lainnya.

Paket API lama, android.hardware.Camera, ditandai sebagai tidak digunakan lagi di Android 5.0, tetapi masih harus tersedia untuk digunakan oleh aplikasi. Implementasi perangkat Android HARUS memastikan dukungan berkelanjutan atas API seperti yang dijelaskan di bagian ini dan di Android SDK.

Semua fitur umum di 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 diharuskan memiliki kecepatan atau kualitas yang cocok, tetapi HARUS memiliki kecocokan 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 saat aplikasi tidak pernah memanggil android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] Selanjutnya HARUS dalam format encoding NV21 saat aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() dan format pratinjaunya adalah YCbCr_420_SP, data dalam byte[] yang diteruskan ke onPreviewFrame(). Artinya, NV21 HARUS menjadi default.
• [C-0-3] HARUS mendukung format YV12 (sebagaimana ditunjukkan oleh konstanta android.graphics.ImageFormat.YV12) untuk pratinjau kamera bagi kamera depan dan belakang untuk android.hardware.Camera. (Encoder dan kamera video 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] Tetap harus 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 memanggil instance android.hardware.Camera.AutoFocusCallback yang terdaftar (meskipun ini tidak memiliki relevansi 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 tetap harus "palsu" seperti yang dijelaskan.
• [C-0-6] HARUS mengenali dan mematuhi setiap nama parameter yang ditetapkan sebagai konstanta di class android.hardware.Camera.Parameters. Sebaliknya, implementasi perangkat TIDAK BOLEH mengikuti 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 memungkinkan, dan TIDAK BOLEH mendukung jenis parameter Kamera kustom. Misalnya, implementasi perangkat yang mendukung pengambilan gambar menggunakan teknik pencitraan rentang dinamis tinggi (HDR) HARUS mendukung parameter kamera Camera.SCENE_MODE_HDR.
• [C-0-7] HARUS melaporkan tingkat dukungan yang tepat dengan properti android.info.supportedHardwareLevel seperti yang dijelaskan dalam Android SDK dan melaporkan tanda fitur framework yang sesuai.
• [C-0-8] Juga HARUS mendeklarasikan kemampuan kamera masing-masing android.hardware.camera2 melalui properti android.request.availableCapabilities dan mendeklarasikan tombol fitur yang sesuai; HARUS menentukan tombol fitur jika salah satu perangkat kamera yang terpasang 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 DIREKOMENDASIKAN 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, 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 selaras 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 MUNGKIN digunakan aplikasi untuk mendownload file data dan aplikasi HARUS dapat mendownload file individual yang berukuran minimal 100 MB ke lokasi “cache” default.

7.6.2. Penyimpanan Bersama Aplikasi

Implementasi perangkat:

• [C-0-1] HARUS menawarkan penyimpanan untuk digunakan bersama oleh aplikasi, yang juga sering disebut sebagai "penyimpanan eksternal bersama", "penyimpanan bersama aplikasi", atau dengan jalur Linux "/sdcard" yang memasangnya.
• [C-0-2] HARUS dikonfigurasi dengan penyimpanan bersama yang terpasang secara default, dengan kata lain "siap pakai", terlepas dari apakah penyimpanan tersebut diterapkan pada komponen penyimpanan internal atau media penyimpanan yang dapat dilepas (misalnya slot kartu Digital Aman).
• [C-0-3] HARUS memasang penyimpanan bersama aplikasi secara langsung di jalur Linux sdcard atau menyertakan link simbolis Linux dari sdcard ke direktori pemasangan 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 semua aplikasi yang mendapatkan izin tersebut.

Implementasi perangkat MUNGKIN memenuhi persyaratan di atas menggunakan salah satu hal berikut:

• Penyimpanan yang dapat dilepas yang dapat diakses pengguna, seperti slot kartu Secure Digital (SD).
• Sebagian penyimpanan internal (tidak dapat dilepas) seperti yang diimplementasikan dalam Proyek Open Source Android (AOSP).

Jika implementasi perangkat menggunakan penyimpanan yang dapat dilepas untuk memenuhi persyaratan di atas, implementasi tersebut:

• [C-1-1] HARUS menerapkan toast atau antarmuka pengguna 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 ditunjukkan pada kotak dan bahan lain yang tersedia pada saat pembelian sehingga media penyimpanan harus dibeli secara terpisah.

Jika implementasi perangkat menggunakan sebagian dari penyimpanan tak dapat dilepas untuk memenuhi persyaratan di atas, implementasi tersebut:

• HARUS menggunakan implementasi AOSP dari 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), implementasi tersebut:

• [C-2-1] HARUS mengizinkan hanya aplikasi Android yang diprainstal dan diberi hak istimewa dengan izin WRITE_EXTERNAL_STORAGE untuk menulis ke penyimpanan eksternal sekunder, kecuali saat menulis ke direktori khusus paket atau dalam URI yang ditampilkan dengan mengaktifkan intent ACTION_OPEN_DOCUMENT_TREE.

Jika implementasi perangkat memiliki port USB dengan dukungan mode periferal USB, implementasi tersebut:

• [C-3-1] HARUS menyediakan mekanisme untuk mengakses data pada aplikasi penyimpanan bersama dari komputer {i>host<i}.
• HARUS mengekspos konten dari kedua jalur penyimpanan secara transparan melalui layanan pemindai media Android dan android.provider.MediaStore.
• MUNGKIN menggunakan penyimpanan massal USB, tetapi HARUS menggunakan Media Transfer Protocol untuk memenuhi persyaratan ini.

Jika implementasi perangkat memiliki port USB dengan mode periferal USB dan mendukung Media Transfer Protocol, implementasi tersebut:

• HARUS kompatibel dengan host MTP Android referensi, Android File Transfer.
• HARUS melaporkan kelas perangkat USB 0x00.
• HARUS melaporkan nama antarmuka USB 'MTP'.

7.6.3. Penyimpanan yang Dapat Diadopsi

Jika perangkat diharapkan bersifat seluler tidak seperti Televisi, implementasi perangkat adalah:

• [SR] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan penyimpanan yang dapat diadopsi di lokasi stabil jangka panjang, karena secara tidak sengaja memutusnya dapat menyebabkan kehilangan/kerusakan data.

Jika port perangkat penyimpanan yang dapat dilepas berada di lokasi stabil jangka panjang, seperti di dalam kompartemen baterai atau penutup pelindung lainnya, implementasi perangkat adalah:

• [SR] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan penyimpanan yang dapat diadopsi.

7.7. USB

Jika implementasi perangkat memiliki port USB, implementasi tersebut:

• HARUS mendukung mode periferal USB dan SEHARUSNYA 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 tipe-A atau tipe-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,5A dan 3,0A sesuai standar resistor Tipe-C dan HARUS mendeteksi perubahan dalam iklan jika mendukung USB Tipe-C.
• [SR] Port SEHARUSNYA menggunakan faktor bentuk USB mikro-B, mikro-AB, atau Tipe-C. Perangkat Android baru dan lama DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
• [SR] Port SEHARUSNYA terletak di bagian bawah perangkat (sesuai dengan orientasi alami) atau mengaktifkan rotasi layar software untuk semua aplikasi (termasuk layar utama), sehingga tampilan ditampilkan dengan benar saat perangkat diorientasikan dengan port di bagian bawah. Perangkat Android lama dan baru DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
• [SR] HARUS menerapkan dukungan untuk menggambar arus 1,5 A selama kicauan dan traffic HS seperti yang ditentukan dalam spesifikasi Pengisian Daya Baterai USB, revisi 1.2. Perangkat Android baru dan lama DIREKOMENDASIKAN untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
• [SR] SANGAT DIREKOMENDASIKAN untuk tidak mendukung metode pengisian daya eksklusif yang memodifikasi voltase Vbus di luar level default, atau mengubah peran sink/sumber sehingga dapat mengakibatkan masalah interoperabilitas dengan pengisi daya atau perangkat yang mendukung metode Pengiriman Daya USB standar. Meskipun hal ini disebut "SANGAT DIREKOMENDASIKAN", dalam versi Android mendatang, kami mungkin MEMERLUKAN semua perangkat type-C untuk mendukung interoperabilitas penuh dengan pengisi daya type-C standar.
• [SR] SANGAT DIREKOMENDASIKAN untuk mendukung Pengiriman Daya untuk pertukaran peran data dan daya saat keduanya mendukung mode host USB dan USB Type-C.
• HARUS mendukung Pengiriman Daya untuk pengisian daya voltase tinggi dan dukungan untuk Mode Alternatif seperti layar keluar.
• HARUS menerapkan Android Open Accessory API (AOA) dan spesifikasi 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] Kelas penyimpanan massal USB HARUS menyertakan string "android" di akhir string deskripsi antarmuka iInterface dari penyimpanan massal USB

7.7.2. Mode host USB

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

• [C-1-1] HARUS menerapkan Android USB host API seperti yang didokumentasikan dalam Android SDK dan HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.host.
• [C-1-2] HARUS mengimplementasikan dukungan untuk menghubungkan periferal USB standar, dengan kata lain, periferal HARUS:
  • Sediakan port tipe C di perangkat atau kirimkan dengan kabel yang menyesuaikan port eksklusif di perangkat ke port USB type-C standar (perangkat USB Type-C).
  • Memiliki tipe A di perangkat atau dikirimkan dengan kabel yang menyesuaikan port eksklusif di perangkat ke port USB type-A standar.
  • Memiliki port micro-AB di perangkat, yang HARUS dikirimkan dengan kabel yang beradaptasi dengan port tipe A standar.
• [C-1-3] TIDAK BOLEH mengirim dengan adaptor yang mengonversi dari port USB tipe A atau mikro-AB ke port tipe-C (wadah).
• [SR] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK.
• SEHARUSNYA mendukung pengisian daya perangkat periferal USB yang terhubung saat dalam mode host; mengiklankan arus sumber minimal 1,5A sebagaimana ditentukan di bagian Parameter Penghentian dari Revisi Spesifikasi Kabel Tipe-C dan Konektor USB Revisi 1.2 untuk konektor USB Type-C atau menggunakan rentang arus output Port Pengisian Daya Downstream(CDP) sebagaimana ditentukan dalam spesifikasi Pengisian Daya Baterai USB, revisi 1.2 untuk.
• HARUS menerapkan dan mendukung standar USB Type-C.

Jika implementasi perangkat menyertakan port USB yang mendukung mode host dan class audio USB, implementasi tersebut:

• [C-2-1] HARUS mendukung class USB HID.
• [C-2-2] HARUS mendukung deteksi dan pemetaan kolom data HID berikut yang ditentukan dalam Tabel Penggunaan HID USB dan Permintaan Penggunaan Perintah Voice ke konstanta KeyEvent seperti di bawah:
  • ID Penggunaan Halaman Penggunaan (0xC): KEYCODE_MEDIA_PLAY_PAUSE
  • ID Penggunaan Halaman Penggunaan (0xC) (0x0E9): KEYCODE_VOLUME_UP
  • ID Penggunaan Halaman Penggunaan (0xC): KEYCODE_VOLUME_DOWN
  • ID Penggunaan Halaman Penggunaan (0xC): KEYCODE_VOICE_ASSIST

Jika implementasi perangkat menyertakan port USB yang mendukung mode host dan Storage Access Framework (SAF), implementasi 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, implementasi tersebut:

• [C-4-1] HARUS menerapkan fungsi Dual Role Port sebagaimana ditetapkan oleh spesifikasi USB Type-C (bagian 4.5.1.3.3).
• [SR] SANGAT DIREKOMENDASIKAN untuk mendukung DisplayPort, HARUS mendukung Kecepatan Data SuperSpeed USB, dan SANGAT DIREKOMENDASIKAN untuk mendukung Pengiriman Daya untuk pertukaran data dan peran daya.
• [SR] SANGAT DIREKOMENDASIKAN untuk TIDAK mendukung Mode Aksesori Adaptor Audio seperti yang dijelaskan di Lampiran A Revisi Spesifikasi Konektor dan Kabel USB Type-C 1.2.
• HARUS menerapkan model Coba.* yang paling sesuai untuk faktor bentuk perangkat. Misalnya, perangkat genggam SEHARUSNYA menerapkan model Coba.SNK.

7.8. Audio

7.8.1. Mikrofon

Jika implementasi perangkat menyertakan mikrofon, implementasi tersebut:

• [C-1-1] HARUS melaporkan konstanta fitur android.hardware.microphone.
• [C-1-2] HARUS memenuhi persyaratan perekaman audio di pasal 5.4.
• [C-1-3] HARUS memenuhi persyaratan latensi audio di bagian 5.6.
• [SR] SANGAT DIREKOMENDASIKAN untuk mendukung perekaman mendekati ultrasonik seperti dijelaskan dalam bagian 7.8.3.

Jika implementasi perangkat menghilangkan mikrofon, implementasi tersebut:

• [C-2-1] TIDAK BOLEH melaporkan konstanta fitur android.hardware.microphone.
• [C-2-2] HARUS mengimplementasikan API perekaman audio setidaknya sebagai tanpa pengoperasian, sesuai dengan bagian 7.

7.8.2. Output Audio

Jika implementasi perangkat menyertakan speaker atau port output audio/multimedia untuk periferal output audio seperti colokan audio 3,5 mm konduktor atau port mode host USB yang menggunakan class audio USB, implementasi perangkat tersebut:

• [C-1-1] HARUS melaporkan konstanta fitur android.hardware.audio.output.
• [C-1-2] HARUS memenuhi persyaratan pemutaran audio di pasal 5.5.
• [C-1-3] HARUS memenuhi persyaratan latensi audio di bagian 5.6.
• [SR] SANGAT DIREKOMENDASIKAN untuk mendukung pemutaran mendekati ultrasonik seperti dijelaskan dalam bagian 7.8.3.

Jika implementasi perangkat tidak menyertakan port output speaker atau audio, implementasi tersebut:

• [C-2-1] TIDAK BOLEH melaporkan fitur android.hardware.audio.output.
• [C-2-2] HARUS mengimplementasikan API terkait Output Audio setidaknya sebagai tanpa operasi.

Untuk keperluan bagian ini, "port output" adalah antarmuka fisik seperti colokan audio 3,5 mm, HDMI, atau port mode host USB dengan kelas audio USB. Dukungan untuk output audio melalui protokol berbasis radio seperti Bluetooth, Wi-Fi, atau jaringan seluler tidak memenuhi syarat termasuk "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, implementasi perangkat tersebut:

• [C-SR] SANGAT DIREKOMENDASIKAN untuk menyertakan setidaknya satu port audio yang menjadi colokan audio 3,5 mm konduktor 4 konduktor.

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

• [C-1-1] HARUS mendukung pemutaran audio ke headphone stereo dan headset stereo dengan mikrofon.
• [C-1-2] HARUS mendukung steker audio TRRS dengan urutan pin-out CTIA.
• [C-1-3] HARUS mendukung deteksi dan pemetaan ke kode tombol untuk 3 rentang impedansi setara berikut antara mikrofon dan konduktor 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 pada steker steker, tetapi hanya setelah semua kontak pada steker menyentuh segmen terkait pada steker.
• [C-1-5] HARUS mampu mengemudi setidaknya 150mV ± 10% dari tegangan output pada impedansi speaker 32 ohm.
• [C-1-6] HARUS memiliki tegangan bias mikrofon antara 1.8V ~ 2.9V.
• [C-1-7] HARUS mendeteksi dan memetakan ke kode tombol untuk rentang impedansi setara berikut antara mikrofon dan konduktor ground pada steker audio:
  • 110-180 ohm: KEYCODE_VOICE_ASSIST
• [C-SR] SANGAT DIREKOMENDASIKAN untuk mendukung steker audio dengan urutan pin-out OMTP.
• [C-SR] SANGAT REKOMENDASI untuk mendukung perekaman audio dari headset stereo dengan mikrofon.

Jika implementasi perangkat memiliki colokan audio 3,5 mm konduktor 4 dan mendukung mikrofon, serta menyiarkan android.intent.action.HEADSET_PLUG dengan mikrofon nilai tambahan yang ditetapkan sebagai 1, implementasi tersebut:

• [C-2-1] HARUS mendukung deteksi mikrofon pada aksesori audio yang dicolokkan.

7.8.3. Dekat Ultrasonik

Audio Near-Ultrasonik adalah pita 18,5 kHz hingga 20 kHz.

Implementasi perangkat:

• HARUS melaporkan dengan benar dukungan kemampuan audio mendekati ultrasonik melalui AudioManager.getProperty API sebagai berikut:

Jika PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND adalah "benar", persyaratan berikut HARUS dipenuhi oleh sumber audio VOICE_RECOGNITION dan UNPROCESSED:

• [C-1-1] Respon daya rata-rata mikrofon dalam band 18,5 kHz s/d 20 kHz HARUS tidak lebih dari 15 dB di bawah respons pada 2 kHz.
• [C-1-2] Rasio sinyal tanpa bobot mikrofon terhadap kebisingan 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 bernilai "benar":

• [C-2-1] Respon rata-rata speaker dalam rentang 18,5 kHz - 20 kHz HARUS tidak lebih rendah dari 40 dB di bawah respons pada 2 kHz.

7.9. Virtual Reality

Android menyertakan API dan fasilitas untuk membangun aplikasi "Virtual Reality" (VR) termasuk pengalaman VR seluler berkualitas tinggi. Implementasi perangkat HARUS menerapkan API dan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.

7.9.1. Mode Virtual Reality

Android menyertakan dukungan untuk Mode VR, fitur yang menangani rendering notifikasi stereoskopis 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 mengimplementasikan EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace, dan menampilkan 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 menampilkan ekstensi dalam daftar ekstensi GL yang tersedia.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan GL_EXT_external_buffer, GL_EXT_EGL_image_array, dan menampilkan ekstensi dalam daftar ekstensi GL yang tersedia.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk mendukung Vulkan 1.1.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk mengimplementasikan VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, dan menampilkannya dalam daftar ekstensi Vulkan yang tersedia.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk mengekspos setidaknya satu kelompok 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 buffer depan bersama sehingga rendering alternatif konten VR pada 60 fps dengan dua konteks render akan ditampilkan tanpa artefak sobek yang terlihat.
• [C-1-9] HARUS mengimplementasikan dukungan untuk flag AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, dan AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT seperti yang dijelaskan dalam NDK.
• [C-1-10] HARUS mengimplementasikan dukungan untuk AHardwareBuffer dengan kombinasi tanda penggunaan AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT setidaknya untuk format berikut: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk mendukung alokasi AHardwareBuffer dengan lebih dari satu lapisan serta flag dan format yang ditentukan dalam C-1-10.
• [C-1-11] HARUS mendukung dekode H.264 minimal 3840 x 2160 pada 30 fps, dikompresi ke rata-rata 40 Mbps (setara dengan 4 instance 1920 x1080 pada 30 fps-10 Mbps atau 2 instans 1080 fps x 6 Mbps).
• [C-1-12] HARUS mendukung HEVC dan VP9, HARUS mampu mendekode setidaknya 1920 x 1080 pada 30 fps yang dikompresi ke rata-rata 10 Mbps dan HARUS mampu mendekode 3840 x 2160 pada 30 fps-20 Mbps Mbps pada 30 fps-20 Mbps (setara dengan 30 fps-20 Mbps) hingga 20 Mbps Mbps.
• [C-1-13] HARUS mendukung HardwarePropertiesManager.getDeviceTemperatures API dan menampilkan nilai yang akurat untuk suhu kulit.
• [C-1-14] HARUS memiliki layar yang tertanam, dan resolusinya minimal HARUS 1920 x 1080.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk memiliki resolusi layar minimal 2560 x 1440.
• [C-1-15] Layar HARUS diperbarui minimal 60 Hz saat berada dalam Mode VR.
• [C-1-17] Layar HARUS mendukung mode persistensi rendah dengan persistensi ≤ 5 milidetik, persistensi didefinisikan sebagai jumlah waktu saat sebuah piksel memancarkan cahaya.
• [C-1-18] HARUS mendukung Ekstensi Panjang Data Bluetooth 4.2 dan Bluetooth LE 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 DIREKOMENDASIKAN untuk mendukung jenis saluran langsung TYPE_HARDWARE_BUFFER bagi semua Jenis Saluran Langsung yang tercantum di atas.
• [C-1-21] HARUS memenuhi persyaratan terkait giroskop, akselerometer, dan magnetometer untuk android.hardware.hifi_sensors, sebagaimana ditentukan dalam bagian 7.3.9.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk mendukung fitur android.hardware.sensor.hifi_sensors.
• [C-1-22] HARUS memiliki gerak end-to-end untuk latensi foton tidak lebih tinggi dari 28 milidetik.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk memiliki gerak end-to-end pada latensi foton yang tidak lebih tinggi dari 20 milidetik.
• [C-1-23] HARUS memiliki rasio bingkai pertama, yang merupakan rasio antara kecerahan piksel pada frame pertama setelah transisi dari hitam ke putih dan kecerahan piksel putih dalam keadaan stabil, minimal 85%.
• [C-SR] SANGAT DIREKOMENDASIKAN 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 inti eksklusif didukung, maka inti:

• [C-2-1] HARUS tidak mengizinkan proses userspace lain untuk dijalankan di dalamnya (kecuali {i>driver<i} perangkat yang digunakan oleh aplikasi), tapi MUNGKIN memungkinkan beberapa proses {i>kernel<i} untuk berjalan sesuai kebutuhan.

8. Performa dan Kekuatan

Beberapa kriteria performa dan daya minimum sangat penting untuk pengalaman pengguna dan memengaruhi asumsi dasar pengukuran yang mungkin dimiliki developer saat mengembangkan aplikasi.

8.1. Konsistensi Pengalaman Pengguna

Antarmuka pengguna yang mulus 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 terukur untuk latensi antarmuka pengguna dan pengalihan tugas seperti yang dijelaskan di bagian 2.

8.2. Performa Akses I/O File

Memberikan dasar umum untuk performa akses file yang konsisten pada penyimpanan data pribadi aplikasi (partisi /data) memungkinkan developer aplikasi menetapkan ekspektasi yang tepat yang akan membantu mereka mendesain software. 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 penulisan acak. Diukur dengan menulis file 256 MB menggunakan buffer tulis 4 KB.
• Performa pembacaan 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 manajemen 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 pemicuan, pemeliharaan, algoritme bangun, dan penggunaan setelan sistem global mode hemat daya Aplikasi Standby dan Istirahatkan.
• [C-1-2] TIDAK BOLEH menyimpang dari implementasi AOSP untuk penggunaan setelan global guna mengelola throttling tugas, alarm, dan jaringan untuk aplikasi di setiap bucket untuk Aplikasi standby.
• [C-1-3] TIDAK BOLEH menyimpang dari implementasi AOSP untuk jumlah Bucket Aplikasi Standby yang digunakan untuk Aplikasi Standby.
• [C-1-4] HARUS menerapkan Bucket Aplikasi Standby dan Istirahatkan seperti yang dijelaskan dalam Pengelolaan Daya.
• [C-1-5] HARUS mengembalikan true untuk PowerManager.isPowerSaveMode() saat perangkat dalam mode hemat daya.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk menyediakan kemampuan pengguna guna mengaktifkan dan menonaktifkan fitur penghemat baterai.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk memberikan kemampuan kepada pengguna agar dapat menampilkan semua Aplikasi yang dikecualikan dari mode hemat daya Aplikasi Standby dan Istirahatkan.

Selain mode hemat daya, implementasi perangkat Android DAPAT mengimplementasikan salah satu atau semua 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 keadaan tidak aktif (misalnya dengan menutup penutup yang secara fisik merupakan bagian 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 ketika aplikasi pihak ketiga tidak memerlukan sumber daya sistem (misalnya layar, CPU).

  Sebaliknya, HARUS keluar dari status S3 saat aplikasi pihak ketiga memerlukan resource sistem, seperti yang dijelaskan di SDK ini.

  Misalnya, meskipun aplikasi pihak ketiga meminta untuk membuat layar tetap aktif melalui FLAG_KEEP_SCREEN_ON atau CPU tetap berjalan 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, pada saat tugas yang diterapkan oleh aplikasi pihak ketiga melalui JobScheduler dipicu atau Firebase Cloud Messaging dikirim ke aplikasi pihak ketiga, perangkat HARUS keluar dari status S3 kecuali 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 Pemakaian Daya

Pencatatan dan pelaporan konsumsi daya yang lebih akurat memberikan insentif dan alat untuk mengoptimalkan pola penggunaan daya aplikasi kepada developer aplikasi.

Implementasi perangkat:

• [SR] SANGAT DIREKOMENDASIKAN untuk menyediakan profil daya per komponen yang menentukan nilai konsumsi saat ini untuk setiap komponen hardware dan perkiraan pengurasan baterai yang disebabkan oleh komponen dari waktu ke waktu seperti yang didokumentasikan di situs Proyek Open Source Android.
• [SR] SANGAT DIREKOMENDASIKAN untuk melaporkan semua nilai konsumsi daya dalam miliampere jam (mAh).
• [SR] SANGAT DIREKOMENDASIKAN untuk melaporkan konsumsi daya CPU per UID setiap proses. Project Open Source Android memenuhi persyaratan melalui implementasi modul kernel uid_cputime.
• [SR] SANGAT DIREKOMENDASIKAN untuk menyediakan penggunaan daya ini melalui perintah shell adb shell dumpsys batterystats kepada developer aplikasi.
• HARUS dikaitkan dengan komponen hardware itu sendiri jika tidak dapat mengatribusikan penggunaan daya komponen hardware ke aplikasi.

8.5. Performa yang Konsisten

Performa dapat berfluktuasi secara dramatis untuk aplikasi berperforma tinggi yang berjalan lama, baik karena aplikasi lain berjalan di latar belakang atau throttling CPU akibat batas suhu. Android menyertakan antarmuka terprogram sehingga jika perangkat mendukung, aplikasi latar depan teratas dapat meminta agar sistem mengoptimalkan alokasi resource untuk mengatasi fluktuasi tersebut.

Implementasi perangkat:

• [C-0-1] HARUS melaporkan dukungan Mode Performa Berkelanjutan secara akurat melalui metode API PowerManager.isSustainedPerformanceModeSupported().

• SEHARUSNYA mendukung Mode Performa Berkelanjutan.

Jika implementasi perangkat melaporkan dukungan Mode Performa Berkelanjutan, implementasi tersebut:

• [C-1-1] HARUS memberikan tingkat performa yang konsisten untuk aplikasi latar depan teratas setidaknya selama 30 menit, saat aplikasi memintanya.
• [C-1-2] HARUS mematuhi Window.setSustainedPerformanceMode() API dan API terkait lainnya.

Jika implementasi perangkat menyertakan dua core CPU atau lebih, implementasi tersebut:

• HARUS menyediakan setidaknya satu inti eksklusif yang dapat dipesan oleh aplikasi latar depan atas.

Jika implementasi perangkat mendukung pencadangan satu inti eksklusif untuk aplikasi latar depan teratas, implementasi tersebut:

• [C-2-1] HARUS melaporkan nomor ID core eksklusif yang dapat dipesan oleh aplikasi latar depan atas melalui metode Process.getExclusiveCores() API.
• [C-2-2] HARUS tidak mengizinkan proses ruang pengguna apa pun kecuali {i>driver <i}perangkat yang digunakan oleh aplikasi untuk berjalan pada inti eksklusif, tetapi MUNGKIN memungkinkan beberapa proses {i>kernel<i} berjalan sesuai kebutuhan.

Jika implementasi perangkat tidak mendukung inti eksklusif, implementasi tersebut:

• [C-3-1] HARUS menampilkan daftar kosong melalui metode API Process.getExclusiveCores().

9. Kompatibilitas Model Keamanan

Implementasi perangkat:

• [C-0-1] HARUS menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang dijelaskan dalam dokumen referensi Keamanan dan Izin dalam API di 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 dalam subbagian berikut.

9.1. Izin

Implementasi perangkat:

• [C-0-1] HARUS mendukung model izin Android seperti yang dijelaskan dalam dokumentasi developer Android. Secara khusus, kebijakan ini HARUS menerapkan setiap izin yang didefinisikan seperti yang dijelaskan dalam dokumentasi SDK; tidak ada izin yang boleh dihilangkan, diubah, atau diabaikan.

• MUNGKIN menambahkan izin tambahan, asalkan string ID izin baru tidak ada dalam namespace android.\*.

• [C-0-2] Izin dengan protectionLevel PROTECTION_FLAG_PRIVILEGED hanya boleh diberikan ke aplikasi yang diprainstal di jalur hak istimewa 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:
  • Izin pengguna dapat diperoleh sebelum aplikasi menggunakannya.
  • Izin runtime dikaitkan dengan pola intent yang aplikasi bawaannya telah disetel sebagai pengendali default.
• [C-0-6] HARUS memberikan izin kepada android.permission.RECOVER_KEYSTORE hanya untuk aplikasi sistem yang mendaftarkan Agen Pemulihan yang diamankan dengan benar. Agen Pemulihan yang diamankan dengan tepat didefinisikan sebagai agen software di perangkat yang menyinkronkan dengan penyimpanan jarak jauh di luar perangkat, yang dilengkapi dengan hardware aman dengan perlindungan yang setara atau lebih kuat dari yang dijelaskan dalam Google Cloud Key Vault Service untuk mencegah serangan brute force pada faktor pengetahuan layar kunci.

Jika implementasi perangkat menyertakan aplikasi bawaan atau ingin mengizinkan aplikasi pihak ketiga mengakses statistik penggunaan, implementasi tersebut:

• [SR] SANGAT DIREKOMENDASIKAN 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 bermaksud untuk melarang aplikasi apa pun, termasuk aplikasi bawaan, agar tidak mengakses statistik penggunaan, aplikasi tersebut:

• [C-1-1] Masih harus memiliki aktivitas yang menangani pola intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, tetapi HARUS menerapkannya sebagai tanpa pengoperasian, yaitu memiliki perilaku yang setara seperti saat pengguna ditolak untuk mendapatkan akses.

9.2. UID dan Isolasi Proses

Implementasi perangkat:

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

9.3. Izin Sistem File

Implementasi perangkat:

• [C-0-1] HARUS mendukung model izin akses file Android seperti yang ditetapkan dalam referensi Keamanan dan Izin.

9.4. Lingkungan Eksekusi Alternatif

Implementasi perangkat HARUS menjaga konsistensi model izin dan keamanan Android, bahkan jika termasuk lingkungan runtime yang mengeksekusi aplikasi menggunakan beberapa software atau teknologi selain Format Dalvik Executable 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 bagian lain di 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 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 persetujuan pengguna untuk izin Android yang digunakan oleh aplikasi.

• [C-0-9] Bila aplikasi perlu memanfaatkan sumber daya perangkat yang memiliki izin Android terkait (seperti Kamera, GPS, dll.), waktu proses alternatif HARUS menginformasikan pengguna bahwa aplikasi akan dapat mengakses sumber daya tersebut.

• [C-0-10] Jika lingkungan runtime tidak merekam 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 dalam sandbox Android yang 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 Multipengguna

Android menyertakan dukungan untuk beberapa pengguna dan memberikan dukungan untuk isolasi pengguna secara penuh.

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

Jika implementasi perangkat mencakup beberapa pengguna, mereka:

• [C-1-1] HARUS memenuhi persyaratan berikut terkait dengan dukungan multi-pengguna.
• [C-1-2] HARUS, untuk setiap pengguna, menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang ditetapkan dalam dokumen referensi Keamanan dan Izin dalam API.
• [C-1-3] HARUS memiliki direktori penyimpanan aplikasi bersama yang terpisah dan terisolasi (alias /sdcard) untuk setiap instance pengguna.
• [C-1-4] HARUS memastikan bahwa aplikasi yang dimiliki dan dijalankan atas nama pengguna tertentu tidak dapat membuat daftar, membaca, atau menulis ke file milik pengguna lain, meskipun data kedua pengguna disimpan pada volume atau sistem file yang sama.
• [C-1-5] HARUS mengenkripsi konten kartu SD saat multipengguna diaktifkan menggunakan kunci yang hanya disimpan pada media yang tidak dapat dilepas dan hanya dapat diakses oleh sistem jika implementasi perangkat menggunakan media yang dapat dilepas untuk API penyimpanan eksternal. Karena ini akan membuat media tidak dapat dibaca oleh PC host, implementasi perangkat akan diperlukan untuk beralih ke MTP atau sistem serupa untuk menyediakan akses ke data pengguna saat ini kepada PC host.

Jika implementasi perangkat mencakup beberapa pengguna dan tidak mendeklarasikan tombol fitur android.hardware.telephony, implementasi tersebut:

• [C-2-1] HARUS mendukung profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuan mereka di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola batasan yang lebih terperinci dalam aplikasi yang tersedia di lingkungan tersebut.

Jika implementasi perangkat mencakup beberapa pengguna dan mendeklarasikan tombol fitur android.hardware.telephony, implementasi tersebut:

• [C-3-1] TIDAK BOLEH mendukung profil yang dibatasi, tetapi HARUS selaras dengan implementasi kontrol AOSP untuk mengaktifkan /menonaktifkan pengguna lain agar tidak mengakses panggilan suara dan SMS.

9.6. Peringatan SMS Premium

Android menyertakan dukungan untuk memperingatkan pengguna tentang setiap pesan SMS premium keluar. Pesan SMS Premium adalah pesan teks yang dikirim ke layanan yang terdaftar dengan operator yang mungkin dikenakan 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.

Android Sandbox 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, bahkan ketika SELinux atau fitur keamanan lainnya diimplementasikan 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 MUNGKIN memiliki antarmuka pengguna yang terlihat saat terjadi pelanggaran keamanan yang dibatalkan pemblokirannya sehingga berhasil dieksploitasi.
• [C-0-3] TIDAK BOLEH membuat SELinux atau fitur keamanan lainnya yang diimplementasikan 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 secara 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 diri merupakan bagian tak terpisahkan dari keamanan Android. Implementasi perangkat:

• [C-0-7] HARUS mengimplementasikan perlindungan overflow buffer stack kernel (misalnya CONFIG_CC_STACKPROTECTOR_STRONG).
• [C-0-8] HARUS mengimplementasikan perlindungan memori kernel yang ketat jika kode yang dapat dieksekusi bersifat hanya baca, data hanya baca tidak dapat dieksekusi dan tidak dapat ditulis, serta data yang dapat ditulis tidak dapat dieksekusi (misalnya CONFIG_DEBUG_RODATA atau CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] HARUS mengimplementasikan batas ukuran objek statis dan dinamis yang memeriksa salinan antara ruang pengguna dan ruang kernel (misalnya CONFIG_HARDENED_USERCOPY) pada perangkat yang awalnya mengirim dengan API level 28 atau yang lebih tinggi.
• [C-0-10] TIDAK BOLEH mengeksekusi memori ruang pengguna saat mengeksekusi dalam mode kernel (misalnya PXN hardware, atau diemulasikan melalui CONFIG_CPU_SW_DOMAIN_PAN atau CONFIG_ARM64_SW_TTBR0_PAN) pada perangkat yang awalnya dikirimkan dengan API level 28 atau yang lebih tinggi.
• [C-0-11] TIDAK BOLEH membaca atau menulis memori ruang pengguna di kernel di luar API akses usercopy normal (misalnya PAN hardware, atau diemulasikan melalui CONFIG_CPU_SW_DOMAIN_PAN atau CONFIG_ARM64_SW_TTBR0_PAN) pada perangkat yang aslinya dikirim dengan API level 28 atau yang lebih tinggi.
• [C-0-12] HARUS menerapkan isolasi tabel halaman kernel di semua perangkat yang awalnya dilengkapi dengan API level 28 atau lebih tinggi (mis. CONFIG_PAGE_TABLE_ISOLATION atau `CONFIG_UNMAP_KERNEL_AT_EL0).
• [SR] SANGAT DIREKOMENDASIKAN untuk menyimpan data kernel yang hanya ditulis selama inisialisasi ditandai hanya baca setelah inisialisasi (misalnya __ro_after_init).
• [SR] SANGAT DIREKOMENDASIKAN untuk mengacak tata letak kode kernel dan memori, serta untuk menghindari eksposur yang dapat mengganggu pengacakan tersebut (misalnya CONFIG_RANDOMIZE_BASE dengan entropi bootloader melalui /chosen/kaslr-seed Device Tree node atau EFI_RNG_PROTOCOL).

Jika implementasi perangkat menggunakan kernel Linux, implementasi tersebut:

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

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 defense in depth yang tak terpisahkan dengan keamanan perangkat.

Implementasi perangkat:

• [C-SR] SANGAT DIREKOMENDASIKAN untuk tidak menonaktifkan Control-Flow Integrity (CFI) atau Integer Overflow Sanitization (IntSan) pada komponen yang telah mengaktifkannya.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk mengaktifkan CFI dan IntSan bagi komponen userspace tambahan yang sensitif terhadap keamanan seperti yang dijelaskan dalam CFI dan IntSan.

9.8. Privasi

9.8.1 Histori Penggunaan

Android menyimpan histori pilihan pengguna dan mengelola histori tersebut melalui UsageStatsManager.

Implementasi perangkat:

• [C-0-1] HARUS mempertahankan periode retensi yang wajar untuk histori pengguna tersebut.
• [SR] SANGAT DIREKOMENDASIKAN untuk mempertahankan periode retensi data 14 hari seperti yang dikonfigurasi secara default dalam implementasi 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 apa pun selain yang dijelaskan dalam dokumen SDK StatsLog. Jika peristiwa sistem tambahan dicatat, mereka MUNGKIN menggunakan ID atom yang berbeda dalam rentang antara 100.000 dan 200.000.

9.8.2. Merekam

Implementasi perangkat:

• [C-0-1] TIDAK BOLEH melakukan pramuat atau mendistribusikan komponen software siap pakai yang mengirimkan informasi pribadi pengguna (misalnya penekanan tombol, teks yang ditampilkan di layar) dari perangkat tanpa persetujuan pengguna atau menghapus notifikasi yang sedang berlangsung.

Jika implementasi perangkat menyertakan fungsi dalam sistem yang mengambil 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 merekam/merekam.

Jika implementasi perangkat menyertakan komponen yang diaktifkan out-of-box, yang mampu merekam audio sekitar untuk menyimpulkan informasi yang berguna tentang konteks pengguna, komponen tersebut:

• [C-2-1] TIDAK BOLEH menyimpan rekaman audio mentah atau format apa pun yang dapat dikonversi kembali ke audio asli atau faksimile yang ada di perangkat, kecuali dengan persetujuan eksplisit dari pengguna.

9.8.3. Konektivitas

Jika implementasi perangkat memiliki port USB dengan dukungan mode periferal USB, implementasi tersebut:

• [C-1-1] HARUS menampilkan antarmuka pengguna yang meminta persetujuan pengguna sebelum mengizinkan akses ke konten penyimpanan bersama melalui port USB.

9.8.4. Traffic Jaringan

Implementasi perangkat:

• [C-0-1] HARUS menginstal root certificate yang sama untuk penyimpanan Certificate Authority (CA) tepercaya sistem seperti yang disediakan di Project Open Source Android upstream.
• [C-0-2] HARUS mengirimkan dengan penyimpanan CA root pengguna kosong.
• [C-0-3] HARUS menampilkan peringatan kepada pengguna yang menunjukkan bahwa traffic jaringan mungkin dipantau, saat root CA pengguna ditambahkan.

Jika traffic perangkat dirutekan melalui VPN, implementasi perangkat akan:

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

Jika penerapan perangkat memiliki mekanisme yang diaktifkan secara default, yang merutekan traffic data jaringan melalui server proxy atau gateway VPN (misalnya, pramuat layanan VPN dengan android.permission.CONTROL_VPN diberikan), implementasi tersebut akan:

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

Jika implementasi perangkat menerapkan kemampuan pengguna untuk mengaktifkan fungsi "VPN selalu aktif" aplikasi VPN pihak ketiga, implementasi tersebut:

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

9,9. Enkripsi Penyimpanan Data

Jika performa kripto Advanced Encryption Standard (AES), diukur dengan teknologi AES berperforma terbaik yang tersedia di perangkat (misalnya ARM Cryptography Extensions), berada di atas 50 MiB/dtk, implementasi perangkat:

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

Jika performa kripto AES berukuran atau di bawah 50 MiB/dtk, implementasi perangkat MUNGKIN menggunakan Adiantum-XChaCha12-AES, bukan dalam bentuk AES yang tercantum di salah satu bagian berikut: AES-256-XTS di Bagian 9.9.2 [C-1-5]; AES-256 dalam mode CBS-CTS di Bagian AES-9

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 Direct Boot mode API meskipun tidak mendukung Enkripsi Penyimpanan.

• [C-0-2] Intent ACTION_LOCKED_BOOT_COMPLETED dan ACTION_USER_UNLOCKED HARUS tetap disiarkan untuk memberi sinyal pada aplikasi yang mendukung Direct Boot bahwa lokasi penyimpanan Device Encrypted (DE) dan Credential Encrypted (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 Device Encrypted (DE) setelah pesan ACTION_LOCKED_BOOT_COMPLETED disiarkan.
• [C-1-2] HARUS mengizinkan akses ke penyimpanan Enkripsi Kredensial (CE) hanya 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 penyimpanan yang dilindungi CE tanpa kredensial yang diberikan pengguna atau kunci dana jaminan yang terdaftar.
• [C-1-4] HARUS mendukung Booting Terverifikasi dan memastikan bahwa kunci DE terikat secara kriptografis ke root hardware tepercaya perangkat.
• [C-1-5] HARUS mendukung enkripsi isi file menggunakan AES-256-XTS. AES-256-XTS mengacu pada Advanced Encryption Standard dengan panjang kunci 256-bit, 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 jika 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 lainnya.

• [C-1-11] Secara default, HARUS menggunakan cipher, panjang kunci, dan mode yang didukung secara wajib.

• [C-SR] SANGAT DIREKOMENDASIKAN untuk mengenkripsi metadata sistem file, seperti ukuran file, kepemilikan, mode, dan atribut Extended (xattrs), dengan kunci yang secara kriptografis terikat dengan root of trust hardware perangkat.

• HARUS buat aplikasi penting yang sudah diinstal lebih dulu (misalnya Alarm, Telepon, Messenger) Direct Boot.

• MUNGKIN mendukung penyandian alternatif, panjang kunci, dan mode untuk konten file dan enkripsi nama file.

Project Open Source Android upstream menyediakan implementasi yang lebih disukai dari fitur ini 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 penyandian 128 bit atau lebih besar.
• [C-1-2] HARUS menggunakan kode sandi default untuk membungkus kunci enkripsi dan TIDAK BOLEH menulis kunci enkripsi ke penyimpanan kapan pun tanpa dienkripsi.
• [C-1-3] HARUS AES mengenkripsi kunci enkripsi secara default, kecuali jika pengguna secara eksplisit memilih tidak ikut, kecuali jika kunci tersebut sedang digunakan secara aktif, dengan kredensial layar kunci direntangkan menggunakan algoritma peregangan yang lambat (misalnya PBKDF2 atau scrypt).
• [C-1-4] Algoritma peregangan sandi default di atas HARUS terikat secara kriptografis ke keystore tersebut saat 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 keluar dari perangkat (bahkan saat dibungkus dengan kode sandi pengguna dan/atau kunci yang terikat dengan perangkat keras).

Project Open Source Android upstream menyediakan implementasi yang lebih disukai dari fitur ini, berdasarkan fitur kernel Linux dm-crypt.

9.10. Integritas Perangkat

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

• [C-0-1] HARUS melaporkan dengan benar melalui metode System API PersistentDataBlockManager.getFlashLockState() apakah status bootloader-nya memungkinkan flash image sistem. Status FLASH_LOCK_UNKNOWN dicadangkan untuk implementasi perangkat yang diupgrade dari versi Android sebelumnya saat metode API sistem baru ini tidak ada.

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

Jika implementasi perangkat sudah diluncurkan tanpa mendukung Booting Terverifikasi pada versi Android yang lebih lama dan tidak dapat menambahkan dukungan terhadap fitur ini dengan update software sistem, implementasi tersebut MUNGKIN dikecualikan dari persyaratan tersebut.

Booting Terverifikasi adalah fitur yang menjamin integritas software perangkat. Jika implementasi perangkat mendukung fitur tersebut, implementasi tersebut:

• [C-1-1] HARUS mendeklarasikan tombol fitur platform android.software.verified_boot.
• [C-1-2] HARUS melakukan verifikasi pada setiap urutan booting.
• [C-1-3] HARUS memulai verifikasi dari kunci perangkat keras yang tidak dapat diubah yang merupakan akar kepercayaan dan berlanjut hingga ke partisi sistem.
• [C-1-4] HARUS menerapkan setiap tahap verifikasi untuk memeriksa integritas dan keaslian semua byte di tahap berikutnya sebelum mengeksekusi kode di tahap berikutnya.
• [C-1-5] HARUS menggunakan algoritma verifikasi sekuat rekomendasi saat ini dari NIST untuk algoritma hashing (SHA-256) dan ukuran kunci publik (RSA-2048).
• [C-1-6] TIDAK BOLEH mengizinkan booting jika terjadi kegagalan verifikasi sistem, kecuali jika pengguna setuju untuk tetap melakukan upaya booting, dalam hal ini data dari blok penyimpanan yang tidak terverifikasi TIDAK BOLEH digunakan.
• [C-1-7] TIDAK BOLEH mengizinkan partisi terverifikasi pada perangkat untuk dimodifikasi kecuali pengguna telah membuka kunci bootloader secara eksplisit.
• [C-SR] Jika ada beberapa chip terpisah di perangkat (misalnya radio, prosesor gambar khusus), proses booting setiap chip tersebut SANGAT DIREKOMENDASIKAN untuk memverifikasi setiap tahap saat booting.
• [C-1-8] HARUS menggunakan penyimpanan yang tahan perusakan: untuk menyimpan apakah bootloader tidak terkunci. Penyimpanan yang tahan perusakan berarti bahwa {i>boot loader<i} dapat mendeteksi apakah penyimpanan telah dirusak dari dalam Android.
• [C-1-9] HARUS meminta konfirmasi pengguna saat perangkat digunakan, dan memerlukan konfirmasi fisik sebelum mengizinkan transisi dari mode terkunci dari boot loader ke mode tidak terkunci boot loader.
• [C-1-10] HARUS menerapkan perlindungan rollback untuk partisi yang digunakan oleh Android (misalnya, booting, partisi sistem) dan menggunakan penyimpanan yang tahan perusakan untuk menyimpan metadata yang digunakan untuk menentukan versi OS minimum yang diizinkan.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk memverifikasi semua file APK aplikasi dengan hak istimewa dengan rantai kepercayaan yang di-root di /system, yang dilindungi oleh Booting Terverifikasi.
• [C-SR] SANGAT DIREKOMENDASIKAN untuk memverifikasi artefak yang dapat dieksekusi yang dimuat oleh aplikasi berhak istimewa dari luar file APK-nya (seperti kode yang dimuat secara dinamis atau kode yang dikompilasi) sebelum mengeksekusinya atau SANGAT DIREKOMENDASIKAN untuk tidak mengeksekusinya sama sekali.
• HARUS menerapkan perlindungan rollback untuk komponen apa pun dengan firmware persisten (misalnya modem, kamera) dan SEHARUSNYA menggunakan penyimpanan yang tahan perusakan 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 pada versi Android yang lebih lama dan tidak dapat menambahkan dukungan untuk persyaratan ini dengan update software sistem, implementasi tersebut DAPAT dikecualikan dari persyaratan ini.

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

Implementasi perangkat:

• [C-R] DIREKOMENDASIKAN untuk mendukung Android Protected Confirmation API.

Jika implementasi perangkat mendukung Android Protected Confirmation API, implementasi tersebut:

• [C-3-1] HARUS melaporkan true untuk ConfirmationPrompt.isSupported() API.
• [C-3-2] HARUS memastikan bahwa hardware aman mengambil kontrol penuh atas tampilan sedemikian rupa sehingga Android OS tidak dapat memblokirnya tanpa deteksi oleh hardware aman.
• [C-3-3] HARUS memastikan bahwa perangkat keras aman mengambil alih kendali 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 setidaknya 8.192 kunci untuk diimpor atau dihasilkan.
• [C-0-2] Otentikasi layar kunci HARUS berupaya membatasi kapasitas dan HARUS memiliki algoritma backoff eksponensial. Di atas 150 upaya gagal, penundaan HARUS minimal 24 jam per upaya.
• TIDAK BOLEH membatasi jumlah kunci yang dapat dibuat

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

• [C-1-1] HARUS mencadangkan implementasi keystore dengan lingkungan eksekusi yang 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 secara aman dari kode yang berjalan pada kernel dan di atasnya. Isolasi aman HARUS memblokir semua mekanisme potensial yang digunakan kode kernel atau userspace dapat mengakses status internal lingkungan yang terisolasi, termasuk DMA. Proyek 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 untuk isolasi berbasis hypervisor yang tepat merupakan opsi alternatif.
• [C-1-3] HARUS melakukan otentikasi layar kunci di lingkungan eksekusi yang terisolasi dan hanya jika berhasil, izinkan kunci yang terikat otentikasi untuk digunakan. Kredensial layar kunci HARUS disimpan dengan cara yang hanya memungkinkan lingkungan eksekusi yang terisolasi untuk melakukan autentikasi layar kunci. Project Open Source Android upstream menyediakan Gatekeeper Hardware Abstraksi Layer (HAL) dan Trusty, yang dapat digunakan untuk memenuhi persyaratan ini.
• [C-1-4] HARUS mendukung pengesahan kunci di mana kunci penandatanganan pengesahan dilindungi oleh perangkat keras yang aman dan penandatanganan dilakukan dalam perangkat keras yang aman. Kunci penandatanganan pengesahan HARUS dibagikan ke seluruh perangkat dalam jumlah yang cukup besar untuk mencegah kunci digunakan sebagai ID perangkat. Salah satu cara untuk memenuhi persyaratan ini adalah dengan berbagi kunci pengesahan yang sama kecuali jika setidaknya 100.000 unit SKU tertentu dihasilkan. Jika terdapat lebih dari 100.000 unit SKU, kunci yang berbeda MUNGKIN digunakan untuk setiap 100.000 unit.
• [C-1-5] HARUS mengizinkan pengguna untuk memilih Waktu tunggu tidur untuk transisi dari keadaan tidak terkunci ke terkunci, dengan waktu tunggu minimum yang diperbolehkan 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 yang terisolasi dan mendukung pengesahan kunci, kecuali jika mendeklarasikan fitur android.hardware.fingerprint yang memerlukan keystore yang didukung oleh lingkungan eksekusi yang terisolasi.

9.11.1. Layar Kunci Aman

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

Implementasi perangkat:

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

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 yang aman untuk mengunci layar, metode autentikasi baru tersebut:

• [C-2-1] HARUS berupa metode autentikasi pengguna seperti yang dijelaskan dalam Mewajibkan Autentikasi Pengguna untuk Penggunaan Kunci.
• [C-2-2] HARUS membuka kunci semua kunci untuk aplikasi developer pihak ketiga untuk digunakan saat pengguna membuka layar kunci yang aman. Misalnya, semua kunci HARUS tersedia untuk aplikasi developer pihak ketiga melalui API yang relevan, seperti createConfirmDeviceCredentialIntent dan setUserAuthenticationRequired.

Jika implementasi perangkat menambahkan atau mengubah metode autentikasi untuk membuka kunci layar kunci jika didasarkan pada rahasia yang diketahui dan menggunakan metode autentikasi baru agar diperlakukan sebagai cara yang 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 input yang mungkin HARUS lebih besar dari 18 bit.
• [C-3-3] Metode otentikasi baru TIDAK BOLEH menggantikan metode otentikasi utama yang direkomendasikan (yaitu PIN, pola, kata sandi) yang diimplementasikan dan disediakan di AOSP.
• [C-3-4] Metode autentikasi yang baru 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_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 agar diperlakukan sebagai cara yang aman untuk mengunci layar, metode baru ini:

• [C-4-1] HARUS memenuhi semua persyaratan yang dijelaskan dalam pasal 7.3.10.2.
• [C-4-2] HARUS memiliki mekanisme fallback untuk menggunakan salah satu metode otentikasi primer yang disarankan berdasarkan 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 flag biometrik terkait (yaitu KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE, atau KEYGUARD_DISABLE_IRIS).
• [C-4-4] HARUS menantang pengguna untuk autentikasi utama yang direkomendasikan (mis. PIN, pola, sandi) setidaknya sekali setiap 72 jam atau kurang.
• [C-4-5] HARUS memiliki tingkat 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 DIREKOMENDASIKAN untuk memiliki tingkat penerimaan spoofing 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 sistem operasi atau penyusupan kernel tidak dapat mengizinkan data untuk diinjeksi secara langsung untuk mengotentikasi palsu sebagai pengguna.
• [C-4-7] HARUS dipasangkan dengan tindakan konfirmasi eksplisit (misalnya: penekanan tombol) untuk memungkinkan akses ke tombol keystore jika aplikasi menyetel true untuk KeyGenParameterSpec.Built.setUserAuthenticationRequired() dan biometriknya pasif (mis. wajah atau iris jika tidak ada sinyal intent yang eksplisit).
• [C-SR] Tindakan konfirmasi untuk biometrik pasif SANGAT DIREKOMENDASIKAN agar diamankan sedemikian rupa sehingga sistem operasi atau kernel yang disusupi tidak dapat melakukan spoofing. Misalnya, ini berarti bahwa tindakan konfirmasi berdasarkan tombol fisik dirutekan melalui pin input/output tujuan umum (GPIO) khusus input dari secure element (SE) yang tidak dapat didorong dengan cara lain selain penekanan tombol fisik.

Jika metode autentikasi biometrik tidak memenuhi tingkat penerimaan spoofing dan penipu seperti yang dijelaskan di 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 ditantang untuk autentikasi utama yang disarankan (misalnya: PIN, pola, kata sandi) setelah periode waktu tunggu tidak ada aktivitas selama 4 jam. Periode waktu tunggu tidak ada aktivitas direset setelah konfirmasi kredensial perangkat berhasil.
• [C-5-3] Metode TIDAK BOLEH diperlakukan sebagai layar kunci 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] Mereka HARUS memiliki mekanisme fallback untuk menggunakan salah satu metode otentikasi 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 ditantang untuk salah satu metode otentikasi utama yang direkomendasikan (misalnya PIN, pola, kata sandi) setidaknya sekali setiap 72 jam atau kurang.
• [C-6-4] Metode baru TIDAK BOLEH diperlakukan sebagai layar kunci aman dan HARUS mengikuti batasan yang tercantum dalam C-8 di bawah ini.

Jika implementasi perangkat memiliki layar kunci yang aman dan menyertakan satu atau beberapa trust agent, yang mengimplementasikan TrustAgentService System API, implementasi tersebut:

• [C-7-1] HARUS memiliki indikasi yang jelas di menu pengaturan dan di layar kunci ketika penguncian perangkat ditunda atau dapat dibuka oleh agen tepercaya. Misalnya, AOSP memenuhi persyaratan ini dengan menampilkan deskripsi teks untuk "Setelan kunci otomatis" dan "Tombol daya seketika terkunci" di menu setelan dan ikon yang dapat dibedakan di layar kunci.
• [C-7-2] HARUS mematuhi dan sepenuhnya menerapkan semua API agen kepercayaan di class DevicePolicyManager, seperti konstanta KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] TIDAK BOLEH mengimplementasikan fungsi TrustAgentService.addEscrowToken() sepenuhnya pada perangkat yang digunakan sebagai perangkat pribadi utama (misalnya, perangkat genggam), tetapi MUNGKIN mengimplementasikan fungsi sepenuhnya pada implementasi perangkat yang biasanya digunakan bersama (misalnya, Android Television atau perangkat Automotive).
• [C-7-4] HARUS mengenkripsi semua token tersimpan yang ditambahkan oleh TrustAgentService.addEscrowToken().
• [C-7-5] TIDAK BOLEH menyimpan kunci enkripsi pada perangkat yang sama 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 fallback untuk menggunakan salah satu metode otentikasi utama yang disarankan.
• [C-7-8] Pengguna HARUS ditantang untuk salah satu metode autentikasi utama yang direkomendasikan (misalnya: metode PIN, pola, kata sandi) setidaknya sekali setiap 72 jam atau kurang.
• [C-7-9] Pengguna HARUS ditantang untuk 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 direset setelah konfirmasi kredensial perangkat berhasil.
• [C-7-10] TIDAK BOLEH diperlakukan sebagai layar kunci yang aman dan HARUS mengikuti batasan yang tercantum dalam C-8 di bawah.

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

• [C-8-1] Metode baru 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_UNSPECIFIED.
• [C-8-2] Mereka TIDAK BOLEH mereset timer masa berlaku sandi yang disetel oleh DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] ID tersebut TIDAK BOLEH mengautentikasi akses ke keystore jika aplikasi menetapkan true untuk KeyGenParameterSpec.Builder.setUserAuthenticationRequired()).

9.11.2. StrongBox

Sistem Android Keystore memungkinkan developer aplikasi untuk menyimpan kunci kriptografis dalam pemroses khusus yang aman serta lingkungan eksekusi terisolasi yang dijelaskan di atas.

Implementasi perangkat:

• [C-SR] SANGAT DIREKOMENDASIKAN untuk mendukung StrongBox.

Jika implementasi perangkat mendukung StrongBox, implementasi tersebut:

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

• [C-1-2] HARUS menyediakan perangkat keras khusus yang aman yang digunakan untuk mendukung keystore dan mengamankan autentikasi pengguna.

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

• [C-1-4] HARUS memastikan bahwa setiap periferal yang dibagikan dengan AP tidak dapat mengubah pemrosesan StrongBox dengan cara apa pun, atau memperoleh 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 sesungguhnya yang menghasilkan output yang terdistribusi secara seragam dan tidak dapat diprediksi.

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

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

• [C-1-9] HARUS memiliki penyimpanan aman yang memastikan kerahasiaan, integritas, keaslian, konsistensi, dan keaktualan 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 berdasarkan Secure IC Protection Profile BSI-CC-PP-0084-2014 atau yang dievaluasi oleh laboratorium pengujian yang terakreditasi secara nasional dan menggabungkan penilaian potensi kerentanan serangan tinggi sesuai dengan Common Criteria Application of Attack Potential to Smartcard.
  • [C-1-11] HARUS menyertakan firmware yang dievaluasi oleh laboratorium pengujian yang terakreditasi secara nasional, yang menggabungkan penilaian kerentanan potensi serangan Tinggi sesuai dengan Common Criteria Application of Attack Potential to Smartcard.
  • [C-SR] SANGAT DIREKOMENDASIKAN untuk menyertakan hardware yang dievaluasi menggunakan Target Keamanan, Evaluation Assurance Level (EAL) 5, ditambah dengan AVA_VAN.5. Sertifikasi EAL 5 kemungkinan akan menjadi persyaratan dalam rilis mendatang.

• [C-SR] SANGAT DIREKOMENDASIKAN untuk memberikan ketahanan terhadap serangan internal (IAR), yang berarti orang dalam yang memiliki akses ke kunci penandatanganan firmware tidak dapat menghasilkan firmware yang menyebabkan StrongBox membocorkan secret, untuk mengabaikan persyaratan keamanan fungsional atau mengaktifkan akses ke data pengguna sensitif. Cara yang disarankan untuk menerapkan IAR adalah dengan mengizinkan pembaruan firmware hanya bila sandi pengguna utama diberikan melalui HAL IAuthSecret.

9.12. Penghapusan Data

Semua implementasi perangkat:

• [C-0-1] HARUS menyediakan mekanisme kepada pengguna untuk melakukan "Reset ke Setelan Pabrik".
• [C-0-2] HARUS menghapus semua data yang dibuat pengguna. Artinya, semua data kecuali untuk hal berikut:
  • Image sistem
  • Semua file sistem operasi yang dibutuhkan oleh image sistem
• [C-0-3] HARUS menghapus data dengan cara sedemikian rupa sehingga akan memenuhi standar industri yang relevan seperti NIST SP800-88.
• [C-0-4] HARUS memicu proses "Reset ke Setelan Pabrik" di atas saat DevicePolicyManager.wipeData() API dipanggil oleh aplikasi Pengontrol Kebijakan Perangkat pengguna utama.
• MUNGKIN menyediakan opsi penghapusan total data cepat yang hanya melakukan penghapusan data logis.

9.13. Mode Booting Aman

Android menyediakan Mode Booting Aman, yang memungkinkan pengguna melakukan booting ke mode yang hanya mengizinkan aplikasi sistem bawaan untuk berjalan dan semua aplikasi pihak ketiga dinonaktifkan. Mode ini, yang dikenal sebagai "Mode Booting Aman", memberi pengguna kemampuan untuk meng-uninstal aplikasi pihak ketiga yang berpotensi berbahaya.

Implementasi perangkat adalah:

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

Jika implementasi perangkat menerapkan Mode Booting Aman, implementasi tersebut:

• [C-1-1] HARUS memberi pengguna opsi untuk masuk ke Mode Booting Aman sedemikian rupa sehingga tidak terganggu dari aplikasi pihak ketiga yang diinstal di perangkat, kecuali jika aplikasi pihak ketiga adalah Pengontrol Kebijakan Perangkat dan telah menyetel tanda UserManager.DISALLOW_SAFE_BOOT sebagai benar (true).

• [C-1-2] HARUS memberi pengguna kemampuan untuk meng-uninstal aplikasi pihak ketiga apa pun dalam Mode Aman.

• HARUS menyediakan opsi kepada pengguna untuk masuk ke Mode Booting Aman dari menu booting menggunakan alur kerja yang berbeda dari proses booting normal.

9.14. Isolasi Sistem Kendaraan Otomotif

Perangkat Android Automotive diharapkan bertukar data dengan subsistem kendaraan penting menggunakan vehicle HAL 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 berbahaya atau tidak disengaja dengan subsistem ini.

9.15. Paket Langganan

"Paket langganan" mengacu pada detail paket hubungan penagihan yang disediakan oleh operator seluler melalui SubscriptionManager.setSubscriptionPlans().

Semua implementasi perangkat:

• [C-0-1] HARUS mengembalikan 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, perhatikan bahwa tidak ada paket pengujian perangkat lunak yang sepenuhnya komprehensif. Karena alasan ini, pengimplementasi perangkat DIREKOMENDASIKAN untuk membuat sesedikit mungkin perubahan pada referensi dan implementasi pilihan Android yang tersedia dari Project Open Source Android. Hal ini akan meminimalkan risiko timbulnya bug yang menimbulkan inkompatibilitas yang memerlukan pengerjaan ulang dan potensi update perangkat.

10.1. Compatibility Test Suite (CTS)

Implementasi perangkat:

• [C-0-1] HARUS lulus Compatibility Test Suite (CTS) Android yang tersedia dari Project Open Source Android, menggunakan software pengiriman akhir di perangkat.

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

CTS dirancang untuk dijalankan pada perangkat yang sebenarnya. Seperti perangkat lunak lainnya, CTS mungkin memiliki bug. CTS akan dibuat versinya secara terpisah dari Compatibility Definition 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 digunakan.

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

10.2. Pemverifikasi CTS

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

Implementasi perangkat:

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

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

Implementasi perangkat:

• [C-0-2] HARUS lulus semua pengujian perangkat keras yang mereka miliki; misalnya, jika perangkat memiliki akselerometer, perangkat HARUS menjalankan kasus uji Akselerometer dengan benar di CTS Verifier.

Kasus pengujian untuk fitur yang dianggap 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 sangat mirip, pengimplementasi perangkat tidak diharapkan untuk secara eksplisit menjalankan CTS Verifier pada build yang hanya berbeda dalam hal yang sepele. Secara khusus, implementasi perangkat yang berbeda dari implementasi yang telah lulus CTS Verifier hanya oleh kumpulan lokalitas yang disertakan, branding, dll. MUNGKIN menghilangkan uji CTS Verifier.

11. Software yang Dapat Diperbarui

• [C-0-1] Implementasi perangkat HARUS menyertakan mekanisme untuk mengganti keseluruhan software sistem. Mekanismenya tidak perlu melakukan upgrade “langsung”—artinya, perangkat yang dimulai ulang MUNGKIN diperlukan. Metode apa pun dapat digunakan, asalkan dapat menggantikan keseluruhan software yang diinstal sebelumnya pada perangkat. Misalnya, salah satu pendekatan berikut akan memenuhi persyaratan ini:

  • Download “over the air (OTA)” dengan update offline melalui reboot.
  • Pembaruan “Tethered” melalui USB dari PC host.
  • Update “Offline” melalui reboot dan update dari file pada penyimpanan yang dapat dilepas.

• [C-0-2] Mekanisme update yang digunakan HARUS mendukung update tanpa menghapus total data pengguna. Artinya, mekanisme update HARUS mempertahankan data pribadi aplikasi dan data bersama aplikasi. Perlu diketahui bahwa software Android upstream menyertakan mekanisme update yang memenuhi persyaratan ini.

Jika implementasi perangkat menyertakan dukungan untuk koneksi data tidak berbayar seperti profil 802.11 atau Bluetooth PAN (Personal Area Network), aplikasi tersebut:

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

Untuk implementasi perangkat yang diluncurkan dengan Android 6.0 dan yang lebih baru, mekanisme update SEHARUSNYA mendukung verifikasi bahwa image sistem biner identik dengan hasil yang diharapkan setelah OTA. Implementasi OTA berbasis blok di Project Open Source Android upstream, yang ditambahkan sejak Android 5.1, memenuhi persyaratan ini.

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

Jika ditemukan error dalam implementasi perangkat setelah dirilis, tetapi selama masa pakai produk yang wajar yang ditentukan melalui konsultasi dengan Tim Kompatibilitas Android untuk memengaruhi kompatibilitas aplikasi pihak ketiga, maka:

• [C-2-1] Implementasi 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:

• [C-3-1] HARUS menerapkan perilaku yang dijelaskan dalam class SystemUpdatePolicy.

12. Log Perubahan Dokumen

Untuk ringkasan perubahan pada Compatibility Definition dalam rilis ini:

• Log perubahan dokumen

Untuk ringkasan perubahan pada masing-masing bagian:

1. Pengantar
2. Jenis Perangkat
3. Software
4. Pengemasan Aplikasi
5. Multimedia
6. Opsi dan Alat Developer
7. Kompatibilitas Hardware
8. Performa dan Kekuatan
9. Model Keamanan
10. Pengujian Kompatibilitas Software
11. Software yang Dapat Diperbarui
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 tampilan atau kosmetik.

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 mengemukakan masalah apa pun yang menurut Anda tidak dicakup dalam dokumen tersebut.