Definisi Kompatibilitas Android 4.4

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Revisi 1
Terakhir diperbarui: 27 November 2013

Hak Cipta © 2013, Google Inc. Semua hak dilindungi undang-undang.
compatibility@android.com

Daftar Isi

1. Pengantar

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

Penggunaan "harus", "tidak boleh", "wajib", "harus", "tidak boleh", "sebaiknya", "sebaiknya tidak", "direkomendasikan", "boleh", dan "opsional" sesuai dengan standar IETF yang ditentukan dalam RFC2119 [Referensi, 1].

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

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

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

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

2. Referensi

1. Level Persyaratan IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
2. Ringkasan Program Kompatibilitas Android: http://source.android.com/docs/compatibility/index.html
3. Project Open Source Android: http://source.android.com/
4. Definisi dan dokumentasi API: http://developer.android.com/reference/packages.html
5. Referensi Izin Android: http://developer.android.com/reference/android/Manifest.permission.html
6. Referensi android.os.Build: http://developer.android.com/reference/android/os/Build.html
7. String versi yang diizinkan Android 4.4: http://source.android.com/docs/compatibility/4.4/versions.html
8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
9. Akselerasi Hardware: http://developer.android.com/guide/topics/graphics/hardware-accel.html
10. Class android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12. Kemampuan offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline
13. Tag video HTML5: http://dev.w3.org/html5/spec/Overview.html#video
14. Geolocation API HTML5/W3C: http://www.w3.org/TR/geolocation-API/
15. API webstorage HTML5/W3C: http://www.w3.org/TR/webstorage/
16. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
17. Spesifikasi Virtual Machine Dalvik: tersedia dalam kode sumber Android, di dalvik/docs
18. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19. Notifikasi: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20. Resource Aplikasi: http://code.google.com/android/reference/available-resources.html
21. Panduan gaya ikon Status Bar: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
22. Pengelola Penelusuran: http://developer.android.com/reference/android/app/SearchManager.html
23. Toast: http://developer.android.com/reference/android/widget/Toast.html
24. Tema: http://developer.android.com/guide/topics/ui/themes.html
25. Class R.style: http://developer.android.com/reference/android/R.style.html
26. Wallpaper Animasi: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
27. Administrasi Perangkat Android: http://developer.android.com/guide/topics/admin/device-admin.html
28. Referensi DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29. API Layanan Aksesibilitas Android: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
30. Android Accessibility API: http://developer.android.com/reference/android/view/accessibility/package-summary.html
31. Project Eyes Free: http://code.google.com/p/eyes-free
32. Text-To-Speech API: http://developer.android.com/reference/android/speech/tts/package-summary.html
33. Dokumentasi alat referensi (untuk adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html
34. Deskripsi file apk Android: http://developer.android.com/guide/topics/fundamentals.html
35. File manifes: http://developer.android.com/guide/topics/manifest/manifest-intro.html
36. Alat pengujian Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
37. Class android.content.pm.PackageManager Android dan Daftar Fitur Hardware: http://developer.android.com/reference/android/content/pm/PackageManager.html
38. Mendukung Beberapa Layar: http://developer.android.com/guide/practices/screens_support.html
39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
40. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
42. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html
43. Protokol Push NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
50. API orientasi kamera: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51. Kamera: http://developer.android.com/reference/android/hardware/Camera.html
52. Aksesori Terbuka Android: http://developer.android.com/guide/topics/usb/accessory.html
53. USB Host API: http://developer.android.com/guide/topics/usb/host.html
54. Referensi Keamanan dan Izin Android: http://developer.android.com/guide/topics/security/permissions.html
55. Aplikasi untuk Android: http://code.google.com/p/apps-for-android
56. DownloadManager Android: http://developer.android.com/reference/android/app/DownloadManager.html
57. Android File Transfer: http://www.android.com/filetransfer
58. Format Media Android: http://developer.android.com/guide/appendix/media-formats.html
59. Protokol Draf HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
60. NFC Connection Handover: http://www.nfc-forum.org/specs/spec_list/#conn_handover
61. Pemasangan Bluetooth Aman dan Sederhana Menggunakan NFC: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
62. Wi-Fi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
63. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
64. Spesifikasi Pengisian Daya USB: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
65. Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
66. Audio USB Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
67. Setelan Berbagi NFC Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
68. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
69. Widget Layar Kunci dan Layar Utama: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
70. Referensi UserManager: http://developer.android.com/reference/android/os/UserManager.html
71. Referensi Penyimpanan Eksternal: /docs/core/storage
72. External Storage API: http://developer.android.com/reference/android/os/Environment.html
73. Kode Singkat SMS: http://en.wikipedia.org/wiki/Short_code
74. Klien Remote Control Media: http://developer.android.com/reference/android/media/RemoteControlClient.html
75. Pengelola Layar: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
76. Mimpi: http://developer.android.com/reference/android/service/dreams/DreamService.html
77. Setelan Terkait Pengembangan Aplikasi Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
78. Kamera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
79. Ekstensi EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
80. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html
81. Konfigurasi Input Sentuh: http://source.android.com/docs/core/interaction/input/touch-devices.html
82. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/
83. Kompatibilitas WebView: http://www.chromium.org/
84. Aplikasi Pemilik Perangkat Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)
85. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html
86. Persyaratan Coding Hardware RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/
87. Settings.Secure LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE
88. Resolver Konten: http://developer.android.com/reference/android/content/ContentResolver.html
89. SettingInjectorService: http://developer.android.com/reference/android/location/SettingInjectorService.html
90. Emulasi Kartu Berbasis Host: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
91. Penyedia Layanan Telepon: http://developer.android.com/reference/android/provider/Telephony.html

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

3. Software

3.1. Kompatibilitas API Terkelola

Lingkungan eksekusi terkelola (berbasis Dalvik) adalah kendaraan utama untuk aplikasi Android. Application programming interface (API) Android adalah kumpulan antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan VM terkelola. Implementasi perangkat HARUS menyediakan implementasi lengkap, termasuk semua perilaku yang didokumentasikan, dari API yang didokumentasikan yang diekspos oleh Android SDK [Referensi, 4].

Implementasi perangkat TIDAK BOLEH menghilangkan API terkelola, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang didokumentasikan, atau menyertakan no-ops, kecuali jika diizinkan secara khusus oleh Definisi Kompatibilitas ini.

Definisi Kompatibilitas ini mengizinkan beberapa jenis hardware yang Android sertakan API-nya untuk dihilangkan oleh implementasi perangkat. Dalam kasus tersebut, API HARUS tetap ada dan berperilaku dengan cara yang wajar. Lihat Bagian 7 untuk mengetahui persyaratan spesifik untuk skenario ini.

3.2. Kompatibilitas Soft API

Selain API terkelola dari Bagian 3.1, Android juga menyertakan API "soft" khusus runtime yang signifikan, dalam bentuk hal-hal seperti Intent, izin, dan aspek serupa dari aplikasi Android yang tidak dapat diterapkan pada waktu kompilasi aplikasi.

3.2.1. Izin

Implementator perangkat HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan oleh halaman referensi Izin [Referensi, 5]. Perhatikan bahwa Bagian 9 mencantumkan persyaratan tambahan yang terkait dengan model keamanan Android.

3.2.2. Parameter Build

Android API menyertakan sejumlah konstanta pada class android.os.Build [Resources, 6] yang dimaksudkan untuk mendeskripsikan perangkat saat ini. 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	Komentar
VERSION.RELEASE	Versi sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Kolom ini HARUS memiliki salah satu nilai string yang ditentukan di [Referensi, 7].
VERSION.SDK	Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 4.4, kolom ini HARUS memiliki nilai bilangan bulat 19.
VERSION.SDK_INT	Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 4.4, kolom ini HARUS memiliki nilai bilangan bulat 19.
VERSION.INCREMENTAL	Nilai yang dipilih oleh implementator perangkat yang menetapkan build tertentu sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build yang berbeda yang tersedia bagi pengguna akhir. Penggunaan umum kolom ini adalah untuk menunjukkan nomor build atau ID perubahan kontrol sumber yang digunakan untuk membuat build. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
PAPAN	Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi hardware internal tertentu yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan kolom ini adalah untuk menunjukkan revisi spesifik dari board yang memberi daya pada perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
BRAND	Nilai yang mencerminkan nama merek yang terkait dengan perangkat seperti yang diketahui oleh pengguna akhir. HARUS dalam format yang dapat dibaca manusia dan HARUS mewakili produsen perangkat atau merek perusahaan tempat perangkat dipasarkan. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
CPU_ABI	Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat Bagian 3.3: Kompatibilitas API Native.
CPU_ABI2	Nama set petunjuk kedua (jenis CPU + konvensi ABI) dari kode native. Lihat Bagian 3.3: Kompatibilitas API Native.
PERANGKAT	Nilai yang dipilih oleh implementer perangkat yang berisi nama pengembangan atau nama kode yang mengidentifikasi konfigurasi fitur hardware dan desain industri perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
SIdik jari	String yang mengidentifikasi build ini secara unik. File ini HARUS dapat dibaca manusia dengan cukup baik. Template ini HARUS mengikuti template ini: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Misalnya: acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys Sidik jari TIDAK BOLEH menyertakan karakter spasi kosong. Jika kolom lain yang disertakan dalam template di atas memiliki karakter spasi kosong, kolom tersebut HARUS diganti dalam sidik jari build dengan karakter lain, seperti karakter garis bawah ("_"). Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit.
PERANGKAT KERAS	Nama hardware (dari command line kernel atau /proc). File ini HARUS dapat dibaca manusia secara wajar. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
PENYELENGGARA	String yang secara unik mengidentifikasi host tempat build dibuat, dalam format yang dapat dibaca manusia. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
ID	ID yang dipilih oleh implementator perangkat untuk merujuk ke rilis tertentu, dalam format yang dapat dibaca manusia. Kolom ini dapat sama dengan android.os.Build.VERSION.INCREMENTAL, tetapi HARUS berupa nilai yang cukup bermakna bagi pengguna akhir untuk membedakan build software. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
PRODUSEN	Nama dagang Produsen Peralatan Asli (OEM) produk. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
MODEL	Nilai yang dipilih oleh implementator perangkat yang berisi nama perangkat seperti yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama yang digunakan untuk memasarkan dan menjual perangkat kepada pengguna akhir. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
PRODUK	Nilai yang dipilih oleh implementer perangkat yang berisi nama pengembangan atau nama kode produk tertentu (SKU) yang HARUS unik dalam merek yang sama. HARUS dapat dibaca manusia, tetapi tidak selalu dimaksudkan untuk dilihat oleh pengguna akhir. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
SERIAL	Nomor seri hardware, yang HARUS tersedia. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^([a-zA-Z0-9]{6,20})$".
TAG	Daftar tag yang dipisahkan koma yang dipilih oleh implementator perangkat yang lebih lanjut membedakan build. Misalnya, "unsigned,debug". Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
WAKTU	Nilai yang mewakili stempel waktu saat build terjadi.
TYPE	Nilai yang dipilih oleh implementator perangkat yang menentukan konfigurasi runtime build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android standar: "user", "userdebug", atau "eng". Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
PENGGUNA	Nama atau ID pengguna (atau pengguna otomatis) yang membuat build. Tidak ada persyaratan pada format khusus kolom ini, kecuali kolom ini TIDAK BOLEH null atau string kosong ("").

3.2.3. Kompatibilitas Intent

Implementasi perangkat HARUS mematuhi sistem Intent pengaitan longgar Android, seperti yang dijelaskan di bagian di bawah. "Dihormati" berarti bahwa implementer perangkat HARUS menyediakan Aktivitas atau Layanan Android yang menentukan filter Intent yang cocok dan mengikat serta menerapkan perilaku yang benar untuk setiap pola Intent yang ditentukan.

3.2.3.1. Intent Aplikasi Inti

Project upstream Android menentukan sejumlah aplikasi inti, seperti kontak, kalender, galeri foto, pemutar musik, dan sebagainya. Implementator perangkat DAPAT mengganti aplikasi ini dengan versi alternatif.

Namun, setiap versi alternatif tersebut HARUS mematuhi pola Intent yang sama yang disediakan oleh project upstream. Misalnya, jika perangkat berisi pemutar musik alternatif, perangkat tersebut harus tetap mematuhi pola Intent yang dikeluarkan oleh aplikasi pihak ketiga untuk memilih lagu.

Aplikasi berikut dianggap sebagai aplikasi sistem Android inti:

• Jam Meja
• Browser
• Kalender
• Kontak
• Galeri
• GlobalSearch
• Peluncur
• Musik
• Setelan

Aplikasi sistem Android inti mencakup berbagai komponen Aktivitas atau Layanan yang dianggap "publik". Artinya, atribut "android:exported" mungkin tidak ada, atau mungkin memiliki nilai "true".

Untuk setiap Aktivitas atau Layanan yang ditentukan di salah satu aplikasi sistem Android inti yang tidak ditandai sebagai non-publik melalui atribut android:exported dengan nilai "false", implementasi perangkat HARUS menyertakan komponen dari jenis yang sama yang menerapkan pola filter Intent yang sama dengan aplikasi sistem Android inti.

Dengan kata lain, implementasi perangkat DAPAT mengganti aplikasi sistem Android inti; namun, jika demikian, implementasi perangkat HARUS mendukung semua pola Intent yang ditentukan oleh setiap aplikasi sistem Android inti yang diganti.

3.2.3.2. Penggantian Intent

Karena Android adalah platform yang dapat diperluas, implementasi perangkat HARUS mengizinkan setiap pola Intent yang dirujuk di Bagian 3.2.3.1 untuk diganti oleh aplikasi pihak ketiga. Implementasi open source Android upstream mengizinkan hal ini secara default; implementator perangkat TIDAK BOLEH melampirkan hak istimewa khusus ke penggunaan aplikasi sistem terhadap pola Intent ini, atau mencegah aplikasi pihak ketiga untuk mengikat dan mengambil alih kontrol atas pola ini. Larangan ini secara khusus mencakup, tetapi tidak terbatas pada, menonaktifkan antarmuka pengguna "Chooser" yang memungkinkan pengguna memilih antara beberapa aplikasi yang semuanya menangani pola Intent yang sama.

Namun, implementasi perangkat DAPAT menyediakan aktivitas default untuk pola URI tertentu (misalnya, http://play.google.com) jika aktivitas default menyediakan filter yang lebih spesifik untuk URI data. Misalnya, filter intent yang menentukan URI data "http://www.android.com" lebih spesifik daripada filter browser untuk "http://". Implementasi perangkat HARUS menyediakan antarmuka pengguna bagi pengguna untuk mengubah aktivitas default untuk intent.

3.2.3.3. Namespace Intent

Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola Intent baru atau Intent Siaran menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android.* atau com.android.*. Implementer perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola Intent baru atau Intent Penyebaran menggunakan ACTION, KATEGORI, atau string kunci lainnya di ruang paket milik organisasi lain. Implementer perangkat TIDAK BOLEH mengubah atau memperluas pola Intent apa pun yang digunakan oleh aplikasi inti yang tercantum di Bagian 3.2.3.1. Implementasi perangkat DAPAT menyertakan pola Intent menggunakan namespace yang jelas dan jelas terkait dengan organisasinya sendiri.

Larangan ini analog dengan yang ditentukan untuk class bahasa Java di Bagian 3.6.

3.2.3.4. Intent Siaran

Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan Intent tertentu untuk memberi tahu mereka tentang perubahan di lingkungan hardware atau software. Perangkat yang kompatibel dengan Android HARUS menyiarkan Intent siaran publik sebagai respons terhadap peristiwa sistem yang sesuai. Intent Siaran dijelaskan dalam dokumentasi SDK.

3.2.3.5. Setelan Aplikasi Default

Android 4.4 menambahkan setelan yang memungkinkan pengguna memilih aplikasi Layar Utama dan SMS default mereka. Implementasi perangkat HARUS menyediakan menu setelan pengguna yang serupa untuk setiap perangkat, yang kompatibel dengan pola filter Intent dan metode API yang dijelaskan dalam dokumentasi SDK [Referensi, 91].

3.3. Kompatibilitas API Native

3.3.1 Antarmuka Biner Aplikasi

Kode terkelola yang berjalan di Dalvik dapat memanggil kode native yang disediakan dalam file .apk aplikasi sebagai file .so ELF yang dikompilasi untuk arsitektur hardware perangkat yang sesuai. Karena kode native sangat bergantung pada teknologi prosesor yang mendasarinya, Android menentukan sejumlah Antarmuka Biner Aplikasi (ABI) di Android NDK, dalam file docs/CPU-ARCH-ABIS.html. Jika implementasi perangkat kompatibel dengan satu atau beberapa ABI yang ditentukan, implementasi tersebut HARUS menerapkan kompatibilitas dengan Android NDK, seperti di bawah ini.

Jika penerapan perangkat menyertakan dukungan untuk ABI Android, penerapan tersebut:

• HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode native, menggunakan semantik Java Native Interface (JNI) standar
• HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk ABI) dengan setiap library yang diperlukan dalam daftar di bawah
• HARUS melaporkan Antarmuka Biner Aplikasi (ABI) native yang didukung oleh perangkat secara akurat, melalui parameter android.os.Build.CPU_ABI API dan android.os.Build.CPU_ABI2.
• HARUS melaporkan, melalui android.os.Build.CPU_ABI2, hanya ABI tersebut yang didokumentasikan dalam Android NDK versi terbaru, dalam file docs/CPU-ARCH-ABIS.html
• HARUS melaporkan, melalui android.os.Build.CPU_ABI, hanya salah satu ABI yang tercantum di bawah
• armeabi-v7a
• x86
• mips
• HARUS dibuat menggunakan kode sumber dan file header yang tersedia di Project Open Source Android upstream

API kode native berikut HARUS tersedia untuk aplikasi yang menyertakan kode native:

• libc (library C)
• libm (library matematika)
• Dukungan minimal untuk C++
• Antarmuka JNI
• liblog (logging Android)
• libz (Kompresi Zlib)
• libdl (dynamic linker)
• libGLESv1_CM.so (OpenGL ES 1.0)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.0)
• libEGL.so (pengelolaan platform OpenGL native)
• libjnigraphics.so
• libOpenSLES.so (dukungan audio OpenSL ES 1.0.1)
• libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
• libandroid.so (dukungan aktivitas Android native)
• Dukungan untuk OpenGL, seperti yang dijelaskan di bawah

Perhatikan bahwa rilis Android NDK mendatang dapat memperkenalkan dukungan untuk ABI tambahan. Jika implementasi perangkat tidak kompatibel dengan ABI standar yang ada, implementasi tersebut TIDAK BOLEH melaporkan dukungan untuk ABI apa pun.

Perhatikan bahwa implementasi perangkat HARUS menyertakan libGLESv3.so dan HARUS memiliki link symlink (simbolik) ke libGLESv2.so. Pada implementasi perangkat yang mendeklarasikan dukungan untuk OpenGL ES 3.0, libGLESv2.so HARUS mengekspor simbol fungsi OpenGL ES 3.0 selain simbol fungsi OpenGL ES 2.0.

Kompatibilitas kode native sangat sulit. Oleh karena itu, perlu diulang bahwa pengimplementasi perangkat SANGAT disarankan untuk menggunakan implementasi upstream library yang tercantum di atas untuk membantu memastikan kompatibilitas.

3.4. Kompatibilitas Web

3.4.1. Kompatibilitas WebView

Implementasi Open Source Android menggunakan kode dari Project Chromium untuk menerapkan android.webkit.WebView [Resources, 10] . Karena tidak memungkinkan untuk mengembangkan rangkaian pengujian yang komprehensif untuk sistem rendering web, implementer perangkat HARUS menggunakan build upstream Chromium tertentu dalam implementasi WebView. Khususnya:

• Implementasi android.webkit.WebView perangkat HARUS didasarkan pada build Chromium dari Project Open Source Android upstream untuk Android 4.4. Build ini mencakup serangkaian fungsi dan perbaikan keamanan tertentu untuk WebView. [Referensi, 83]
• String agen pengguna yang dilaporkan oleh WebView HARUS dalam format ini:
  Mozilla/5.0 (Linux; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
  • Nilai string $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE.
  • Nilai string $(LOCALE) bersifat opsional, HARUS mengikuti konvensi ISO untuk kode negara dan bahasa, dan HARUS merujuk ke lokalitas perangkat yang dikonfigurasi saat ini. Jika dihilangkan, titik koma di akhir HARUS juga dihapus.
  • Nilai string $(MODEL) HARUS sama dengan nilai untuk android.os.Build.MODEL.
  • Nilai string $(BUILD) HARUS sama dengan nilai untuk android.os.Build.ID.
  • Nilai string $(CHROMIUM_VER) HARUS berupa versi Chromium di Project Open Source Android upstream.
  • Implementasi perangkat DAPAT menghilangkan Mobile dalam string agen pengguna.

Komponen WebView HARUS menyertakan dukungan untuk HTML5 [Referensi, 11] sebanyak mungkin.

3.4.2. Kompatibilitas Browser

Implementasi perangkat HARUS menyertakan aplikasi Browser mandiri untuk penjelajahan web pengguna umum. Browser mandiri DAPAT didasarkan pada teknologi browser selain WebKit. Namun, meskipun aplikasi Browser alternatif digunakan, komponen android.webkit.WebView yang disediakan untuk aplikasi pihak ketiga HARUS didasarkan pada WebKit, seperti yang dijelaskan dalam Bagian 3.4.1.

Implementasi DAPAT mengirimkan string agen pengguna kustom di aplikasi browser mandiri.

Aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream maupun pengganti pihak ketiga) HARUS menyertakan dukungan untuk HTML5 [Referensi, 11] sebanyak mungkin. Minimal, implementasi perangkat HARUS mendukung setiap API berikut yang terkait dengan HTML5:

• cache aplikasi/operasi offline [Referensi, 12]
• tag <video> [Referensi, 13]
• geolocation [Referensi, 14]

Selain itu, implementasi perangkat HARUS mendukung API webstorage HTML5/W3C [Referensi, 15], dan HARUS mendukung API IndexedDB HTML5/W3C [Referensi, 16]. Perhatikan bahwa karena badan standar pengembangan web bertransisi untuk lebih memilih IndexedDB daripada webstorage, IndexedDB diharapkan menjadi komponen yang diperlukan dalam versi Android mendatang.

3.5. Kompatibilitas Perilaku API

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

• Perangkat TIDAK BOLEH mengubah perilaku atau semantik Intent standar
• Perangkat TIDAK BOLEH mengubah siklus proses atau semantik siklus proses jenis komponen sistem tertentu (seperti Layanan, Aktivitas, ContentProvider, dll.)
• Perangkat TIDAK BOLEH mengubah semantik izin standar

Daftar di atas tidak lengkap. Compatibility Test Suite (CTS) menguji sebagian besar platform untuk kompatibilitas perilaku, tetapi tidak semuanya. Implementator bertanggung jawab untuk memastikan kompatibilitas perilaku dengan Android Open Source Project. Oleh karena itu, implementer perangkat HARUS menggunakan kode sumber yang tersedia melalui Project Open Source Android jika memungkinkan, bukan menerapkan ulang bagian penting sistem.

3.6. Namespace API

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

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

Modifikasi yang dilarang mencakup:

• Implementasi perangkat TIDAK BOLEH mengubah API yang diekspos secara publik di platform Android dengan mengubah tanda tangan metode atau class, atau dengan menghapus class atau kolom class.
• Implementer perangkat DAPAT mengubah implementasi API yang mendasarinya, tetapi modifikasi tersebut TIDAK BOLEH memengaruhi perilaku yang dinyatakan dan tanda tangan bahasa Java dari API apa pun yang ditampilkan secara publik.
• Implementer perangkat TIDAK BOLEH menambahkan elemen apa pun yang ditampilkan secara publik (seperti class atau antarmuka, atau kolom atau metode ke class atau antarmuka yang ada) ke API di atas.

"Elemen yang ditampilkan secara publik" adalah konstruksi apa pun yang tidak dihias dengan penanda "@hide" seperti yang digunakan dalam kode sumber Android upstream. Dengan kata lain, implementer perangkat TIDAK BOLEH mengekspos API baru atau mengubah API yang ada di namespace yang disebutkan di atas. Implementator perangkat DAPAT melakukan modifikasi khusus internal, tetapi modifikasi tersebut TIDAK BOLEH diiklankan atau ditampilkan kepada developer.

Implementator perangkat DAPAT menambahkan API kustom, tetapi API tersebut TIDAK BOLEH berada dalam namespace yang dimiliki oleh atau merujuk ke organisasi lain. Misalnya, implementer perangkat TIDAK BOLEH menambahkan API ke namespace com.google.* atau yang serupa; hanya Google yang dapat melakukannya. Demikian pula, Google TIDAK BOLEH menambahkan API ke namespace perusahaan lain. Selain itu, jika implementasi perangkat menyertakan API kustom di luar namespace Android standar, API tersebut HARUS dikemas dalam library bersama Android sehingga hanya aplikasi yang menggunakannya secara eksplisit (melalui mekanisme <uses-library>) yang terpengaruh oleh peningkatan penggunaan memori API tersebut.

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

Perhatikan bahwa batasan di atas sesuai dengan konvensi standar untuk memberi nama 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 Virtual Machine

Implementasi perangkat HARUS mendukung spesifikasi bytecode Dalvik Executable (DEX) lengkap dan semantik Mesin Virtual Dalvik [Referensi, 17].

Implementasi perangkat HARUS mengonfigurasi Dalvik untuk mengalokasikan memori sesuai dengan platform Android upstream, dan seperti yang ditentukan oleh tabel berikut. (Lihat Bagian 7.1.1 untuk mengetahui definisi ukuran layar dan kepadatan layar.)

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

Ukuran Layar	Kepadatan Layar	Memori Aplikasi
kecil / normal / besar	ldpi / mdpi	16MB
kecil / normal / besar	tvdpi / hdpi	32MB
kecil / normal / besar	xhdpi	64MB
kecil / normal / besar	400dpi	96MB
kecil / normal / besar	xxhdpi	128MB
kecil / normal / besar	xxxhdpi	256MB
xlarge	mdpi	32MB
xlarge	tvdpi / hdpi	64MB
xlarge	xhdpi	128MB
xlarge	400dpi	192MB
xlarge	xxhdpi	256MB
xlarge	xxxhdpi	512 MB

3.8. Kompatibilitas Antarmuka Pengguna

3.8.1. Peluncur (Layar Utama)

Android menyertakan aplikasi peluncur (layar utama) dan dukungan untuk aplikasi pihak ketiga guna menggantikan peluncur perangkat (layar utama). Implementasi perangkat yang memungkinkan aplikasi pihak ketiga mengganti layar utama perangkat HARUS mendeklarasikan fitur platform android.software.home_screen.

3.8.2. Widget

Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos "AppWidget" kepada pengguna akhir [Referensi, 18]. Implementasi perangkat yang mendukung penyematan widget di layar utama HARUS memenuhi persyaratan berikut dan mendeklarasikan dukungan untuk fitur platform android.software.app_widgets.

• Peluncur perangkat HARUS menyertakan dukungan bawaan untuk AppWidget, dan mengekspos kemampuan antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus AppWidget langsung dalam Peluncur.
• Implementasi perangkat HARUS dapat merender widget berukuran 4x4 dalam ukuran petak standar. (Lihat Panduan Desain Widget Aplikasi dalam dokumentasi Android SDK [Referensi, 18] untuk mengetahui detailnya.
• Implementasi perangkat yang menyertakan dukungan untuk layar kunci HARUS mendukung widget aplikasi di layar kunci.

3.8.3. Notifikasi

Android menyertakan API yang memungkinkan developer memberi tahu pengguna tentang peristiwa penting [Referensi, 19], menggunakan fitur hardware dan software perangkat.

Beberapa API memungkinkan aplikasi melakukan notifikasi atau menarik perhatian menggunakan hardware, khususnya suara, getaran, dan cahaya. Implementasi perangkat HARUS mendukung notifikasi yang menggunakan fitur hardware, seperti yang dijelaskan dalam dokumentasi SDK, dan sejauh mungkin dengan hardware implementasi perangkat. Misalnya, jika implementasi perangkat menyertakan vibrator, perangkat HARUS menerapkan API getaran dengan benar. Jika implementasi perangkat tidak memiliki hardware, API yang sesuai HARUS diterapkan sebagai no-ops. Perhatikan bahwa perilaku ini dijelaskan lebih lanjut di Bagian 7.

Selain itu, implementasi HARUS merender semua resource (ikon, file suara, dll.) dengan benar yang disediakan di API [Resources, 20], atau dalam panduan gaya ikon Status/Panel Sistem [Resources, 21]. Implementator perangkat DAPAT memberikan pengalaman pengguna alternatif untuk notifikasi selain yang disediakan oleh implementasi Android Open Source referensi; namun, sistem notifikasi alternatif tersebut HARUS mendukung resource notifikasi yang ada, seperti di atas.

Android menyertakan dukungan untuk notifikasi lengkap, seperti View interaktif untuk notifikasi yang sedang berlangsung. Implementasi perangkat HARUS menampilkan dan menjalankan notifikasi lengkap dengan benar, seperti yang didokumentasikan dalam Android API.

3.8.4. Telusuri

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

Implementasi perangkat HARUS menyertakan satu antarmuka pengguna penelusuran secara bersama di seluruh sistem yang mampu memberikan saran real-time sebagai respons terhadap input pengguna. Implementasi perangkat HARUS menerapkan API yang memungkinkan developer menggunakan kembali antarmuka pengguna ini untuk menyediakan penelusuran dalam aplikasi mereka sendiri. Implementasi perangkat HARUS menerapkan API yang memungkinkan aplikasi pihak ketiga menambahkan saran ke kotak penelusuran saat dijalankan dalam mode penelusuran global. Jika tidak ada aplikasi pihak ketiga yang diinstal yang menggunakan fungsi ini, perilaku default HARUS menampilkan hasil dan saran mesin telusur web.

3.8.5. Toast

Aplikasi dapat menggunakan API "Toast" (ditentukan dalam [Referensi, 23]) untuk menampilkan string non-modal singkat kepada pengguna akhir, yang menghilang setelah periode waktu singkat. Implementasi perangkat HARUS menampilkan Toast dari aplikasi ke pengguna akhir dengan cara yang sangat terlihat.

3.8.6. Tema

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

Android menyertakan keluarga tema "Holo" sebagai sekumpulan gaya yang ditentukan untuk digunakan developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema Holo seperti yang ditentukan oleh Android SDK [Referensi, 24]. Implementasi perangkat TIDAK BOLEH mengubah atribut tema Holo apa pun yang ditampilkan ke aplikasi [Resources, 25].

Android juga menyertakan grup tema "Default Perangkat" sebagai kumpulan gaya yang ditentukan untuk digunakan developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema perangkat seperti yang ditentukan oleh pengimplementasi perangkat. Implementasi perangkat DAPAT mengubah atribut tema DeviceDefault yang ditampilkan ke aplikasi [Referensi, 25].

Mulai versi 4.4, Android kini mendukung tema varian baru dengan panel sistem transparan, sehingga developer aplikasi dapat mengisi area di belakang status dan menu navigasi dengan konten aplikasi mereka. Untuk mengaktifkan pengalaman developer yang konsisten dalam konfigurasi ini, gaya ikon status bar harus dipertahankan di berbagai implementasi perangkat. Oleh karena itu, implementasi perangkat Android HARUS menggunakan warna putih untuk ikon status sistem (seperti kekuatan sinyal dan level baterai) dan notifikasi yang dikeluarkan oleh sistem, kecuali jika ikon menunjukkan status yang bermasalah [Referensi, 25].

3.8.7. Wallpaper Animasi

Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos satu atau beberapa "Wallpaper Animasi" kepada pengguna akhir [Referensi, 26]. 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 hidup dengan andal jika dapat menjalankan semua wallpaper hidup, tanpa batasan fungsi, pada framerate yang wajar tanpa dampak buruk pada aplikasi lain. Jika batasan pada hardware menyebabkan wallpaper dan/atau aplikasi mengalami error, malfungsi, menggunakan daya CPU atau baterai secara berlebihan, atau berjalan dengan kecepatan frame yang tidak dapat diterima, hardware dianggap tidak dapat menjalankan wallpaper live. Misalnya, beberapa wallpaper hidup dapat menggunakan konteks Open GL 1.0 atau 2.0 untuk merender kontennya. Wallpaper hidup tidak akan berjalan dengan andal di hardware yang tidak mendukung beberapa konteks OpenGL karena penggunaan wallpaper hidup dari konteks OpenGL dapat bertentangan dengan aplikasi lain yang juga menggunakan konteks OpenGL.

Implementasi perangkat yang mampu menjalankan wallpaper animasi dengan andal seperti yang dijelaskan di atas HARUS menerapkan wallpaper animasi. Implementasi perangkat yang ditentukan untuk tidak menjalankan wallpaper animasi dengan andal seperti yang dijelaskan di atas TIDAK BOLEH menerapkan wallpaper animasi.

3.8.8. Tampilan Aplikasi Terbaru

Kode sumber Android upstream menyertakan antarmuka pengguna untuk menampilkan aplikasi terbaru menggunakan gambar thumbnail status grafis aplikasi pada saat pengguna terakhir kali keluar dari aplikasi. Implementasi perangkat DAPAT mengubah atau menghapus antarmuka pengguna ini; namun, versi Android mendatang direncanakan untuk menggunakan fungsi ini secara lebih luas. Implementasi perangkat sangat disarankan untuk menggunakan antarmuka pengguna Android upstream (atau antarmuka berbasis thumbnail serupa) untuk aplikasi terbaru, atau mungkin tidak kompatibel dengan versi Android mendatang.

3.8.9. Pengelolaan Input

Android menyertakan dukungan untuk Pengelolaan Input dan dukungan untuk editor metode input pihak ketiga. Implementasi perangkat yang memungkinkan pengguna menggunakan metode input pihak ketiga di perangkat HARUS mendeklarasikan fitur platform android.software.input_methods dan mendukung IME API seperti yang ditentukan dalam dokumentasi Android SDK.

Implementasi perangkat yang mendeklarasikan fitur android.software.input_methods HARUS menyediakan mekanisme yang dapat diakses pengguna untuk menambahkan dan mengonfigurasi metode input pihak ketiga. Implementasi perangkat HARUS menampilkan antarmuka setelan sebagai respons terhadap intent android.settings.INPUT_METHOD_SETTINGS.

3.8.10. Remote Kontrol Media Layar Kunci

Android menyertakan dukungan untuk Remote Control API yang memungkinkan aplikasi media berintegrasi dengan kontrol pemutaran yang ditampilkan dalam tampilan jarak jauh seperti layar kunci perangkat [Referensi, 74]. Implementasi perangkat yang mendukung layar kunci di perangkat dan memungkinkan pengguna menambahkan widget di layar utama HARUS menyertakan dukungan untuk menyematkan kontrol jarak jauh di layar kunci perangkat [Referensi, 69].

3.8.11. Mimpi

Android menyertakan dukungan untuk screensaver interaktif yang disebut Dreams [Referensi, 76]. Dreams memungkinkan pengguna berinteraksi dengan aplikasi saat perangkat pengisian daya tidak ada aktivitas, atau disambungkan ke dok meja. Implementasi perangkat HARUS menyertakan dukungan untuk Dreams dan menyediakan opsi setelan bagi pengguna untuk mengonfigurasi Dreams.

3.8.12. Lokasi

Mode lokasi HARUS ditampilkan di menu Lokasi dalam Setelan [Referensi, 87]. Layanan lokasi yang disediakan melalui SettingInjectorService yang diperkenalkan di Android 4.4 harus ditampilkan di menu Lokasi yang sama [Referensi, 89].

3.8.13. Unicode

Android 4.4 menyertakan dukungan untuk karakter emoji warna. Implementasi perangkat Android HARUS menyediakan metode input kepada pengguna untuk karakter Emoji yang ditentukan dalam Unicode 6.1 [Referensi, 82] dan HARUS dapat merender karakter emoji ini dalam glyph warna.

3.9. Administrasi Perangkat

Android menyertakan fitur yang memungkinkan aplikasi yang memahami keamanan untuk menjalankan fungsi administrasi perangkat di tingkat sistem, seperti menerapkan kebijakan sandi atau melakukan penghapusan total jarak jauh, melalui Android Device Administration API [Referensi, 27]. Implementasi perangkat HARUS menyediakan implementasi class DevicePolicyManager [Resources, 28]. Implementasi perangkat yang menyertakan dukungan untuk layar kunci HARUS mendukung berbagai kebijakan pengelolaan perangkat yang ditentukan dalam dokumentasi Android SDK [Referensi, 27].

Implementasi perangkat DAPAT memiliki aplikasi bawaan yang menjalankan fungsi administrasi perangkat, tetapi aplikasi ini TIDAK BOLEH disetel secara otomatis sebagai aplikasi Pemilik Perangkat default [Referensi, 84].

3.10. Aksesibilitas

Android menyediakan lapisan aksesibilitas yang membantu pengguna difabel untuk menjelajahi perangkat mereka dengan lebih mudah. Selain itu, Android menyediakan API platform yang memungkinkan implementasi layanan aksesibilitas menerima callback untuk peristiwa pengguna dan sistem serta menghasilkan mekanisme respons alternatif, seperti text-to-speech, respons haptik, dan navigasi trackball/d-pad [Referensi, 29]. Implementasi perangkat HARUS menyediakan implementasi framework aksesibilitas Android yang konsisten dengan implementasi Android default. Secara khusus, implementasi perangkat HARUS memenuhi persyaratan berikut.

• Implementasi perangkat HARUS mendukung implementasi layanan aksesibilitas pihak ketiga melalui API android.accessibilityservice [Referensi, 30].
• Implementasi perangkat HARUS menghasilkan AccessibilityEvents dan mengirimkan peristiwa ini ke semua implementasi AccessibilityService terdaftar dengan cara yang konsisten dengan implementasi Android default.
• Implementasi perangkat HARUS menyediakan mekanisme yang dapat diakses pengguna untuk mengaktifkan dan menonaktifkan layanan aksesibilitas, dan HARUS menampilkan antarmuka ini sebagai respons terhadap intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

Selain itu, implementasi perangkat HARUS menyediakan implementasi layanan aksesibilitas di perangkat, dan HARUS menyediakan mekanisme bagi pengguna untuk mengaktifkan layanan aksesibilitas selama penyiapan perangkat. Implementasi open source layanan aksesibilitas tersedia dari project Eyes Free [Referensi, 31].

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 [Referensi, 32]. Implementasi perangkat HARUS memenuhi persyaratan berikut yang terkait dengan framework TTS Android:

• Implementasi perangkat HARUS mendukung API framework TTS Android dan HARUS menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat. Perhatikan bahwa software open source Android upstream menyertakan implementasi mesin TTS berfitur lengkap.
• Implementasi perangkat HARUS mendukung penginstalan mesin TTS pihak ketiga.
• Implementasi perangkat HARUS menyediakan antarmuka yang dapat diakses pengguna yang memungkinkan pengguna memilih mesin TTS untuk digunakan di tingkat sistem.

4. Kompatibilitas Pengemasan Aplikasi

Implementasi perangkat HARUS menginstal dan menjalankan file ".apk" Android seperti yang dihasilkan oleh alat "aapt" yang disertakan dalam Android SDK resmi [Referensi, 33].

Implementasi perangkat TIDAK BOLEH memperluas format .apk [Resources, 34], Manifes Android [Resources, 35], bytecode Dalvik [Resources, 17], atau bytecode renderscript sedemikian rupa sehingga mencegah file tersebut diinstal dan berjalan dengan benar di perangkat lain yang kompatibel. Implementator perangkat HARUS menggunakan implementasi upstream referensi Dalvik, dan sistem pengelolaan paket implementasi referensi.

5. Kompatibilitas Multimedia

Implementasi perangkat HARUS menyertakan minimal satu bentuk output audio, seperti speaker, jack headphone, koneksi speaker eksternal, dll.

5.1. Codec Media

Implementasi perangkat HARUS mendukung format media inti yang ditentukan dalam dokumentasi Android SDK [Referensi, 58] kecuali jika secara eksplisit diizinkan dalam dokumen ini. Secara khusus, implementasi perangkat HARUS mendukung format media, encoder, decoder, jenis file, dan format penampung yang ditentukan dalam tabel di bawah. Semua codec ini disediakan sebagai implementasi software dalam implementasi Android yang diinginkan dari Project Open Source Android.

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

Perhatikan bahwa tabel ini tidak mencantumkan persyaratan kecepatan bit tertentu untuk sebagian besar codec video karena hardware perangkat saat ini tidak selalu mendukung kecepatan bit yang dipetakan persis dengan kecepatan bit yang diperlukan yang ditentukan oleh standar yang relevan. Sebagai gantinya, implementasi perangkat HARUS mendukung kecepatan bit tertinggi yang praktis pada hardware, hingga batas yang ditentukan oleh spesifikasi.

Jenis	Format / Codec	Encoder	Decoder	Detail	Jenis File/Format Penampung
Audio	Profil AAC MPEG-4 (AAC LC)	DIPERLUKAN untuk implementasi perangkat yang menyertakan hardware mikrofon dan menentukan android.hardware.microphone.	WAJIB	Dukungan untuk konten mono/stereo/5.0/5.1* dengan frekuensi pengambilan sampel standar dari 8 hingga 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC mentah ADTS (.aac, dekode di Android 3.1+, enkode di Android 4.0+, ADIF tidak didukung) MPEG-TS (.ts, tidak dapat digeser, Android 3.0+)
	Profil MPEG-4 HE AAC (AAC+)	DIPERLUKAN untuk implementasi perangkat yang menyertakan hardware mikrofon dan menentukan android.hardware.microphone	WAJIB	Dukungan untuk konten mono/stereo/5.0/5.1* dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
	Profil MPEG-4 HE AAC v2 (AAC+ ditingkatkan)		WAJIB	Dukungan untuk konten mono/stereo/5.0/5.1* dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
	Jenis Objek Audio MPEG-4 ER AAC ELD (AAC yang Ditingkatkan dengan Delay Rendah)	DIPERLUKAN untuk implementasi perangkat yang menyertakan hardware mikrofon dan menentukan android.hardware.microphone	WAJIB	Dukungan untuk konten mono/stereo dengan frekuensi pengambilan sampel standar dari 16 hingga 48 kHz.
	AMR-NB	DIPERLUKAN untuk implementasi perangkat yang menyertakan hardware mikrofon dan menentukan android.hardware.microphone.	WAJIB	4,75 hingga 12,2 kbps dengan sampel @ 8 kHz	3GPP (.3gp)
	AMR-WB	DIPERLUKAN untuk implementasi perangkat yang menyertakan hardware mikrofon dan menentukan android.hardware.microphone.	WAJIB	9 frekuensi dari 6,60 kbit/dtk hingga 23,85 kbit/dtk dengan sampel @ 16 kHz	3GPP (.3gp)
	FLAC		WAJIB (Android 3.1+)	Mono/Stereo (tanpa multisaluran). Frekuensi sampel hingga 48 kHz (tetapi direkomendasikan hingga 44,1 kHz di perangkat dengan output 44,1 kHz, karena penurun sampel 48 hingga 44,1 kHz tidak menyertakan filter tingkat rendah). Direkomendasikan 16-bit; tidak ada dither yang diterapkan untuk 24-bit.	Hanya FLAC (.flac)
	MP3		WAJIB	Mono/Stereo 8-320 Kbps konstan (CBR) atau kecepatan bit variabel (VBR)	MP3 (.mp3)
	MIDI		WAJIB	MIDI Jenis 0 dan 1. DLS Versi 1 dan 2. XMF dan Mobile XMF. Dukungan untuk format nada dering RTTTL/RTX, OTA, dan iMelody	Jenis 0 dan 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
	Vorbis		WAJIB		Ogg (.ogg) Matroska (.mkv)
	PCM/WAVE	WAJIB	WAJIB	PCM linear 8-bit dan 16-bit** (frekuensi hingga batas hardware). Perangkat HARUS mendukung frekuensi sampling untuk perekaman PCM mentah pada frekuensi 8000, 16.000, dan 44.100 Hz	WAVE (.wav)
Gambar	JPEG	WAJIB	WAJIB	Dasar+progresif	JPEG (.jpg)
	GIF		WAJIB		GIF (.gif)
	PNG	WAJIB	WAJIB		PNG (.png)
	BMP		WAJIB		BMP (.bmp)
	WEBP	WAJIB	WAJIB		WebP (.webp)
Video	H.263	DIPERLUKAN untuk implementasi perangkat yang menyertakan hardware kamera dan menentukan android.hardware.camera atau android.hardware.camera.front.	WAJIB		3GPP (.3gp) MPEG-4 (.mp4)
	H.264 AVC	DIPERLUKAN untuk implementasi perangkat yang menyertakan hardware kamera dan menentukan android.hardware.camera atau android.hardware.camera.front.	WAJIB	Profil Dasar Pengukuran (BP)	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, AAC hanya audio, tidak dapat digeser, Android 3.0+)
	MPEG-4 SP		WAJIB		3GPP (.3gp)
	VP8****	WAJIB (Android 4.3+)	WAJIB (Android 2.3.3+)		WebM (.webm) dan Matroska (.mkv, Android 4.0+)***
	VP9		WAJIB (Android 4.4+)		WebM (.webm) dan Matroska (.mkv, Android 4.0+)***

• *Catatan: Hanya downmix konten 5.0/5.1 yang diperlukan; merekam atau merender lebih dari 2 saluran bersifat opsional.
• **Catatan: Perekaman PCM linear 16-bit wajib dilakukan. Perekaman PCM linear 8-bit tidak wajib.
• ***Catatan: Implementasi perangkat HARUS mendukung penulisan file Matroska WebM.
• ****Catatan: Untuk kualitas streaming video web dan layanan konferensi video yang dapat diterima, implementasi perangkat HARUS menggunakan codec VP8 hardware yang memenuhi persyaratan di [Referensi, 86].

5.2. Encoding Video

Implementasi perangkat Android yang menyertakan kamera belakang dan mendeklarasikan android.hardware.camera HARUS mendukung profil encoding video H.264 berikut.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD (Jika didukung oleh hardware)
Resolusi video	176 x 144 px	480 x 360 px	1280 x 720 px
Frekuensi gambar video	12 fps	30 fps	30 fps
Kecepatan bit video	56 Kbps	500 Kbps atau lebih tinggi	2 Mbps atau lebih tinggi
Codec audio	AAC-LC	AAC-LC	AAC-LC
Saluran audio	1 (mono)	2 (stereo)	2 (stereo)
Kecepatan bit audio	24 Kbps	128 Kbps	192 Kbps

Implementasi perangkat Android yang menyertakan kamera belakang dan mendeklarasikan android.hardware.camera HARUS mendukung profil encoding video VP8 berikut

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p (Jika didukung oleh hardware)	HD 1080p (Jika didukung oleh hardware)
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.3. Dekode Video

Implementasi perangkat Android HARUS mendukung profil decoding video VP8, VP9, dan H.264 berikut. Penerapan perangkat JUGA HARUS mendukung peralihan resolusi video dinamis dalam streaming yang sama untuk codec VP8, VP9, dan H.264.

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD 720p (Jika didukung oleh hardware)	HD 1080p (Jika didukung oleh hardware)
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	8 Mbps	20 Mbps

5.4. Perekaman Audio

Saat aplikasi telah menggunakan android.media.AudioRecord API untuk mulai merekam streaming audio, implementasi perangkat yang menyertakan hardware mikrofon dan mendeklarasikan android.hardware.microphone HARUS mengambil sampel dan merekam audio dengan setiap perilaku berikut:

• Perangkat HARUS menunjukkan karakteristik amplitudo versus frekuensi yang kira-kira datar; khususnya, ±3 dB, dari 100 Hz hingga 4.000 Hz
• Sensitivitas input audio HARUS disetel sedemikian rupa sehingga sumber level daya suara (SPL) 90 dB pada 1.000 Hz menghasilkan RMS 2.500 untuk sampel 16-bit.
• Level amplitudo PCM HARUS melacak perubahan SPL input secara linear setidaknya dalam rentang 30 dB dari -18 dB hingga +12 dB re 90 dB SPL di mikrofon.
• Total harmonic distortion HARUS kurang dari 1% untuk 1 KHz pada level input SPL 90 dB.

Selain spesifikasi perekaman di atas, saat aplikasi telah mulai merekam streaming audio menggunakan sumber audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

• Pemrosesan pengurangan bising, jika ada, HARUS dinonaktifkan.
• Automatic gain control, jika ada, HARUS dinonaktifkan.

Dari Android 4.4, class android.media.MediaRecorder.AudioSource memiliki sumber audio baru: REMOTE_SUBMIX. Perangkat HARUS menerapkan sumber audio REMOTE_SUBMIX dengan benar sehingga saat aplikasi menggunakan android.media.AudioRecord API untuk merekam dari sumber audio ini, aplikasi dapat merekam campuran semua streaming audio kecuali untuk hal berikut:

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

Catatan: meskipun beberapa persyaratan yang diuraikan di atas dinyatakan sebagai "HARUS" sejak Android 4.3, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi "HARUS". Artinya, persyaratan ini bersifat opsional di Android 4.4, tetapi akan diperlukan oleh versi mendatang. Perangkat yang ada dan baru yang menjalankan Android sangat disarankan untuk memenuhi persyaratan ini, atau perangkat tersebut tidak akan dapat mencapai kompatibilitas Android saat diupgrade ke versi mendatang.

Jika platform mendukung teknologi peredam bising yang disesuaikan untuk pengenalan ucapan, efeknya HARUS dapat dikontrol dari android.media.audiofx.NoiseSuppressor API. Selain itu, kolom "uuid" untuk deskripsi efek peredam bising HARUS mengidentifikasi secara unik setiap implementasi teknologi peredam bising.

5.5. Latensi Audio

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

Untuk tujuan bagian ini:

• "latensi output" didefinisikan sebagai interval antara saat aplikasi menulis frame data yang dienkode PCM dan saat suara yang sesuai dapat didengar oleh pemroses eksternal atau diamati oleh transduser
• "latensi output dingin" didefinisikan sebagai latensi output untuk frame pertama, saat sistem output audio tidak ada aktivitas dan dimatikan sebelum permintaan
• "latensi output kontinu" ditentukan sebagai latensi output untuk frame berikutnya, setelah perangkat sudah memutar audio
• "latensi input" adalah interval antara saat suara eksternal ditampilkan ke perangkat dan saat aplikasi membaca frame data berkode PCM yang sesuai
• "cold input latency" didefinisikan sebagai 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" didefinisikan sebagai latensi input untuk frame berikutnya, saat perangkat sudah merekam audio
• "OpenSL ES PCM buffer queue API" adalah kumpulan OpenSL ES API terkait PCM dalam Android NDK; lihat NDK_root/docs/opensles/index.html

Sesuai dengan Bagian 5, semua implementasi perangkat yang kompatibel HARUS menyertakan minimal satu bentuk output audio. Implementasi perangkat HARUS memenuhi atau melebihi persyaratan latensi output berikut:

• latensi output cold 100 milidetik atau kurang
• latensi output kontinu sebesar 45 milidetik atau kurang

Jika implementasi perangkat memenuhi persyaratan bagian ini setelah kalibrasi awal saat menggunakan API antrean buffer PCM OpenSL ES, untuk latensi output berkelanjutan dan latensi output dingin di setidaknya satu perangkat output audio yang didukung, perangkat DAPAT melaporkan dukungan untuk audio latensi rendah, dengan melaporkan fitur "android.hardware.audio.low-latency" melalui class android.content.pm.PackageManager. [Referensi, 37] Sebaliknya, jika implementasi perangkat tidak memenuhi persyaratan ini, perangkat TIDAK BOLEH melaporkan dukungan untuk audio latensi rendah.

Sesuai dengan Bagian 7.2.5, hardware mikrofon dapat dihilangkan oleh implementasi perangkat.

Implementasi perangkat yang menyertakan hardware mikrofon dan mendeklarasikan android.hardware.microphone HARUS memenuhi persyaratan latensi audio input ini:

• latensi input cold 100 milidetik atau kurang
• latensi input berkelanjutan sebesar 50 milidetik atau kurang

5.6. Protokol Jaringan

Perangkat HARUS mendukung protokol jaringan media untuk pemutaran audio dan video seperti yang ditentukan dalam dokumentasi Android SDK [Referensi, 58]. Secara khusus, perangkat HARUS mendukung protokol jaringan media berikut:

• RTSP (RTP, SDP)
• Streaming progresif HTTP(S)
• Protokol draf Streaming Live HTTP(S), Versi 3 [Referensi, 59]

6. Kompatibilitas Alat dan Opsi Developer

6.1. Alat Pengembang

Implementasi perangkat HARUS mendukung Alat Developer Android yang disediakan di Android SDK. Secara khusus, perangkat yang kompatibel dengan Android HARUS kompatibel dengan:

• Android Debug Bridge (dikenal sebagai adb) [Referensi, 33]
  Implementasi perangkat HARUS mendukung semua fungsi adb seperti yang didokumentasikan dalam Android SDK. Daemon adb sisi perangkat HARUS tidak aktif secara default, dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Android Debug Bridge.
• Android menyertakan dukungan untuk adb aman. adb aman mengaktifkan adb di host terautentikasi yang diketahui. Implementasi perangkat HARUS mendukung adb aman.
• Dalvik Debug Monitor Service (dikenal sebagai ddms) [Referensi, 33]
  Implementasi perangkat HARUS mendukung semua fitur ddms seperti yang didokumentasikan dalam Android SDK. Karena ddms menggunakan adb, dukungan untuk ddms HARUS tidak aktif secara default, tetapi HARUS didukung setiap kali pengguna mengaktifkan Android Debug Bridge, seperti di atas.
• Monkey [Referensi, 36]
  Implementasi perangkat HARUS menyertakan framework Monkey, dan membuatnya tersedia untuk digunakan aplikasi.
• SysTrace [Referensi, 33]
  Implementasi perangkat HARUS mendukung alat systrace seperti yang didokumentasikan dalam Android SDK. Systrace harus tidak aktif secara default, dan HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Systrace.

Sebagian besar sistem berbasis Linux dan sistem Apple Macintosh mengenali perangkat Android menggunakan alat Android SDK standar, tanpa dukungan tambahan; tetapi sistem Microsoft Windows biasanya memerlukan driver untuk perangkat Android baru. (Misalnya, ID vendor baru dan terkadang ID perangkat baru memerlukan driver USB kustom untuk sistem Windows.) Jika implementasi perangkat tidak dikenali oleh alat adb seperti yang disediakan di SDK Android standar, pengimplementasi perangkat HARUS menyediakan driver Windows yang memungkinkan developer terhubung ke perangkat menggunakan protokol adb. Driver ini HARUS disediakan untuk Windows XP, Windows Vista, Windows 7, dan Windows 8, dalam versi 32-bit dan 64-bit.

6.2. Opsi Developer

Android menyertakan dukungan bagi developer untuk mengonfigurasi setelan terkait pengembangan aplikasi. Implementasi perangkat HARUS mematuhi intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS untuk menampilkan setelan terkait pengembangan aplikasi [Referensi, 77]. Implementasi Android upstream menyembunyikan menu Opsi Developer secara default, dan memungkinkan pengguna meluncurkan Opsi Developer setelah menekan tujuh (7) kali pada item menu Setelan > Tentang Perangkat > Nomor Build. Implementasi perangkat HARUS memberikan pengalaman yang konsisten untuk Opsi Developer. Secara khusus, implementasi perangkat HARUS menyembunyikan Opsi Developer secara default dan HARUS menyediakan mekanisme untuk mengaktifkan Opsi Developer yang konsisten dengan implementasi Android upstream.

6.2.1. Eksperimental

Android 4.4 memperkenalkan ART, runtime Android eksperimental, yang dapat diakses dalam menu Opsi Developer untuk pratinjau. Implementasi perangkat HARUS menyertakan ART (libart.so) dan mendukung booting ganda dari Opsi Developer, tetapi HARUS mempertahankan Dalvik (libdvm.so) sebagai runtime default.

7. Kompatibilitas Hardware

Jika perangkat menyertakan komponen hardware tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, implementasi perangkat HARUS menerapkan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK. Jika API di SDK berinteraksi dengan komponen hardware yang dinyatakan sebagai opsional dan implementasi perangkat tidak memiliki komponen tersebut:

• definisi class lengkap (seperti yang didokumentasikan oleh SDK) untuk API komponen HARUS tetap ada
• perilaku API HARUS diimplementasikan sebagai no-ops dengan cara yang wajar
• Metode API HARUS menampilkan nilai null jika diizinkan oleh dokumentasi SDK
• Metode API HARUS menampilkan implementasi no-op class jika nilai null tidak diizinkan oleh dokumentasi SDK
• Metode API TIDAK BOLEH menampilkan pengecualian yang tidak didokumentasikan oleh dokumentasi SDK

Contoh umum skenario tempat persyaratan ini berlaku adalah telephony API: bahkan di perangkat non-ponsel, API ini harus diimplementasikan sebagai no-ops yang wajar.

Implementasi perangkat HARUS melaporkan informasi konfigurasi hardware yang akurat secara akurat melalui metode getSystemAvailableFeatures() dan hasSystemFeature(String) di class android.content.pm.PackageManager. [Referensi, 37]

7.1. Layar dan Grafis

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

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

• "Ukuran diagonal fisik" adalah jarak dalam inci antara dua sudut yang berlawanan dari bagian layar yang diterangi.
• "dpi" (yang berarti "titik per inci") adalah jumlah piksel yang dicakup oleh rentang horizontal atau vertikal linear 1". Jika nilai dpi dicantumkan, dpi horizontal dan vertikal harus berada dalam rentang.
• "Rasio aspek" adalah rasio dimensi layar yang lebih panjang dengan dimensi yang lebih pendek. Misalnya, layar berukuran 480x854 piksel akan menjadi 854 / 480 = 1,779, atau kira-kira "16:9".
• "Piksel kepadatan mandiri" atau ("dp") adalah satuan piksel virtual yang dinormalisasi ke layar 160 dpi, yang dihitung sebagai: pixels = dps * (density / 160).

7.1.1. Konfigurasi Layar

Ukuran Layar

Framework UI Android mendukung berbagai ukuran layar, dan memungkinkan aplikasi mengkueri ukuran layar perangkat (alias "tata letak layar") melalui android.content.res.Configuration.screenLayout dengan SCREENLAYOUT_SIZE_MASK. Implementasi perangkat HARUS melaporkan ukuran layar yang benar seperti yang ditentukan dalam dokumentasi Android SDK [Referensi, 38] dan ditentukan oleh platform Android upstream. Secara khusus, implementasi perangkat harus melaporkan ukuran layar yang benar sesuai dengan dimensi layar piksel kepadatan mandiri (dp) logis berikut.

• Perangkat HARUS memiliki ukuran layar minimal 426 dp x 320 dp ('kecil')
• Perangkat yang melaporkan ukuran layar 'normal' HARUS memiliki ukuran layar minimal 480 dp x 320 dp
• Perangkat yang melaporkan ukuran layar 'besar' HARUS memiliki ukuran layar minimal 640 dp x 480 dp
• Perangkat yang melaporkan ukuran layar 'xlarge' HARUS memiliki ukuran layar minimal 960 dp x 720 dp

Selain itu, perangkat HARUS memiliki ukuran layar minimal 2,5 inci ukuran diagonal fisik.

Perangkat TIDAK BOLEH mengubah ukuran layar yang dilaporkan kapan saja.

Aplikasi secara opsional menunjukkan ukuran layar yang didukung melalui atribut <supports-screens> dalam file AndroidManifest.xml. Implementasi perangkat HARUS mematuhi dukungan yang dinyatakan aplikasi untuk layar kecil, normal, besar, dan ekstra besar dengan benar, seperti yang dijelaskan dalam dokumentasi Android SDK.

Rasio Aspek Layar

Rasio aspek HARUS berupa nilai dari 1,3333 (4:3) hingga 1,86 (kira-kira 16:9)

Kepadatan Layar

Framework UI Android menentukan serangkaian kepadatan logis standar untuk membantu developer aplikasi menargetkan resource aplikasi. Implementasi perangkat HARUS melaporkan salah satu kepadatan framework Android logis berikut melalui API android.util.DisplayMetrics, dan HARUS menjalankan aplikasi pada kepadatan standar ini.

• 120 dpi, yang dikenal sebagai 'ldpi'
• 160 dpi, yang dikenal sebagai 'mdpi'
• 213 dpi, yang dikenal sebagai 'tvdpi'
• 240 dpi, yang dikenal sebagai 'hdpi'
• 320 dpi, yang dikenal sebagai 'xhdpi'
• 400 dpi, dikenal sebagai '400dpi'
• 480 dpi, yang dikenal sebagai 'xxhdpi'
• 640 dpi, yang dikenal sebagai 'xxxhdpi'

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

7.1.2. Metrik Display

Implementasi perangkat HARUS melaporkan nilai yang benar untuk semua metrik tampilan yang ditentukan di android.util.DisplayMetrics [Resource, 39].

7.1.3. Orientasi Layar

Perangkat HARUS mendukung orientasi dinamis oleh aplikasi untuk orientasi layar potret atau lanskap. Artinya, perangkat harus mengikuti permintaan aplikasi untuk orientasi layar tertentu. Implementasi perangkat DAPAT memilih orientasi potret atau lanskap sebagai default.

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

Perangkat TIDAK BOLEH mengubah ukuran atau kepadatan layar yang dilaporkan saat mengubah orientasi.

Perangkat HARUS melaporkan orientasi layar yang didukung ( android.hardware.screen.portrait dan/atau android.hardware.screen.landscape) dan HARUS melaporkan minimal satu orientasi yang didukung. Misalnya, perangkat dengan layar lanskap orientasi tetap, seperti televisi atau laptop, HANYA BOLEH melaporkan android.hardware.screen.landscape.

7.1.4. Akselerasi Grafis 2D dan 3D

Implementasi perangkat HARUS mendukung OpenGL ES 1.0 dan 2.0, seperti yang diwujudkan dan dijelaskan dalam dokumentasi Android SDK. Implementasi perangkat HARUS mendukung OpenGL ES 3.0 di perangkat yang mampu mendukung OpenGL ES 3.0. Implementasi perangkat JUGA HARUS mendukung Android Renderscript, seperti yang dijelaskan dalam dokumentasi Android SDK [Referensi, 8].

Implementasi perangkat JUGA HARUS mengidentifikasi dirinya dengan benar sebagai mendukung OpenGL ES 1.0, OpenGL ES 2.0, atau OpenGL ES 3.0. Artinya:

• API terkelola (seperti melalui metode GLES10.getString()) HARUS melaporkan dukungan untuk OpenGL ES 1.0 dan OpenGL ES 2.0
• API OpenGL C/C++ native (yaitu, yang tersedia untuk aplikasi melalui libGLES_v1CM.so, libGLES_v2.so, atau libEGL.so) HARUS melaporkan dukungan untuk OpenGL ES 1.0 dan OpenGL ES 2.0.
• Implementasi perangkat yang mendeklarasikan dukungan untuk OpenGL ES 3.0 HARUS mendukung API terkelola OpenGL ES 3.0 dan menyertakan dukungan untuk API C/C++ native. Pada implementasi perangkat yang mendeklarasikan dukungan untuk OpenGL ES 3.0, libGLESv2.so HARUS mengekspor simbol fungsi OpenGL ES 3.0 selain simbol fungsi OpenGL ES 2.0.

Implementasi perangkat DAPAT menerapkan ekstensi OpenGL ES yang diinginkan. Namun, implementasi perangkat HARUS melaporkan melalui API native dan yang dikelola OpenGL ES semua string ekstensi yang didukungnya, dan sebaliknya HARUS TIDAK melaporkan string ekstensi yang tidak didukungnya.

Perhatikan bahwa Android menyertakan dukungan untuk aplikasi agar secara opsional menentukan bahwa aplikasi memerlukan format kompresi tekstur OpenGL tertentu. Format ini biasanya khusus vendor. Implementasi perangkat tidak diperlukan oleh Android untuk menerapkan format kompresi tekstur tertentu. Namun, format kompresi tekstur yang didukung harus dilaporkan secara akurat, melalui metode getString() di OpenGL API.

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 [Referensi, 9].

Di Android 4.4, implementasi perangkat HARUS mengaktifkan akselerasi hardware secara default, dan HARUS menonaktifkan akselerasi hardware jika developer memintanya dengan menetapkan android:hardwareAccelerated="false" atau menonaktifkan akselerasi hardware secara langsung melalui Android View API.

Selain itu, implementasi perangkat HARUS menunjukkan perilaku yang konsisten dengan dokumentasi Android SDK tentang akselerasi hardware [Referensi, 9].

Android menyertakan objek TextureView yang memungkinkan developer mengintegrasikan tekstur OpenGL ES yang diakselerasi hardware secara langsung sebagai target rendering dalam hierarki UI. Implementasi perangkat HARUS mendukung TextureView API, dan HARUS menunjukkan perilaku yang konsisten dengan implementasi Android upstream.

Android menyertakan dukungan untuk EGL_ANDROID_RECORDABLE, atribut EGLConfig yang menunjukkan apakah EGLConfig mendukung rendering ke ANativeWindow yang merekam gambar ke video. Implementasi perangkat HARUS mendukung ekstensi EGL_ANDROID_RECORDABLE [Referensi, 79].

7.1.5. Mode Kompatibilitas Aplikasi Lama

Android menentukan "mode kompatibilitas" tempat framework beroperasi dalam mode ukuran layar 'normal' yang setara (lebar 320 dp) untuk manfaat aplikasi lama yang tidak dikembangkan untuk Android versi lama yang lebih lama dari independensi ukuran layar. Implementasi perangkat 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.1.6. Jenis Layar

Layar penerapan perangkat diklasifikasikan sebagai salah satu dari dua jenis:

• Implementasi layar piksel tetap: layar adalah satu panel yang hanya mendukung lebar dan tinggi satu piksel. Biasanya layar terintegrasi secara fisik dengan perangkat. Contohnya termasuk ponsel, tablet, dan sebagainya.
• Implementasi layar piksel variabel: implementasi perangkat tidak memiliki layar tersemat dan menyertakan port output video seperti VGA, HDMI, atau port nirkabel untuk layar, atau memiliki layar tersemat yang dapat mengubah dimensi piksel. Contohnya meliputi televisi, dekoder, dan sebagainya.

Implementasi Perangkat Piksel Tetap

Implementasi perangkat piksel tetap DAPAT menggunakan layar dari dimensi piksel apa pun, asalkan memenuhi persyaratan yang ditentukan dalam Definisi Kompatibilitas ini.

Implementasi piksel tetap DAPAT menyertakan port output video untuk digunakan dengan layar eksternal. Namun, jika layar tersebut pernah digunakan untuk menjalankan aplikasi, perangkat HARUS memenuhi persyaratan berikut:

• Perangkat HARUS melaporkan konfigurasi layar dan metrik tampilan yang sama, seperti yang dijelaskan di Bagian 7.1.1 dan 7.1.2, seperti layar piksel tetap.
• Perangkat HARUS melaporkan kepadatan logis yang sama dengan layar piksel tetap.
• Perangkat HARUS melaporkan dimensi layar yang sama dengan, atau sangat mirip dengan, layar piksel tetap.

Misalnya, tablet berukuran diagonal 7" dengan resolusi piksel 1024x600 dianggap sebagai implementasi tampilan mdpi besar dengan piksel tetap. Jika berisi port output video yang ditampilkan pada 720p atau 1080p, implementasi perangkat HARUS menskalakan output sehingga aplikasi hanya dieksekusi di jendela mdpi besar, terlepas dari apakah layar piksel tetap atau port output video sedang digunakan.

Implementasi Perangkat Piksel Variabel

Implementasi perangkat piksel variabel HARUS mendukung minimal salah satu dari 1280x720, 1920x1080, atau 3840x2160 (yaitu, 720p, 1080p, atau 4K). Implementasi perangkat dengan layar piksel variabel TIDAK BOLEH mendukung konfigurasi atau mode layar lainnya. Implementasi perangkat dengan layar piksel variabel DAPAT mengubah konfigurasi atau mode layar saat runtime atau waktu booting. Misalnya, pengguna set-top box dapat mengganti layar 720p dengan layar 1080p, dan penerapan perangkat dapat disesuaikan.

Selain itu, implementasi perangkat piksel variabel HARUS melaporkan bucket konfigurasi berikut untuk dimensi piksel ini:

• 1280x720 (juga dikenal sebagai 720p): ukuran layar 'besar', kepadatan 'tvdpi' (213 dpi)
• 1920x1080 (juga dikenal sebagai 1080p): ukuran layar 'besar', kepadatan 'xhdpi' (320 dpi)
• 3840x2160 (juga dikenal sebagai 4K): ukuran layar 'besar', kepadatan 'xxxhdpi' (640 dpi)

Untuk memperjelas, implementasi perangkat dengan dimensi piksel variabel dibatasi hingga 720p, 1080p, atau 4K di Android 4.4, dan HARUS dikonfigurasi untuk melaporkan bucket ukuran dan kepadatan layar seperti yang disebutkan di atas.

7.1.7. Teknologi Layar

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

• Perangkat HARUS mendukung layar yang mampu merender grafis warna 16-bit dan HARUS mendukung layar yang mampu merender grafis warna 24-bit.
• Perangkat HARUS mendukung layar yang mampu merender animasi.
• Teknologi layar yang digunakan HARUS memiliki rasio aspek piksel (PAR) antara 0,9 dan 1,1. Artinya, rasio aspek piksel HARUS mendekati persegi (1,0) dengan toleransi 10%.

7.1.8. Layar Eksternal

Android menyertakan dukungan untuk layar sekunder guna mengaktifkan kemampuan berbagi media dan API developer untuk mengakses layar eksternal. Jika perangkat mendukung layar eksternal melalui koneksi layar tambahan berkabel, nirkabel, atau tersemat, implementasi perangkat HARUS menerapkan API pengelola layar seperti yang dijelaskan dalam dokumentasi Android SDK [Referensi, 75]. Implementasi perangkat yang mendukung output video aman dan mampu mendukung platform aman HARUS mendeklarasikan dukungan untuk Display.FLAG_SECURE. Secara khusus, implementasi perangkat yang mendeklarasikan dukungan untuk Display.FLAG_SECURE, HARUS mendukung HDCP 2.x atau yang lebih tinggi untuk layar nirkabel Miracast atau HDCP 1.2 atau yang lebih tinggi untuk layar berkabel. Implementasi open source Android upstream mencakup dukungan untuk layar nirkabel (Miracast) dan berkabel (HDMI) yang memenuhi persyaratan ini.

7.2. Perangkat Masukan

7.2.1. Keyboard

Implementasi perangkat:

• HARUS menyertakan dukungan untuk Framework Pengelolaan Input (yang memungkinkan developer pihak ketiga membuat Mesin Pengelolaan Input - yaitu keyboard virtual) seperti yang dijelaskan di http://developer.android.com
• HARUS menyediakan minimal satu implementasi keyboard virtual (terlepas dari apakah keyboard fisik ada atau tidak)
• DAPAT menyertakan penerapan keyboard virtual tambahan
• DAPAT menyertakan keyboard hardware
• TIDAK BOLEH menyertakan keyboard hardware yang tidak cocok dengan salah satu format yang ditentukan di android.content.res.Configuration.keyboard [Resources, 40] (yaitu, QWERTY, atau 12 tombol)

7.2.2. Navigasi Non-sentuh

Implementasi perangkat:

• DAPAT menghilangkan opsi navigasi non-sentuh (yaitu, dapat menghilangkan trackball, d-pad, atau roda)
• HARUS melaporkan nilai yang benar untuk android.content.res.Configuration.navigation [Resources, 40]
• HARUS menyediakan mekanisme antarmuka pengguna alternatif yang wajar untuk pemilihan dan pengeditan teks, yang kompatibel dengan Mesin Pengelolaan Input. Implementasi open source Android upstream menyertakan mekanisme pemilihan yang sesuai untuk digunakan dengan perangkat yang tidak memiliki input navigasi non-sentuh.

7.2.3. Tombol navigasi

Fungsi Beranda, Terbaru, dan Kembali sangat penting untuk paradigma navigasi Android. Implementasi perangkat HARUS menyediakan fungsi ini kepada pengguna setiap saat saat menjalankan aplikasi. Fungsi ini DAPAT diterapkan melalui tombol fisik khusus (seperti tombol sentuh mekanis atau kapasitif), atau DAPAT diterapkan menggunakan tombol software khusus di bagian yang berbeda dari layar, gestur, panel sentuh, dll. Android mendukung kedua penerapan tersebut. Semua fungsi ini HARUS dapat diakses dengan satu tindakan (misalnya ketuk, klik dua kali, atau gestur) saat terlihat.

Fungsi Kembali dan Terbaru HARUS memiliki tombol atau ikon yang terlihat, kecuali disembunyikan bersama dengan fungsi navigasi lainnya dalam mode layar penuh. Fungsi Rumah HARUS memiliki tombol atau ikon yang terlihat, kecuali jika disembunyikan bersama dengan fungsi navigasi lainnya dalam mode layar penuh.

Fungsi Menu tidak digunakan lagi dan diganti dengan panel tindakan sejak Android 4.0. Implementasi perangkat TIDAK BOLEH menerapkan tombol fisik khusus untuk fungsi Menu. Jika tombol Menu fisik diterapkan dan perangkat menjalankan aplikasi dengan targetSdkVersion > 10, implementasi perangkat:

• untuk perangkat yang diluncurkan dengan Android 4.4, HARUS menampilkan tombol tambahan tindakan di panel tindakan saat panel tindakan terlihat dan pop-up menu tambahan tindakan yang dihasilkan tidak kosong.
• untuk perangkat yang sudah ada yang diluncurkan dengan versi sebelumnya, tetapi diupgrade ke Android 4.4, HARUS menampilkan tombol menu tambahan tindakan di panel tindakan saat panel tindakan terlihat dan pop-up menu tambahan tindakan yang dihasilkan tidak kosong.
• TIDAK BOLEH mengubah posisi pop-up tambahan tindakan yang ditampilkan dengan memilih tombol tambahan di panel tindakan.
• DAPAT merender pop-up tambahan tindakan pada posisi yang diubah di layar saat ditampilkan dengan memilih tombol menu fisik.

Untuk kompatibilitas mundur, implementasi perangkat HARUS menyediakan fungsi Menu ke aplikasi saat targetSdkVersion <= 10, baik dengan tombol fisik, tombol software, maupun gestur. Fungsi Menu ini harus ditampilkan kecuali jika disembunyikan bersama dengan fungsi navigasi lainnya.

Android mendukung tindakan Bantuan [Referensi, 63]. Implementasi perangkat HARUS menyediakan tindakan Bantuan kepada pengguna setiap saat saat menjalankan aplikasi. Tindakan Bantuan HARUS diterapkan sebagai penekanan lama pada tombol Layar utama atau gestur geser ke atas pada tombol Layar utama software. Fungsi ini DAPAT diterapkan melalui tombol fisik, tombol software, atau gestur lain, tetapi HARUS dapat diakses dengan satu tindakan (misalnya, ketuk, klik dua kali, atau gestur) saat tombol navigasi lainnya terlihat.

Penerapan perangkat DAPAT menggunakan bagian layar yang berbeda untuk menampilkan tombol navigasi, tetapi jika demikian, HARUS memenuhi persyaratan berikut:

• Tombol navigasi implementasi perangkat HARUS menggunakan bagian layar yang berbeda, tidak tersedia untuk aplikasi, dan TIDAK BOLEH mengaburkan atau mengganggu bagian layar yang tersedia untuk aplikasi.
• Implementasi perangkat HARUS menyediakan sebagian layar untuk aplikasi yang memenuhi persyaratan yang ditentukan dalam Bagian 7.1.1.
• Implementasi perangkat HARUS menampilkan tombol navigasi saat aplikasi tidak menentukan mode UI sistem, atau menentukan SYSTEM_UI_FLAG_VISIBLE.
• Implementasi perangkat HARUS menampilkan tombol navigasi dalam mode "profil rendah" (misalnya, redup) yang tidak mengganggu saat aplikasi menentukan SYSTEM_UI_FLAG_LOW_PROFILE.
• Implementasi perangkat HARUS menyembunyikan tombol navigasi saat aplikasi menentukan SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Input layar sentuh

Implementasi perangkat HARUS memiliki sistem input pointer (seperti mouse, atau sentuh). Namun, jika implementasi perangkat tidak mendukung sistem input pointer, implementasi tersebut TIDAK BOLEH melaporkan konstanta fitur android.hardware.touchscreen atau android.hardware.faketouch. Implementasi perangkat yang menyertakan sistem input pointer:

• HARUS mendukung pointer yang dilacak sepenuhnya secara independen, jika sistem input perangkat mendukung beberapa pointer
• HARUS melaporkan nilai android.content.res.Configuration.touchscreen [Resources, 40] yang sesuai dengan jenis layar sentuh tertentu di perangkat

Android menyertakan dukungan untuk berbagai layar sentuh, touchpad, dan perangkat input sentuh palsu. Implementasi perangkat berbasis layar sentuh dikaitkan dengan layar [Referensi, 81] sehingga pengguna memiliki kesan bahwa mereka langsung memanipulasi item di layar. Karena pengguna langsung menyentuh layar, sistem tidak memerlukan kemampuan tambahan untuk menunjukkan objek yang sedang dimanipulasi. Sebaliknya, 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 menunjuk atau memfokuskan terlebih dahulu, lalu mengklik. Banyak perangkat input seperti mouse, trackpad, mouse udara berbasis giroskop, pointer giroskop, joystick, dan trackpad multi-kontrol dapat mendukung interaksi sentuh palsu. Android 4.0 menyertakan konstanta fitur android.hardware.faketouch, yang sesuai dengan perangkat input non-sentuh fidelitas tinggi (yaitu, berbasis pointer) seperti mouse atau trackpad yang dapat mengemulasi input berbasis sentuhan secara memadai (termasuk dukungan gestur dasar), dan menunjukkan bahwa perangkat mendukung subset fungsi layar sentuh yang diemulasi. Implementasi perangkat yang mendeklarasikan fitur sentuhan palsu HARUS memenuhi persyaratan sentuhan palsu di Bagian 7.2.5.

Implementasi perangkat HARUS melaporkan fitur yang benar sesuai dengan jenis input yang digunakan. Implementasi perangkat yang menyertakan layar sentuh (sentuhan tunggal atau lebih baik) HARUS melaporkan konstanta fitur platform android.hardware.touchscreen. Implementasi perangkat yang melaporkan konstanta fitur platform android.hardware.touchscreen JUGA HARUS melaporkan konstanta fitur platform android.hardware.faketouch. Implementasi perangkat yang tidak menyertakan layar sentuh (dan hanya mengandalkan perangkat pointer) TIDAK BOLEH melaporkan fitur layar sentuh apa pun, dan HANYA BOLEH melaporkan android.hardware.faketouch jika memenuhi persyaratan sentuh palsu di Bagian 7.2.5.

7.2.5. Input sentuh palsu

Implementasi perangkat yang mendeklarasikan dukungan untuk android.hardware.faketouch

• HARUS melaporkan posisi layar X dan Y absolut dari lokasi pointer dan menampilkan pointer visual di layar [Referensi, 80]
• HARUS melaporkan peristiwa sentuh dengan kode tindakan [Resources, 80] yang menentukan perubahan status yang terjadi pada kursor yang beralih ke down atau up di layar [Resources, 80]
• HARUS mendukung pointer down dan up pada objek di layar, yang memungkinkan pengguna mengemulasi ketukan pada objek di layar
• HARUS mendukung pointer down, pointer up, pointer down, lalu pointer up di tempat yang sama pada objek di layar dalam batas waktu, yang memungkinkan pengguna mengemulasi ketuk dua kali pada objek di layar [Referensi, 80]
• HARUS mendukung pointer down pada titik arbitrer di layar, pointer berpindah ke titik arbitrer lainnya di layar, diikuti dengan pointer up, yang memungkinkan pengguna mengemulasi tarik sentuh
• HARUS mendukung pointer down, lalu memungkinkan pengguna memindahkan objek dengan cepat ke posisi lain di layar, lalu pointer up di layar, yang memungkinkan pengguna melempar objek di layar

Perangkat yang mendeklarasikan dukungan untuk android.hardware.faketouch.multitouch.distinct HARUS memenuhi persyaratan untuk faketouch di atas, dan JUGA HARUS mendukung pelacakan yang berbeda dari dua atau beberapa input pointer independen.

7.2.6. Mikrofon

Implementasi perangkat DAPAT menghilangkan mikrofon. Namun, jika implementasi perangkat menghilangkan mikrofon, implementasi tersebut TIDAK BOLEH melaporkan konstanta fitur android.hardware.microphone, dan harus mengimplementasikan API perekaman audio sebagai no-ops, sesuai Bagian 7. Sebaliknya, implementasi perangkat yang memiliki mikrofon:

• HARUS melaporkan konstanta fitur android.hardware.microphone
• HARUS memenuhi persyaratan kualitas audio di Bagian 5.4
• HARUS memenuhi persyaratan latensi audio di Bagian 5.5

7.3. Sensor

Android menyertakan API untuk mengakses berbagai jenis sensor. Implementasi perangkat umumnya DAPAT menghilangkan sensor ini, seperti yang disediakan dalam subbagian berikut. Jika perangkat menyertakan jenis sensor tertentu yang memiliki API yang sesuai untuk developer pihak ketiga, implementasi perangkat HARUS menerapkan API tersebut seperti yang dijelaskan dalam dokumentasi Android SDK. Misalnya, penerapan perangkat:

• HARUS melaporkan keberadaan atau ketiadaan sensor secara akurat sesuai class android.content.pm.PackageManager. [Referensi, 37]
• HARUS menampilkan daftar sensor yang didukung secara akurat melalui SensorManager.getSensorList() dan metode serupa
• HARUS berperilaku wajar untuk semua API sensor lainnya (misalnya, dengan menampilkan true atau false sebagaimana mestinya saat aplikasi mencoba mendaftarkan pemroses, tidak memanggil pemroses sensor saat sensor yang sesuai tidak ada; dll.)
• HARUS melaporkan semua pengukuran sensor menggunakan nilai Sistem Satuan Internasional (yaitu metrik) yang relevan untuk setiap jenis sensor seperti yang ditentukan dalam dokumentasi Android SDK [Referensi, 41]

Daftar di atas tidak lengkap; perilaku yang didokumentasikan dari Android SDK harus dianggap kredibel.

Beberapa jenis sensor bersifat sintetis, yang berarti dapat berasal dari data yang disediakan oleh satu atau beberapa sensor lainnya. (Contohnya mencakup sensor orientasi, dan sensor akselerasi linear.) Implementasi perangkat HARUS menerapkan jenis sensor ini, jika menyertakan sensor fisik prasyarat.

Android menyertakan konsep sensor "streaming", yaitu sensor yang menampilkan data secara terus-menerus, bukan hanya saat data berubah. Implementasi perangkat HARUS terus memberikan sampel data berkala untuk API apa pun yang ditunjukkan oleh dokumentasi Android SDK sebagai sensor streaming. Perhatikan bahwa implementasi perangkat HARUS memastikan bahwa aliran sensor tidak boleh mencegah CPU perangkat memasuki status penangguhan atau aktif dari status penangguhan.

7.3.1. Akselerometer

Implementasi perangkat HARUS menyertakan akselerometer 3 sumbu. Jika implementasi perangkat menyertakan akselerometer 3 sumbu, implementasi tersebut:

• HARUS dapat mengirimkan peristiwa pada kecepatan 120 Hz atau lebih tinggi. Perhatikan bahwa meskipun frekuensi akselerometer di atas dinyatakan sebagai "HARUS" untuk Android 4.4, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi "HARUS". Artinya, standar ini opsional di Android, tetapi akan diperlukan di versi mendatang. Perangkat yang ada dan baru yang menjalankan Android sangat disarankan untuk memenuhi persyaratan ini di Android sehingga perangkat tersebut dapat diupgrade ke rilis platform mendatang
• HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan di Android API (lihat [Referensi, 41])
• HARUS dapat mengukur dari jatuh bebas hingga dua kali gravitasi (2g) atau lebih pada vektor tiga dimensi apa pun
• HARUS memiliki akurasi 8-bit atau lebih
• HARUS memiliki deviasi standar tidak lebih dari 0,05 m/s^2

7.3.2. Magnetometer

Implementasi perangkat HARUS menyertakan magnetometer 3 sumbu (yaitu kompas). Jika perangkat menyertakan magnetometer 3 sumbu, perangkat tersebut:

• HARUS dapat mengirimkan peristiwa pada kecepatan 10 Hz atau lebih tinggi
• HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan di Android API (lihat [Referensi, 41]).
• HARUS dapat mengambil sampel rentang kekuatan medan yang memadai untuk mencakup medan geomagnetik
• HARUS memiliki akurasi 8-bit atau lebih
• HARUS memiliki deviasi standar tidak lebih dari 0,5 µT

7.3.3. GPS

Implementasi perangkat HARUS menyertakan penerima GPS. Jika implementasi perangkat menyertakan penerima GPS, implementasi tersebut HARUS menyertakan beberapa bentuk teknik "GPS berbantuan" untuk meminimalkan waktu penguncian GPS.

7.3.4. Giroskop

Implementasi perangkat HARUS menyertakan giroskop (yaitu sensor perubahan sudut). Perangkat TIDAK BOLEH menyertakan sensor giroskop kecuali jika akselerometer 3 sumbu juga disertakan. Jika implementasi perangkat menyertakan giroskopi, perangkat tersebut:

• HARUS memiliki kompensasi suhu.
• HARUS dapat mengukur perubahan orientasi hingga 5, 5*Pi radian/detik (yaitu,sekitar 1.000 derajat per detik).
• HARUS dapat mengirimkan peristiwa pada 200 Hz atau lebih tinggi. Perhatikan bahwa meskipun frekuensi giroskop di atas dinyatakan sebagai "HARUS" untuk Android 4.4, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi "HARUS". Artinya, standar ini opsional di Android, tetapi akan diperlukan di versi mendatang. Perangkat lama dan baru yang menjalankan Android sangat disarankan untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang.
• HARUS memiliki akurasi 12-bit atau lebih
• HARUS memiliki varians tidak lebih besar dari 1e-7 rad^2 / s^2 per Hz (varians per Hz, atau rad^2 / s). Varians diizinkan untuk bervariasi dengan frekuensi sampling, tetapi harus dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varians giroskop pada frekuensi sampling 1 Hz, nilainya tidak boleh lebih besar dari 1e-7 rad^2/s^2.
• HARUS memiliki stempel waktu yang sedekat mungkin dengan waktu terjadinya peristiwa hardware. Latensi konstan harus dihapus.

7.3.5. Barometer

Implementasi perangkat DAPAT menyertakan barometer (yaitu sensor tekanan udara sekitar). Jika implementasi perangkat menyertakan barometer, perangkat tersebut:

• HARUS dapat mengirimkan peristiwa pada 5 Hz atau lebih
• HARUS memiliki presisi yang memadai untuk memungkinkan estimasi ketinggian
• HARUS memiliki kompensasi suhu

7.3.6. Thermometer

Implementasi perangkat DAPAT menyertakan termometer ambien (yaitu sensor suhu). Jika ada, SENSOR INI HARUS ditentukan sebagai SENSOR_TYPE_AMBIENT_TEMPERATURE dan HARUS mengukur suhu ruangan sekitar dalam derajat Celcius.

Implementasi perangkat DAPAT tetapi TIDAK BOLEH menyertakan sensor suhu CPU. Jika ada, SENSOR_TYPE_TEMPERATURE HARUS ditentukan sebagai SENSOR_TYPE_TEMPERATURE, HARUS mengukur suhu CPU perangkat, dan TIDAK BOLEH mengukur suhu lainnya. Perhatikan bahwa jenis sensor SENSOR_TYPE_TEMPERATURE tidak digunakan lagi di Android 4.0.

7.3.7. Fotometer

Implementasi perangkat DAPAT menyertakan fotometer (yaitu sensor cahaya ambien).

7.3.8. Sensor Kedekatan

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

7.4. Konektivitas Data

7.4.1. Telepon

"Telepon" seperti yang digunakan oleh Android API dan dokumen ini merujuk khusus pada hardware yang terkait dengan melakukan panggilan suara dan mengirim pesan SMS melalui jaringan GSM atau CDMA. Meskipun panggilan suara ini mungkin atau mungkin tidak di-packet-switch, panggilan tersebut untuk tujuan Android dianggap terlepas dari konektivitas data apa pun yang dapat diterapkan menggunakan jaringan yang sama. Dengan kata lain, fungsi "telepon" dan API Android merujuk khusus pada panggilan suara dan SMS; misalnya, implementasi perangkat yang tidak dapat melakukan panggilan atau mengirim/menerima pesan SMS TIDAK BOLEH melaporkan fitur "android.hardware.telephony" atau sub-fitur apa pun, terlepas dari apakah fitur tersebut menggunakan jaringan seluler untuk konektivitas data.

Android DAPAT digunakan di perangkat yang tidak menyertakan hardware telefoni. Artinya, Android kompatibel dengan perangkat yang bukan ponsel. Namun, jika implementasi perangkat menyertakan telepon GSM atau CDMA, perangkat HARUS menerapkan dukungan penuh untuk API untuk teknologi tersebut. Implementasi perangkat yang tidak menyertakan hardware telefoni HARUS menerapkan API lengkap sebagai no-ops.

7.4.2. IEEE 802.11 (Wi-Fi)

Implementasi perangkat Android HARUS menyertakan dukungan untuk satu atau beberapa bentuk 802.11 (b/g/a/n, dll.) Jika implementasi perangkat menyertakan dukungan untuk 802.11, implementasi tersebut HARUS menerapkan Android API yang sesuai.

Implementasi perangkat HARUS mengimplementasikan multicast API seperti yang dijelaskan dalam dokumentasi SDK [Referensi, 62]. Implementasi perangkat yang menyertakan dukungan Wi-Fi HARUS mendukung DNS multicast (mDNS). Implementasi perangkat TIDAK BOLEH memfilter paket mDNS (224.0.0.251) kapan saja saat beroperasi, termasuk saat layar tidak dalam status aktif.

7.4.2.1. Wi-Fi Direct

Implementasi perangkat HARUS menyertakan dukungan untuk Wi-Fi direct (Wi-Fi peer-to-peer). Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Direct, implementasi tersebut HARUS menerapkan Android API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK [Referensi, 68]. Jika implementasi perangkat menyertakan dukungan untuk Wi-Fi Direct, maka:

• HARUS mendukung operasi Wi-Fi reguler
• HARUS mendukung operasi Wi-Fi dan Wi-Fi Direct serentak

7.4.2.2. Penyiapan Link Langsung Wi-Fi dengan Tunnel

Implementasi perangkat HARUS menyertakan dukungan untuk Wi-Fi Tunneled Direct Link Setup (TDLS) seperti yang dijelaskan dalam Dokumentasi Android SDK [Referensi, 85]. Jika implementasi perangkat menyertakan dukungan untuk TDLS dan TDLS diaktifkan oleh WiFiManager API, perangkat:

• HARUS menggunakan TDLS hanya jika memungkinkan DAN bermanfaat.
• HARUS memiliki beberapa heuristik dan TIDAK menggunakan TDLS jika performanya mungkin lebih buruk daripada melalui titik akses Wi-Fi.

7.4.3. Bluetooth

Implementasi perangkat HARUS menyertakan transceiver Bluetooth. Implementasi perangkat yang menyertakan transceiver Bluetooth HARUS mengaktifkan Bluetooth API berbasis RFCOMM seperti yang dijelaskan dalam dokumentasi SDK dan mendeklarasikan fitur hardware android.hardware.bluetooth [Referensi, 42]. Implementasi perangkat HARUS menerapkan profil Bluetooth yang relevan, seperti A2DP, AVRCP, OBEX, dll. sesuai dengan perangkat.

Implementasi perangkat yang menyertakan dukungan untuk Bluetooth GATT (profil atribut generik) untuk mengaktifkan komunikasi dengan perangkat Bluetooth Smart atau Smart Ready HARUS mengaktifkan Bluetooth API berbasis GATT seperti yang dijelaskan dalam dokumentasi SDK dan mendeklarasikan fitur hardware android.hardware.bluetooth_le [Referensi, 42].

7.4.4. Komunikasi Nirkabel Jarak Dekat

Implementasi perangkat HARUS menyertakan transceiver dan hardware terkait untuk Komunikasi Nirkabel Jarak Dekat (NFC). Jika implementasi perangkat menyertakan hardware NFC, maka:

• HARUS melaporkan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature(). [Referensi, 37]
• HARUS dapat membaca dan menulis pesan NDEF melalui standar NFC berikut:
  • HARUS dapat bertindak sebagai pembaca/penulis Forum NFC (sebagaimana ditentukan oleh spesifikasi teknis Forum NFC NFCForum-TS-DigitalProtocol-1.0) melalui standar NFC berikut:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • IsoDep (ISO 14443-4)
    • Jenis Tag NFC Forum 1, 2, 3, 4 (ditentukan oleh NFC Forum)
• HARUS dapat membaca dan menulis pesan NDEF melalui standar NFC berikut. Perhatikan bahwa meskipun standar NFC di bawah dinyatakan sebagai "HARUS", Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi "HARUS". Artinya, standar ini bersifat opsional dalam versi ini, tetapi akan diperlukan dalam versi mendatang. Perangkat yang ada dan baru yang menjalankan versi Android ini sangat disarankan untuk memenuhi persyaratan ini sekarang sehingga perangkat tersebut dapat diupgrade ke rilis platform mendatang.
  • NfcV (ISO 15693)
• HARUS dapat mengirim dan menerima data melalui standar dan protokol peer-to-peer berikut:
  • ISO 18092
  • LLCP 1.0 (ditentukan oleh NFC Forum)
  • SDP 1.0 (ditentukan oleh NFC Forum)
  • NDEF Push Protocol [Referensi, 43]
  • SNEP 1.0 (ditentukan oleh NFC Forum)
• HARUS menyertakan dukungan untuk Android Beam [Referensi, 65]:
  • HARUS menerapkan server default SNEP. Pesan NDEF yang valid yang diterima oleh server SNEP default HARUS dikirim ke aplikasi menggunakan intent android.nfc.ACTION_NDEF_DISCOVERED. Menonaktifkan Android Beam di setelan TIDAK BOLEH menonaktifkan pengiriman pesan NDEF yang masuk.
  • Implementasi perangkat HARUS mematuhi intent android.settings.NFCSHARING_SETTINGS untuk menampilkan setelan berbagi NFC [Referensi, 67].
  • HARUS menerapkan server NPP. Pesan yang diterima oleh server NPP HARUS diproses dengan cara yang sama seperti server default SNEP.
  • HARUS menerapkan klien SNEP dan mencoba mengirim NDEF P2P keluar ke server SNEP default saat Android Beam diaktifkan. Jika tidak ada server SNEP default yang ditemukan, klien HARUS mencoba mengirim ke server NPP.
  • HARUS mengizinkan aktivitas latar depan untuk menetapkan pesan NDEF P2P keluar menggunakan android.nfc.NfcAdapter.setNdefPushMessage, dan android.nfc.NfcAdapter.setNdefPushMessageCallback, dan android.nfc.NfcAdapter.enableForegroundNdefPush.
  • HARUS menggunakan gestur atau konfirmasi di layar, seperti 'Sentuh untuk Beam', sebelum mengirim pesan NDEF P2P keluar.
  • HARUS mengaktifkan Android Beam secara default
  • HARUS mendukung pengalihan Koneksi NFC ke Bluetooth saat perangkat mendukung Profil Push Objek Bluetooth. Implementasi perangkat harus mendukung pengalihan koneksi ke Bluetooth saat menggunakan android.nfc.NfcAdapter.setBeamPushUris, dengan menerapkan spesifikasi "Connection Handover version 1.2" [Resources, 60] dan "Bluetooth Secure Simple Pairing Using NFC version 1.0" [Resources, 61] dari NFC Forum. Implementasi tersebut HARUS mengimplementasikan layanan LLCP handover dengan nama layanan "urn:nfc:sn:handover" untuk bertukar permintaan handover/data yang dipilih melalui NFC, dan HARUS menggunakan Profil Push Objek Bluetooth untuk transfer data Bluetooth yang sebenarnya. Untuk alasan lama (agar tetap kompatibel dengan perangkat Android 4.1), penerapan HARUS tetap menerima permintaan GET SNEP untuk bertukar permintaan handover/data tertentu melalui NFC. Namun, penerapan itu sendiri TIDAK BOLEH mengirim permintaan GET SNEP untuk melakukan pengalihan koneksi.
• HARUS melakukan polling untuk semua teknologi yang didukung saat dalam mode penemuan NFC.
• HARUS dalam mode penemuan NFC saat perangkat aktif dengan layar aktif dan layar kunci tidak terkunci.

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

Android 4.4 memperkenalkan dukungan untuk mode Host Card Emulation (HCE) NFC. Jika penerapan perangkat menyertakan pengontrol NFC yang mampu melakukan perutean HCE dan ID Aplikasi (AID), maka:

• HARUS melaporkan konstanta fitur android.hardware.nfc.hce
• HARUS mendukung NFC HCE API seperti yang ditentukan dalam Android SDK [Referensi, 90]

Selain itu, implementasi perangkat DAPAT menyertakan dukungan pembaca/penulis untuk teknologi MIFARE berikut.

• MIFARE Classic (NXP MF1S503x [Referensi, 44], MF1S703x [Referensi, 45])
• MIFARE Ultralight (NXP MF0ICU1 [Referensi, 46], MF0ICU2 [Referensi, 47])
• NDEF di MIFARE Classic (NXP AN130511 [Referensi, 48], AN130411 [Referensi, 49])

Perhatikan bahwa Android menyertakan API untuk jenis MIFARE ini. Jika implementasi perangkat mendukung MIFARE dalam peran pembaca/penulis, implementasi tersebut:

• HARUS mengimplementasikan API Android yang sesuai seperti yang didokumentasikan oleh Android SDK
• HARUS melaporkan fitur com.nxp.mifare dari metode android.content.pm.PackageManager.hasSystemFeature(). [Resources, 37] Perhatikan bahwa ini bukan fitur Android standar, sehingga tidak muncul sebagai konstanta di class PackageManager.
• TIDAK BOLEH mengimplementasikan API Android yang sesuai atau melaporkan fitur com.nxp.mifare kecuali jika juga mengimplementasikan dukungan NFC umum seperti yang dijelaskan di bagian ini

Jika implementasi perangkat tidak menyertakan hardware NFC, implementasi tersebut TIDAK BOLEH mendeklarasikan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature() [Resources, 37], dan HARUS mengimplementasikan Android NFC API sebagai no-op.

Karena class android.nfc.NdefMessage dan android.nfc.NdefRecord mewakili format representasi data yang tidak bergantung pada protokol, implementasi perangkat HARUS menerapkan API ini meskipun tidak menyertakan dukungan untuk NFC atau mendeklarasikan fitur android.hardware.nfc.

7.4.5. Kemampuan Jaringan Minimum

Implementasi perangkat HARUS menyertakan dukungan untuk satu atau beberapa bentuk jaringan data. Secara khusus, implementasi perangkat HARUS menyertakan dukungan untuk setidaknya satu standar data yang mampu mencapai 200 Kbit/detik atau lebih tinggi. Contoh teknologi yang memenuhi persyaratan ini mencakup EDGE, HSPA, EV-DO, 802.11g, Ethernet, dll.

Implementasi perangkat dengan standar jaringan fisik (seperti Ethernet) sebagai koneksi data utama HARUS juga menyertakan dukungan untuk setidaknya satu standar data nirkabel umum, seperti 802.11 (Wi-Fi).

Perangkat DAPAT menerapkan lebih dari satu bentuk konektivitas data.

7.4.6. Setelan Sinkronisasi

Implementasi perangkat HARUS mengaktifkan setelan sinkronisasi otomatis master secara default sehingga metode getMasterSyncAutomatically() menampilkan "true" [Resources, 88].

7.5. Kamera

Implementasi perangkat HARUS menyertakan kamera belakang, dan DAPAT menyertakan kamera depan. Kamera belakang adalah kamera yang terletak di sisi perangkat yang berlawanan dengan layar; yaitu, kamera ini mengambil gambar di sisi jauh perangkat, seperti kamera tradisional. Kamera depan adalah kamera yang terletak di sisi perangkat yang sama dengan layar; yaitu, kamera yang biasanya digunakan untuk mengambil gambar pengguna, seperti untuk konferensi video dan aplikasi yang serupa.

7.5.1. Kamera Belakang

Implementasi perangkat HARUS menyertakan kamera belakang. Jika implementasi perangkat menyertakan kamera belakang, hal ini:

• HARUS memiliki resolusi minimal 2 megapiksel
• HARUS memiliki fokus otomatis hardware, atau fokus otomatis software yang diterapkan di driver kamera (transparan untuk software aplikasi)
• DAPAT memiliki hardware fokus tetap atau EDOF (extended depth of field)
• DAPAT menyertakan flash. Jika Kamera menyertakan flash, lampu flash TIDAK HARUS menyala saat instance android.hardware.Camera.PreviewCallback telah terdaftar di platform pratinjau Kamera, kecuali jika aplikasi telah secara eksplisit mengaktifkan flash dengan mengaktifkan atribut FLASH_MODE_AUTO atau FLASH_MODE_ON dari objek Camera.Parameters. Perhatikan bahwa batasan ini tidak berlaku untuk aplikasi kamera sistem bawaan perangkat, tetapi hanya untuk aplikasi pihak ketiga yang menggunakan Camera.PreviewCallback.

7.5.2. Kamera Depan

Implementasi perangkat DAPAT menyertakan kamera depan. Jika implementasi perangkat menyertakan kamera depan, perangkat tersebut:

• HARUS memiliki resolusi minimal VGA (yaitu, 640x480 piksel)
• TIDAK BOLEH menggunakan kamera depan sebagai default untuk Camera API. Artinya, API kamera di Android memiliki dukungan khusus untuk kamera depan, dan implementasi perangkat TIDAK BOLEH mengonfigurasi API untuk memperlakukan kamera depan sebagai kamera belakang default, meskipun itu satu-satunya kamera di perangkat.
• DAPAT menyertakan fitur (seperti fokus otomatis, flash, dll.) yang tersedia untuk kamera belakang seperti yang dijelaskan dalam Pasal 7.5.1.
• HARUS mencerminkan (yaitu mencerminkan) streaming secara horizontal yang ditampilkan oleh aplikasi di CameraPreview, sebagai berikut:
• Jika implementasi perangkat dapat diputar oleh pengguna (seperti otomatis melalui akselerometer atau secara manual melalui input pengguna), pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi perangkat saat ini.
• Jika aplikasi saat ini telah secara eksplisit meminta agar tampilan Kamera diputar melalui panggilan ke metode android.hardware.Camera.setDisplayOrientation() [Resources, 50], pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi yang ditentukan oleh aplikasi.
• Jika tidak, pratinjau HARUS dicerminkan di sepanjang sumbu horizontal default perangkat.
• HARUS mencerminkan gambar yang ditampilkan oleh postview dengan cara yang sama seperti streaming gambar pratinjau kamera. (Jika penerapan perangkat tidak mendukung postview, persyaratan ini jelas tidak berlaku.)
• TIDAK BOLEH mencerminkan gambar diam atau streaming video akhir yang diambil dan ditampilkan ke callback aplikasi atau di-commit ke penyimpanan media

7.5.3. Perilaku Camera API

Implementasi perangkat HARUS menerapkan perilaku berikut untuk API terkait kamera, baik untuk kamera depan maupun belakang:

1. Jika aplikasi belum pernah memanggil android.hardware.Camera.Parameters.setPreviewFormat(int), perangkat HARUS menggunakan android.hardware.PixelFormat.YCbCr_420_SP untuk data pratinjau yang diberikan ke callback aplikasi.
2. Jika aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() saat format pratinjau adalah YCbCr_420_SP, data dalam byte[] yang diteruskan ke onPreviewFrame() harus lebih lanjut dalam format encoding NV21. Artinya, NV21 HARUS menjadi default.
3. Implementasi perangkat HARUS mendukung format YV12 (seperti yang ditunjukkan oleh konstanta android.graphics.ImageFormat.YV12) untuk pratinjau kamera untuk kamera depan dan belakang. (Encoder video dan kamera hardware dapat menggunakan format piksel native apa pun, tetapi implementasi perangkat HARUS mendukung konversi ke YV12.)

Implementasi perangkat HARUS mengimplementasikan Camera API lengkap yang disertakan dalam dokumentasi Android SDK [Referensi, 51]), terlepas dari apakah perangkat menyertakan fokus otomatis hardware atau kemampuan lainnya. Misalnya, kamera yang tidak memiliki fokus otomatis HARUS tetap memanggil instance android.hardware.Camera.AutoFocusCallback yang terdaftar (meskipun hal ini tidak relevan dengan kamera non-fokus otomatis.) Perhatikan bahwa hal ini berlaku untuk kamera depan; misalnya, meskipun sebagian besar kamera depan tidak mendukung fokus otomatis, callback API masih harus "dipalsukan" seperti yang dijelaskan.

Implementasi perangkat HARUS mengenali dan mematuhi setiap nama parameter yang ditentukan sebagai konstanta pada class android.hardware.Camera.Parameters, jika hardware yang mendasarinya mendukung fitur tersebut. Jika hardware perangkat tidak mendukung fitur, API harus berperilaku seperti yang didokumentasikan. Sebaliknya, implementasi Perangkat TIDAK BOLEH mematuhi atau mengenali konstanta string yang diteruskan ke metode android.hardware.Camera.setParameters() selain yang didokumentasikan sebagai konstanta di android.hardware.Camera.Parameters. Artinya, penerapan perangkat HARUS mendukung semua parameter Kamera standar jika hardware mengizinkan, dan TIDAK BOLEH mendukung jenis parameter Kamera kustom. Misalnya, implementasi perangkat yang mendukung pengambilan gambar menggunakan teknik pencitraan rentang dinamis tinggi (HDR) HARUS mendukung parameter kamera Camera.SCENE_MODE_HDR [Resources, 78]).

Implementasi perangkat HARUS menyiarkan intent Camera.ACTION_NEW_PICTURE setiap kali gambar baru diambil oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media.

Implementasi perangkat HARUS menyiarkan intent Camera.ACTION_NEW_VIDEO setiap kali video baru direkam oleh kamera dan entri gambar telah ditambahkan ke penyimpanan media.

7.5.4. Orientasi Kamera

Kamera depan dan belakang, jika ada, HARUS diorientasikan sehingga dimensi panjang kamera sejajar dengan dimensi panjang layar. Artinya, saat perangkat dipegang dalam orientasi lanskap, kamera HARUS mengambil gambar dalam orientasi lanskap. Hal ini berlaku terlepas dari orientasi alami perangkat; yaitu, berlaku untuk perangkat utama lanskap serta perangkat utama potret.

7.6. Memori dan Penyimpanan

7.6.1. Memori dan Penyimpanan Minimum

Implementasi perangkat HARUS memiliki memori minimal 340 MB yang tersedia untuk kernel dan ruang pengguna. 340 MB HARUS ditambahkan ke memori apa pun yang didedikasikan untuk komponen hardware seperti radio, video, dan sebagainya yang tidak berada di bawah kontrol kernel.

Implementasi perangkat dengan memori kurang dari 512 MB yang tersedia untuk kernel dan ruang pengguna HARUS menampilkan nilai "true" untuk ActivityManager.isLowRamDevice().

Implementasi perangkat HARUS memiliki penyimpanan non-volatil minimal 1 GB yang tersedia untuk data pribadi aplikasi. Artinya, partisi /data HARUS setidaknya 1 GB. Implementasi perangkat yang menjalankan Android sangat disarankan untuk memiliki penyimpanan non-volatil minimal 2 GB untuk data pribadi aplikasi sehingga dapat mengupgrade ke rilis platform mendatang.

Android API menyertakan Download Manager yang dapat digunakan aplikasi untuk mendownload file data [Referensi, 56]. Implementasi perangkat Download Manager HARUS dapat mendownload setiap file berukuran minimal 100 MB ke lokasi "cache" default.

7.6.2. Penyimpanan Eksternal Bersama

Implementasi perangkat HARUS menawarkan penyimpanan bersama untuk aplikasi. Penyimpanan bersama yang disediakan HARUS berukuran minimal 1 GB.

Implementasi perangkat HARUS dikonfigurasi dengan penyimpanan bersama yang dipasang secara default, "langsung pakai". Jika penyimpanan bersama tidak dipasang di jalur Linux /sdcard, perangkat HARUS menyertakan link simbolis Linux dari /sdcard ke titik pemasangan yang sebenarnya.

Implementasi perangkat HARUS menerapkan izin android.permission.WRITE_EXTERNAL_STORAGE seperti yang didokumentasikan pada penyimpanan bersama ini. Penyimpanan bersama HARUS dapat ditulis oleh aplikasi apa pun yang mendapatkan izin tersebut.

Implementasi perangkat DAPAT memiliki hardware untuk penyimpanan yang dapat dilepas dan diakses pengguna, seperti kartu Secure Digital. Atau, implementasi perangkat DAPAT mengalokasikan penyimpanan internal (tidak dapat dilepas) sebagai penyimpanan bersama untuk aplikasi. Project Open Source Android upstream menyertakan implementasi yang menggunakan penyimpanan perangkat internal untuk API penyimpanan eksternal bersama; implementasi perangkat HARUS menggunakan konfigurasi dan implementasi software ini.

Terlepas dari bentuk penyimpanan bersama yang digunakan, implementasi perangkat HARUS menyediakan beberapa mekanisme untuk mengakses konten penyimpanan bersama dari komputer host, seperti penyimpanan massal USB (UMS) atau Media Transfer Protocol (MTP). Implementasi perangkat DAPAT menggunakan penyimpanan massal USB, tetapi HARUS menggunakan Media Transfer Protocol. Jika implementasi perangkat mendukung Media Transfer Protocol:

• Implementasi perangkat HARUS kompatibel dengan host MTP Android referensi, Android File Transfer [Referensi, 57].
• Implementasi perangkat HARUS melaporkan class perangkat USB 0x00.
• Implementasi perangkat HARUS melaporkan nama antarmuka USB 'MTP'.

Jika implementasi perangkat tidak memiliki port USB, perangkat HARUS memberikan akses ke konten penyimpanan bersama kepada komputer host dengan beberapa cara lain, seperti sistem file jaringan.

Mari kita pertimbangkan dua contoh umum. Jika implementasi perangkat menyertakan slot kartu SD untuk memenuhi persyaratan penyimpanan bersama, kartu SD berformat FAT berukuran 1 GB atau lebih BUKTIKAN disertakan dengan perangkat seperti yang dijual kepada pengguna, dan HARUS dipasang secara default. Atau, jika implementasi perangkat menggunakan penyimpanan tetap internal untuk memenuhi persyaratan ini, penyimpanan tersebut HARUS berukuran 1 GB atau lebih besar dan dipasang di /sdcard (atau /sdcard HARUS berupa link simbolis ke lokasi fisik jika dipasang di tempat lain.)

Implementasi perangkat yang menyertakan beberapa jalur penyimpanan bersama (seperti slot kartu SD dan penyimpanan internal bersama) TIDAK BOLEH mengizinkan aplikasi Android menulis ke penyimpanan eksternal sekunder, kecuali untuk direktori khusus paketnya di penyimpanan eksternal sekunder, tetapi HARUS mengekspos konten dari kedua jalur penyimpanan secara transparan melalui layanan pemindai media Android dan android.provider.MediaStore.

7.7. USB

Implementasi perangkat HARUS menyertakan port klien USB, dan HARUS menyertakan port host USB.

Jika implementasi perangkat menyertakan port klien USB:

• port HARUS dapat dihubungkan ke host USB dengan port USB-A standar
• port HARUS menggunakan faktor bentuk USB mikro di sisi perangkat. Perangkat yang ada dan baru yang menjalankan Android sangat disarankan untuk memenuhi persyaratan ini di Android sehingga perangkat tersebut dapat diupgrade ke rilis platform mendatang
• port HARUS berada di tengah tepi. Implementasi perangkat HARUS menempatkan port di bagian bawah perangkat (sesuai dengan orientasi alami) atau mengaktifkan rotasi layar software untuk semua aplikasi (termasuk layar utama), sehingga layar digambar dengan benar saat perangkat diorientasikan dengan port di bagian bawah. Perangkat lama dan baru yang menjalankan Android sangat dianjurkan untuk memenuhi persyaratan ini di Android sehingga dapat diupgrade ke rilis platform mendatang.
• jika perangkat memiliki port lain (seperti port pengisian daya non-USB), port tersebut HARUS berada di tepi yang sama dengan port micro-USB
• host HARUS mengizinkan host yang terhubung ke perangkat untuk mengakses konten volume penyimpanan bersama menggunakan penyimpanan massal USB atau Media Transfer Protocol
• API ini HARUS menerapkan API dan spesifikasi Aksesori Terbuka Android seperti yang didokumentasikan dalam dokumentasi Android SDK, dan HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.accessory [Referensi, 52]
• Aplikasi HARUS menerapkan class audio USB seperti yang didokumentasikan dalam dokumentasi Android SDK [Referensi, 66]
• Perangkat HARUS menerapkan dukungan untuk spesifikasi pengisian daya baterai USB [Referensi, 64] Perangkat lama dan baru yang menjalankan Android sangat disarankan untuk memenuhi persyaratan ini sehingga dapat diupgrade ke rilis platform mendatang
• Nilai iSerialNumber dalam deskripsi perangkat standar USB HARUS sama dengan nilai android.os.Build.SERIAL.

Jika implementasi perangkat menyertakan port host USB:

• perangkat DAPAT menggunakan faktor bentuk port non-standar, tetapi jika demikian, HARUS dilengkapi dengan satu atau beberapa kabel yang mengadaptasi port ke USB-A standar
• API ini HARUS menerapkan API host USB Android seperti yang didokumentasikan dalam Android SDK, dan HARUS mendeklarasikan dukungan untuk fitur hardware android.hardware.usb.host [Referensi, 53]

Implementasi perangkat HARUS menerapkan Android Debug Bridge. Jika implementasi perangkat menghilangkan port klien USB, implementasi tersebut HARUS menerapkan Android Debug Bridge melalui jaringan area lokal (seperti Ethernet atau 802.11)

8. Kompatibilitas Performa

Implementasi perangkat HARUS memenuhi metrik performa utama perangkat yang kompatibel dengan Android yang ditentukan dalam tabel di bawah:

Metrik	Nilai Minimum Performa	Komentar
Waktu Peluncuran Aplikasi	Aplikasi berikut harus diluncurkan dalam waktu yang ditentukan. Browser: kurang dari 1.300 md Kontak: kurang dari 700 md Setelan: kurang dari 700 md	Waktu peluncuran diukur sebagai total waktu untuk menyelesaikan pemuatan aktivitas default untuk aplikasi, termasuk waktu yang diperlukan untuk memulai proses Linux, memuat paket Android ke VM Dalvik, dan memanggil onCreate.
Aplikasi Simultan	Jika beberapa aplikasi telah diluncurkan, meluncurkan ulang aplikasi yang sudah berjalan setelah diluncurkan harus memerlukan waktu kurang dari waktu peluncuran awal.

9. Kompatibilitas Model Keamanan

Implementasi perangkat HARUS menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang ditentukan dalam dokumen referensi Keamanan dan Izin di API [Referensi, 54] dalam dokumentasi developer Android. Implementasi perangkat HARUS mendukung penginstalan aplikasi yang ditandatangani sendiri tanpa memerlukan izin/sertifikat tambahan dari pihak ketiga/otoritas mana pun. Secara khusus, perangkat yang kompatibel HARUS mendukung mekanisme keamanan yang dijelaskan di subbagian berikut.

9.1. Izin

Implementasi perangkat HARUS mendukung model izin Android seperti yang ditentukan dalam dokumentasi developer Android [Referensi, 54]. Secara khusus, penerapan HARUS menerapkan setiap izin yang ditentukan seperti yang dijelaskan dalam dokumentasi SDK; tidak ada izin yang boleh dihilangkan, diubah, atau diabaikan. Implementasi DAPAT menambahkan izin tambahan, asalkan string ID izin baru tidak berada dalam namespace android.*.

9.2. Isolasi UID dan Proses

Implementasi perangkat HARUS mendukung model sandbox aplikasi Android, yang setiap aplikasinya berjalan sebagai UID bergaya Unix yang unik dan dalam proses terpisah. Implementasi perangkat HARUS mendukung beberapa aplikasi yang berjalan sebagai ID pengguna Linux yang sama, asalkan aplikasi ditandatangani dan dibuat dengan benar, seperti yang ditentukan dalam referensi Keamanan dan Izin [Referensi, 54].

9.3. Izin Sistem File

Implementasi perangkat HARUS mendukung model izin akses file Android seperti yang ditentukan dalam referensi Keamanan dan Izin [Referensi, 54].

9.4. Lingkungan Eksekusi Alternatif

Implementasi perangkat DAPAT menyertakan lingkungan runtime yang mengeksekusi aplikasi menggunakan beberapa software atau teknologi selain mesin virtual Dalvik atau kode native. Namun, lingkungan eksekusi alternatif tersebut TIDAK BOLEH mengancam model keamanan Android atau keamanan aplikasi Android yang diinstal, seperti yang dijelaskan di bagian ini.

Runtime alternatif HARUS berupa aplikasi Android, dan mematuhi model keamanan Android standar, seperti yang dijelaskan di tempat lain dalam Bagian 9.

Runtime alternatif TIDAK BOLEH diberi akses ke resource yang dilindungi oleh izin yang tidak diminta dalam file AndroidManifest.xml runtime melalui mekanisme <uses-permission>.

Runtime alternatif TIDAK BOLEH mengizinkan aplikasi menggunakan fitur yang dilindungi oleh izin Android yang dibatasi untuk aplikasi sistem.

Runtime alternatif HARUS mematuhi model sandbox Android. Khususnya:

• Runtime alternatif HARUS menginstal aplikasi melalui PackageManager ke dalam sandbox Android terpisah (yaitu, ID pengguna Linux, dll.)
• Runtime alternatif DAPAT menyediakan satu sandbox Android yang digunakan bersama oleh semua aplikasi yang menggunakan runtime alternatif
• Runtime alternatif 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
• Runtime alternatif TIDAK BOLEH diluncurkan dengan, memberikan, atau diberi akses ke sandbox yang sesuai dengan aplikasi Android lainnya

Runtime alternatif TIDAK BOLEH diluncurkan dengan, diberikan, atau memberikan kepada aplikasi lain hak istimewa pengguna super (root), atau ID pengguna lainnya.

File .apk runtime alternatif DAPAT disertakan dalam image sistem implementasi perangkat, tetapi HARUS ditandatangani dengan kunci yang berbeda dari kunci yang digunakan untuk menandatangani aplikasi lain yang disertakan dengan implementasi perangkat.

Saat menginstal aplikasi, runtime alternatif HARUS mendapatkan izin pengguna untuk izin Android yang digunakan oleh aplikasi. Artinya, jika aplikasi perlu menggunakan resource perangkat yang memiliki izin Android yang sesuai (seperti Kamera, GPS, dll.), runtime alternatif HARUS memberi tahu pengguna bahwa aplikasi akan dapat mengakses resource tersebut. Jika lingkungan runtime tidak mencatat kemampuan aplikasi dengan cara ini, lingkungan runtime HARUS mencantumkan semua izin yang dimiliki oleh runtime itu sendiri saat menginstal aplikasi apa pun menggunakan runtime tersebut.

9.5. Dukungan Multi-Pengguna

Android menyertakan dukungan untuk beberapa pengguna dan memberikan dukungan untuk isolasi pengguna penuh [Referensi, 70].

Implementasi perangkat HARUS memenuhi persyaratan ini yang terkait dengan dukungan multi-pengguna [Referensi, 71]:

• Karena perilaku API telephony di perangkat dengan beberapa pengguna saat ini tidak ditentukan, implementasi perangkat yang mendeklarasikan android.hardware.telephony TIDAK BOLEH mengaktifkan dukungan multi-pengguna.
• Implementasi perangkat HARUS, untuk setiap pengguna, menerapkan model keamanan yang konsisten dengan model keamanan platform Android seperti yang ditentukan dalam dokumen referensi Keamanan dan Izin di API [Referensi, 54]
• Android menyertakan dukungan untuk profil yang dibatasi, fitur yang memungkinkan pemilik perangkat mengelola pengguna tambahan dan kemampuan mereka di perangkat. Dengan profil yang dibatasi, pemilik perangkat dapat dengan cepat menyiapkan lingkungan terpisah bagi pengguna tambahan untuk bekerja, dengan kemampuan untuk mengelola pembatasan yang lebih terperinci dalam aplikasi yang tersedia di lingkungan tersebut. Implementasi perangkat yang menyertakan dukungan untuk beberapa pengguna HARUS menyertakan dukungan untuk profil yang dibatasi. Project Open Source Android upstream menyertakan implementasi yang memenuhi persyaratan ini.

Setiap instance pengguna di perangkat Android HARUS memiliki direktori penyimpanan eksternal yang terpisah dan terisolasi. Implementasi perangkat DAPAT menyimpan data beberapa pengguna di volume atau sistem file yang sama. Namun, implementasi perangkat HARUS memastikan bahwa aplikasi yang dimiliki dan berjalan atas nama pengguna tertentu tidak dapat mencantumkan, membaca, atau menulis ke data yang dimiliki oleh pengguna lain. Perhatikan bahwa media yang dapat dilepas, seperti slot kartu SD, dapat memungkinkan satu pengguna mengakses data pengguna lain melalui PC host. Oleh karena itu, implementasi perangkat yang menggunakan media yang dapat dilepas untuk API penyimpanan eksternal HARUS mengenkripsi konten kartu SD jika multi-pengguna diaktifkan menggunakan kunci yang hanya disimpan di media yang tidak dapat dilepas dan hanya dapat diakses oleh sistem. Karena hal ini akan membuat media tidak dapat dibaca oleh PC host, implementasi perangkat akan diwajibkan untuk beralih ke MTP atau sistem serupa untuk memberi PC host akses ke data pengguna saat ini. Oleh karena itu, implementasi perangkat DAPAT tetapi TIDAK BOLEH mengaktifkan multi-pengguna jika menggunakan media yang dapat dilepas [Referensi, 72] untuk penyimpanan eksternal utama.

9.6. Peringatan SMS Premium

Android menyertakan dukungan untuk memperingatkan pengguna tentang pesan SMS premium keluar [Referensi, 73] . Pesan SMS Premium adalah pesan teks yang dikirim ke layanan yang terdaftar dengan operator yang dapat dikenai biaya kepada pengguna. Implementasi perangkat yang mendeklarasikan dukungan untuk android.hardware.telephony 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 Kernel

Sandbox Android menyertakan fitur yang dapat menggunakan sistem kontrol akses wajib (MAC) Security-Enhanced Linux (SELinux) dan fitur keamanan lainnya di kernel Linux. SELinux atau fitur keamanan lainnya, jika diterapkan di bawah framework Android:

• HARUS mempertahankan kompatibilitas dengan aplikasi yang ada
• HARUS tidak memiliki antarmuka pengguna yang terlihat, meskipun jika pelanggaran terdeteksi
• TIDAK BOLEH dikonfigurasi oleh pengguna atau developer

Jika API untuk konfigurasi kebijakan diekspos ke aplikasi yang dapat memengaruhi aplikasi lain (seperti Device Administration API), API TIDAK BOLEH mengizinkan konfigurasi yang merusak kompatibilitas.

Perangkat HARUS menerapkan SELinux dan memenuhi persyaratan berikut, yang dipenuhi oleh implementasi referensi di Project Open Source Android upstream.

• harus mendukung kebijakan SELinux yang memungkinkan mode SELinux ditetapkan berdasarkan per domain dengan:
• domain yang berada dalam mode penerapan di penerapan Open Source Android upstream (seperti installd, netd, dan vold) HARUS dalam mode penerapan
• domain untuk aplikasi pihak ketiga HARUS tetap dalam mode permisif untuk memastikan kompatibilitas yang berkelanjutan
• file INI HARUS memuat kebijakan dari file /sepolicy di perangkat
• HARUS mendukung update dinamis file kebijakan SELinux tanpa memerlukan update image sistem
• harus MENCATAT pelanggaran kebijakan apa pun tanpa merusak aplikasi atau memengaruhi perilaku sistem

Implementasi perangkat HARUS mempertahankan kebijakan SELinux default yang disediakan di Project Open Source Android upstream, hingga mereka terlebih dahulu mengaudit penambahan mereka ke kebijakan SELinux. Implementasi perangkat HARUS kompatibel dengan Project Open Source Android upstream.

9.8. Privasi

Jika perangkat menerapkan fungsi dalam sistem yang merekam konten yang ditampilkan di layar dan/atau merekam streaming audio yang diputar di perangkat, perangkat HARUS terus memberi tahu pengguna setiap kali fungsi ini diaktifkan dan merekam/merekam secara aktif.

9.9. Enkripsi Disk Penuh

JIKA perangkat memiliki layar kunci, perangkat HARUS mendukung enkripsi disk penuh.

10. Pengujian Kompatibilitas Software

Implementasi perangkat HARUS lulus semua pengujian yang dijelaskan di bagian ini.

Namun, perlu diperhatikan bahwa tidak ada paket pengujian software yang sepenuhnya komprehensif. Oleh karena itu, pengimplementasi perangkat sangat disarankan untuk membuat jumlah perubahan minimum sebanyak mungkin pada referensi dan penerapan Android pilihan yang tersedia dari Project Open Source Android. Tindakan ini akan meminimalkan risiko munculnya bug yang menyebabkan inkompatibilitas yang memerlukan pengerjaan ulang dan potensi update perangkat.

10.1. Compatibility Test Suite (CTS)

Implementasi perangkat HARUS lulus Android Compatibility Test Suite (CTS) [Referensi, 2] yang tersedia dari Project Open Source Android, menggunakan software pengiriman akhir di perangkat. Selain itu, implementer perangkat HARUS menggunakan implementasi referensi di hierarki Android Open Source sebanyak mungkin, dan HARUS memastikan kompatibilitas jika ada ambiguitas di CTS dan untuk penerapan ulang bagian kode sumber referensi.

CTS dirancang untuk dijalankan di perangkat yang sebenarnya. Seperti software lainnya, CTS itu sendiri mungkin berisi bug. CTS akan diberi versi secara terpisah dari Definisi Kompatibilitas ini, dan beberapa revisi CTS dapat dirilis untuk Android 4.4. Implementasi perangkat HARUS lulus versi CTS terbaru yang tersedia pada saat software perangkat selesai.

10.2. Pemverifikasi CTS

Implementasi perangkat HARUS menjalankan semua kasus yang berlaku dengan benar di Pemverifikasi CTS. CTS Verifier disertakan dengan Compatibility Test Suite, dan dimaksudkan untuk dijalankan oleh operator manusia untuk menguji fungsi yang tidak dapat diuji oleh sistem otomatis, seperti fungsi kamera dan sensor yang benar.

CTS Verifier memiliki pengujian untuk berbagai jenis hardware, termasuk beberapa hardware yang bersifat opsional. Implementasi perangkat HARUS lulus semua pengujian untuk hardware yang dimilikinya; misalnya, jika perangkat memiliki akselerometer, perangkat HARUS menjalankan kasus pengujian Akselerasi dengan benar di CTS Verifier. Kasus pengujian untuk fitur yang dinyatakan sebagai opsional oleh Dokumen Definisi Kompatibilitas ini DAPAT dilewati atau dihilangkan.

Setiap perangkat dan setiap build HARUS menjalankan CTS Verifier dengan benar, seperti yang disebutkan di atas. Namun, karena banyak build yang sangat mirip, implementer perangkat tidak diharapkan untuk menjalankan Verifikator CTS secara eksplisit pada build yang hanya berbeda dengan cara yang tidak penting. Secara khusus, implementasi perangkat yang berbeda dari implementasi yang telah lulus CTS Verifier hanya dengan kumpulan lokalitas, branding, dan sebagainya yang disertakan DAPAT menghilangkan pengujian CTS Verifier.

10.3. Aplikasi Referensi

Implementator perangkat HARUS menguji kompatibilitas implementasi menggunakan aplikasi open source berikut:

• Aplikasi "Apps for Android" [Referensi, 55]
• Replica Island (tersedia di Google Play Store)

Setiap aplikasi di atas HARUS diluncurkan dan berperilaku dengan benar pada penerapan, agar penerapan dianggap kompatibel.

11. Software yang Dapat Diupdate

Implementasi perangkat HARUS menyertakan mekanisme untuk mengganti seluruh software sistem. Mekanisme ini tidak perlu melakukan upgrade "langsung", yaitu memulai ulang perangkat MUNGKIN diperlukan.

Metode apa pun dapat digunakan, asalkan dapat menggantikan seluruh software yang diprainstal di perangkat. Misalnya, salah satu pendekatan berikut akan memenuhi persyaratan ini:

• Download over the air (OTA) dengan update offline melalui mulai ulang
• Update "Tethered" melalui USB dari PC host
• Update "Offline" melalui mulai ulang dan update dari file di penyimpanan yang dapat dilepas

Mekanisme update yang digunakan HARUS mendukung update tanpa menghapus data pengguna. Artinya, mekanisme update HARUS mempertahankan data pribadi aplikasi dan data bersama aplikasi. Perhatikan bahwa software Android upstream menyertakan mekanisme update yang memenuhi persyaratan ini.

Jika error ditemukan dalam penerapan perangkat setelah dirilis, tetapi dalam masa aktif produk yang wajar yang ditentukan melalui konsultasi dengan Tim Kompatibilitas Android untuk memengaruhi kompatibilitas aplikasi pihak ketiga, pelaksana perangkat HARUS memperbaiki error melalui update software yang tersedia dan dapat diterapkan sesuai dengan mekanisme yang baru saja dijelaskan.

12. Log Perubahan Dokumen

Tabel berikut berisi ringkasan perubahan pada Definisi Kompatibilitas dalam rilis ini.

Bagian	Ringkasan perubahan
3.2.2. Parameter Build	Deskripsi MERK, PERANGKAT, dan PRODUK yang telah direvisi. SERIAL kini wajib diisi.
3.2.3.5. Setelan Aplikasi Default	Bagian baru yang menambahkan persyaratan untuk mematuhi setelan aplikasi default baru
3.3.1 Antarmuka Biner Aplikasi	Memperjelas nilai yang diizinkan untuk parameter android.os.Build.CPU_ABI dan android.os.Build.CPU_ABI2.
3.4.1. Kompatibilitas WebView	Menambahkan Chromium sebagai penerapan WebView yang diperlukan.
3.7. Kompatibilitas Virtual Machine	Menambahkan persyaratan untuk kepadatan layar xxhdpi dan 400 dpi.
3.8.6. Tema	Diupdate untuk mencerminkan penggunaan panel sistem transparan.
3.8.12. Lokasi	Bagian baru yang menambahkan setelan lokasi persyaratan agar terpusat.
3.8.13. Unicode	Bagian baru yang menambahkan persyaratan untuk dukungan emoji.
3.9. Administrasi Perangkat	Aplikasi administratif bawaan yang dicatat tidak boleh menjadi aplikasi Pemilik Perangkat default.
5.1. Codec Media	Menambahkan persyaratan decoder VP9. Menambahkan spesifikasi yang direkomendasikan untuk codec VP8 hardware.
5.3. Dekode Video	Menambahkan VP9. Menambahkan rekomendasi untuk pengalihan resolusi dinamis.
5.4. Perekaman Audio	Menambahkan REMOTE_SUBMIX sebagai sumber audio baru yang diperlukan. Mewajibkan penggunaan android.media.audiofx.NoiseSuppressor API.
6.2.1 Eksperimental	Bagian baru yang memperkenalkan runtime ART dan memerlukan Dalvik sebagai runtime default.
7.1.1. Konfigurasi Layar	Mengganti rasio aspek 1,85 dengan 1,86. Menambahkan kepadatan layar 400 dpi.
7.1.6. Jenis Layar	Menambahkan konfigurasi resolusi 640 dpi (4K).
7.2.3. Tombol navigasi	Menambahkan fungsi Terbaru sebagai penting; mendemosikan fungsi Menu dalam prioritas.
7.3.6. Thermometer	Menambahkan SENSOR_TYPE_AMBIENT_TEMPERATURE sebagai termometer yang direkomendasikan.
7.4.2.2. Penyiapan Link Langsung Wi-Fi dengan Tunnel	Bagian baru yang menambahkan dukungan untuk Penyiapan Link Langsung Wi-Fi dengan Tunnel (TDLS).
7.4.4. Komunikasi Nirkabel Jarak Dekat	Menambahkan Host Card Emulation (HCE) sebagai persyaratan. Mengganti SNEP GET dengan Logical Link Control Protocol (LLCP) dan menambahkan Profil Bluetooth Object Push sebagai persyaratan.
7.4.6. Setelan Sinkronisasi	Bagian baru yang menambahkan persyaratan agar data sinkronisasi otomatis diaktifkan secara default.
7.6.1. Memori dan Penyimpanan Minimum	Menambahkan persyaratan setelan ActivityManager.isLowRamDevice() untuk perangkat dengan memori kurang dari 512 MB. Peningkatan persyaratan penyimpanan dari 512 MB dan 1 GB menjadi 1 GB dan 2 GB.
7.6.2. Penyimpanan "Eksternal" Bersama	Perbaikan editorial seperti perubahan nama bagian, dan memindahkan teks yang sesuai di bagian ini dari bagian 9.5. Aplikasi yang dicatat dapat menulis ke direktori khusus paketnya di penyimpanan eksternal sekunder.
7.7. USB	Menambahkan persyaratan bahwa semua perangkat melaporkan nomor seri USB.
9.5. Dukungan Multi-Pengguna	Memindahkan teks khusus non-multi-pengguna ke bagian 7.6.2.
9.7. Fitur Keamanan Kernel	Ditulis ulang untuk mencatat peralihan SELinux ke mode penerapan dan persyaratan output SELinux tidak dirender di antarmuka pengguna.
9.8. Privasi	Bagian baru yang menambahkan persyaratan perekaman audio dan video harus memicu notifikasi berkelanjutan kepada pengguna.
9.9. Enkripsi Disk Penuh	Bagian baru yang menambahkan persyaratan perangkat dengan layar kunci yang mendukung enkripsi disk penuh.
12. Log Perubahan Dokumen	Bagian baru yang merangkum perubahan dalam CDD berdasarkan bagian.

 

13. Hubungi Kami

Anda dapat menghubungi penulis dokumen di compatibility@android.com untuk mendapatkan klarifikasi dan menyampaikan masalah yang menurut Anda tidak tercakup dalam dokumen.