Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.

Halaman ini diterjemahkan oleh Cloud Translation API.

Definisi Kompatibilitas Android 4.1

Definisi Kompatibilitas Android 4.1
Revisi 3
Terakhir diperbarui: 24 Juni 2013
Hak Cipta © 2012, Google Inc. Semua hak dilindungi.
compatibility@android.com
Daftar Isi
1. Pengantar
2. Referensi
3. Software
3.1. Kompatibilitas API yang Dikelola3 .2.
Kompatibilitas API Soft
3.2.1. Izin
3.2.2. Mem-build Parameter
3.2.3. Kompatibilitas Intent
3.2.3.1. Intent Aplikasi Core
3.2.3.2. Penggantian Intent
3.2.3.3. Namespace Intent
3.2.3.4. Intent Siaran
3.3. Kompatibilitas API Native
3.3.1 Aplikasi Binary Interfaces
3.4. Kompatibilitas Web
3.4.1. Kompatibilitas WebView
3.4.2. Kompatibilitas Browser
3.5. Kompatibilitas Perilaku API
3.6. Namespace API
3.7. Kompatibilitas Virtual Machine
3.8. Kompatibilitas Antarmuka Pengguna
3.8.1. Widget
3.8.2. Notifikasi
3.8.3. Telusuri
3.8.4. Toast
3.8.5. Tema
3.8.6. Live Wal papers
3.8.7. Tampilan Aplikasi Terbaru
3 .8.8. Input Management Settings
3.8.9. Kontrol Jarak Jauh Layar Kunci
3.9 Device Administration
3.10 Accessibility
3.11 Text-to-Speech
4. Kompatibilitas Pengemasan Aplikasi
5. Kompatibilitas Multimedia
5.1. Codec Media
5.2. Encoding Video
5.3. Rekaman Audio
5.4. Latensi Audio
5,5. Protokol Jaringan
6. Kompatibilitas Alat Developer
7. Kompatibilitas Hardware
7.1. Tampilan dan Grafik
7.1.1. Konfigurasi Layardi
7.1.2. Metrik Display
7.1.3. Orientasi Layarn
7.1.4. Akselerasi Grafis 2D dan 3Dleration
7 .1.5. Mode Kompatibilitas Aplikasi Lama
7.1.6. Jenis Layar
7.1.7. Teknologi Layar
7.2. DiPerangkat Input
7.2.1. Keyboard
7.2.2. Navigasi non-sentuh
7.2.3. Tombol navigasi
7.2.4. Input layar sentuh
7.2.5. Input sentuh palsu
7.2.6. Mikrofon
7.3. Sensor
7.3.1. Akselerometer

7.3.1. Akselerometer
7.3.2. Magnetometer
7.3.3. GPS
7.3.4. Giroskop
7.3.5. Barometer
7.3.6. Termometer
7.3.7. Fotometer
7.3.8. Sensor Kedekatan
7.4. Konektivitas Data
7.4.1. Telepon
7.4.2. IEEE 802.11 (Wi-Fi)
7.4.2.1. Wi-Fi Direct
7.4.3. Bluetooth
7.4.4. Komunikasi Nirkabel Jarak Dekat
7.4.5. Kemampuan Jaringan Minimum
7.5. Camera
7.5.1. Kamera-Belakang
7.5.2. Kamera Depan
7.5.3. Perilaku Camera API
7.5.4. Orientasi Kamera
7.6. Memori dan Penyimpanan
7.6.1. Memori dan Penyimpanan Minimum
7.6.2. Penyimpanan Bersama Aplikasi
7.7. USB
8. Kompatibilitas Performa
9. Kompatibilitas Model Keamanan
9.1. Izin
9.2. UID dan Proses Isolasi
9.3. Izin Sistem File
9.4. Lingkungan Eksekusi Alternatif
10. Pengujian Kompatibilitas Software
10.1. Compatibility Test Suite
10.2. CTS Verifier
10.3. Aplikasi Referensi
11. Updatable Software
12. Contact Us
Lampiran A - Prosedur Pengujian Bluetooth

1. Pengantar
Dokumen ini menguraikan persyaratan yang harus dipenuhi agar perangkat
kompatibel dengan Android 4.1.
Penggunaan "harus", "tidak boleh", "wajib", "harus ", "tidak harus", "sebaiknya", "sebaiknya tidak",
"direkomendasikan", "boleh" dan "opsional" adalah 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.1. "Penerapan
perangkat" atau "penerapan" adalah solusi hardware/software yang dikembangkan.
Agar dianggap kompatibel dengan Android 4.1, implementasi perangkat HARUS memenuhi
persyaratan yang ditampilkan dalam Definisi Kompatibilitas ini, termasuk dokumen apa pun
yang disertakan melalui referensi.
Jika definisi ini atau pengujian software yang dijelaskan di Bagian 10 tidak ada,
ambigu, atau tidak lengkap, developer implementasi perangkat bertanggung jawab untuk memastikan
kompatibilitas dengan implementasi yang ada.
Oleh karena itu, Project Open Source Android [Referensi, 3] adalah referensi
dan implementasi pilihan Android. Penerapkan perangkat sangat
dianjurkan untuk mendasarkannya sebanyak mungkin pada
kode sumber"upstream" yang tersedia dari Project Open Source Android. Meskipun beberapa
komponen dapat secara hipotetik diganti dengan implementasi alternatif, praktik
ini sangat tidak dianjurkan, karena lulus pengujian software akan menjadi
jauh lebih sulit. Penerap bertanggung jawab untuk memastikan kompatibilitas
perilaku yang lengkap dengan implementasi Android standar, termasuk dan di luar
Compatibility Test Suite. Terakhir, perhatikan bahwa penggantian komponen dan
perubahan tertentu secara eksplisit dilarang oleh dokumen ini.
2. Referensi
1.  Tingkat Persyaratan RFC2119 IETF: http://www.ietf.org/rfc/rfc2119.txt
2.  Ringkasan Program Kompatibilitas Android:
http://source.android.com/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.  Android 4.1 al lowed version strings:
http://source.android.com/compatibility/4.1/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.  HTML5/W3C geolocation API: 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.  Referensi 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.  Search Manager:
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 Live: http://developer.android.com/resources/articles/live-
wal papers.html
27.  Administrasi Perangkat Android:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  class android.app.admin.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.  API Aksesibilitas Android:
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):
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.  Daftar Fitur Hardware dan class android.content.pm.PackageManager
Android:
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/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.  android.hardware.Camera:
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.  Apps for Android: http://code.google.com/p/apps-for-android
56.  class android.app.DownloadManager:
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 Streaming Live HTTP: 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.  Bluetooth Secure Simple Pairing Using 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.  Media Remote Control Client:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  Motion Event API:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  Konfigurasi Input Sentuhan: http://source.android.com/tech/input/touch-
devices.html
Banyak dari referensi ini berasal langsung atau tidak langsung dari Android 4.1 SDK,
dan akan  berfungsi secara identik dengan informasi dalam dokumentasi SDK tersebut. Dalam
kasus apa pun saat Definisi Kompatibilitas ini atau Compatibility Test Suite tidak setuju dengan
dokumentasi SDK, dokumentasi SDK dianggap otoritatif. Setiap
detail teknis yang disediakan dalam referensi yang disertakan di atas dianggap oleh
penyertaan 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 ditampilkan ke aplikasi yang berjalan di lingkungan
VM terkelola. Implementasi perangkat HARUS menyediakan implementasi lengkap,
termasuk semua perilaku yang didokumentasikan, dari API yang didokumentasikan dan ditampilkan oleh Android
4.1 SDK [Referensi, 4].
Implementasi perangkat MUST NOT omit any managed APIs, alter API interfaces or
signatures, deviate from the documented behavior, or include no-ops, except where
specifical y al owed by this Compatibility Definition.
Definisi Kompatibilitas ini memungkinkan 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 persyaratan
spesifik untuk skenario ini.
3.2. Kompatibilitas API Soft
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
Penerapan 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
API Android menyertakan sejumlah konstanta di  class android.os.Build
[Resources, 6] yang dimaksudkan untuk menjelaskan perangkat saat ini. Untuk memberikan nilai
yang konsisten dan bermakna di seluruh implementasi perangkat, tabel di bawah ini menyertakan pembatasan
tambahan pada format nilai ini yang harus
conform dengan implementasi perangkat.
Parameter
Komentar
Versi sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Kolom ini HARUS memiliki satu
android.os.Build.VERSION.RELEASE
dari nilai string yang ditentukan di [Resources, 7].
Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga.
android.os.Build.VERSION.SDK
Untuk Android 4.1, kolom ini HARUS memiliki nilai bilangan bulat 16.

Versi sistem Android yang sedang dijalankan, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga.
android.os.Build.VERSION.SDK_INT
Untuk Android 4.1, kolom ini HARUS memiliki nilai bilangan bulat 16.
Nilai yang dipilih oleh penerapkan perangkat yang menetapkan build tertentu dari sistem Android
yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build yang berbeda yang tersedia untuk pengguna akhir
android.os.Build.VERSION.INCREMENTAL
. Penggunaan biasa kolom ini adalah untuk menunjukkan nomor build atau ID perubahan kontrol sumber yang
digunakan untuk membuat build. Tidak ada persyaratan pada format tertentu kolom ini, kecuali bahwa kolom ini HARUS
BUKAN nol  atau string kosong ("").
Nilai yang dipilih oleh penerapkan perangkat yang mengidentifikasi hardware internal tertentu yang digunakan oleh perangkat, dalam
format yang dapat dibaca manusia. Kemungkinan penggunaan kolom ini adalah untuk menunjukkan revisi tertentu dari papan yang mengaktifkan
android.os.Build.BOARD
perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCI 7-bit dan cocok dengan ekspresi reguler
"^[a-zA-Z0-9.,_-]+$".
Nilai yang dipilih oleh penerapkan 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
android.os.Build.BRAND
dan/atau operator yang menjual perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCI 7-bit dan cocok dengan ekspresi reguler
"^[a-zA-Z0-9.,_-]+$".
Nama set petunjuk (jenis CPU + konvensi ABI) kode native. Lihat  Bagian 3.3: API Native
android.os.Build.CPU_ABI
Kompatibilitas.
Nama set petunjuk kedua (jenis CPU + konvensi ABI) kode native. Lihat  Bagian 3.3: Kompatibilitas
android.os.Build.CPU_ABI2
API Native.
Nilai yang dipilih oleh penerapkan perangkat yang mengidentifikasi konfigurasi atau revisi tertentu dari body
android.os.Build.DEVICE
(terkadang disebut "desain industri") dari perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCI
7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
String yang mengidentifikasi build ini secara unik. Metadata HARUS dapat dibaca oleh manusia. Template ini HARUS mengikuti template
ini:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Misalnya:
android.os.Build.FINGERPRINT
acme/mydevice/generic:4.1/JRN53/3359:userdebug/test-keys
Sidik jari HARUS TIDAK menyertakan karakter spasi kosong. Jika kolom lain yang disertakan dalam template di atas memiliki karakter spasi kosong
, kolom tersebut HARUS diganti di sidik jari build dengan karakter lain, seperti karakter garis bawah
("_"). Nilai kolom ini HARUS dapat dienkode sebagai ASCI 7-bit.
Nama hardware (dari command line kernel atau /proc). Harus cukup dapat dibaca manusia
android.os.Build.HARDWARE
. Nilai kolom ini HARUS dapat dienkode sebagai ASCI 7-bit dan cocok dengan ekspresi reguler "^[a-
zA-Z0-9.,_-]+$".
String yang secara unik mengidentifikasi host tempat build dibuat, dalam format yang dapat dibaca manusia. Tidak ada persyaratan
android.os.Build.HOST
pada format tertentu dari kolom ini, kecuali bahwa kolom ini TIDAK BOLEH nol  atau string kosong ("").
ID yang dipilih oleh penerapkan perangkat untuk merujuk ke rilis tertentu, dalam format yang dapat dibaca manusia. Kolom
ini dapat sama dengan android.os.Build.VERSION.INCREMENTAL, tetapi HARUS merupakan nilai yang cukup
android.os.Build.ID
yang bermakna bagi pengguna akhir untuk membedakan antara build software. Nilai kolom ini HARUS dapat dienkode
sebagai ASCI 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
Nama dagang Produsen Peralatan Asli (OEM) produk. Tidak ada persyaratan pada
android.os.Build.MANUFACTURER
format tertentu dari kolom ini, kecuali bahwa kolom ini TIDAK BOLEH nol  atau string kosong ("").
Nilai yang dipilih oleh penerapkan perangkat yang berisi nama perangkat seperti yang diketahui oleh pengguna akhir.
android.os.Build.MODEL
INI HARUS memiliki nama yang sama dengan nama yang digunakan untuk memasarkan dan menjual perangkat kepada pengguna akhir. Tidak ada
persyaratan pada format tertentu kolom ini, kecuali bahwa kolom ini TIDAK BOLEH nol  atau string kosong ("").
Nilai yang dipilih oleh penerapkan perangkat yang berisi nama pengembangan atau nama kode produk
android.os.Build.PRODUCT
(SKU). HARUS dapat dibaca manusia, tetapi tidak selalu dimaksudkan untuk dilihat oleh pengguna akhir. Nilai kolom
HARUS dapat dienkode sebagai ASCI 7-bit dan cocok dengan ekspresi reguler "^[a-zA-Z0-9.,_-]+$".
Nomor serial hardware, jika tersedia. Nilai kolom ini HARUS dapat dienkode sebagai ASCI 7-bit dan cocok
android.os.Build.SERIAL
ekspresi reguler "^([a-zA-Z0-9]{0,20})$".
Daftar tag yang dipisahkan koma yang dipilih oleh penerapkan perangkat yang lebih membedakan build. Untuk contoh
android.os.Build.TAGS
, "unsigned,debug". Nilai kolom ini HARUS dapat dienkode sebagai ASCI 7-bit dan cocok dengan ekspresi
reguler "^[a-zA-Z0-9.,_-]+$".
android.os.Build.TIME
Nilai yang mewakili stempel waktu saat build terjadi.
Nilai yang dipilih oleh penerapkan perangkat yang menentukan konfigurasi runtime build. Kolom ini
HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android standar: "user",
android.os.Build.TYPE
"userdebug", atau "eng". Nilai kolom ini HARUS dapat dienkode sebagai ASCI 7-bit dan cocok dengan ekspresi
reguler "^[a-zA-Z0-9.,_-]+$".
Nama atau ID pengguna dari pengguna (atau pengguna otomatis) yang membuat build. Tidak ada persyaratan pada
android.os.Build.USER
format tertentu dari kolom ini, kecuali bahwa kolom ini TIDAK BOLEH nol  atau string kosong ("").
3.2.3. Kompatibilitas Intent
Implementasi perangkat HARUS menghormati sistem Intent penghubung longgar Android, seperti

dijelaskan di bagian di bawah. Dengan "dihormati", artinya penerapkan perangkat
HARUS menyediakan Aktivitas atau Layanan Android yang menentukan filter Intent yang cocok dan
mengikat ke dan 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. Penerapan perangkat DAPAT mengganti
aplikasi ini dengan versi alternatif.
Namun, setiap versi alternatif tersebut HARUS menghormati pola Intent yang sama yang disediakan
oleh project upstream. Misalnya, jika perangkat berisi pemutar musik alternatif,
perangkat masih harus mengikuti pola Intent yang diterbitkan 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", penerapan
perangkat HARUS menyertakan komponen dari jenis yang sama yang menerapkan
pola filter Intent yang sama seperti aplikasi sistem Android inti.
Dengan kata lain, penerapan perangkat DAPAT mengganti aplikasi sistem Android inti;
tetapi, jika ya, penerapan 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 direferensikan di Bagian 3.2.3.2 untuk diganti oleh aplikasi pihak ketiga.
Implementasi open source upstream Android memungkinkan hal ini secara default; penerapkan
perangkat TIDAK BOLEH melampirkan hak istimewa khusus ke penggunaan aplikasi sistem
pola Intent ini, atau mencegah aplikasi pihak ketiga dari mengikat ke dan mengambil
kontrol atas pola ini. Larangan ini khususnya mencakup, tetapi tidak terbatas pada
menonaktifkan antarmuka pengguna "Chooser" yang memungkinkan pengguna memilih antara beberapa
aplikasi yang 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 agar pengguna dapat mengubah aktivitas default
untuk intent.
3.2.3.3. Namespace Intent
Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang menghormati
pola Intent baru atau Intent Broadcast menggunakan ACTION, CATEGORY, atau string kunci
lainnya di namespace android.* atau com.android.*. Penerapan perangkat TIDAK BOLEH
menyertakan komponen Android apa pun yang menghormati pola Intent baru atau Intent Broadcast
menggunakan ACTION, CATEGORY, atau string kunci lainnya di ruang paket milik
organisasi lain. Penerapan perangkat TIDAK BOLEH mengubah atau memperluas salah satu pola Intent
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 dikaitkan dengan organisasi
sendiri.
Larangan ini analog dengan yang ditentukan untuk class bahasa Java di Bagian
3.6.
3.2.3.4. Intent Penyebaran
Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan Intent tertentu guna memberi tahu

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 Pemberian Disiarkan dijelaskan dalam dokumentasi SDK.
3.3. Kompatibilitas API Native
3.3.1 Antarmuka Biner Aplikasi
Kode terkelola yang berjalan di Dalvik dapat diubah menjadi kode native yang disediakan dalam file
.apk aplikasi sebagai file .so ELF yang dikompilasi untuk arsitektur hardware perangkat yang sesuai.
Karena kode native sangat tergantung pada teknologi prosesor yang mendasarinya, Android
menentukan sejumlah Antarmuka Biner Aplikasi (ABI) di NDK Android, dalam file
docs/CPU-ARCH-ABIS.html. Jika implementasi perangkat kompatibel dengan satu atau beberapa
yang ditentukan, implementasi HARUS menerapkan kompatibilitas dengan Android NDK, seperti di bawah.
Jika implementasi perangkat menyertakan dukungan untuk Android ABI, implementasi tersebut:
HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil ke dalam
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 dengan akurat Antarmuka Biner Aplikasi native (ABI) yang didukung
oleh perangkat, melalui API android.os.Build.CPU_ABI
HARUS melaporkan hanya ABI tersebut yang didokumentasikan dalam versi terbaru Android
NDK, dalam file docs/CPU-ARCH-ABIS.txt
HARUS di-build 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 (penaut dinamis)
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 mendatang dari Android NDK mungkin akan memperkenalkan dukungan untuk
ABI tambahan. Jika implementasi perangkat tidak kompatibel dengan ABI yang telah ditetapkan sebelumnya,
TIDAK BOLEH melaporkan dukungan untuk ABI apa pun .
Kompatibilitas kode native sangat menantang. Oleh karena itu, perlu diulang bahwa
penerapkan perangkat SANGAT sangat dianjurkan untuk menggunakan implementasi
upstream dari 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 mungkin untuk mengembangkan
suite pengujian komprehensif untuk sistem rendering web, penerapkan perangkat HARUS menggunakan
build upstream khusus WebKit dalam implementasi WebView. Secara khusus:
Implementasi android.webkit.WebView implementasi perangkat HARUS
didasarkan pada build WebKit 534.30 dari hierarki Open Source Android upstream
untuk Android 4.1. Build ini menyertakan serangkaian perbaikan fungsi dan keamanan
tertentu untuk WebView. Penerapan perangkat DAPAT menyertakan penyesuaian pada penerapan
WebKit; tetapi, penyesuaian tersebut TIDAK BOLEH mengubah
perilaku WebView, termasuk perilaku rendering.
String agen pengguna yang dilaporkan oleh WebView HARUS berformat ini:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
Nilai string $(VERSION) HARUS sama dengan nilai untuk

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
yang dikonfigurasi saat ini dari perangkat
Nilai string $(MODEL) HARUS sama dengan nilai untuk
android.os.Build.MODEL
Nilai string $(BUILD) HARUS sama dengan nilai untuk
android.os.Build.ID
Penerapan perangkat DAPAT menghapus Mobile dalam string agen pengguna
Komponen WebView HARUS menyertakan dukungan untuk sebanyak mungkin HTML5
[Resources, 11]. Minimal, implementasi perangkat HARUS mendukung setiap
API ini yang dikaitkan dengan HTML5 di WebView:
cache aplikasi/operasi offline [Referensi, 12]
tag <video> [Referensi, 13]
geolokasi [Resourensi, 14]
Selain itu, implementasi perangkat HARUS mendukung API webstorage HTML5/W3C
[Referensi, 15], dan HARUS mendukung API IndexedDB HTML5/W3C [Referensi,
16]. Perhatikan bahwa seiring lembaga standar pengembangan web bertransisi untuk memilih
IndexedDB daripada webstorage, IndexedDB diharapkan akan menjadi komponen
yang diperlukan di versi Android mendatang.
API HTML5, seperti semua API JavaScript, 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
berdasarkan WebKit, seperti yang dijelaskan di Bagian 3.4.1.
Implementasi DAPAT mengirimkan string agen pengguna kustom di aplikasi Browser
mandiri.
Aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream
atau penggantian pihak ketiga) HARUS menyertakan dukungan untuk sebanyak mungkin
HTML5 [Referensi, 11]. Minimal, implementasi perangkat HARUS mendukung
setiap API ini yang dikaitkan dengan HTML5:
cache aplikasi/operasi offline [Referensi, 12]
tag <video> [Referensi, 13]
geolokasi [Referensi, 14]
Selain itu, implementasi perangkat HARUS mendukung API webstorage HTML5/W3C
[Referensi, 15], danHARUS mendukung API IndexedDB HTML5/W3C [Referensi,
16]. Perhatikan bahwa saat lembaga standar pengembangan web bertransisi untuk memilih
IndexedDB daripada webstorage, IndexedDB diharapkan akan menjadi komponen
yang diperlukan di versi Android mendatang.
3.5. Kompatibilitas Perilaku API
Perilaku setiap jenis API (terkelola, soft, native, dan web) harus
konsisten dengan implementasi yang lebih disukai dari project open source upstream Android
[Referensi, 3]. Beberapa area kompatibilitas tertentu adalah:
Perangkat TIDAK BOLEH mengubah perilaku atau semantik Intent standar
Devices MUST NOT alter the lifecycle or lifecycle semantics of a particular type
of system component (such as Service, Activity, ContentProvider, etc.)
Devices MUST NOT change the semantics of a standard permission
Daftar di atas tidak komprehensif. Compatibility Test Suite (CTS) menguji
bagian penting platform untuk kompatibilitas perilaku, tetapi tidak semua .
Implementer bertanggung jawab untuk memastikan kompatibilitas perilaku dengan Project Open Source
Android. Oleh karena itu, penerapkan perangkat HARUS menggunakan kode
sumber yang tersedia melalui Project Open Source Android jika memungkinkan, bukan menerapkan ulang bagian penting dari 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, penerapkan
perangkat TIDAK BOLEH melakukan modifikasi yang dilarang (lihat di bawah) pada namespace
paket ini:
java.*
javax.*
sun.*
android.*
com.android.*
Perubahan yang dilarang mencakup:
Implementasi perangkat TIDAK BOLEH mengubah API yang ditampilkan secara publik di
platform Android dengan mengubah tanda tangan metode atau class, atau dengan menghapus
class atau kolom class.
Penerapan perangkat DAPAT mengubah implementasi dasar API, tetapi
perubahan tersebut TIDAK BOLEH memengaruhi perilaku yang dinyatakan dan tanda tangan
bahasa Java dari API apa pun yang ditampilkan secara publik.
Penerapan 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 dihiasi dengan penanda
"@hide" seperti yang digunakan dalam kode sumber Android upstream. Dengan kata lain, penerapkan
perangkat TIDAK BOLEH mengekspos API baru atau mengubah API yang ada di namespace
yang dinyatakan di atas. Penerapan perangkat DAPAT melakukan modifikasi khusus internal, tetapi
modifikasi tersebut TIDAK BOLEH diiklankan atau ditampilkan kepada developer.
Penerapan perangkat DAPAT menambahkan API kustom, tetapi API tersebut TIDAK BOLEH berada di namespace
yang dimiliki oleh atau merujuk ke organisasi lain. Misalnya, penerapkan
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 umum Android
sehingga hanya aplikasi yang secara eksplisit menggunakannya (melalui mekanisme <uses-library>
) yang dipengaruhi oleh peningkatan penggunaan memori dari API tersebut.
Jika penerapkan perangkat menyarankan untuk meningkatkan salah satu namespace paket di atas
(seperti dengan menambahkan fungsi baru yang berguna ke API yang ada, atau menambahkan API baru), penerapkan
HARUS membuka 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 menamai API di
bahasa pemrograman Java; bagian ini hanya bertujuan untuk memperkuat konvensi
tersebut dan membuatnya mengikat melalui penyertaan dalam definisi kompatibilitas ini.
3.7. Kompatibilitas Mesin Virtual
Implementasi perangkat HARUS mendukung spesifikasi bytecode Dalvik Executable (DEX)
lengkap dan semantik Mesin Virtual Dalvik [Referensi, 17].
Implementasi perangkat HARUS mengonfigurasi Dalvik untuk menca tukan memori sesuai
dengan platform Android upstream, dan seperti yang ditentukan olehta bel berikut. (Lihat
Bagian 7.1.1 untuk definisi ukuran layar dan kepadatan layar.)
Perhatikan bahwa nilai memori yang ditentukan di bawah dianggap nilai minimum, dan implementasi
perangkat DAPAT mengalokasikan lebih banyak memori per aplikasi.
Ukuran Layar
Kepadatan Layar
Memori Aplikasi
kecil  / normal / besar
ldpi / mdpi
16 MB
kecil  / normal / besar
tvdpi / hdpi
32 MB
kecil  / normal / besar
xhdpi
64 MB
besar
mdpi
32 MB
besar
tvdpi / hdpi
64 MB
besar
xhdpi
128 MB
3.8. Kompatibilitas Antarmuka Pengguna
3.8.1. Widget
Android menentukan jenis komponen dan API dan siklus proses yang sesuai yang memungkinkan
aplikasi

untuk mengekspos "AppWidget" kepada pengguna akhir [Resources, 18]. Rilis referensi Open Source Android
menyertakan aplikasi Peluncur yang menyertakan fitur 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 fitur antarmuka pengguna untuk menambahkan, mengonfigurasi, melihat, dan menghapus
AppWidget langsung dalam Peluncur. Peluncur Alternatif DAPAT menghapus elemen antarmuka
pengguna ini; tetapi, jika elemen ini dihapus, implementasi perangkat HARUS
menyediakan aplikasi terpisah yang dapat diakses dari Peluncur yang memungkinkan pengguna menambahkan,
mengonfigurasi, melihat, dan menghapus Widget Aplikasi.
Implementasi perangkat HARUS mampu merender widget yang 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, terutama suara, getaran, dan cahaya. Implementasi perangkat HARUS
mendukung notifikasi yang menggunakan fitur hardware, seperti yang dijelaskan dalam dokumentasi
SDK, dan sebanyak mungkin dengan hardware implementasi perangkat.
Misalnya, jika implementasi perangkat menyertakan vibrator, implementasi tersebut HARUS
menerapkan API getaran dengan benar. Jika implementasi perangkat tidak memiliki hardware,
API yang sesuai HARUS diimplementasikan sebagai no-ops. Perhatikan bahwa perilaku ini
dijelaskan lebih lanjut di Bagian 7.
Selain itu, implementasin HARUS merender semua resource (ikon, file
suara, dll.) yang disediakan di API [Resources, 20], atau di panduan gaya ikon
Status/Panel Sistem [Resources, 21]. Penerapan perangkat DAPAT memberikan pengalaman
pengguna alternatif untuk notifikasi daripada yang disediakan oleh implementasi
Open Source Android referensi; tetapi, sistem notifikasi alternatif tersebut HARUS mendukung resource notifikasi
yang ada, seperti di atas.
Android 4.1 menyertakan dukungan untuk notifikasi lengkap, seperti Tampilan interaktif untuk
notifikasi yang sedang berlangsung. Implementasi perangkat HARUS menampilkan dan menjalankan notifikasi
lengkap dengan benar, seperti yang didokumentasikan di Android API.
3.8.3. Penelusuran
Android menyertakan API [Referensi, 22] yang memungkinkan developer memasukkan penelusuran ke dalam
aplikasi mereka, dan mengekspos data aplikasi mereka ke dalam penelusuran sistem global.
Secara umum, fungsi ini terdiri dari satu antarmuka pengguna seluruh sistem
yang memungkinkan pengguna memasukkan kueri, menampilkan saran saat pengguna mengetik, dan menampilkan
hasil. Android API memungkinkan developer menggunakan ulang 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
yang dibagikan dan 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 adalah menampilkan
hasil dan saran mesin penelusuran web.
3.8.4. Toast
Aplikasi dapat menggunakan API "Toast" (ditentukan di [Resources, 23]) untuk menampilkan string non-
modal singkat kepada pengguna akhir, yang menghilang setelah jangka waktu singkat. Implementasi
perangkat HARUS menampilkan Toast dari aplikasi ke pengguna akhir dengan cara visibilitas
tinggi.
3.8.5. Tema
Android menyediakan "tema" sebagai mekanisme untuk aplikasi menerapkan gaya di
seluruh Aktivitas atau aplikasi. Android 3.0 memperkenalkan tema "Holo" atau "holografis"
baru sebagai serangkaian gaya yang ditentukan untuk digunakan oleh developer aplikasi jika mereka ingin mencocokkan
tampilan dan nuansa tema Holo seperti yang ditentukan oleh Android SDK [Referensi, 24]. Implementasi
perangkat TIDAK BOLEH mengubah salah satu atribut tema Holo yang ditampilkan ke aplikasi

[Resource, 25].
Android 4.0 memperkenalkan tema "Default Perangkat" baru sebagai serangkaian gaya yang ditentukan untuk digunakan oleh
developer aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema
perangkat seperti yang ditentukan oleh penerapkan perangkat. Penerapan perangkat DAPAT mengubah
atribut tema DeviceDefault yang ditampilkan ke aplikasi [Resources, 25].
3.8.6. Wallpaper Animasi
Android menentukan jenis komponen dan API serta 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 yang mirip dengan kemampuan input
terbatas yang ditampilkan sebagai wallpaper, di balik aplikasi lain.
Hardware dianggap mampu menjalankan wallpaper live dengan andal jika dapat menjalankan semua wallpaper
live, tanpa batasan pada fungsi, dengan kecepatan frame yang wajar tanpa
dampak negatif pada aplikasi lain. Jika batasan pada hardware menyebabkan wallpaper wal
dan/atau aplikasi error, berfungsi tidak semestinya, menggunakan daya CPU atau baterai secara berlebihan, atau
berjalan dengan kecepatan frame yang tidak dapat diterima, hardware dianggap tidak dapat menjalankan
wallpaper wal live. Sebagai contoh, beberapa wallpaper live 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 konteks OpenGL
oleh wallpaper hidup dapat bertentangan dengan aplikasi lain yang juga menggunakan konteks OpenGL.
Implementasi perangkat yang mampu menjalankan wallpaper live secara andal seperti yang dijelaskan
di atas HARUS menerapkan wallpaper live. Implementasi perangkat yang ditentukan untuk tidak
menjalankan wallpaper live secara andal seperti yang dijelaskan di atas TIDAK BOLEH menerapkan wallpaper live.
3.8.7. Tampilan Aplikasi Terbaru
Kode sumber upstream Android 4.1 menyertakan antarmuka pengguna untuk menampilkan aplikasi
terbaru menggunakan gambar thumbnail status grafis aplikasi pada
saat pengguna terakhir keluar dari aplikasi. Implementasi perangkat DAPAT mengubah atau
menghapus antarmuka pengguna ini; tetapi, versi Android mendatang direncanakan untuk menggunakan
fungsi ini secara lebih luas. Implementasi perangkat sangat
dianjurkan untuk menggunakan antarmuka pengguna Android 4.1 upstream (atau antarmuka berbasis thumbnail
yang mirip) untuk aplikasi terbaru, atau mungkin tidak kompatibel dengan
versi Android mendatang.
3.8.8. Setelan Pengelolaan Input
Android 4.1 menyertakan dukungan untuk Mesin Pengelolaan Input. API Android 4.1
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. Kontrol Jarak Jauh Layar Kunci
Android 4.0 memperkenalkan dukungan untuk Remote Control API yang memungkinkan aplikasi media
berintegrasi dengan kontrol pemutaran yang ditampilkan dalam tampilan jarak jauh seperti layar kunci
perangkat [Referensi, 69]. Implementasi perangkat HARUS menyertakan dukungan untuk
menyematan kontrol jarak jauh di layar kunci perangkat.
3.9 Pengelolaan Perangkat
Android 4.1 menyertakan fitur yang memungkinkan aplikasi yang memahami keamanan untuk melakukan fungsi pengelolaan
perangkat di tingkat sistem, seperti menerapkan kebijakan sandi atau
melakukan pembersihan jarak jauh, melalui Android Device Administration API [Referensi,
27]. Implementasi perangkat HARUS menyediakan implementasi
class DevicePolicyManager [Resources, 28], dan HARUS mendukung seluruh rentang
kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK [Resources,
27].
Catatan: meskipun beberapa persyaratan yang diuraikan di atas dinyatakan sebagai "HARUS" untuk
Android 4.1, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubah
ini menjadi "HARUS". Artinya, persyaratan ini opsional di Android 4.1, tetapi akan
diperlukan oleh versi mendatang. Perangkat yang sudah ada dan baru yang menjalankan Android 4.1 sangat
dianjurkan untuk memenuhi persyaratan ini di Android 4.1, atau perangkat tersebut tidak akan
dapat mencapai kompatibilitas Android saat diupgrade ke versi mendatang.
3.10 Aksesibilitas
Android 4.1 menyediakan lapisan aksesibilitas yang membantu pengguna dengan disabilitas untuk menavigasi
perangkat mereka dengan lebih mudah. Selain itu, Android 4.1 menyediakan API platform yang memungkinkan

implementasi layanan aksesibilitas untuk menerima callback untuk peristiwa pengguna dan sistem
dan membuat mekanisme masukan alternatif, seperti text-to-speech, masukan
haptik, dan navigasi trackball /d-pad [Resources, 29].Implementasi perangkat
HARUS menyediakan implementasi framework aksesibilitas Android yang konsisten
dengan implementasi Android default. Khususnya, implementasi perangkat HARUS
memenuhi persyaratan berikut.
Implementasi perangkat HARUS mendukung implementasi layanan aksesibilitas pihak ketiga
melalui API android.accessibilityservice [Referensi,
30].
Implementasi perangkat HARUS membuat AccessibilityEvents dan mengirimkan
peristiwa ini ke semua implementasi AccessibilityService yang 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.1 menyertakan API yang memungkinkan aplikasi menggunakan layanan text-to-speech (TTS)
, dan memungkinkan penyedia layanan menyediakan implementasi layanan TTS
[Referensi, 32]. Implementasi perangkat HARUS memenuhi persyaratan ini 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 upstream Android menyertakan implementasi mesin TTS yang 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 Pembungkusan Aplikasi
Implementasi perangkat HARUS menginstal dan menjalankan file ".apk" Android seperti yang dibuat 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
sehingga mencegah file tersebut diinstal dan berjalan secara benar
di perangkat kompatibel lainnya.Penerapan perangkat HARUSmenggunakan implementasi upstream
referensi Dalvik, dan sistem pengelolaan paket
implementasi referensi.
5. Kompatibilitas Multimedia
Implementasi perangkat HARUS menyertakan setidaknya satu bentuk output audio, seperti
speaker, colokan 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 diizinkan secara eksplisit dalam dokumen
ini. Secara khusus, implementasi perangkat HARUS mendukung format media,
enkoder, dekoder, 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.
Perlu diingat bahwa baik Google maupun Open Handset Alliance tidak memberikan
pernyataan bahwa codec ini tidak terikat oleh paten pihak ketiga.
Bagi yang berniat menggunakan kode sumber ini dalam produk hardware atau software,
perlu diingat bahwa 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 bitrate tertentu untuk sebagian besar codec video
karena hardware perangkat saat ini tidak selalu mendukung bitrate yang memetakan
persyaratan bitrate yang ditentukan oleh standar yang relevan. Sebaliknya, implementasi
perangkat HARUS mendukung bitrate tertinggi yang praktis di hardware, hingga

batas yang ditentukan oleh spesifikasi.

Jenis File /
Format /
Jenis
Encoder
Decoder
Detail
Penampung
Codec
Format
Dukungan untuk
DIWAJIBKAN
mono/stereo/5.0/5.1*
MPEG-4
Wajib untuk implementasi perangkat
konten dengan
Profil AAC
yang menyertakan hardware mikrofon
DIWAJIBKAN
sampling standar
(AAC LC)
dan menentukan
kecepatan
3GPP
dari 8 hingga 48
android.hardware.microphone.
(.3gp)
kHz.
MPEG-4
Dukungan untuk
(.mp4,
MPEG-4
mono/stereo/5.0/5.1*
.m4a)
HE AAC
konten dengan
ADTS mentah

DIBUTUHKAN
Profil
sampling standar
AAC (.aac,
(AAC+)
kecepatan dari 16 hingga 48
dekode dalam
kHz.
Android
3.1+,
Dukungan untuk
MPEG-4
DIBUTUHKAN untuk perangkat
encode dalam
mono/stereo/5.0/5.1*
implementasi HE AAC v2
yang menyertakan
konten
Android dengan
hardware mikrofon
Profil
dan

4.0+, sampling standar ADIF
(enhanced
define
not
rates from 16 to 48
AAC+)
android.hardware.microphone
didukung)
kHz.
MPEG-TS
MPEG-4
(.ts, not
Audio
REQUIRED for device
Support for
seekable,
Object Type
implementations that include
mono/stereo content
Android
ER AAC
microphone hardware and
REQUIRED
with standard
3.0+)
ELD
define
sampling rates from
(Enhanced
android.hardware.microphone
16 to 48 kHz.
Penundaan Rendah
AAC)
DIPERLUKAN
Wajib untuk implementasi perangkat
4,75 hingga 12,2 kbps
AMR-NB
yang menyertakan hardware mikrofon
DIPERLUKAN
3GPP (.3gp)
dengan sampel @ 8 kHz
dan menentukan
android.hardware.microphone.
DIBUTUHKAN
Wajib untuk implementasi perangkat
9 frekuensi dari 6,60
AMR-WB
yang menyertakan hardware mikrofon
DIBUTUHKAN
kbit/dtk hingga 23,85 kbit/dtk
3GPP (.3gp)
dan menentukan
sampel @ 16 kHz
android.hardware.microphone.
Mono/Stereo (tanpa
multisaluran).
Audio
Frekuensi sampling hingga
48 kHz (tetapi hingga
44,1 kHz direkomendasikan di
perangkat dengan 44,1
DIBUTUHKAN
FLAC

output kHz, karena penurun sampel
FLAC (.flac) hanya
(Android 3.1+)
ke 44,1 kHz
tidak
menyertakan filter
pass rendah).
16-bit
direkomendasikan; tidak ada
dither yang diterapkan untuk 24-
bit.
Mono/Stereo 8-
320 Kbps konstan
MP3

WAJIB
MP3 (.mp3)
(CBR) atau kecepatan bit
variabel (VBR)
Jenis 0 dan
MIDI Jenis 0 dan 1.
1 (.mid,
DLS Versi 1 dan
.xmf, .mxmf)
2. XMF dan Mobile
RTTTL/RTX
MIDI

DIBUTUHKAN
XMF. Dukungan untuk
(.rtttl, .rtx)
format nada dering
OTA (.ota)
RTTTL/RTX, OTA,
iMelody
dan iMelody
(.imy)

Ogg (.ogg)
Vorbis

WAJIB

Matroska
(.mkv)
PCM linear 8-bit dan 16-bit
** (kecepatan
hingga batas
hardware).Perangkat
HARUS mendukung
PCM/WAVE
WAJIB
WAJIB
WAVE (.wav)
kecepatan sampling untuk
perekaman PCM mentah
pada frekuensi
8000,16000 dan
44100 Hz

JPEG
WAJIB
WAJIB
Base+progressive
JPEG (.jpg)
GIF

WAJIB

GIF (.gif)
Gambar
PNG
WAJIB
WAJIB

PNG (.png)
BMP

WAJIB

BMP (.bmp)
WEBP
WAJIB
WAJIB

WebP (.webp)
WAJIB
Wajib untuk implementasi perangkat
3GPP
yang menyertakan hardware kamera dan
(.3gp)
H.263
WAJIB

tentukan android.hardware.camera
MPEG-4
atau
(.mp4)
android.hardware.camera.front.
3GPP
(.3gp)
WAJIB
MPEG-4
(.mp4)
Wajib untuk implementasi perangkat
MPEG-TS
yang menyertakan hardware kamera dan
Profil Dasar Pengukuran
Video
H.264 AVC
WAJIB
(.ts, AAC
menentukan android.hardware.camera
(BP)
hanya audio,
atau
tidak
android.hardware.camera.front.
dapat di-seek,
Android
3.0+)
MPEG-4

WAJIB

3GPP (.3gp)
SP
WebM (.webm)
WAJIB
dan Matroska
VP8

(Android

(.mkv, Android
2.3.3+)
4.0+)
*Catatan: Hanya downmix konten 5.0/5.1 yang diperlukan; perekaman atau rendering lebih dari 2
saluran adalah opsional. **Catatan: Perekaman PCM linear 16-bit wajib. Perekaman PCM
linear 8-bit tidak wajib.
5.2 Video Encoding
Implementasi perangkat Android yang menyertakan kamera belakang dan mendeklarasikan
android.hardware.camera HARUS mendukung profil encoding video berikut.
HD (Jika didukung oleh

SD (Kualitas rendah) SD (Kualitas tinggi)
hardware)
Baseline H.264
Baseline H.264
Codec video
Profil Baseline H.264
Profil
Profil
Video
176 x 144 px
480 x 360 px
1280 x 720 px
resolusi
Frame video 12 fps
30 fps
30 fps
kecepatan
500 Kbps atau
Bitrate video 56 Kbps
2 Mbps atau lebih tinggi
lebih tinggi
Codec audio AAC-LC
AAC-LC
AAC-LC

Audio
1 (mono)
2 (stereo)
2 (stereo)
saluran
Bitrate audio 24 Kbps
128 Kbps
192 Kbps
5.3. 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 ini:
Perangkat HARUS menunjukkan karakteristik amplitudo versus frekuensi
yang hampir datar; khususnya, ±3 dB, dari 100 Hz hingga 4000 Hz
Kepekaan input audio HARUS ditetapkan sehingga sumber tingkat daya suara
(SPL) 90 dB pada 1000 Hz menghasilkan RMS 2500 untuk sampel 16-bit.
Tingkat amplitudo PCM HARUS melacak perubahan SPL input secara linear selama setidaknya
rentang 30 dB dari -18 dB hingga +12 dB re 90 dB SPL di mikrofon.
Distorsi harmonis total HARUS kurang dari 1% untuk 1Khz pada tingkat input
SPL 90 dB.
Selain spesifikasi perekaman di atas, saat aplikasi telah memulai
merekam streaming audio menggunakan
sumber audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:
Pemrosesan pengurangan derau, jika ada, HARUS dinonaktifkan.
Kontrol penguatan otomatis, jika ada, HARUS dinonaktifkan.
Catatan: meskipun beberapa persyaratan yang diuraikan di atas dinyatakan sebagai "HARUS" untuk
Android 4.1, Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubah persyaratan ini
menjadi "HARUS". Artinya, persyaratan ini opsional di Android 4.1, tetapi akan
diperlukan oleh versi mendatang. Perangkat yang sudah ada dan baru yang menjalankan Android 4.1 sangat
dianjurkan untuk memenuhi persyaratan ini di Android 4.1, atau perangkat tersebut tidak akan
dapat mencapai kompatibilitas Android saat diupgrade ke versi mendatang.
5.4. Latensi Audio
Latensi audio secara luas didefinisikan sebagai interval antara saat aplikasi meminta
operasi pemutaran atau perekaman audio, dan saat implementasi perangkat sebenarnya
memulai operasi. Banyak class aplikasi mengandalkan latensi singkat, untuk mencapai
efek real-time seperti efek suara atau komunikasi VOIP. Implementasi perangkat
yang menyertakan hardware mikrofon dan mendeklarasikan android.hardware.microphone
HARUS memenuhi semua persyaratan latensi audio yang diuraikan di bagian ini. Lihat Bagian 7
untuk mengetahui detail kondisi yang memungkinkan hardware mikrofon dihilangkan oleh
implementasi perangkat.
Untuk tujuan bagian ini:
"latensi output dingin" didefinisikan sebagai interval antara saat aplikasi
meminta pemutaran audio dan saat suara mulai diputar, saat sistem audio
baru-baru ini digunakan tetapi saat ini tidak ada aktivitas (yaitu, diam)
"latensi output hangat" didefinisikan sebagai interval antara saat aplikasi
meminta pemutaran audio dan saat suara mulai diputar, saat sistem audio
baru-baru ini digunakan tetapi saat ini tidak ada aktivitas (yaitu, diam)
"latensi output kontinu" didefinisikan sebagai interval antara saat
aplikasi mengeluarkan sampel untuk diputar dan saat speaker secara fisik memutar
suara yang sesuai, saat perangkat saat ini memutar audio
"latensi input dingin" didefinisikan sebagai interval antara saat aplikasi
meminta perekaman audio dan saat sampel pertama dikirim ke
aplikasi melalui cal back-nya, saat sistem audio dan mikrofon telah
tidak ada aktivitas dan dimatikan sebelum permintaan
"latensi input kontinu" didefinisikan sebagai saat suara ambient terjadi dan
saat sampel yang sesuai dengan suara tersebut dikirim ke aplikasi
perekaman melalui cal back-nya, saat perangkat berada dalam mode perekaman
Dengan menggunakan definisi di atas, implementasi perangkat HARUS menunjukkan setiap properti
ini:
latensi output dingin 100 milidetik atau kurang
latensi output hangat 10 milidetik atau kurang
latensi output kontinu 45 milidetik atau kurang
latensi input dingin 100 milidetik atau kurang
latensi input kontinu 50 milidetik atau kurang
Catatan: meskipun persyaratan yang diuraikan di atas dinyatakan sebagai "HARUS" untuk Android 4.1,

Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi "HARUS".
Artinya, persyaratan ini opsional di Android 4.1 tetapi akan diperlukan oleh versi
mendatang. Perangkat yang sudah ada dan baru yang menjalankan Android 4.1 sangat
dianjurkan untuk memenuhi persyaratan ini di Android 4.1, atau perangkat tersebut tidak akan dapat
mencapai kompatibilitas Android saat diupgrade ke versi mendatang.
Jika implementasi perangkat memenuhi persyaratan bagian ini, perangkat DAPAT melaporkan
dukungan untuk audio latensi rendah, dengan melaporkan fitur "android.hardware.audio.low-
latency" melalui class android.content.pm.PackageManager. [Resources, 37]
Sebaliknya, jika implementasi perangkat tidak memenuhi persyaratan ini, perangkat HARUS
TIDAK melaporkan dukungan untuk audio latensi rendah.
5.5. 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 Live Streaming HTTP(S), Versi 3 [Referensi, 59]
6. Kompatibilitas 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 di
Android SDK. Daemon adb sisi perangkat HARUS tidak aktif secara default, dan
HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Android Debug
Bridge.
Dalvik Debug Monitor Service (dikenal sebagai ddms) [Referensi, 33]
Implementasi perangkat HARUS mendukung semua fitur ddms seperti yang didokumentasikan di
Android SDK. Karena ddms menggunakan adb, dukungan untuk ddms HARUS tidak aktif secara
default, tetapi HARUS didukung setiap kali pengguna telah mengaktifkan Android
Debug Bridge, seperti di atas.
Monkey [Referensi, 36]
Implementasi perangkat HARUS menyertakan framework Monkey, dan membuatnya
tersedia untuk aplikasi digunakan.
Sebagian besar sistem berbasis Linux dan sistem Apple Macintosh mengenali perangkat Android
menggunakan alat Android SDK standar, tanpa dukungan tambahan; tetapi sistem Windows
Microsoft 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 Android SDK standar, penerapkan perangkat HARUS menyediakan driver
Windows yang memungkinkan developer terhubung ke perangkat menggunakan protokol adb.
Driver ini HARUS disediakan untuk Windows XP, Windows Vista, dan Windows 7, dalam
versi 32-bit dan 64-bit.
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-op dengan cara yang wajar

metode API HARUS menampilkan nilai nol jika diizinkan oleh dokumentasi SDK
metode API HARUS menampilkan implementasi no-op class jika nilai nol
tidak diizinkan oleh dokumentasi SDK
metode API HARUS TIDAK menampilkan pengecualian yang tidak didokumentasikan oleh dokumentasi
SDK
Contoh tipikal sebuah skenario yang menerapkan persyaratan ini adalah API telepon:
bahkan di perangkat non-ponsel, API ini harus diimplementasikan sebagai no-op 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. [Resources, 37]
7.1. Layar dan Grafis
Android 4.1 menyertakan fasilitas yang otomatis menyesuaikan aset aplikasi dan tata letak
UI secara tepat untuk perangkat, untuk memastikan bahwa 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 yang dinyalakan dari layar.
"dpi" (yang berarti "titik per inci") adalah jumlah piksel yang tercakup oleh rentang linear
horizontal atau vertikal 1". Jika nilai dpi tercantum, dpi horizontal dan
vertikal harus tercakup dalam rentang.
"Rasio aspek" adalah rasio dimensi layar yang lebih panjang dengan dimensi
yang lebih pendek. Misalnya, layar 480x854 piksel adalah 854 / 480 =
1,779, atau kira-kira "16:9".
"Piksel kepadatan mandiri" atau ("dp") adalah satuan piksel virtual yang diseragamkan ke layar 160
dpi, dihitung sebagai: piksel = dp * (kepadatan / 160).
7.1.1. Konfigurasi Layar
Ukuran Layar
Framework UI Android mendukung berbagai ukuran layar yang berbeda, dan memungkinkan
aplikasi untuk 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 (dp) kepadatan-mandiri logika 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 dalam ukuran diagonal
fisik.
Perangkat TIDAK BOLEH mengubah ukuran layar yang dilaporkan kapan saja.
Aplikasi opsional y menunjukkan ukuran layar yang didukung melalui atribut <supports-
screens> dalam file AndroidManifest.xml. Implementasi perangkat HARUS
menghormati dukungan yang dinyatakan aplikasi untuk layar kecil , normal, besar, dan xlarge
dengan benar, seperti yang dijelaskan dalam dokumentasi Android SDK.
Rasio Lebar Tinggi Layar
Rasio lebar tinggi HARUS antara 1,3333 (4:3) dan 1,85 (16:9).
Kepadatan Layar
Framework UI Android menentukan serangkaian kepadatan logika standar untuk membantu
developer aplikasi menargetkan resource aplikasi. Implementasi perangkat HARUS
melaporkan salah satu densitas framework Android logis berikut melalui
API android.util.DisplayMetrics, dan HARUS menjalankan aplikasi pada densitas
standar ini.
120 dpi, dikenal sebagai 'ldpi'
160 dpi, dikenal sebagai 'mdpi'
213 dpi, dikenal sebagai 'tvdpi'
240 dpi, dikenal sebagai 'hdpi'
320 dpi, dikenal sebagai 'xhdpi'
480 dpi, dikenal sebagai 'xxhdpi'
Implementasi perangkat HARUS menentukan kepadatan framework Android standar yang
adalah angka y yang paling dekat dengan kepadatan fisik layar, kecuali jika kepadatan logika tersebut

adalah angka y yang paling dekat dengan kepadatan fisik layar, kecuali jika kepadatan logika tersebut
mendorong ukuran layar yang dilaporkan di bawah minimum yang didukung. Jika kerapatan framework
Android standar yang numerik paling dekat dengan kerapatan fisik menghasilkan ukuran
layar yang lebih kecil dari ukuran layar kompatibel terkecil yang didukung (lebar 320 dp),
implementasi perangkat HARUS melaporkan kerapatan framework
Android standar terendah berikutnya.
7.1.2. Metrik Layar
Implementasi perangkat HARUS melaporkan nilai yang benar untuk semua metrik layar yang ditentukan di
android.util.DisplayMetrics [Resources, 39].
7.1.3. Orientasi Layar
Perangkat HARUS mendukung orientasi dinamis oleh aplikasi ke 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
di-kueri melalui android.content.res.Configuration.orientation,
android.view.Display.getOrientation(), atau API lainnya.
Perangkat TIDAK BOLEH mengubah ukuran layar atau kepadatan yang dilaporkan saat mengubahorientasi
.
Perangkat HARUS melaporkan orientasi layar yang didukung (
android.hardware.screen.portrait dan/atau android.hardware.screen.landscape)
dan HARUS melaporkan setidaknya satu orientasi yang didukung. Misalnya, perangkat dengan
layar lanskap orientasi tetap, seperti televisi atau laptop, HARUS hanya 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 diterapkan
dan dijelaskan dalam dokumentasi Android SDK. Implementasi perangkat JUGA HARUS
mendukung Renderscript Android, seperti yang dijelaskan dalam dokumentasi Android SDK
[Referensi, 8].
Implementasi perangkat JUGA HARUS mengidentifikasi dirinya secara benar sebagai mendukung
OpenGL ES 1.0 dan 2.0. Yaitu:
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 OpenGL ES yang dikelola semua string ekstensi yang didukung, dan sebaliknya HARUS TIDAK melaporkan
string ekstensi yang tidak didukung.

Perhatikan bahwa Android 4.1 menyertakan dukungan untuk aplikasi agar dapat menentukan bahwa aplikasi
memerlukan format kompresi tekstur OpenGL tertentu. Format ini biasanya khusus
vendor. Implementasi perangkat tidak diperlukan oleh Android 4.1 untuk menerapkan
format kompresi tekstur tertentu. Namun, format tersebut HARUS melaporkan
format kompresi tekstur apa pun yang didukung, melalui metode getString() di
OpenGL API.
Android 4.1 menyertakan mekanisme untuk aplikasi mendeklarasikan bahwa aplikasi ingin
mengaktifkan akselerasi hardware untuk grafik 2D di tingkat Aplikasi, Aktivitas, Jendela, atau
Tampilan melalui penggunaan tag manifes android:hardwareAccelerated atau panggilan
API langsung [Referensi, 9].
Di Android 4.1, implementasi perangkat HARUS mengaktifkan akselerasi hardware secara
default, dan HARUS menonaktifkan akselerasi hardware jika developer meminta 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.1 menyertakan objek TextureView yang memungkinkan developer secara langsung mengintegrasikan
tekstur OpenGL ES yang diakselerasi hardware 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.1 menentukan "mode kompatibilitas" tempat framework beroperasi dalam mode
ukuran layar'normal' yang setara (lebar 320dp) untuk manfaat aplikasi
lama yang tidak dikembangkan untuk versi lama Android yang sebelum 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:
Penerapan 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 seluler, 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 termasuk televisi, dekoder TV, dan sebagainya.
Implementasi Perangkat Piksel Tetap
Implementasi perangkat piksel tetap DAPAT menggunakan layar dari dimensi piksel mana pun,
asalkan memenuhi persyaratan yang ditentukan oleh 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 metrik layar dan konfigurasi layar yang sama, seperti
yang dijelaskan di Bagian 7.1.1 dan 7.1.2, seperti layar piksel tetap.
Perangkat HARUS melaporkan kepadatan logika yang sama dengan layar piksel tetap.
Perangkat HARUS melaporkan dimensi layar yang sama dengan, atau sangat dekat
dengan, layar piksel tetap.
Misalnya, tablet berukuran diagonal 7" dengan resolusi piksel 1024x600
dianggap sebagai implementasi tampilan mdpi besar 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 layar atau
mode saat runtime atau waktu booting. Misalnya, pengguna set-top box dapat mengganti tampilan
720p dengan tampilan 1080p, dan implementasi perangkat dapat menyesuaikan
.
Selain itu, implementasi perangkat dengan dimensi piksel variabel dibatasi ke
720p atau 1080p di Android 4.1, dan HARUS dikonfigurasi untuk melaporkan ukuran layar dan
bucket kepadatan seperti yang dinyatakan di atas.

7.1.7. Teknologi Layar
Platform Android menyertakan API yang memungkinkan aplikasi merender grafik yang kaya ke
layar. Perangkat HARUS mendukung semua API ini seperti yang ditentukan oleh Android SDK
kecuali jika dijelaskan secara khusus dalam dokumen ini. Secara khusus:
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 hampir persegi (1,0) dengan toleransi
10%.
7.2. Perangkat Input
7.2.1. Keyboard
Implementasi perangkat:
HARUS menyertakan dukungan untuk Input Management Framework (yang memungkinkan developer pihak ketiga membuat Input Management Engine - yaitu keyboard virtual) seperti
yang dijelaskan di http://developer.android.com
HARUS menyediakan setidaknya satu implementasi keyboard virtual (terlepas dari apakah
keyboard fisik ada)
DAPAT menyertakan implementasi keyboard virtual tambahan
DAPAT menyertakan keyboard hardware
HARUS TIDAK menyertakan keyboard hardware yang tidak cocok dengan salah satu format
yang ditentukan di android.content.res.Configuration.keyboard [Resources, 40]
(yaitu, QWERTY, atau 12-key)
7.2.2.
Navigasi tanpa sentuh
Implementasi perangkat:
DAPAT menghapus opsi navigasi tanpa sentuh (yaitu, dapat menghapus trackbal , 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, kompatibel dengan Mesin Pengelolaan Input.
Software open source upstream Android menyertakan mekanisme pemilihan
yang cocok 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 diimplementasikan melalui
tombol fisik khusus (seperti tombol sentuh mekanis atau kapasitif), atau DAPAT
diimplementasikan menggunakan tombol software khusus, gestur, panel sentuh, dll. Android
4.1 mendukung kedua implementasi.
Android 4.1 memperkenalkan dukungan untuk tindakan bantuan [Referensi, 63]. Implementasi
perangkat HARUS menyediakan tindakan bantuan kepada pengguna setiap saat saat
menjalankan aplikasi. Fungsi ini DAPAT diimplementasikan melalui kunci hardware atau software
.
Penerapan perangkat DAPAT menggunakan bagian layar yang berbeda untuk menampilkan
tombol navigasi, tetapi jika ya, HARUS memenuhi persyaratan ini:
Tombol navigasi penerapan perangkat HARUS menggunakan bagian layar yang berbeda dari
layar, tidak tersedia untuk aplikasi, dan HARUS TIDAK menyembunyikan atau secara lain
mengganggu bagian layar yang tersedia untuk aplikasi.
Penerapan perangkat HARUS menyediakan bagian layar untuk
aplikasi yang memenuhi persyaratan yang ditentukan di Bagian 7.1.1.
Penerapan perangkat HARUS menampilkan tombol navigasi saat aplikasi tidak
menentukan mode UI sistem, atau menentukan SYSTEM_UI_FLAG_VISIBLE.
Penerapan perangkat HARUS menampilkan tombol navigasi dalam modetidak mencolok
"profil rendah" (misalnya, redup) 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.
Implementasi perangkat HARUS menyediakan sebagian layar ke
aplikasi yang memenuhi persyaratan yang ditentukan di Bagian 7.1.1.
7.2.4. Input layar sentuh
Implementasi perangkat HARUS memiliki sistem input pointerdari jenis tertentu (
seperti mouse, atau sentuh). Namun, jika penerapan perangkat tidak mendukung sistem input
pointer, perangkat TIDAK BOLEH melaporkan konstanta fitur android.hardware.touchscreen atau
android.hardware.faketouch. Implementasi perangkat yang

menyertakan sistem input pointer:
HARUS mendukung pointer yang dilacak secara mandiri, jika sistem input perangkat
mendukung beberapa pointer
HARUS melaporkan nilai android.content.res.Configuration.touchscreen
[Resources, 40] cyang sesuai dengan jenis layar sentuh tertentu di
perangkat
Android 4.0 menyertakan dukungan untuk berbagai layar sentuh, touchpad, dan perangkat input sentuh
palsu. Implementasi perangkat berbasis layar sentuh dikaitkan dengan
layar [Referensi, 71] sehingga pengguna memiliki kesan seolah-olah secara langsung memanipulasi item
di layar. Karena pengguna langsung menyentuh layar, sistem tidak
memerlukan affordance tambahan apa pun untuk menunjukkan objek yang dimanipulasi. Sebaliknya, antarmuka sentuh palsu menyediakan sistem input pengguna yang memperkirakan
subkumpulan kemampuan layar sentuh.
Misalnya, mouse atau remote control yang mendorong
kursor di layar mendekatan sentuhan, tetapi memerlukan pengguna untuk menunjuk atau memfokuskan terlebih dahulu
lalu mengklik. Banyak perangkat input seperti mouse, trackpad, mouse udara berbasis giroskop,
pointer giroskop, joystick, dan trackpad multi-sentuh yang dapat mendukung interaksi sentuh palsu.
Android 4.0 menyertakan konstanta fitur android.hardware.faketouch, yang
sesuai dengan perangkat input non-sentuh fidelitas tinggi (yaitu, berbasis pointer) seperti
mouse atau trackpad yang dapat mengemulasikan input berbasis sentuh secara memadai (termasuk dukungan gestur
dasar), dan menunjukkan bahwa perangkat mendukung subkumpulan yang diemulasikan dari
fungsi layar sentuh. Implementasi perangkat yang mendeklarasikan fitur sentuhan palsu
HARUS memenuhi persyaratan sentuhan palsu di Bagian 7.2.5.
Implementasi perangkat HARUS melaporkan fitur yang benar yang sesuai dengan jenis
input yang digunakan. Implementasi perangkat yang menyertakan layar sentuh (sentuhan tunggal atau lebih baik)
HARUS melaporkan konstanta fitur platform android.hardware.touchscreen. Implementasi
perangkat yang melaporkan konstanta fitur platform
android.hardware.touchscreen JUGA HARUS melaporkan konstanta fitur platform
android.hardware.faketouch. Implementasi perangkat yang tidak menyertakan layar sentuh
(dan hanya mengandalkan perangkat pointer) TIDAK BOLEH melaporkan fitur
layar sentuh, dan HARUS melaporkan hanya android.hardware.faketouch jika memenuhi persyaratan sentuh
palsu di Bagian 7.2.5.
7.2.5. Input sentuh palsu
Implementasi perangkat yang mendeklarasikan dukungan untuk android.hardware.faketouch
HARUS melaporkan posisi layar X dan Y absolut dari lokasi kursor dan
menampilkan kursor visual di layar[Resources, 70]
HARUS melaporkan peristiwa sentuh dengan kode tindakan [Resources, 70] yang menentukan
perubahan status yang terjadi pada kursor yang turun atau naik di layar
[Resources, 70]
HARUS mendukung kursor turun dan naik pada objek di layar, yang memungkinkan
upengguna mengemulasikan ketukan pada objek di layar
HARUS mendukung kursor turun, kursor naik, kursor turun, lalu kursor naik di tempat
yang sama pada objek di layar dalam batas waktu, yang memungkinkan pengguna untuk
mengemulasikan ketukan ganda pada objek di layar [Resources, 70]
HARUS mendukung kursor turun pada titik arbitrer di layar, kursor bergerak ke
titik arbitrer lainnya di layar, diikuti oleh kursor naik, yang memungkinkan
pengguna mengemulasikan tarik sentuh
HARUS mendukung kursor turun lalu memungkinkan pengguna untuk segera memindahkan objek ke
posisi yang berbeda di layar, lalu kursor naik di layar, yang memungkinkan
pengguna untuk menggeser objek di layar
Perangkat yang mendeklarasikan dukungan untuk android.hardware.faketouch.multitouch.distinct
HARUS memenuhi persyaratan untuk faketouch di atas, dan HARUS juga mendukung pelacakan
yang berbeda dari dua atau beberapa input kursor independen.
7.2.6. Mikrofon
Implementasi perangkat DAPAT melewatkan mikrofon. Namun, jika implementasi perangkat
menghilangkan mikrofon, implementasi tersebut TIDAK BOLEH melaporkan konstanta fitur android.hardware.microphone
, dan harus menerapkan 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.1 menyertakan API untuk mengakses berbagai jenis sensor. Penerapan
perangkat umumnya DAPAT menghapus sensor ini, seperti yang disediakan di 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, implementasi perangkat:
HARUS melaporkan kehadiran atau ketiadaan sensor secara akurat sesuai dengan
class android.content.pm.PackageManager. [Resources, 37]
HARUS menampilkan daftar sensor yang didukung secara akurat melalui
SensorManager.getSensorList() dan metode yang serupa
HARUS berperilaku secara 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
yang relevan (yaitu metrik) untuk setiap jenis sensor seperti yang ditentukan dalam dokumentasi Android SDK
[Referensi, 41]
Daftar di atas tidak komprehensif; perilaku yang didokumentasikan dari Android SDK
harus dianggap otoritatif.
Beberapa jenis sensor adalah sintetis, yang berarti sensor tersebut dapat berasal dari data yang disediakan oleh
satu atau beberapa sensor lain. (Contoh mencakup sensor orientasi, dan sensor akselerasi
linear.) Implementasi perangkat HARUS menerapkan jenis
sensor ini, jika menyertakan sensor fisik prasyarat.
API Android 4.1 memperkenalkan konsep sensor "streaming", yang merupakan sensor yang
menampilkan data secara terus-menerus, bukan hanya saat data berubah. Implementasi
perangkat HARUS terus-menerus memberikan sampel data berkala untuk API apa pun
yang ditunjukkan oleh dokumentasi Android 4.1 SDK sebagai sensor streaming.
7.3.1. Akselerometer
Implementasi perangkat HARUS menyertakan akselerometer 3 sumbu. Jika penerapan
perangkat menyertakan akselerometer 3 sumbu, perangkat:
HARUS dapat mengirimkan peristiwa pada 120 Hz atau lebih. Perhatikan bahwa meskipun frekuensi akselerometer
di atas dinyatakan sebagai "HARUS" untuk Android 4.1,
Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi
"HARUS". Artinya, standar ini opsional di Android 4.1 tetapi akan
diperlukan di versi mendatang. Perangkat yang sudah ada dan baru yang menjalankan Android 4.1
sangat dianjurkan untuk memenuhi persyaratan ini di Android 4.1 sehingga
perangkat tersebut akan dapat diupgrade ke rilis platform mendatang
HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam
API Android (lihat [Referensi, 41])
HARUS mampu mengukur dari freefall hingga dua kali gravitasi (2g) atau lebih di
vektor tiga dimensial
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 10 Hz atau lebih
HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan dalam
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 penerapan perangkat
menyertakan penerima GPS, penerapan 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 akselerometer 3 sumbu
juga disertakan. Jika implementasi perangkat menyertakan giroskop, perangkat tersebut:

HARUS dikompensasi suhu
HARUS mampu mengukur perubahan orientasi hingga 5, 5*Pi
radian/detik (yaitu,sekitar 1.000 derajat per detik)
HARUS mampu mengirimkan peristiwa pada 200 Hz atau lebih. Perhatikan bahwa meskipun frekuensi giroskopi
di atas dinyatakan sebagai "HARUS" untuk Android 4.1,
Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubahnya menjadi
"HARUS". Artinya, standar ini opsional di Android 4.1 tetapi akan
diperlukan di versi mendatang. Perangkat lama dan baru yang menjalankan Android 4.1
sangat dianjurkan untuk memenuhi persyaratan ini di Android 4.1 sehingga
perangkat ini akan dapat diupgrade ke rilis platform mendatang
HARUS memiliki akurasi 12 bit atau lebih
HARUS memiliki varian tidak lebih dari 1e-7 rad^2 / s^2 per Hz (varian per Hz,
atau rad^2 / s). Varians diizinkan untuk berubah sesuai dengan frekuensi sampling, tetapi harus
dibatasi oleh nilai ini. Dengan kata lain, jika Anda mengukur varian giroskopi
pada frekuensi sampling 1 Hz, nilainya tidak boleh lebih dari 1e-7 rad^2/s^2.
HARUS memiliki stempel waktu yang sesegera mungkin setelah peristiwa hardware terjadi
. Latensi konstanta harus dihapus.
7.3.5. Barometer
Implementasi perangkat DAPAT menyertakan barometer (yaitu sensor tekanan udara sekitar.) Jika
penerapan perangkat menyertakan barometer, perangkat tersebut:
HARUS dapat mengirimkan peristiwa pada 5 Hz atau lebih
HARUS memiliki presisi yang memadai untuk memungkinkan estimasi ketinggian
HARUS dikompensasi suhu
7.3.7. Termometer
Implementasi perangkat DAPAT tetapi TIDAK BOLEH menyertakan termometer (yaitu
sensor suhu.) Jika penerapan perangkat menyertakan termometer, perangkat HARUS
mengukur suhu CPU perangkat. Perangkat TIDAK BOLEH mengukur suhu
lainnya. (Perhatikan bahwa jenis sensor ini tidak lagi digunakan di API Android 4.1.)
7.3.7. Photometer
Implementasi perangkat DAPAT menyertakan photometer (yaitu sensor cahaya sekitar.)
7.3.8. Sensor Kedekatan
Implementasi perangkat DAPAT menyertakan sensor kedekatan. Jika implementasi perangkat
memang menyertakan sensor kedekatan, perangkat 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 dari jenis sensor ini adalah untuk mendeteksi
ponsel yang digunakan oleh pengguna. Jika penerapan perangkat menyertakan sensor kedekatan dengan
orientasi lainnya, sensor 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.1 dan dokumen ini mengacu khusus ke
hardware yang terkait dengan melakukan panggilan suara dan mengirim pesan SMS melalui jaringan GSM atau
CDMA. Meskipun panggilan suara ini mungkin atau mungkin tidak dilakukan dengan packet-switched, panggilan ini
untuk tujuan Android 4.1 dianggap terlepas dari konektivitas data apa pun yang
dapat diterapkan menggunakan jaringan yang sama. Dengan kata lain, fungsi dan API
"telephony" Android mengacu khusus ke 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.1 DAPAT digunakan di perangkat yang tidak menyertakan hardware telepon. Artinya,
Android 4.1 kompatibel dengan perangkat yang bukan ponsel. Namun, jika penerapan
perangkat menyertakan telepon GSM atau CDMA, perangkat HARUS menerapkan dukungan lengkap
untuk API untuk teknologi tersebut. Implementasi perangkat yang tidak menyertakan hardware
telepon HARUS menerapkan API lengkap sebagai no-ops.
7.4.2. IEEE 802.11 (WiFi)
Implementasi perangkat Android 4.1 HARUS menyertakan dukungan untuk satu atau beberapa bentuk
802.11 (b/g/a/n, dll.) Jika penerapan perangkat menyertakan dukungan untuk 802.11, perangkat
HARUS menerapkan API Android yang sesuai.

Implementasi perangkat HARUS menerapkan multicast API seperti yang dijelaskan dalam dokumentasi SDK
[Referensi, 62]. Deplementasi perangkat yang menyertakan dukungan Wi-Fi
HARUS mendukung DNS multicast (mDNS). Implementasi perangkat HARUS tidak 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 langsung, implementasi tersebut HARUS menerapkan
Android API yang sesuai seperti yang dijelaskan dalam dokumentasi SDK [Referensi, 68]. Jika
implementasi perangkat menyertakan dukungan untuk Wi-Fi langsung, maka perangkat tersebut:
HARUS mendukung operasi Wi-Fi reguler
HARUS mendukung operasi Wi-Fi dan Wi-Fi langsung serentak
7.4.3. Bluetooth
Implementasi perangkat HARUS menyertakan transceiver Bluetooth. Implementasi
perangkat yang menyertakan transceiver Bluetooth HARUS mengaktifkan API Bluetooth berbasis RFCOMM-
seperti yang dijelaskan dalam dokumentasi SDK [Referensi, 42]. Implementasi
perangkat HARUS menerapkan profil Bluetooth yang relevan, seperti A2DP,
AVRCP, OBEX, dll. sebagaimana sesuai untuk perangkat.
Compatibility Test Suite menyertakan kasus yang mencakup operasi dasar Android
RFCOMM Bluetooth API. Namun, karena Bluetooth adalah protokol komunikasi
antar-perangkat, Bluetooth tidak dapat diuji sepenuhnya oleh pengujian unit yang berjalan di satu perangkat.
Akibatnya, implementasi perangkat JUGA HARUS lulus prosedur pengujian Bluetooth
yang dilakukan oleh manusia yang dijelaskan di 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, perangkat tersebut:
HARUS melaporkan fitur android.hardware.nfc dari metode
android.content.pm.PackageManager.hasSystemFeature().
[Resources, 37]
HARUS mampu membaca dan menulis pesan NDEF melalui standar
NFC berikut:
HARUS mampu bertindak sebagai pembaca/penulis NFC Forum (seperti yang ditentukan oleh
spesifikasi teknis NFC Forum 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 mampu membaca dan menulis pesan NDEF melalui standar NFC berikut:
Perhatikan bahwa meskipun standar NFC di bawah dinyatakan sebagai
"HARUS" untuk Android 4.1, Definisi Kompatibilitas untuk versi mendatang
direncanakan untuk mengubahnya menjadi "HARUS". Artinya, standar ini opsional di
Android 4.1 tetapi akan diperlukan di versi mendatang. Perangkat yang ada dan baru
yang menjalankan Android 4.1 sangat dianjurkan untuk memenuhi persyaratan
ini di Android 4.1 sehingga perangkat tersebut akan dapat diupgrade ke rilis platform
mendatang.
NfcV (ISO 15693)
HARUS mampu mentransmisikan dan menerima data melalui protokol dan standar 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 menghormati intent
android.settings.NFCSHARING_SETTINGS untuk menampilkan setelan

berbagi NFC [Resources, 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.setNdefPushMessageCal kembali, dan
android.nfc.NfcAdapter.enableForegroundNdefPush.
HARUS menggunakan gestur atau konfirmasi di layar, seperti 'Sentuh ke
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 SHOULD tersebut menggunakan permintaan SNEP GET
untuk bertukar permintaan handover / memilih data melalui NFC, dan
HARUS menggunakan Profil Push Objek Bluetooth untuk transfer data Bluetooth yang sebenarnya
.
HARUS membuat pol untuk semua teknologi yang didukung saat dalam mode penemuan NFC.
HARUS dalam mode penemuan NFC saat perangkat aktif dengan layar
aktif dan layar kunci terbuka.
(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 [Resources, 44], MF1S703x [Resources, 44])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 46])
NDEF di MIFARE Classic (NXP AN130511 [Resources, 48], AN130411
[Resources, 49])
Perhatikan bahwaAndroid 4.1 mencakup API untuk jenis MIFARE ini. Jika penerapan
perangkat mendukung MIFARE dalam peran pembaca/penulis, perangkat:
HARUS menerapkan 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, dan karenanya
tidak muncul sebagai konstanta di class PackageManager.
HARUS TIDAK menerapkan API Android yang sesuai atau melaporkan fitur
com.nxp.mifare kecuali jika juga menerapkan dukungan NFC umum seperti
dijelaskan di bagian ini
Jika penerapan perangkat tidak menyertakan hardware NFC, penerapan tersebut HARUS TIDAK mendeklarasikan fitur
android.hardware.nfc dari
metode android.content.pm.PackageManager.hasSystemFeature() [Resources, 37],
dan HARUS menerapkan Android 4.1 NFC API sebagai tidak beroperasi.
Karena class android.nfc.NdefMessage dan android.nfc.NdefRecord mewakili format representasi data yang tidak tergantung protokol, penerapan 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. Contoh teknologi yang
memenuhi persyaratan ini mencakup EDGE, HSPA, EV-DO, 802.11g, Ethernet, dll.
Implementasi perangkat dengan standar jaringan fisik (seperti Ethernet) adalah
koneksi data utama HARUS juga menyertakan dukungan untuk setidaknya satu standar data nirkabel
umum, seperti 802.11 (WiFi).
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 berada di sisi
perangkat yang berlawanan dengan layar; yaitu, kamera mengambil gambar adegan di sisi jauh perangkat, seperti
kamera tradisional. Kamera depan adalah kamera yang berada di sisi yang sama dengan
perangkat seperti layar; yaitu, kamera yang biasanya digunakan untuk mengambil gambar pengguna, seperti untuk
konferensi video dan aplikasi serupa.
7.5.1. Kamera Belakang
Implementasi perangkat HARUS menyertakan kamera belakang. Jika implementasi
perangkat menyertakan kamera depan, perangkat tersebut:
HARUS memiliki resolusi setidaknya 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 BOLEH
menyala saat instance back android.hardware.Camera.PreviewCal telah
terdaftar di platform pratinjau Kamera, kecuali jika aplikasi telah
mengaktifkan flash secara eksplisit dengan mengaktifkan atribut FLASH_MODE_AUTO atau FLASH_MODE_ON
dari objek Camera.Parameters. Perhatikan bahwa batasan ini tidak berlaku untuk
aplikasi kamera sistem bawaan perangkat, tetapi hanya untuk aplikasi pihak ketiga
yang menggunakan Camera.PreviewCallback.
7.5.2. Kamera Depan
Implementasi perangkat DAPAT menyertakan kamera depan. Jika implementasi perangkat
menyertakan kamera depan, perangkat:
HARUS memiliki resolusi minimal VGA (yaitu, 640x480 piksel)
HARUS TIDAK menggunakan kamera depan sebagai default untuk Camera API. Artinya,
API kamera di Android 4.1 memiliki dukungan khusus untuk kamera depan, dan
implementasi perangkat HARUS TIDAK mengonfigurasi API untuk memperlakukan kamera
depan sebagai kamera belakang default, meskipun kamera tersebut adalah satu-satunya kamera di
perangkat.
DAPAT menyertakan fitur (seperti fokus otomatis, flash, dll.) yang tersedia untuk kamera
belakang seperti yang dijelaskan di Bagian 7.5.1.
HARUS mencerminkan (yaitu mencerminkan) streaming yang ditampilkan oleh aplikasi di
CameraPreview secara horizontal, seperti berikut:
Jika implementasi perangkat dapat diputar oleh pengguna (seperti
otomatis melalui akselerometer atau manual melalui input pengguna), pratinjau
kamera HARUS dicerminkan secara horizontal secara relatif terhadap orientasi
perangkat saat ini.
Jika aplikasi saat ini telah secara eksplisit meminta agar layar Kamera
diputar melalui cal  ke metode
android.hardware.Camera.setDisplayOrientation() [Resources, 50]
, pratinjau kamera HARUS dicerminkan secara horizontal secara relatif terhadap orientasi
yang ditentukan oleh aplikasi.
Jika tidak, pratinjau HARUS dicerminkan di sepanjang sumbu horizontal
default perangkat.
HARUS mencerminkan gambar yang ditampilkan oleh tampilan postingan dengan cara yang sama seperti streaming gambar pratinjau kamera
. (Jika implementasi perangkat tidak mendukung
postview, persyaratan ini jelas tidak berlaku.)
TIDAK BOLEH mencerminkan gambar atau streaming video yang diambil akhir yang ditampilkan ke
panggilan balik aplikasi atau di-commit ke penyimpanan media
7.5.3. Perilaku API Kamera
Implementasi perangkat HARUS menerapkan perilaku berikut untuk API terkait
kamera, baik kamera depan maupun belakang:
1.  Jika aplikasi belum pernah memanggil
android.hardware.Camera.Parameters.setPreviewFormat(int), maka perangkat
HARUS menggunakan android.hardware.PixelFormat.YCbCr_420_SP untuk data
pratinjau yang disediakan ke panggilan 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 berada 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. (Decoder video hardware dan kamera dapat
menggunakan format piksel native apa pun, tetapi implementasi perangkat HARUS mendukung
konversi ke YV12.)
Implementasi perangkat HARUS menerapkan Camera API lengkap yang disertakan dalam dokumentasi Android
4.1 SDK [Resources, 51]), rapa pun 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, API cal back masih harus "dipalsukan" seperti
dijelaskan.
Implementasi perangkat HARUS mengenali dan menghormati setiap nama parameter yang ditentukan sebagai
konstanta di class android.hardware.Camera.Parameters, jika
hardware dasar mendukung fitur. Jika hardware perangkat tidak mendukung fitur,
API harus berperilaku seperti yang didokumentasikan. Sebaliknya, Implementasi perangkat TIDAK BOLEH
menghormati atau mengenali konstanta string yang diteruskan ke metode
android.hardware.Camera.setParameters() selain yang didokumentasikan sebagai
konstanta di android.hardware.Camera.Parameters. Artinya, implementasi
perangkat HARUS mendukung semua parameter Kamera standar jika hardware
mengizinkan, dan TIDAK BOLEH mendukung jenis parameter Kamera kustom.
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
, hal ini 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 setidaknya 340 MB memori yang tersedia untuk kernel
dan ruang pengguna. 340 MB HARUS ditambahkan ke memori apa pun yang didedikasikan untuk komponen
hardware seperti radio, video, dan seterusnya yang tidak dikontrol
kernel.
Implementasi perangkat HARUS memiliki setidaknya 350 MB penyimpanan non-volatil yang tersedia
untuk data pribadi aplikasi. Artinya, partisi /data HARUS minimal 350 MB.
Android API menyertakan Download Manager yang dapat digunakan aplikasi untuk mendownload
file data [Referensi, 56]. Implementasi perangkat Download Manager
HARUS mampu mendownload setiap file dengan ukuran 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 simbolik Linux dari /sdcard ke titik pemasangan yang sebenarnya.
Implementasi perangkat HARUS menerapkan seperti yang didokumentasikan izin
android.permission.WRITE_EXTERNAL_STORAGE di 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 dapat diakses pengguna,
seperti kartu Secure Digital. Atau, implementasi perangkat DAPAT menempatkan
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 penerapan perangkat mendukung Media Transfer Protocol:
Penerapan perangkat HARUS kompatibel dengan host MTP Android
referensi, Android File Transfer [Resources, 57].
Penerapan perangkat HARUS melaporkan class perangkat USB 0x00.
Penerapan perangkat HARUS melaporkan nama antarmuka USB 'MTP'.
Jika implementasi perangkat tidak memiliki port USB, perangkat HARUS memberikan komputer host
akses ke konten penyimpanan bersama dengan beberapa cara lain, seperti sistem file
jaringan.
Berikut dua contoh umum untuk menjelaskannya. Jika penerapan perangkat menyertakan
slot kartu SD untuk memenuhi persyaratan penyimpanan bersama, kartu SD berformat FAT
berukuran 1 GB atau lebih BISA disertakan dengan perangkat seperti yang dijual kepada pengguna, dan HARUS
dipasang secara default. Atau, jika penerapan 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 merupakan link simbolik 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 secara transparan di kedua lokasi
.
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 terhubung ke host USB dengan port USB-A standar
port HARUS menggunakan faktor bentuk USB mikro di sisi perangkat. Perangkat
dan baru yang menjalankan Android 4.1 sangat dianjurkan untuk memenuhi
persyaratan ini di Android 4.1 sehingga perangkat tersebut akan dapat diupgrade ke rilis platform
mendatang
port HARUS dipusatkan 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
layar), sehingga layar digambar dengan benar saat perangkat diorientasikan dengan
port di bagian bawah. Perangkat yang sudah ada dan baru yang menjalankan Android 4.1 sangat
dianjurkan untuk memenuhi persyaratan ini di Android 4.1 sehingga perangkat ini akan dapat
diupgrade ke rilis platform mendatang.
Jika perangkat memiliki port lain (seperti port pengisian daya non-USB), perangkat HARUS berada
di sisi yang sama dengan port micro-USB
perangkat HARUS mengizinkan host yang terhubung ke perangkat untuk mengakses konten
volume penyimpanan bersama menggunakan penyimpanan massal USB atau Protokol Transfer
Media
perangkat HARUS menerapkan spesifikasi dan API Aksesori Terbuka Android seperti
yang didokumentasikan dalam dokumentasi Android SDK, dan HARUS mendeklarasikan dukungan untuk
fitur hardware android.hardware.usb.accessory [Referensi, 52]
perangkat 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 yang sudah ada dan baru yang menjalankan Android 4.1 sangat
dianjurkan untuk memenuhi persyaratan ini di Android 4.1 sehingga perangkat ini akan dapat
diupgrade ke rilis platform mendatang
Jika penerapan perangkat menyertakan port host USB:
perangkat DAPAT menggunakan faktor bentuk port non-standar, tetapi jika ya, HARUS dikirimkan dengan kabel atau
kabel yang menyesuaikan port ke USB-A standar
perangkat 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 menghapus 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 dari perangkat yang kompatibel dengan Android 4.1
yang ditentukan dalam tabel di bawah:
Metrik
Batas Performa
Komentar
Aplikasi berikut
harus diluncurkan dalam
waktu yang ditentukan.
Waktu peluncuran diukur sebagai
waktu total untuk menyelesaikan pemuatan
Browser: kurang dari
aktivitas default untuk aplikasi,
Aplikasi
1300 md
termasuk waktu yang diperlukan untuk memulai
Waktu Peluncuran
Kontak: kurang dari
proses Linux, muat paket Android
700 md
ke VM Dalvik, dan cal
Setelan: kurang dari
onCreate.
700 md
Jika beberapa aplikasi
telah diluncurkan,
meluncurkan ulang aplikasi yang sudah
berjalan Simultan
setelah

Aplikasi
telah diluncurkan harus
memerlukan waktu yang lebih singkat dari waktu peluncuran
asli.
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.
Khususnya, perangkat yang kompatibel HARUS mendukung mekanisme keamanan yang dijelaskan di
sub-bagian berikut.
9.1. Izin
Implementasi perangkat HARUS mendukung model izin Android seperti yang ditentukan dalam
dokumentasi developer Android [Referensi, 54]. Secara khusus, implementasi
HARUS menerapkan setiap izin yang ditentukan seperti yang dijelaskan dalam dokumentasi SDK; tidak ada izin
yang dapat dihilangkan, diubah, atau diabaikan. Implementasi DAPAT menambahkan izin
tambahan, asalkan string ID izin baru tidak ada di namespace android.*
.
9.2. UID dan Isolasi Proses
Implementasi perangkat HARUS mendukung model sandbox aplikasi Android, di mana
setiap aplikasi berjalan sebagai UID gaya 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 lain daripada 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 sendiri merupakan aplikasi Android, dan mematuhi
model keamanan Android standar, seperti yang dijelaskan di tempat lain di 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. Secara khusus:
Runtime alternatif HARUS menginstal aplikasi melalui PackageManager ke
sandbox Android terpisah (yaitu, ID pengguna Linux, dll.)
Runtime alternatif DAPAT menyediakan satu sandbox Android yang dibagikan oleh semua
aplikasi yang menggunakan runtime alternatif
Runtime alternatif dan aplikasi yang diinstal menggunakan runtime alternatif HARUS
TIDAK menggunakan kembali sandbox aplikasi lain yang diinstal di perangkat, kecuali melalui
mekanisme Android standar dari ID pengguna yang dibagikan dan sertifikat penandatanganan
Runtime alternatif HARUS TIDAK diluncurkan dengan, memberikan, atau diberikan akses ke
sandbox yang sesuai dengan aplikasi Android lainnya
Runtime alternatif HARUS TIDAK diluncurkan dengan, diberikan, atau memberikan kepada aplikasi
lain setiap hak istimewa superuser (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
lainnya 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 yang menggunakan runtime tersebut.
10. Pengujian Kompatibilitas Software
Implementasi perangkat HARUS lulus semua pengujian yang dijelaskan di bagian ini.
Namun, perhatikan bahwa tidak ada paket pengujian software yang sepenuhnya komprehensif. Oleh karena itu,
penerapkan perangkat sangat sangat dianjurkan untuk melakukan jumlah minimum
perubahan sebanyak mungkin pada referensi dan penerapan pilihan Android 4.1
yang tersedia dari Project Open Source Android. Tindakan ini akan meminimalkan risiko
memunculkan bug yang menyebabkan inkompatibel yang memerlukan pembuatan ulang dan potensi update
perangkat.
10.1. Compatibility Test Suite
Implementasi perangkat HARUS lulus Compatibility Test Suite (CTS) Android
[Referensi, 2] yang tersedia dari Android Open Source Project, menggunakan software pengiriman
final di perangkat. Selain itu, penerapkan perangkat HARUS menggunakan
implementasireferensi di hierarki Open Source Android sebanyak mungkin, dan
HARUS memastikan kompatibilitas dalam kasus ambiguitas di CTS dan untuk
implementasi ulang bagian kode sumber referensi.
CTS dirancang untuk berjalan di perangkat yang sebenarnya. Seperti software apa pun, CTS
sendiri mungkin berisi bug. CTS akan diberi versi secara mandiri dari Definisi
Kompatibilitas ini, dan beberapa revisi CTS dapat dirilis untuk Android 4.1. Implementasi
perangkat HARUS lulus versi CTS terbaru yang tersedia pada saat software
perangkat selesai.
10.2. CTS Verifier
Penerapan perangkat HARUS menjalankan semua kasus yang berlaku dengan benar di CTS
Verifier. 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 banyak jenis hardware, termasuk beberapa hardware yang
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 dilewatkan atau dihilangkan.
Setiap perangkat dan setiap build HARUS menjalankan Pemverifikasi CTS dengan benar, seperti yang dinyatakan di atas.
Namun, karena banyak build yang sangat mirip, penerapkan perangkat tidak diharapkan untuk
secara eksplisit menjalankan Pemverifikasi CTS pada build yang hanya berbeda dengan cara yang sepele. Khususnya,
implementasi perangkat yang berbeda dari implementasi yang telah lulus Verifikator
CTS hanya oleh kumpulan lokalitas, branding, dll. yang disertakan DAPAT menghapus pengujian Verifikator CTS

.
10.3. Aplikasi Referensi
Penerapan perangkat HARUS menguji kompatibilitas penerapan menggunakan aplikasi open
source berikut:
Aplikasi "Aplikasi untuk Android" [Resources, 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 Diperbarui
Penerapan perangkat HARUS menyertakan mekanisme untuk mengganti seluruh
software sistem. Mekanisme tidak perlu melakukan upgrade "live" - yaitu, perangkat
MUNGKIN diperlukan untuk dimulai ulang.
Metode apa pun dapat digunakan, asalkan dapat mengganti seluruh software
yang diinstal di perangkat. Misalnya, salah satu pendekatan berikut akan memenuhi
persyaratan ini:
Download over-the-air (OTA) dengan update offline melalui reboot
Update"Tethered" melalui USB dari PC host
Update"Offline" melalui reboot dan update dari file di penyimpanan yang dapat dipindah-pindah
Mekanisme update yang digunakan HARUS mendukung update tanpa menghapus data pengguna. Artinya,
mekanisme update HARUS mempertahankan data pribadi aplikasi dan data
yang dibagikan aplikasi. Perhatikan bahwa software Android upstream menyertakan mekanisme update
yang memenuhi persyaratan ini.
Jika error ditemukan dalam implementasi perangkat setelah dirilis tetapi dalam
masa aktif produk yang wajar yang ditentukan dalam konsultasi dengan Tim Kompatibilitas
Android untuk memengaruhi kompatibilitas aplikasi pihak ketiga, penerapkan
perangkat HARUS memperbaiki error melalui update software yang tersedia yang dapat
diterapkan sesuai dengan mekanisme yang baru dijelaskan.
12. Hubungi Kami
Anda dapat menghubungi penulis dokumen di compatibility@android.com untuk mendapatkan klarifikasi
dan untuk menyampaikan masalah apa pun yang Anda rasa 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
antar-perangkat, 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 dari
model dari implementasi perangkat yang diuji - yaitu, implementasi perangkat
"yang baik"
Prosedur pengujian di bawah merujuk ke perangkat ini sebagai perangkat "kandidat" dan "
baik", masing-masing.
Penyiapan dan Penginstalan
1.  Build BluetoothChat.apk melalui 'make samples' dari hierarki kode sumber Android
2.  Instal  BluetoothChat.apk di perangkat yang berfungsi baik
3.  Instal  BluetoothChat.apk di perangkat kandidat
Uji Kontrol Bluetooth oleh Aplikasi
1.  Luncurkan BluetoothChat di perangkat kandidat, saat Bluetooth dinonaktifkan
2.  Pastikan perangkat kandidat mengaktifkan Bluetooth, atau meminta pengguna
dengan dialog untuk mengaktifkan Bluetooth
Uji Penyambungan dan Komunikasi
1.  Luncurkan aplikasi Bluetooth Chat di kedua perangkat
2.  Buat 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 verifikasi bahwa perangkat lain
menerimanya dengan benar
5.  Tutup aplikasi BluetoothChat di kedua perangkat dengan menekan Beranda
6.  Batalkan sambungan setiap perangkat dari perangkat lainnya, menggunakan aplikasi Setelan perangkat
Uji Penautan dan Komunikasi dalam Arah
Terbalik
1.  Luncurkan aplikasi Bluetooth Chat di kedua perangkat.
2.  Buat perangkat kandidat dapat ditemukan dari dalam BluetoothChat (menggunakan Menu
).
3.  Di perangkat yang berfungsi baik, pindai perangkat Bluetooth dari dalam BluetoothChat
(menggunakan Menu) dan sambungkan dengan perangkat kandidat.
4.  Kirim 10 pesan dari setiap perangkat, dan verifikasi bahwa perangkat lain
menerimanya dengan benar.
5.  Tutup aplikasi Chat Bluetooth di kedua perangkat dengan menekan Kembali berulang kali untuk
membuka Peluncur.
Menguji Peluncuran Ulang
1.  Luncurkan kembali aplikasi Chat Bluetooth di kedua perangkat.
2.  Kirim 10 pesan dari setiap perangkat, dan verifikasi bahwa perangkat lain
menerimanya dengan benar.
Catatan: pengujian di atas memiliki beberapa kasus yang mengakhiri bagian pengujian dengan 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 akan menyelesaikan()), dan secara implisit dikirim
ke latar belakang (melalui pengguna yang menekan Beranda.) Setiap urutan pengujian HARUS dilakukan
seperti yang dijelaskan.