Definisi Kompatibilitas Android 4.2

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

Revisi 2
Terakhir diperbarui: 17 Februari 2013

Hak Cipta © 2012, 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.2.

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.2. "Penerapan perangkat" atau "penerapan" adalah solusi hardware/software yang dikembangkan.

Agar dianggap kompatibel dengan Android 4.2, 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.2: http://source.android.com/docs/compatibility/4.2/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 webdatabase HTML5/W3C: http://www.w3.org/TR/webdatabase/
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/security.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. Wifi 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. Wifi Direct (Wifi 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: https://source.android.com/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

Kamera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

Banyak resource ini berasal secara langsung atau tidak langsung dari Android 4.2 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 4.2 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 10 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
android.os.Build.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].
android.os.Build.VERSION.SDK	Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 4.2, kolom ini HARUS memiliki nilai bilangan bulat 17.
android.os.Build.VERSION.SDK_INT	Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 4.2, kolom ini HARUS memiliki nilai bilangan bulat 17.
android.os.Build.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 ("").
android.os.Build.BOARD	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.,_-]+$".
android.os.Build.BRAND	Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi nama perusahaan, organisasi, individu, dll. yang memproduksi perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan kolom ini adalah untuk menunjukkan OEM dan/atau operator yang menjual perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
android.os.Build.CPU_ABI	Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat Bagian 3.3: Kompatibilitas API Native.
android.os.Build.CPU_ABI2	Nama set petunjuk kedua (jenis CPU + konvensi ABI) dari kode native. Lihat Bagian 3.3: Kompatibilitas API Native.
android.os.Build.DEVICE	Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi konfigurasi atau revisi tertentu dari bodi (terkadang disebut "desain industri") perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
android.os.Build.FINGERPRINT	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/mydevice/generic:4.2/JRN53/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.
android.os.Build.HARDWARE	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.,_-]+$".
android.os.Build.HOST	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 ("").
android.os.Build.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.,_-]+$".
android.os.Build.MANUFACTURER	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 ("").
android.os.Build.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 ("").
android.os.Build.PRODUCT	Nilai yang dipilih oleh implementator perangkat yang berisi nama pengembangan atau nama kode produk (SKU). 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.,_-]+$".
android.os.Build.SERIAL	Nomor seri hardware, jika tersedia. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler "^([a-zA-Z0-9]{0,20})$".
android.os.Build.TAGS	Daftar tag yang dipisahkan koma yang dipilih oleh implementer 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.,_-]+$".
android.os.Build.TIME	Nilai yang mewakili stempel waktu saat build terjadi.
android.os.Build.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.,_-]+$".
android.os.Build.USER	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.2 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.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 android.os.Build.CPU_ABI API
• HARUS hanya melaporkan ABI yang didokumentasikan dalam versi terbaru Android NDK, dalam file docs/CPU-ARCH-ABIS.txt
• 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)
• 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.

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 mesin rendering WebKit untuk menerapkan android.webkit.WebView. Karena tidak memungkinkan untuk mengembangkan rangkaian pengujian yang komprehensif untuk sistem rendering web, implementer perangkat HARUS menggunakan build upstream WebKit tertentu dalam implementasi WebView. Khususnya:

• Implementasi android.webkit.WebView perangkat HARUS didasarkan pada build WebKit 534.30 dari hierarki Open Source Android upstream untuk Android 4.2. Build ini mencakup kumpulan fitur dan perbaikan keamanan tertentu untuk WebView. Implementer perangkat DAPAT menyertakan penyesuaian pada penerapan WebKit; namun, penyesuaian tersebut TIDAK BOLEH mengubah perilaku WebView, termasuk perilaku rendering.
• String agen pengguna yang dilaporkan oleh WebView HARUS dalam format ini:
  Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.2 Mobile Safari/534.30
  • Nilai string $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE
  • Nilai string $(LOCALE) HARUS mengikuti konvensi ISO untuk kode negara dan bahasa, dan HARUS merujuk ke lokalitas perangkat yang dikonfigurasi saat ini
  • Nilai string $(MODEL) HARUS sama dengan nilai untuk android.os.Build.MODEL
  • Nilai string $(BUILD) HARUS sama dengan nilai untuk android.os.Build.ID
  • Implementasi perangkat DAPAT menghilangkan Mobile dalam string agen pengguna

Komponen WebView HARUS menyertakan dukungan untuk HTML5 [Referensi, 11] sebanyak mungkin. Minimal, implementasi perangkat HARUS mendukung setiap API ini yang terkait dengan HTML5 di WebView:

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

HTML5 API, seperti semua JavaScript API, HARUS dinonaktifkan secara default di WebView, kecuali jika developer secara eksplisit mengaktifkannya melalui API Android biasa.

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 yang diinginkan dari project open source Android upstream [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
xlarge	mdpi	32MB
xlarge	tvdpi / hdpi	64MB
xlarge	xhdpi	128MB

3.8. Kompatibilitas Antarmuka Pengguna

3.8.1. Widget

Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos "AppWidget" kepada pengguna akhir [Referensi, 18]. Rilis referensi Open Source Android menyertakan aplikasi Peluncur yang menyertakan kemampuan antarmuka pengguna yang memungkinkan pengguna menambahkan, melihat, dan menghapus AppWidget dari layar utama.

Implementasi perangkat DAPAT mengganti alternatif untuk Peluncur referensi (yaitu layar utama). Peluncur Alternatif HARUS menyertakan dukungan bawaan untuk AppWidget, dan mengekspos kemampuan antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus AppWidget langsung dalam Peluncur. Peluncur Alternatif DAPAT menghapus elemen antarmuka pengguna ini; namun, jika dihapus, implementasi perangkat HARUS menyediakan aplikasi terpisah yang dapat diakses dari Peluncur yang memungkinkan pengguna menambahkan, mengonfigurasi, melihat, dan menghapus AppWidget.

Implementasi perangkat HARUS dapat merender widget berukuran 4 x 4 dalam ukuran petak standar. (Lihat Panduan Desain Widget Aplikasi dalam dokumentasi Android SDK [Referensi, 18] untuk mengetahui detailnya.

3.8.2. 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 4.2 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.3. 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.4. 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.5. Tema

Android menyediakan "tema" sebagai mekanisme bagi aplikasi untuk menerapkan gaya di seluruh Aktivitas atau aplikasi. Android 4.2 menyertakan tema "Holo" atau "holografis" sebagai kumpulan 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 [Referensi, 25].

Android 4.2 menyertakan tema "Default Perangkat" baru 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].

3.8.6. 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.7. Tampilan Aplikasi Terbaru

Kode sumber Android 4.2 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 4.2 upstream (atau antarmuka berbasis thumbnail serupa) untuk aplikasi terbaru, atau antarmuka tersebut mungkin tidak kompatibel dengan versi Android mendatang.

3.8.8. Setelan Pengelolaan Input

Android 4.2 menyertakan dukungan untuk Mesin Pengelolaan Input. API Android 4.2 memungkinkan IME aplikasi kustom menentukan setelan yang dapat disesuaikan pengguna. Implementasi perangkat HARUS menyertakan cara bagi pengguna untuk mengakses setelan IME setiap saat saat IME yang menyediakan setelan pengguna tersebut ditampilkan.

3.8.9. Widget Layar Kunci dan Layar Utama

Android 4.2 menyertakan dukungan untuk widget aplikasi yang dapat disematkan pengguna di layar utama atau layar kunci (Lihat Panduan Desain Widget Aplikasi dalam dokumentasi Android SDK [Referensi, 69] untuk mengetahui detailnya). Widget aplikasi memungkinkan akses cepat ke data dan layanan aplikasi tanpa meluncurkan aktivitas baru. Widget mendeklarasikan dukungan untuk penggunaan di layar utama atau layar kunci dengan mendeklarasikan tag manifes android:widgetCategory yang memberi tahu sistem tempat widget dapat ditempatkan. Secara khusus, implementasi perangkat HARUS memenuhi persyaratan berikut.

• Implementasi perangkat HARUS mendukung widget aplikasi di layar utama.
• Implementasi perangkat HARUS mendukung layar kunci. Jika implementasi perangkat menyertakan dukungan untuk layar kunci, implementasi perangkat HARUS mendukung widget aplikasi di layar kunci.

3.8.10. Remote Kontrol Media Layar Kunci

Android 4.2 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 HARUS menyertakan dukungan untuk menyematkan kontrol jarak jauh di layar kunci perangkat.

3.8.11. Mimpi

Android 4.2 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.9 Administrasi Perangkat

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

Catatan: meskipun beberapa persyaratan yang diuraikan di atas dinyatakan sebagai "HARUS" untuk Android 4.2, implementasi perangkat yang mendukung layar kunci HARUS mendukung kebijakan perangkat untuk mengelola widget di layar kunci seperti yang ditentukan dalam dokumentasi Android SDK [Referensi, 27].

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

3.10 Aksesibilitas

Android 4.2 menyediakan lapisan aksesibilitas yang membantu pengguna difabel untuk menavigasi perangkat mereka dengan lebih mudah. Selain itu, Android 4.2 menyediakan API platform yang memungkinkan implementasi layanan aksesibilitas menerima callback untuk peristiwa pengguna dan sistem serta menghasilkan mekanisme masukan alternatif, seperti text-to-speech, haptic feedback, dan navigasi trackball/d-pad [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 4.2 menyertakan API yang memungkinkan aplikasi menggunakan layanan text-to-speech (TTS), dan memungkinkan penyedia layanan untuk 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)	WAJIB Wajib 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	WAJIB Wajib 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	WAJIB Wajib 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	WAJIB Wajib 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	WAJIB Wajib 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 2.3.3+)		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.

5.2 Encoding Video

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

	SD (Kualitas rendah)	SD (Kualitas tinggi)	HD (Jika didukung oleh hardware)
Codec video	Profil Dasar Pengukuran H.264	Profil Dasar Pengukuran H.264	Profil Dasar Pengukuran H.264
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

5.3 Decoding Video

Implementasi perangkat Android HARUS mendukung profil dekode 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	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.

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

5.5. Latensi Audio

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

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 Developer

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 4.2.2 menyertakan dukungan untuk adb aman. adb aman mengaktifkan adb di host terautentikasi yang diketahui. Perangkat lama dan baru yang menjalankan Android 4.2.2 sangat disarankan untuk memenuhi persyaratan ini di Android 4.2, atau perangkat tersebut tidak akan dapat mencapai kompatibilitas Android saat diupgrade ke versi mendatang.

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

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 4.2 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 antara 1,3333 (4:3) dan 1,85 (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'
• 480 dpi, yang dikenal sebagai 'xxhdpi'

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 juga 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 dan 2.0. Artinya:

• API terkelola (seperti melalui metode GLES10.getString()) HARUS melaporkan dukungan untuk OpenGL ES 1.0 dan 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 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 4.2 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 4.2 untuk menerapkan format kompresi tekstur tertentu. Namun, format kompresi tekstur yang didukung harus dilaporkan secara akurat, melalui metode getString() di OpenGL API.

Android 4.2 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.2, 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 4.2 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.

7.1.5. Mode Kompatibilitas Aplikasi Lama

Android 4.2 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 salah satu atau kedua resolusi 1280x720, atau 1920x1080 (yaitu, 720p atau 1080p). 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)

Untuk memperjelas, implementasi perangkat dengan dimensi piksel variabel dibatasi hingga 720p atau 1080p di Android 4.2, 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 4.2 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.SECURE_FLAG. Secara khusus, implementasi perangkat yang mendeklarasikan dukungan untuk Display.SECURE_FLAG, 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, Menu, 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, gestur, panel sentuh, dll. khusus. Android 4.2 mendukung kedua penerapan tersebut.

Android 4.2 menyertakan dukungan untuk tindakan bantuan [Referensi, 63]. Implementasi perangkat HARUS membuat tindakan bantuan tersedia untuk pengguna setiap saat saat menjalankan aplikasi. Fungsi ini DAPAT diterapkan melalui kunci hardware atau software.

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.
• Implementasi perangkat HARUS menampilkan tombol Menu ke aplikasi saat targetSdkVersion <= 10 dan TIDAK BOLEH menampilkan tombol Menu saat targetSdkVersion > 10.

7.2.4. Input layar sentuh

Implementasi perangkat:

• HARUS memiliki sistem input pointer (seperti mouse, atau sentuh)
• DAPAT memiliki layar sentuh dari modalitas apa pun (seperti kapasitif atau resistif)
• HARUS mendukung pointer yang dilacak sepenuhnya secara independen, jika layar sentuh mendukung beberapa pointer
• HARUS melaporkan nilai android.content.res.Configuration [Resources, 39] yang mencerminkan jenis layar sentuh tertentu di perangkat

Implementasi perangkat HARUS melaporkan fitur yang benar sesuai dengan jenis input yang digunakan. Perhatikan bahwa Android 4.2 menyertakan 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 sentuh secara memadai (termasuk dukungan gestur dasar), dan menunjukkan bahwa perangkat mendukung subset fungsi layar sentuh yang diemulasi. Implementasi perangkat yang menyertakan layar sentuh (sentuhan tunggal atau lebih baik) JUGA HARUS melaporkan 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.

7.2.5. 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 4.2 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 4.2 menyertakan konsep sensor "streaming", yang merupakan 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 4.2 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.2, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi "HARUS". Artinya, standar ini opsional di Android 4.2, tetapi akan diperlukan di versi mendatang. Perangkat yang ada dan baru yang menjalankan Android 4.2 sangat disarankan untuk memenuhi persyaratan ini di Android 4.2 sehingga 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.2, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi "HARUS". Artinya, standar ini opsional di Android 4.2, tetapi akan diperlukan di versi mendatang. Perangkat yang ada dan baru yang menjalankan Android 4.2 sangat disarankan untuk memenuhi persyaratan ini di Android 4.2 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.7. Thermometer

Implementasi perangkat DAPAT tetapi TIDAK BOLEH menyertakan termometer (yaitu sensor suhu). Jika implementasi perangkat menyertakan termometer, perangkat HARUS mengukur suhu CPU perangkat. Sensor TIDAK BOLEH mengukur suhu lainnya. (Perhatikan bahwa jenis sensor ini tidak digunakan lagi di API Android 4.2.)

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 API Android 4.2 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 ini untuk tujuan Android 4.2 dianggap independen 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 4.2 DAPAT digunakan di perangkat yang tidak menyertakan hardware telefoni. Artinya, Android 4.2 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 4.2 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, perangkat tersebut:

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

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 [Referensi, 42]. Implementasi perangkat HARUS menerapkan profil Bluetooth yang relevan, seperti A2DP, AVRCP, OBEX, dll. sesuai dengan perangkat.

Compatibility Test Suite menyertakan kasus yang mencakup operasi dasar Android RFCOMM Bluetooth API. Namun, karena Bluetooth adalah protokol komunikasi antarperangkat, Bluetooth tidak dapat diuji sepenuhnya oleh pengujian unit yang berjalan di satu perangkat. Oleh karena itu, implementasi perangkat JUGA HARUS lulus prosedur pengujian Bluetooth yang dijalankan manusia yang dijelaskan dalam Lampiran A.

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" untuk Android 4.2, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi "HARUS". Artinya, standar ini bersifat opsional di Android 4.2, tetapi akan diperlukan di versi mendatang. Perangkat lama dan baru yang menjalankan Android 4.2 sangat dianjurkan untuk memenuhi persyaratan ini di Android 4.2 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 menggunakan permintaan SNEP GET untuk bertukar permintaan handover / data yang dipilih melalui NFC, dan HARUS menggunakan Profil Push Objek Bluetooth untuk transfer data Bluetooth yang sebenarnya.
• 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.)

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

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

Perhatikan bahwa Android 4.2 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, perangkat TIDAK BOLEH mendeklarasikan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature() [Resources, 37], dan HARUS mengimplementasikan Android 4.2 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.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 4.2 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 4.2 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 HARUS memiliki penyimpanan non-volatil setidaknya 350 MB yang tersedia untuk data pribadi aplikasi. Artinya, partisi /data HARUS setidaknya berukuran 350 MB.

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 Bersama Aplikasi

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.

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) HARUS mengubah aplikasi inti seperti pemindai media dan ContentProvider untuk mendukung file yang ditempatkan di kedua lokasi secara transparan.

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 4.2 sangat disarankan untuk memenuhi persyaratan ini di Android 4.2 sehingga 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 4.2 sangat dianjurkan untuk memenuhi persyaratan ini di Android 4.2 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 4.2 sangat disarankan untuk memenuhi persyaratan ini di Android 4.2 sehingga dapat diupgrade ke rilis platform mendatang

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

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. Project open source Android upstream menyertakan implementasi yang menggunakan penyimpanan perangkat internal untuk API penyimpanan eksternal aplikasi; implementasi perangkat HARUS menggunakan konfigurasi dan implementasi software ini. Implementasi perangkat yang menyertakan beberapa jalur penyimpanan eksternal TIDAK BOLEH mengizinkan aplikasi Android menulis ke penyimpanan eksternal sekunder

9.6. Peringatan SMS Premium

Android 4.2 menyertakan dukungan untuk memperingatkan pengguna tentang pesan SMS premium keluar. Pesan SMS Premium adalah pesan teks yang dikirim ke layanan yang terdaftar dengan operator yang dapat dikenai biaya kepada pengguna. 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.

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. Karena alasan ini, implementer perangkat sangat dianjurkan untuk membuat jumlah perubahan minimum sebanyak mungkin pada referensi dan implementasi Android 4.2 yang diinginkan 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.2. 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 Verfier hanya dengan kumpulan lokalitas, branding, dan sebagainya yang disertakan DAPAT menghilangkan pengujian CTS Verfier.

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 Android Market)

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

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

Lampiran A - Prosedur Pengujian Bluetooth

Compatibility Test Suite menyertakan kasus yang mencakup operasi dasar Android RFCOMM Bluetooth API. Namun, karena Bluetooth adalah protokol komunikasi antarperangkat, Bluetooth tidak dapat diuji sepenuhnya oleh pengujian unit yang berjalan di satu perangkat. Akibatnya, implementasi perangkat JUGA HARUS lulus prosedur pengujian Bluetooth yang dioperasikan manusia yang dijelaskan di bawah.

Prosedur pengujian didasarkan pada aplikasi contoh BluetoothChat yang disertakan dalam hierarki project open source Android. Prosedur ini memerlukan dua perangkat:

• implementasi perangkat kandidat yang menjalankan build software yang akan diuji
• implementasi perangkat terpisah yang sudah diketahui kompatibel, dan model dari implementasi perangkat yang sedang diuji - yaitu, implementasi perangkat "yang diketahui baik"

Prosedur pengujian di bawah ini merujuk pada perangkat ini sebagai perangkat "kandidat" dan "diketahui baik".

Penyiapan dan Pemasangan

1. Mem-build BluetoothChat.apk melalui 'make samples' dari hierarki kode sumber Android
2. Instal BluetoothChat.apk di perangkat yang diketahui baik
3. Instal BluetoothChat.apk di perangkat kandidat

Menguji Kontrol Bluetooth oleh Aplikasi

1. Meluncurkan BluetoothChat di perangkat kandidat, saat Bluetooth dinonaktifkan
2. Verifikasi bahwa perangkat kandidat mengaktifkan Bluetooth, atau meminta pengguna dengan dialog untuk mengaktifkan Bluetooth

Menguji Penyambungan dan Komunikasi

1. Luncurkan aplikasi Bluetooth Chat di kedua perangkat
2. Membuat perangkat yang diketahui baik dapat ditemukan dari dalam BluetoothChat (menggunakan Menu)
3. Di perangkat kandidat, pindai perangkat Bluetooth dari dalam BluetoothChat (menggunakan Menu) dan sambungkan dengan perangkat yang diketahui baik
4. Kirim 10 pesan atau lebih dari setiap perangkat, dan pastikan perangkat lain menerimanya dengan benar
5. Tutup aplikasi BluetoothChat di kedua perangkat dengan menekan Beranda
6. Lepaskan sambungan setiap perangkat dari perangkat lainnya, menggunakan aplikasi Setelan perangkat

Menguji Penyambungan dan Komunikasi dalam Arah Terbalik

1. Luncurkan aplikasi Chat Bluetooth di kedua perangkat.
2. Buat perangkat kandidat dapat ditemukan dari dalam BluetoothChat (menggunakan Menu).
3. Di perangkat yang diketahui baik, pindai perangkat Bluetooth dari dalam BluetoothChat (menggunakan Menu) dan sambungkan dengan perangkat kandidat.
4. Kirim 10 pesan atau lebih dari setiap perangkat, dan pastikan perangkat lain menerimanya dengan benar.
5. Tutup aplikasi Bluetooth Chat di kedua perangkat dengan menekan Kembali berulang kali untuk membuka Peluncur.

Pengujian Peluncuran Ulang

1. Luncurkan ulang aplikasi Bluetooth Chat di kedua perangkat.
2. Kirim 10 pesan atau lebih dari setiap perangkat, dan pastikan perangkat lain menerimanya dengan benar.

Catatan: pengujian di atas memiliki beberapa kasus yang mengakhiri bagian pengujian menggunakan Beranda, dan beberapa menggunakan Kembali. Pengujian ini tidak berlebihan dan tidak opsional: tujuannya adalah untuk memverifikasi bahwa API dan stack Bluetooth berfungsi dengan benar baik saat Aktivitas dihentikan secara eksplisit (melalui pengguna yang menekan Kembali, yang memanggil finish()), dan secara implisit dikirim ke latar belakang (melalui pengguna yang menekan Beranda.) Setiap urutan pengujian HARUS dilakukan seperti yang dijelaskan.