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 1.6

Definisi Kompatibilitas Android: Android 1.6
Android 1.6 r2
Google Inc.
compatibility@android.com

1. Pengantar
Dokumen ini mencantumkan persyaratan yang harus dipenuhi agar ponsel
kompatibel dengan Android 1.6. Definisi ini mengasumsikan Anda sudah memahami Program Kompatibilitas Android
[Referensi, 1].
Penggunaan "harus", "tidak boleh", "wajib", "harus", "tidak boleh", "sebaiknya", "sebaiknya tidak", "direkomendasikan",
"boleh", dan "opsional" sesuai dengan standar IETF yang ditentukan dalam RFC2119 [Referensi, 2].
Seperti yang digunakan dalam dokumen ini, "penerapkan perangkat" atau "penerapkan" adalah orang atau organisasi yang mengembangkan
solusi hardware/software yang menjalankan Android 1.6. "Implementasi perangkat" atau "implementasi" adalah
solusi hardware/software yang dikembangkan.
Agar dianggap kompatibel dengan Android 1.6, implementasi perangkat:
1. HARUS memenuhi persyaratan yang disajikan dalam Definisi Kompatibilitas ini, termasuk dokumen apa pun
yang disertakan melalui referensi.
2. HARUS lulus Android Compatibility Test Suite (CTS) yang tersedia sebagai bagian dari Project Open
Source Android [Referensi, 3]. CTS menguji sebagian besar, tetapi tidak semua, komponen yang diuraikan dalam
dokumen ini.
Jika definisi ini atau CTS tidak jelas, ambigu, atau tidak lengkap, tanggung jawab implementer
perangkat adalah untuk memastikan kompatibilitas dengan implementasi yang ada. Karena alasan ini, Project Open
Source Android [Resources, 4] adalah referensi dan implementasi Android yang lebih disukai. Implementer
perangkat sangat disarankan untuk mendasarkan implementasi mereka pada kode sumber "upstream"
yang tersedia dari Project Open Source Android. Meskipun secara hipotetis beberapa komponen dapat diganti
dengan implementasi alternatif, praktik ini sangat tidak dianjurkan, karena lulus pengujian CTS akan menjadi
jauh lebih sulit. Implementer bertanggung jawab untuk memastikan kompatibilitas perilaku penuh dengan
implementasi Android standar, termasuk dan di luar Compatibility Test Suite.
2. Referensi
Definisi Kompatibilitas ini merujuk pada sejumlah referensi yang dapat diperoleh di sini.
1. Ringkasan Program Kompatibilitas Android: https://sites.google.com/a/android.com/compatibility/
how-it-works
2. Tingkat Persyaratan IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
3. Compatibility Test Suite: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--cts
4. Project Open Source Android: http://source.android.com/
5. Definisi dan dokumentasi API: http://developer.android.com/reference/packages.html
6. Penyedia Konten: http://code.google.com/android/reference/android/provider/package-
summary.html
7. Referensi yang Tersedia: http://code.google.com/android/reference/available-resources.html
8. File Manifes Android: http://code.google.com/android/devel/bblocks-manifest.html
9. Referensi Izin Android: http://developer.android.com/reference/android/
Manifest.permission.html
10. Konstanta Build: http://developer.android.com/reference/android/os/Build.html
11. WebView: http://developer.android.com/reference/android/webkit/WebView.html
12. Gears Browser Extensions: http://code.google.com/apis/gears/

13. Spesifikasi Virtual Machine Dalvik, yang ditemukan di direktori dalvik/docs dari checkout kode sumber
; juga tersedia di http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. Notifikasi: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. Panduan gaya ikon Status Bar: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Pengelola Penelusuran: http://developer.android.com/reference/android/app/SearchManager.html
18. Toast: http://developer.android.com/reference/android/widget/Toast.html
19. Apps For Android: http://code.google.com/p/apps-for-android
20. Deskripsi file apk Android: http://developer.android.com/guide/topics/fundamentals.html
21. Android Debug Bridge (adb): http://code.google.com/android/reference/adb.html
22. Dalvik Debug Monitor Service (ddms): http://code.google.com/android/reference/ddms.html
23. Monkey: http://developer.android.com/guide/developing/tools/monkey.html
24. Dokumentasi Independensi Layar:
25. Konstanta Konfigurasi: http://developer.android.com/reference/android/content/res/
Configuration.html
26. Metrik Layar: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. Kamera: http://developer.android.com/reference/android/hardware/Camera.html
28. Ruang koordinat sensor: http://developer.android.com/reference/android/hardware/
SensorEvent.html
29. Referensi Keamanan dan Izin Android: http://developer.android.com/guide/topics/security/
security.html
Banyak referensi ini berasal secara langsung atau tidak langsung dari SDK Android 1.6, dan akan
secara fungsional identik dengan informasi dalam dokumentasi SDK tersebut. Jika
Definisi Kompatibilitas ini tidak sesuai dengan dokumentasi SDK, dokumentasi SDK dianggap
otoritatif. Semua detail teknis yang diberikan dalam referensi yang disertakan di atas dianggap oleh penyertaan
sebagai bagian dari Definisi Kompatibilitas ini.
3. Software
Platform Android mencakup sekumpulan API terkelola ("hard"), dan kumpulan API yang disebut "soft"
seperti sistem Intent, API kode native, dan API aplikasi web. Bagian ini menjelaskan API hard dan
soft yang merupakan bagian integral dari kompatibilitas, serta perilaku
antarmuka pengguna dan teknis tertentu yang relevan. Implementasi perangkat HARUS mematuhi semua persyaratan di bagian ini.
3.1. Kompatibilitas API Terkelola
Lingkungan eksekusi terkelola (berbasis Dalvik) adalah kendaraan utama untuk aplikasi Android.
Application programming interface (API) Android adalah kumpulan antarmuka platform Android yang diekspos ke
aplikasi yang berjalan di lingkungan VM terkelola. Implementasi perangkat HARUS menyediakan implementasi
lengkap, termasuk semua perilaku yang didokumentasikan, dari API yang didokumentasikan yang diekspos oleh Android
1.6 SDK, seperti:
1. API bahasa Java Android inti [Resources, 5].
2. Penyedia Konten [Referensi, 6].
3. Referensi [Resources, 7].
4. Atribut dan elemen AndroidManifest.xml [Resources, 8].

Implementasi perangkat TIDAK BOLEH menghilangkan API terkelola, mengubah antarmuka atau tanda tangan API, menyimpang
dari perilaku yang didokumentasikan, atau menyertakan no-ops, kecuali jika diizinkan secara khusus oleh Definisi
Kompatibilitas ini.
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. Bagian ini menjelaskan API "soft" dan perilaku
sistem yang diperlukan untuk kompatibilitas dengan Android 1.6. Implementasi perangkat HARUS memenuhi semua
persyaratan yang disajikan di bagian ini.
3.2.1. Izin
Penerapan perangkat HARUS mendukung dan menerapkan semua konstanta izin seperti yang didokumentasikan oleh
halaman referensi Izin [Referensi, 9]. Perhatikan bahwa Bagian 10 mencantumkan persyaratan tambahan yang terkait dengan
model keamanan Android.
3.2.2. Parameter Build
Android API menyertakan sejumlah konstanta pada class android.os.Build [Resources, 10] yang
dimaksudkan untuk mendeskripsikan perangkat saat ini. Untuk memberikan nilai yang konsisten dan bermakna di seluruh implementasi
perangkat, tabel di bawah menyertakan batasan tambahan pada format nilai ini yang HARUS sesuai dengan
implementasi perangkat.
Parameter
Komentar
Versi sistem Android yang sedang dijalankan, dalam format yang dapat dibaca manusia, yaitu
android.os.Build.VERSION.RELEASE
. Untuk Android 1.6, kolom ini HARUS memiliki nilai string
"1.6".
Versi sistem Android yang sedang dieksekusi, dalam format
android.os.Build.VERSION.SDK
yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 1.6, kolom ini
HARUS memiliki nilai bilangan bulat 4.
Nilai yang dipilih oleh implementator perangkat yang menetapkan build tertentu
dari sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia.
Nilai ini TIDAK BOLEH digunakan kembali untuk build yang berbeda yang dikirim ke pengguna
android.os.Build.VERSION.INCREMENTAL akhir. Penggunaan umum kolom ini adalah untuk menunjukkan nomor build atau
ID perubahan kontrol sumber yang digunakan untuk membuat build. Tidak ada
persyaratan pada format spesifik kolom ini, kecuali bahwa
TIDAK BOLEH null atau string kosong ("").
Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi hardware internal
tertentu yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan
android.os.Build.BOARD
kolom ini adalah untuk menunjukkan revisi spesifik dari board yang mendukung
perangkat. Tidak ada persyaratan pada format spesifik kolom ini,
kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi nama
perusahaan, organisasi, individu, dll.
android.os.Build. BRAND
yang memproduksi perangkat, dalam
format yang dapat dibaca manusia. Kemungkinan penggunaan kolom ini adalah untuk menunjukkan OEM

dan/atau operator yang menjual perangkat. Tidak ada persyaratan pada
format tertentu kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string
kosong ("").
Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi konfigurasi
atau revisi tertentu dari isi (terkadang disebut "desain
android.os.Build.DEVICE
industri") perangkat. Tidak ada persyaratan pada format tertentu
kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
String yang mengidentifikasi build ini secara unik. File ini HARUS
dapat dibaca manusia. Ini HARUS mengikuti template ini:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
Misalnya: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/test-keys
Sidik jari TIDAK BOLEH menyertakan spasi. Jika kolom lain yang disertakan dalam
template di atas memiliki spasi, kolom tersebut HARUS diganti dengan karakter garis bawah ASCII
("_") dalam sidik jari.
String yang secara unik mengidentifikasi host tempat build dibuat, dalam format yang dapat dibaca manusia
android.os.Build.HOST
. Tidak ada persyaratan pada format khusus kolom
ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
ID yang dipilih oleh implementator perangkat untuk merujuk ke rilis
tertentu, dalam format yang dapat dibaca manusia. Kolom ini dapat sama dengan
android.os.Build.VERSION.INCREMENTAL, tetapi HARUS berupa nilai
android.os.Build.ID
yang dimaksudkan untuk menjadi agak bermakna bagi pengguna akhir. Tidak ada
persyaratan pada format spesifik kolom ini, kecuali bahwa kolom ini TIDAK BOLEH
null atau string kosong ("").
Nilai yang dipilih oleh pengimplementasi perangkat yang berisi nama
perangkat seperti yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama
android.os.Build.MODEL
yang digunakan untuk memasarkan dan menjual perangkat kepada pengguna akhir. Tidak ada
persyaratan pada format spesifik kolom ini, kecuali bahwa kolom ini TIDAK BOLEH
null atau string kosong ("").
Nilai yang dipilih oleh implementator perangkat yang berisi nama
pengembangan atau nama kode perangkat. HARUS dapat dibaca manusia, tetapi tidak
android.os.Build.PRODUCT
selalu dimaksudkan untuk dilihat oleh pengguna akhir. Tidak ada persyaratan
pada format spesifik kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau
string kosong ("").
Daftar tag yang dipisahkan koma yang dipilih oleh implementator perangkat yang
lebih lanjut membedakan build. Misalnya, "unsigned,debug". Kolom ini
android.os.Build.TAGS
TIDAK BOLEH null atau string kosong (""), tetapi satu tag (seperti
"release") tidak masalah.
android.os.Build.TIME
Nilai yang mewakili stempel waktu saat build terjadi.
Nilai yang dipilih oleh implementator perangkat yang menentukan konfigurasi
runtime build. Kolom ini HARUS memiliki salah satu nilai
android.os.Build.TYPE
yang sesuai dengan tiga konfigurasi runtime Android standar: "user",
"userdebug", atau "eng".
Nama atau ID pengguna pengguna (atau pengguna otomatis) yang membuat build
android.os.Build.USER
. Tidak ada persyaratan pada format khusus kolom ini,
kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").

3.2.3. Kompatibilitas Intent
Android menggunakan Intent untuk mencapai integrasi yang terikat longgar antar-aplikasi. Bagian ini menjelaskan
persyaratan terkait pola Intent yang HARUS dipatuhi oleh implementasi perangkat. Dengan
"dihormati", maksudnya adalah implementator perangkat HARUS menyediakan Aktivitas, Layanan, atau komponen
Android lainnya yang menentukan filter Intent yang cocok dan mengikat serta menerapkan perilaku yang benar untuk setiap
pola Intent yang ditentukan.
3.2.3.1. Intent Aplikasi Inti
Project upstream Android menentukan sejumlah aplikasi inti, seperti alat pilih nomor telepon, kalender,
buku kontak, pemutar musik, dan sebagainya. Implementator perangkat DAPAT mengganti aplikasi ini dengan
versi alternatif.
Namun, versi alternatif tersebut HARUS mematuhi pola Intent yang sama yang disediakan oleh project
upstream. (Misalnya, jika perangkat berisi pemutar musik alternatif, perangkat tersebut tetap harus mematuhi pola Intent
yang dikeluarkan oleh aplikasi pihak ketiga untuk memilih lagu.) Implementasi perangkat HARUS mendukung semua pola Intent
yang tercantum dalam Lampiran A.
3.2.3.2. Penggantian Intent
Karena Android adalah platform yang dapat diperluas, pengimplementasi perangkat HARUS mengizinkan setiap pola Intent yang dijelaskan dalam
Lampiran A untuk diganti oleh aplikasi pihak ketiga. Project open source Android upstream
mengizinkan hal ini secara default; pengimplementasi perangkat TIDAK BOLEH melampirkan hak istimewa khusus ke penggunaan
pola Intent ini oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga untuk mengikat dan mengambil alih kontrol
pola ini. Pengecualian ini secara khusus mencakup penonaktifan antarmuka pengguna "Chooser" yang memungkinkan
pengguna memilih antara beberapa aplikasi yang semuanya menangani pola Intent yang sama.
3.2.3.3. Namespace Intent
Penerapan perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola Intent baru atau
Broadcast Intent menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android.*.
Penerapan perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola Intent baru atau
Broadcast Intent menggunakan ACTION, CATEGORY, atau string kunci lainnya di ruang paket
milik organisasi lain. Implementer perangkat TIDAK BOLEH mengubah atau memperluas pola Intent
apa pun yang tercantum dalam Lampiran A atau B.
Larangan ini analog dengan yang ditentukan untuk class bahasa Java di Pasal 3.6.

3.2.3.4. Intent Siaran
Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan Intent tertentu guna memberi tahu mereka tentang perubahan dalam
lingkungan hardware atau software. Perangkat yang kompatibel dengan Android HARUS menyiarkan Intent
siaran publik sebagai respons terhadap peristiwa sistem yang sesuai. Daftar Intent Siaran yang diperlukan diberikan dalam
Lampiran B; namun, perhatikan bahwa SDK dapat menentukan intent siaran tambahan, yang JUGA HARUS
dihormati.
3.3. Kompatibilitas API Native
Kode terkelola yang berjalan di Dalvik dapat memanggil kode native yang disediakan dalam file .apk aplikasi sebagai file ELF
.so yang dikompilasi untuk arsitektur hardware perangkat yang sesuai. Implementasi perangkat HARUS menyertakan
dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode native, menggunakan semantik Java
Native Interface (JNI) standar. API berikut harus tersedia untuk kode native:
• libc (library C)
• libm (library matematika)
• antarmuka JNI
• libz (Kompresi Zlib)
• liblog (Logging Android)
• Dukungan minimal untuk C++
• OpenGL ES 1.1
Library ini HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk arsitektur prosesor
tertentu) dengan versi yang disediakan di Bionic oleh project Open Source Android. Karena
implementasi Bionic tidak sepenuhnya kompatibel dengan implementasi lain seperti library GNU C
, implementator perangkat HARUS menggunakan implementasi Android. Jika implementator perangkat menggunakan
implementasi library yang berbeda, mereka harus memastikan kompatibilitas header dan biner.
Kompatibilitas kode native sulit. Oleh karena itu, kami ingin mengulangi bahwa pengimplementasi perangkat
SANGAT disarankan untuk menggunakan implementasi upstream library yang tercantum di atas, untuk membantu
memastikan kompatibilitas.
3.4. Kompatibilitas Web API
Banyak developer dan aplikasi mengandalkan perilaku class android.webkit.WebView [Referensi,
11] untuk antarmuka pengguna mereka, sehingga implementasi WebView harus kompatibel di seluruh implementasi
Android. Implementasi Open Source Android menggunakan versi mesin rendering WebKit untuk
menerapkan WebView.
Karena tidak memungkinkan untuk mengembangkan rangkaian pengujian yang komprehensif untuk browser web, pengimplementasi perangkat
HARUS menggunakan build upstream WebKit tertentu dalam implementasi WebView. Secara khusus:
• WebView HARUS menggunakan build WebKit 528.5+ dari hierarki Open Source Android upstream untuk
Android 1.6. Build ini mencakup serangkaian fungsi dan perbaikan keamanan tertentu untuk WebView.
• String agen pengguna yang dilaporkan oleh WebView HARUS dalam format ini:
Mozilla/5.0 (Linux; U; Android 1.6; <language>-<country>; <device
name>; Build/<build ID>) AppleWebKit/528.5+ (KHTML, seperti Gecko)
Version/3.1.2 Mobile Safari/525.20.1

◦ String "<device name>" HARUS sama dengan nilai untuk
android.os.Build.MODEL
◦ String "<build ID>" HARUS sama dengan nilai untuk android.os.Build.ID.
◦ String "<language>" dan "<country>" HARUS mengikuti konvensi biasa untuk
kode negara dan bahasa, dan HARUS merujuk ke lokalitas perangkat saat ini pada
waktu permintaan.
Implementasi DAPAT mengirimkan string agen pengguna kustom di aplikasi Browser mandiri. Selain itu, Browser mandiri DAPAT didasarkan pada teknologi browser alternatif (seperti Firefox,
Opera, dll.)
Namun, meskipun aplikasi Browser alternatif dikirimkan, komponen WebView
yang disediakan untuk aplikasi pihak ketiga HARUS didasarkan pada WebKit, seperti di atas.
Aplikasi Browser mandiri HARUS menyertakan dukungan untuk Gears [Referensi, 12] dan DAPAT
menyertakan dukungan untuk sebagian atau semua HTML5.
3.5. Kompatibilitas Perilaku API
Perilaku setiap jenis API (terkelola, soft, native, dan web) harus konsisten dengan
implementasi Android pilihan yang tersedia dari Android Open Source Project.
Beberapa area kompatibilitas tertentu adalah:
• Perangkat TIDAK BOLEH mengubah perilaku atau makna Intent standar
• Perangkat TIDAK BOLEH mengubah siklus proses atau semantik siklus proses dari jenis komponen sistem
tertentu (seperti Layanan, Aktivitas, ContentProvider, dll.)
• Perangkat TIDAK BOLEH mengubah semantik izin tertentu
Daftar di atas tidak komprehensif, dan tanggung jawabnya ada pada implementator perangkat untuk memastikan kompatibilitas
perilaku. Oleh karena itu, jika memungkinkan, implementator perangkat HARUS menggunakan kode sumber yang tersedia melalui
Project Open Source Android, bukan menerapkan ulang bagian penting sistem.
Compatibility Test Suite (CTS) menguji sebagian besar platform untuk kompatibilitas perilaku,
tetapi tidak semuanya. Implementer bertanggung jawab untuk memastikan kompatibilitas perilaku dengan Project Open Source
Android.
3.6. Namespace API
Android mengikuti konvensi namespace paket dan class yang ditentukan oleh bahasa pemrograman
Java. Untuk memastikan kompatibilitas dengan aplikasi pihak ketiga, pengimplementasi perangkat TIDAK BOLEH membuat
modifikasi apa pun 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 API yang mendasarinya, tetapi modikasi
tersebut TIDAK BOLEH memengaruhi perilaku yang dinyatakan dan tanda tangan bahasa Java dari
API yang diekspos 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 diekspos secara publik" adalah konstruksi apa pun yang tidak dihiasi dengan penanda "@hide" dalam
kode sumber Android upstream. Dengan kata lain, pengimplementasi perangkat TIDAK BOLEH mengekspos API baru atau
mengubah API yang ada dalam namespace yang disebutkan di atas. Penerapan perangkat BOLEH melakukan modifikasi
khusus internal, tetapi modifikasi tersebut TIDAK BOLEH diiklankan atau diekspos kepada developer.
Penerapan perangkat DAPAT menambahkan API kustom, tetapi API tersebut TIDAK BOLEH berada dalam namespace yang dimiliki
oleh atau merujuk ke organisasi lain. Misalnya, pengimplementasi 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.
Jika pengimplementasi perangkat mengusulkan untuk meningkatkan salah satu namespace paket di atas (seperti dengan menambahkan
fungsi baru yang berguna ke API yang ada, atau menambahkan API baru), pengimplementasi HARUS mengunjungi
source.android.com dan memulai proses untuk berkontribusi pada perubahan dan kode, sesuai dengan
informasi di situs tersebut.
Perhatikan bahwa batasan di atas sesuai dengan konvensi standar untuk penamaan API dalam bahasa pemrograman
Java; bagian ini hanya bertujuan untuk memperkuat konvensi tersebut dan membuatnya mengikat
melalui penyertaan dalam definisi kompatibilitas ini.
3.7. Kompatibilitas Virtual Machine
Perangkat Android yang kompatibel harus mendukung spesifikasi bytecode Dalvik Executable (DEX) lengkap dan
semantik Virtual Machine Dalvik [Referensi, 13].
3.8. Kompatibilitas Antarmuka Pengguna
Platform Android menyertakan beberapa API developer yang memungkinkan developer terhubung ke antarmuka
pengguna sistem. Implementasi perangkat HARUS menggabungkan API UI standar ini ke dalam antarmuka pengguna kustom
yang mereka kembangkan, seperti yang dijelaskan di bawah.
3.8.1. Widget
Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos
"AppWidget" kepada pengguna akhir [Referensi, 14]. Rilis referensi Open Source Android menyertakan
aplikasi Peluncur yang menyertakan elemen antarmuka pengguna yang memungkinkan pengguna menambahkan, melihat, dan menghapus
AppWidget dari layar utama.
Penerapan perangkat DAPAT mengganti alternatif dengan Peluncur referensi (yaitu layar utama).
Peluncur Alternatif HARUS menyertakan dukungan bawaan untuk AppWidget, dan mengekspos elemen antarmuka pengguna
untuk menambahkan, melihat, dan menghapus AppWidget langsung dalam Peluncur. Peluncur Alternatif DAPAT
menghapus elemen antarmuka pengguna ini; namun, jika dihapus, implementator perangkat HARUS menyediakan
aplikasi terpisah yang dapat diakses dari Peluncur yang memungkinkan pengguna menambahkan, melihat, dan menghapus
AppWidget.

3.8.2. Notifikasi
Android menyertakan API yang memungkinkan developer memberi tahu pengguna tentang peristiwa penting [Referensi, 15]. Penerapan
perangkat HARUS memberikan dukungan untuk setiap class notifikasi yang ditentukan; khususnya: suara,
getaran, lampu, dan status bar.
Selain itu, penerapan HARUS dirender dengan benar dan semua resource (ikon, file suara, dll.)
disediakan di API [Referensi, 7], atau di Panduan gaya ikon Status Bar [Referensi, 16]. Penerapan
perangkat DAPAT memberikan pengalaman pengguna alternatif untuk notifikasi selain yang disediakan oleh
implementasi Android Open Source referensi; namun, sistem notifikasi alternatif tersebut HARUS
mendukung resource notifikasi yang ada, seperti di atas.
3.8.3. Penelusuran
Android menyertakan API [Referensi, 17] yang memungkinkan developer menggabungkan penelusuran ke dalam aplikasi mereka,
dan mengekspos data aplikasi mereka ke dalam penelusuran sistem global. Secara umum, fungsi ini
terdiri dari satu antarmuka pengguna seluruh sistem yang memungkinkan pengguna memasukkan kueri, menampilkan saran
saat pengguna mengetik, dan menampilkan hasil. Android API memungkinkan developer menggunakan kembali antarmuka ini untuk menyediakan
penelusuran dalam aplikasi mereka sendiri, dan memungkinkan developer menyediakan hasil ke antarmuka
pengguna penelusuran global umum.
Implementasi perangkat HARUS menyertakan satu antarmuka pengguna penelusuran bersama di seluruh sistem yang mampu memberikan
saran real-time sebagai respons terhadap input pengguna. Implementasi perangkat HARUS mengimplementasikan API yang
memungkinkan developer menggunakan kembali antarmuka pengguna ini untuk menyediakan penelusuran dalam aplikasi mereka sendiri.
Implementasi perangkat HARUS menerapkan API yang memungkinkan aplikasi pihak ketiga menambahkan saran
ke kotak penelusuran saat dijalankan dalam mode penelusuran global. Jika tidak ada aplikasi pihak ketiga yang diinstal yang
menggunakan fungsi ini, perilaku default HARUS menampilkan hasil dan
saran mesin telusur web.
Implementasi perangkat DAPAT mengirimkan antarmuka pengguna penelusuran alternatif, tetapi HARUS menyertakan tombol penelusuran khusus
keras atau lunak, yang dapat digunakan kapan saja dalam aplikasi apa pun untuk memanggil framework penelusuran,
dengan perilaku yang disediakan dalam dokumentasi API.
3.8.4. Toast
Aplikasi dapat menggunakan "Toast" API (ditentukan dalam [Referensi, 18]) untuk menampilkan string non-modal singkat kepada
pengguna akhir, yang menghilang setelah jangka waktu singkat. Implementasi perangkat HARUS menampilkan Toast dari
aplikasi kepada pengguna akhir dengan cara yang sangat terlihat.
4. Kompatibilitas Software Referensi
Penerapan perangkat HARUS menguji kompatibilitas implementasi menggunakan aplikasi
open source berikut:
• Kalkulator (disertakan dalam SDK)
• Lunar Lander (disertakan dalam SDK)
• ApiDemos (disertakan dalam SDK)
• Aplikasi "Apps for Android" [Referensi, 19]
Setiap aplikasi di atas HARUS diluncurkan dan berperilaku dengan benar pada implementasi, agar implementasi

dianggap kompatibel.
5. Kompatibilitas Pengemasan Aplikasi
Implementasi perangkat HARUS menginstal dan menjalankan file ".apk" Android seperti yang dihasilkan oleh alat "aapt"
yang disertakan dalam Android SDK resmi [Referensi, 20].
Implementasi perangkat TIDAK BOLEH memperluas format .apk, Manifes Android, atau bytecode Dalvik
sedemikian rupa sehingga mencegah file tersebut diinstal dan berjalan dengan benar di perangkat
kompatibel lainnya. Implementator perangkat HARUS menggunakan implementasi upstream referensi Dalvik,
dan sistem pengelolaan paket implementasi referensi.
6. Kompatibilitas Multimedia
Perangkat Android yang kompatibel harus mendukung codec multimedia berikut. Semua codec ini
disediakan sebagai implementasi software dalam implementasi Android yang diinginkan dari Project Open
Source Android [Referensi, 4].
Perlu diperhatikan bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan apa pun bahwa codec
ini tidak terikat oleh paten pihak ketiga. Bagi yang ingin menggunakan kode sumber ini dalam produk hardware atau
software, sebaiknya implementasi kode ini, termasuk dalam software open source atau
shareware, mungkin memerlukan lisensi paten dari pemegang paten yang relevan.
Nama
Audio
Detail Decoder Encoder
File yang Didukung
Konten Mono/Stereo dalam
3GPP (.3gp) dan
kombinasi kecepatan bit standar
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
hingga 160 kbps dan file kecepatan sampling. Tidak ada dukungan untuk konten AAC (.aac)

raw
Mono/Stereo antara 8 hingga 48 kHz
dalam kombinasi
3GPP (.3gp) dan
HE-AACv1
kecepatan bit standar
MPEG-4 (.mp4, .m4a)
X
(AAC+)
hingga 96 kbps dan file frekuensi sampling. Tidak ada dukungan untuk konten AAC (.aac)

raw
Mono/Stereo antara 8 hingga 48 kHz
dalam file
HE-AACv2
3GPP (.3gp) dan
kombinasi kecepatan bit standar
(enhanced
MPEG-4 (.mp4, .m4a)
X
hingga 96 kbps dan frekuensi sampling
AAC+)
. Tidak ada dukungan untuk raw
antara 8 hingga 48 kHz
AAC (.aac)
AMR-NB
4,75 hingga 12,2 kbps yang diambil sampelnya @
file 3GPP (.3gp)
X
X
8 kHz
AMR-WB
9 kecepatan dari 6,60 kbit/s hingga 23,85
-file 3GPP (.3gp)
X
kbit/s yang diambil sampelnya @ 16 kHz
MP3
Mono/Stereo 8-320 Kbps konstan file MP3 (.mp3)
X
(CBR) atau kecepatan bit variabel (VBR)
Jenis 0 dan 1 (.mid, .xmf,
MIDI Jenis 0 dan 1. DLS Versi 1
MIDI
X
.mxmf). Juga RTTTL/RTX
dan 2. XMF dan Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Dukungan untuk format nada dering
dan iMelody (.imy)
RTTTL/RTX, OTA, dan iMelody
Ogg Vorbis
.ogg
X
PCM linear 8- dan 16-bit (kecepatan hingga
PCM
X
WAVE
batas hardware)
Gambar
File
Nama
Encoder Decoder Details
Didukung
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
Video
File
Nama
Encoder Decoder Details
Didukung
file 3GPP (.3gp)
H.263
X
X

file 3GPP (.3gp)
H.264
X
dan MPEG-4
(.mp4)
MPEG4
X
file 3GPP (.3gp)
SP
7. 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 atau adb [Referensi, 21]
Implementasi perangkat HARUS mendukung semua fungsi adb seperti yang didokumentasikan dalam Android
SDK. Daemon adb sisi perangkat HARUS tidak aktif secara default, tetapi HARUS ada mekanisme yang dapat diakses
pengguna untuk mengaktifkan Android Debug Bridge.
• Dalvik Debug Monitor Service atau ddms [Referensi, 22]
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 mengaktifkan Android Debug Bridge, seperti di atas.

• Monkey [Resources, 23]
Implementasi perangkat HARUS menyertakan framework Monkey, dan menyediakannya untuk digunakan oleh
aplikasi.
8. Kompatibilitas Hardware
Android ditujukan untuk mendukung pengimplementasi perangkat yang membuat konfigurasi dan faktor bentuk yang inovatif.
Pada saat yang sama, developer Android mengharapkan hardware, sensor, dan API tertentu di semua perangkat
Android. Bagian ini mencantumkan fitur hardware yang harus didukung oleh semua perangkat yang kompatibel dengan Android 1.6. Di
Android 1.6, sebagian besar fitur hardware (seperti Wi-Fi, kompas, dan akselerometer) diperlukan.
Jika perangkat menyertakan komponen hardware tertentu yang memiliki API yang sesuai untuk developer
pihak ketiga, implementasi perangkat HARUS menerapkan API tersebut seperti yang ditentukan dalam dokumentasi
Android SDK.
8.1. Tampilan
Android 1.6 menyertakan fasilitas yang melakukan operasi penskalaan dan transformasi otomatis tertentu dalam
beberapa situasi, untuk memastikan aplikasi pihak ketiga berjalan cukup baik pada konfigurasi
hardware yang tidak perlu dirancang secara eksplisit [Referensi, 24]. Perangkat HARUS
menerapkan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.
8.1.1. Konfigurasi Layar Standar
Tabel ini mencantumkan konfigurasi layar standar yang dianggap kompatibel dengan Android:
Diagonal
Ukuran Layar
Kepadatan Layar
Jenis Layar
Lebar (Piksel)
Tinggi (Piksel)
Rentang Panjang
Grup
Grup
(inci)
QVGA
240
320
2,6 - 3,0
Kecil
Rendah
WQVGA
240
400
3,2 - 3,5
Normal
Rendah
FWQVGA
240
432
3,5 - 3,8
Normal
Rendah
HVGA
320
480
3,0 - 3,5
Normal
Sedang
WVGA
480
800
3,3 - 4,0
Normal
Tinggi
FWVGA
480
854
3,5 - 4,0
Normal
Tinggi
WVGA
480
800
4,8 - 5,5
Besar
Sedang
FWVGA
480
854
5,0 - 5,8
Besar
Sedang
Implementasi perangkat yang sesuai dengan salah satu konfigurasi standar di atas HARUS dikonfigurasi
untuk melaporkan ukuran layar yang ditunjukkan ke aplikasi melalui class android.content.res.Configuration [Resources,
25].
Beberapa paket .apk memiliki manifes yang tidak mengidentifikasinya sebagai mendukung rentang kepadatan tertentu.
Saat menjalankan aplikasi tersebut, batasan berikut berlaku:

• Implementasi perangkat HARUS menafsirkan resource apa pun yang ada sebagai default ke
"medium" (dikenal sebagai "mdpi" dalam dokumentasi SDK.)
• Saat beroperasi di layar dengan kepadatan "rendah", implementasi perangkat HARUS menskalakan aset mdpi medium/
dengan faktor 0,75.
• Saat beroperasi di layar dengan kepadatan "tinggi", implementasi perangkat HARUS menskalakan aset mdpi medium/
dengan faktor 1,5.
• Implementasi perangkat TIDAK BOLEH menskalakan aset dalam rentang kepadatan, dan HARUS menskalakan aset dengan faktor ini persis di antara rentang kepadatan.

8.1.2. Konfigurasi Layar Non-Standar
Konfigurasi layar yang tidak cocok dengan salah satu konfigurasi standar yang tercantum di Bagian 8.2.1 memerlukan
pertimbangan dan upaya tambahan agar kompatibel. Implementator perangkat HARUS menghubungi Tim Kompatibilitas
Android seperti yang disediakan di Bagian 12 untuk mendapatkan klasifikasi untuk bucket ukuran layar, kepadatan,
dan faktor penskalaan. Jika diberikan informasi ini, implementasi perangkat HARUS menerapkannya
seperti yang ditentukan.
Perhatikan bahwa beberapa konfigurasi layar (seperti layar yang sangat besar atau sangat kecil, dan beberapa rasio aspek)
pada dasarnya tidak kompatibel dengan Android 1.6; oleh karena itu, pengimplementasi perangkat dianjurkan untuk
menghubungi Tim Kompatibilitas Android sedini mungkin dalam proses pengembangan.
8.1.3. Metrik Layar
Implementasi perangkat HARUS melaporkan nilai yang benar untuk semua metrik layar yang ditentukan dalam
android.util.DisplayMetrics [Resources, 26].
8.2. Keyboard
Implementasi perangkat:
• HARUS menyertakan dukungan untuk Framework Pengelolaan Input (yang memungkinkan developer
pihak ketiga membuat Mesin Pengelolaan Input -- yaitu keyboard virtual) seperti yang dijelaskan di
developer.android.com
• HARUS menyediakan minimal satu implementasi keyboard virtual (terlepas dari apakah keyboard
fisik ada)
• DAPAT menyertakan implementasi keyboard virtual tambahan
• DAPAT menyertakan keyboard hardware
• TIDAK BOLEH menyertakan keyboard hardware yang tidak cocok dengan salah satu format yang ditentukan
di android.content.res.Configuration [Resources, 25] (yaitu, QWERTY, atau 12 tombol)
8.3. Navigasi Non-sentuh
Implementasi perangkat:
• DAPAT menghilangkan opsi navigasi non-sentuh (yaitu, dapat menghilangkan trackball, tombol arah 5 arah, atau
roda)
• HARUS melaporkan melalui android.content.res.Configuration [Resources, 25] nilai yang benar untuk
hardware perangkat

8.4. Orientasi Layar
Perangkat yang kompatibel HARUS mendukung orientasi dinamis oleh aplikasi ke orientasi layar
potret atau lanskap. Artinya, perangkat harus mematuhi permintaan aplikasi untuk orientasi
layar tertentu. Implementasi perangkat DAPAT memilih orientasi potret atau lanskap sebagai default.
Perangkat HARUS melaporkan nilai yang benar untuk orientasi perangkat saat ini, setiap kali dikueri melalui
android.content.res.Configuration.orientation, android.view.Display.getOrientation(), atau API lainnya.
8.5. Input layar sentuh
Implementasi perangkat:
• HARUS memiliki layar sentuh
• DAPAT memiliki layar sentuh kapasitif atau resistif
• HARUS melaporkan nilai android.content.res.Configuration [Resources, 25] yang mencerminkan
sesuai dengan jenis layar sentuh tertentu di perangkat
8.6. USB
Implementasi perangkat:
• HARUS mengimplementasikan klien USB, yang dapat dihubungkan ke host USB dengan port USB-A standar
• HARUS mengimplementasikan Android Debug Bridge melalui USB (seperti yang dijelaskan di Bagian 7)
• HARUS mengimplementasikan klien penyimpanan massal USB untuk penyimpanan media/yang dapat dilepas yang ada di
perangkat
• HARUS menggunakan faktor bentuk USB mikro di sisi perangkat
• HARUS mengimplementasikan dukungan untuk spesifikasi Penyimpanan Massal USB (sehingga penyimpanan
yang dapat dilepas atau tetap di perangkat dapat diakses dari PC host)
• DAPAT menyertakan port non-standar di sisi perangkat, tetapi jika demikian, HARUS dikirimkan dengan kabel yang mampu
menghubungkan pinout kustom ke port USB-A standar
8.7. Tombol navigasi
Fungsi Beranda, Menu, dan Kembali sangat penting untuk paradigma navigasi Android. Implementasi
perangkat HARUS menyediakan fungsi ini kepada pengguna setiap saat, terlepas dari status
aplikasi. Fungsi ini HARUS diterapkan melalui tombol khusus. Fitur ini DAPAT diterapkan
menggunakan software, gestur, panel sentuh, dll., tetapi jika demikian, fitur ini HARUS selalu dapat diakses dan tidak mengaburkan atau
mengganggu area tampilan aplikasi yang tersedia.
Penerapan perangkat JUGA HARUS menyediakan kunci penelusuran khusus. Penerapan perangkat JUGA DAPAT
menyediakan tombol kirim dan akhiri untuk panggilan telepon.
8.8. Wi-Fi
Implementasi perangkat HARUS mendukung 802.11b dan 802.11g, dan DAPAT mendukung 802.11a.

8.9. Kamera
Implementasi perangkat HARUS menyertakan kamera. Kamera yang disertakan:
• HARUS memiliki resolusi minimal 2 megapiksel
• HARUS memiliki fokus otomatis hardware, atau fokus otomatis software yang diterapkan di driver
kamera (transparan untuk software aplikasi)
• DAPAT memiliki hardware fokus tetap atau EDOF (extended depth of field)
• DAPAT menyertakan flash. Jika Kamera menyertakan flash, lampu flash TIDAK BOLEH menyala saat instance
android.hardware.Camera.PreviewCallback telah terdaftar di platform pratinjau
Kamera.
Implementasi perangkat HARUS menerapkan perilaku berikut untuk API terkait kamera
[Resources, 27]:
1. Jika aplikasi belum pernah memanggil android.hardware.Camera.Parameters.setPreviewFormat(int),
perangkat HARUS menggunakan android.hardware.PixelFormat.YCbCr_420_SP untuk data pratinjau
yang diberikan ke callback aplikasi.
2. Jika aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem
memanggil metode onPreviewFrame() saat format pratinjau adalah YCbCr_420_SP,
data dalam byte[] yang diteruskan ke onPreviewFrame() harus lebih lanjut dalam format encoding NV21.
(Ini adalah format yang digunakan secara native oleh keluarga hardware 7k.) Artinya, NV21 HARUS menjadi default.
8.9.1. Kamera Non-Autofokus
Jika perangkat tidak memiliki kamera autofokus, pengimplementasi perangkat HARUS memenuhi persyaratan tambahan di
bagian ini. Implementasi perangkat HARUS menerapkan Camera API lengkap yang disertakan dalam dokumentasi SDK
Android 1.6 dengan cara yang wajar, terlepas dari kemampuan hardware kamera yang sebenarnya.
Untuk Android 1.6, jika kamera tidak memiliki fokus otomatis, implementasi perangkat HARUS mematuhi hal berikut:
1. Sistem HARUS menyertakan properti sistem hanya baca bernama "ro.workaround.noautofocus"
dengan nilai "1". Nilai ini dimaksudkan untuk digunakan oleh aplikasi seperti Android Market untuk
mengidentifikasi kemampuan perangkat secara selektif, dan akan diganti di versi Android mendatang dengan
API yang andal.
2. Jika aplikasi memanggil android.hardware.Camera.autoFocus(), sistem HARUS memanggil metode callback
onAutoFocus() pada instance
android.hardware.Camera.AutoFocusCallback yang terdaftar, meskipun tidak ada pemfokusan yang benar-benar
terjadi. Hal ini untuk menghindari aplikasi yang ada mengalami error dengan menunggu callback fokus otomatis
yang tidak akan pernah datang.
3. Panggilan ke metode AutoFocusCallback.onAutoFocus() HARUS dipicu oleh driver atau framework
dalam peristiwa baru pada thread Looper framework utama. Artinya, Camera.autoFocus()
TIDAK BOLEH langsung memanggil AutoFocusCallback.onAutoFocus() karena hal ini melanggar model threading framework
Android dan akan merusak aplikasi.
8.10. Akselerometer
Implementasi perangkat HARUS menyertakan akselerometer 3 sumbu dan HARUS dapat mengirimkan peristiwa dengan minimal
50 Hz. Sistem koordinat yang digunakan oleh akselerometer HARUS mematuhi sistem koordinat sensor
Android seperti yang dijelaskan dalam [Referensi, 28] Android API.

8.11. Kompas
Implementasi perangkat HARUS menyertakan kompas 3 sumbu dan HARUS dapat mengirimkan peristiwa setidaknya
10 Hz. Sistem koordinat yang digunakan oleh kompas HARUS mematuhi sistem koordinat sensor Android
sebagaimana ditentukan dalam Android API [Referensi, 28].
8.12. GPS
Implementasi perangkat HARUS menyertakan GPS, dan HARUS menyertakan beberapa bentuk teknik "GPS berbantuan"
untuk meminimalkan waktu penguncian GPS.
8.13. Telepon
Implementasi perangkat:
• HARUS menyertakan telepon GSM atau CDMA
• HARUS menerapkan API yang sesuai seperti yang dijelaskan dalam dokumentasi Android SDK di
developer.android.com
Perhatikan bahwa persyaratan ini menyiratkan bahwa perangkat non-ponsel tidak kompatibel dengan Android 1.6; perangkat Android
1.6 HARUS menyertakan hardware telepon. Lihat Lampiran C untuk mengetahui informasi tentang perangkat
non-ponsel.
8.14. Kontrol volume
Perangkat yang kompatibel dengan Android HARUS menyertakan mekanisme untuk memungkinkan pengguna meningkatkan dan menurunkan
volume audio. Implementasi perangkat HARUS menyediakan fungsi ini kepada pengguna setiap saat,
terlepas dari status aplikasi. Fungsi ini DAPAT diterapkan menggunakan tombol hardware fisik,
software, gestur, panel sentuh, dll., tetapi fungsi ini HARUS selalu dapat diakses dan tidak mengaburkan atau mengganggu
area tampilan aplikasi yang tersedia (lihat Tampilan di atas).
Saat tombol ini digunakan, peristiwa utama yang sesuai HARUS dibuat dan dikirim ke
aplikasi latar depan. Jika peristiwa tidak dicegat dan ditenggelamkan oleh aplikasi, implementasi
perangkat HARUS menangani peristiwa sebagai kontrol volume sistem.
9. Kompatibilitas Performa
Salah satu sasaran Program Kompatibilitas Android adalah untuk memastikan pengalaman aplikasi yang konsisten bagi
konsumen. Implementasi yang kompatibel tidak hanya harus memastikan bahwa aplikasi berjalan dengan benar di
perangkat, tetapi juga dengan performa yang wajar dan pengalaman pengguna yang baik secara keseluruhan.
Implementasi perangkat HARUS memenuhi metrik performa utama perangkat yang kompatibel dengan Android 1.6,
seperti dalam tabel di bawah:
Metrik
Batas Performa
Komentar

Ini diuji oleh CTS.
Aplikasi berikut
Waktu peluncuran diukur sebagai total waktu untuk
harus diluncurkan dalam
menyelesaikan pemuatan aktivitas default untuk
Aplikasi
waktu yang ditentukan.
aplikasi, termasuk waktu yang diperlukan untuk memulai
Waktu Peluncuran
Browser: kurang dari 1300 md
proses Linux, memuat paket Android ke dalam
MMS/SMS: kurang dari 700 md
VM Dalvik, dan memanggil onCreate.
AlarmClock: kurang dari 650 md
Beberapa aplikasi akan
Ini diuji oleh CTS.
diluncurkan. Meluncurkan ulang
Aplikasi pertama serentak harus
Aplikasi
selesai dengan waktu kurang dari
waktu peluncuran awal.
10. 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, 29] 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 berikut:
10.1. Izin
Implementasi perangkat HARUS mendukung model izin Android seperti yang ditentukan dalam dokumentasi developer
Android [Referensi, 9]. Secara khusus, implementasi HARUS menerapkan setiap izin
yang ditentukan seperti yang dijelaskan dalam dokumentasi SDK; tidak ada izin yang boleh dihilangkan, diubah, atau diabaikan.
Implementasi DAPAT menambahkan izin tambahan, asalkan string ID izin baru tidak berada dalam namespace
android.*.
10.2. Isolasi Pengguna dan Proses
Implementasi perangkat HARUS mendukung model sandbox aplikasi Android, dengan 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, 29].

10.3. Izin Sistem File
Implementasi perangkat HARUS mendukung model izin akses file Android seperti yang ditentukan dalam
yang ditentukan dalam referensi Keamanan dan Izin [Referensi, 29].
11. Compatibility Test Suite
Implementasi perangkat HARUS lulus Compatibility Test Suite (CTS) Android [Referensi, 3] yang tersedia
dari Android Open Source Project, menggunakan software pengiriman akhir di perangkat. Selain itu,
penerapkan perangkat HARUS menggunakan implementasi referensi di hierarki Open Source Android sebanyak
mungkin, dan HARUS memastikan kompatibilitas jika terjadi ambiguitas di CTS dan untuk
penerapan ulang bagian kode sumber referensi.
CTS dirancang untuk dijalankan di perangkat yang sebenarnya. Seperti software lainnya, CTS itu sendiri mungkin berisi bug.
CTS akan diberi versi secara independen dari Definisi Kompatibilitas ini, dan beberapa revisi
CTS dapat dirilis untuk Android 1.6. Namun, rilis tersebut hanya akan memperbaiki bug perilaku dalam pengujian CTS
dan tidak akan menerapkan pengujian, perilaku, atau API baru untuk rilis platform tertentu.
12. Hubungi Kami
Anda dapat menghubungi Tim Kompatibilitas Android di compatibility@android.com untuk mendapatkan klarifikasi terkait
Definisi Kompatibilitas ini dan memberikan masukan tentang Definisi ini.

Menggunakan
EXTRA_CREATE_DESCRIPTION
dengan SHOW_OR_CREATE_CONTACT untuk
menentukan deskripsi yang tepat untuk

ditampilkan saat meminta pengguna untuk
membuat kontak baru.
Digunakan
dengan SHOW_OR_CREATE_CONTACT untuk
EXTRA_FORCE_CREATE
memaksa pembuatan kontak baru jika tidak ada
kontak yang cocok.
Ini adalah intent yang diaktifkan saat
SEARCH_SUGGESTION_CLICKED
saran penelusuran diklik.
Ini adalah intent yang diaktifkan saat
SEARCH_SUGGESTION_CREATE_CONTACT_CLICKED saran penelusuran untuk membuat
kontak diklik.
Ini adalah intent yang diaktifkan saat
SEARCH_SUGGESTION_DIAL_NUMBER_CLICKED
saran penelusuran untuk menelepon nomor
diklik.
Mengambil URI data dengan skema mailto:
SHOW_OR_CREATE_CONTACT
atau tel: sebagai input.

Lampiran B: Intent Siaran yang DiperlukanCATATAN: daftar ini bersifat sementara, dan akan
diperbarui pada masa mendatang.
Action Intent
Deskripsi
Action Siaran: Ini disiarkan satu kali, setelah sistem
ACTION_BOOT_COMPLETED
selesai melakukan booting.
Tindakan Siaran: Ini disiarkan satu kali, saat panggilan
ACTION_CALL_BUTTON
diterima.
Tindakan Siaran: "Tombol Kamera"
ACTION_CAMERA_BUTTON
ditekan.
Tindakan Siaran: Konfigurasi (orientasi, lokalitas, dll.) perangkat
ACTION_CONFIGURATION_CHANGED
saat ini telah
berubah.
ACTION_DATE_CHANGED
Tindakan Siaran: Tanggal telah berubah.
Tindakan Siaran: Menunjukkan kondisi memori rendah
ACTION_DEVICE_STORAGE_LOW
di perangkat
Tindakan Siaran: Menunjukkan kondisi memori rendah
ACTION_DEVICE_STORAGE_OK
di perangkat tidak ada lagi
Tindakan Siaran: Headset Berkabel dicolokkan atau
ACTION_HEADSET_PLUG
dicabut.
Tindakan Siaran: Metode input telah
ACTION_INPUT_METHOD_CHANGED
berubah.
Tindakan Siaran: Media eksternal telah dihapus
ACTION_MEDIA_BAD_REMOVAL
dari slot kartu SD, tetapi titik pemasangan tidak
dilepas.
Tindakan Siaran: "Tombol Media"
ACTION_MEDIA_BUTTON
ditekan.
Tindakan Siaran: Media eksternal ada, dan
diperiksa disk. Jalur ke titik pemasangan untuk
ACTION_MEDIA_CHECKING
media pemeriksaan terdapat di
kolom Intent.mData.
Tindakan Siaran: Pengguna telah menyatakan keinginan untuk
ACTION_MEDIA_EJECT
menghapus media penyimpanan eksternal.
Tindakan Siaran: Media eksternal ada dan
ACTION_MEDIA_MOUNTED
dipasang di titik pemasangannya.
Tindakan Siaran: Media eksternal ada, tetapi
menggunakan fs yang tidak kompatibel (atau kosong) Jalur ke
ACTION_MEDIA_NOFS
titik pemasangan untuk media pemeriksaan
terdapat di kolom Intent.mData.
Tindakan Siaran: Media eksternal telah
ACTION_MEDIA_REMOVED
dihapus.
Tindakan Siaran: Pemindai media telah selesai
ACTION_MEDIA_SCANNER_FINISHED
memindai direktori.
Tindakan Siaran: Minta pemindai media untuk
ACTION_MEDIA_SCANNER_SCAN_FILE
memindai file dan menambahkannya ke database media.

Tindakan Siaran: Pemindai media telah mulai
ACTION_MEDIA_SCANNER_STARTED
memindai direktori.
Tindakan Siaran: Media eksternal dilepas dari pemasangan
ACTION_MEDIA_SHARED
karena dibagikan melalui penyimpanan massal USB.
Tindakan Siaran: Media eksternal ada, tetapi
ACTION_MEDIA_UNMOUNTABLE
tidak dapat dipasang.
Tindakan Siaran: Media eksternal ada, tetapi
ACTION_MEDIA_UNMOUNTED
tidak dipasang di titik pemasangannya.
Action Siaran: Panggilan keluar akan
ACTION_NEW_OUTGOING_CALL
dilakukan.
Action Siaran: Paket aplikasi baru telah
ACTION_PACKAGE_ADDED
diinstal di perangkat.
Tindakan Siaran: Paket aplikasi yang ada
ACTION_PACKAGE_CHANGED
telah diubah (misalnya, komponen telah
diaktifkan atau dinonaktifkan.
Tindakan Siaran: Pengguna telah menghapus data
paket. Hal ini harus didahului
oleh ACTION_PACKAGE_RESTARTED, setelah itu
ACTION_PACKAGE_DATA_CLEARED
semua data persistennya akan dihapus dan siaran
ini dikirim. Perhatikan bahwa paket yang dihapus
tidak menerima siaran ini. Data berisi
nama paket.
Tindakan Siaran: Paket aplikasi yang ada
telah dihapus dari perangkat. Data
ACTION_PACKAGE_REMOVED
berisi nama paket. Paket
yang sedang diinstal tidak menerima Intent ini.
Tindakan Siaran: Versi baru paket aplikasi
ACTION_PACKAGE_REPLACED
telah diinstal, menggantikan versi
yang ada yang diinstal sebelumnya.
Tindakan Siaran: Pengguna telah memulai ulang
paket, dan semua prosesnya telah dihentikan.
Semua status runtime yang terkait dengannya (proses,
ACTION_PACKAGE_RESTARTED
alarm, notifikasi, dll.) harus dihapus. Perhatikan
bahwa paket yang dimulai ulang tidak menerima siaran
ini. Data berisi nama paket
.
Tindakan Siaran: Beberapa penyedia konten memiliki
bagian namespace tempat mereka memublikasikan peristiwa atau item
ACTION_PROVIDER_CHANGED
baru yang mungkin sangat
diminati pengguna.
ACTION_SCREEN_OFF
Action Siaran: Dikirim setelah layar dinonaktifkan.
ACTION_SCREEN_ON
Action Siaran: Dikirim setelah layar diaktifkan.
Tindakan Siaran: ID pengguna telah dihapus
ACTION_UID_REMOVED
dari sistem.
Tindakan Siaran: Perangkat telah memasuki mode Penyimpanan Massal
ACTION_UMS_CONNECTED
USB.

Tindakan Siaran: Perangkat telah keluar dari mode Penyimpanan Massal
ACTION_UMS_DISCONNECTED
USB.
Action Siaran: Dikirim saat pengguna ada
ACTION_USER_PRESENT
setelah perangkat aktif (misalnya saat pelindung kunci
tidak ada).
Tindakan Siaran: Wallpaper sistem saat ini
ACTION_WALLPAPER_CHANGED
telah berubah.
ACTION_TIME_CHANGED
Tindakan Siaran: Waktu telah ditetapkan.
ACTION_TIME_TICK
Tindakan Siaran: Waktu saat ini telah berubah.
ACTION_TIMEZONE_CHANGED
Tindakan Siaran: Zona waktu telah berubah.
Tindakan Siaran: Status pengisian daya, atau level
ACTION_BATTERY_CHANGED
baterai telah berubah.
Tindakan Siaran: Menunjukkan kondisi baterai lemah
ACTION_BATTERY_LOW
di perangkat. Siaran ini sesuai dengan dialog sistem
"Peringatan baterai lemah".
Tindakan Siaran: Menunjukkan bahwa baterai sekarang sudah baik
setelah lemah. Ini akan dikirim
ACTION_BATTERY_OKAY
setelah ACTION_BATTERY_LOW setelah baterai
kembali ke status baik.
Status Jaringan
Tindakan Intent
Deskripsi
Tindakan intent siaran yang menunjukkan bahwa
NETWORK_STATE_CHANGED_ACTION
status konektivitas Wi-Fi telah berubah.
Tindakan intent siaran yang menunjukkan bahwa
RSSI_CHANGED_ACTION
RSSI (kekuatan sinyal) telah berubah.
Tindakan intent siaran yang menunjukkan bahwa koneksi
SUPPLICANT_STATE_CHANGED_ACTION
ke pemohon telah
dibuat atau hilang.
Tindakan intent siaran yang menunjukkan bahwa Wi-Fi
WIFI_STATE_CHANGED_ACTION
telah diaktifkan, dinonaktifkan, mengaktifkan,
menonaktifkan, atau tidak diketahui.
ID jaringan dari jaringan yang dikonfigurasi
NETWORK_IDS_CHANGED_ACTION
mungkin telah berubah.
Tindakan intent siaran yang menunjukkan bahwa setelan
ACTION_BACKGROUND_DATA_SETTING_CHANGED untuk penggunaan data latar belakang telah
mengubah nilai.
Intent siaran yang menunjukkan bahwa perubahan pada konektivitas jaringan
CONNECTIVITY_ACTION
telah terjadi.
Tindakan Siaran: Pengguna telah mengalihkan ponsel
ACTION_AIRPLANE_MODE_CHANGED
ke dalam atau keluar dari Mode Pesawat.

Lampiran C: Pertimbangan di Masa Mendatang Lampiran ini menjelaskan bagian tertentu dari Definisi Kompatibilitas Android
1.6 ini, dan dalam beberapa kasus membahas perubahan yang diperkirakan atau direncanakan yang ditujukan untuk
versi platform Android mendatang. Lampiran ini hanya untuk tujuan informasi dan perencanaan, dan
bukan bagian dari Definisi Kompatibilitas untuk Android 1.6.
1. Perangkat Non-telepon
Android 1.6 ditujukan secara eksklusif untuk telepon; fungsi telefoni tidak bersifat opsional. Versi mendatang
platform Android diharapkan akan membuat telepon menjadi opsional (sehingga memungkinkan perangkat Android
non-ponsel), tetapi hanya ponsel yang kompatibel dengan Android 1.6.
2. Kompatibilitas Bluetooth
Rilis Android 1.6 tidak mendukung Bluetooth API, sehingga dari perspektif kompatibilitas
Bluetooth tidak memberlakukan pertimbangan apa pun untuk versi platform ini. Namun, versi Android
mendatang akan memperkenalkan Bluetooth API. Pada saat itu, dukungan Bluetooth akan menjadi wajib untuk kompatibilitas
.
Oleh karena itu, sebaiknya perangkat Android 1.6 menyertakan Bluetooth, sehingga
kompatibel dengan versi Android mendatang yang memerlukan Bluetooth.
3. Komponen Hardware yang Diperlukan
Semua komponen hardware di Bagian 8 (termasuk WiFi, magnetometer/kompas, akselerometer, dll.)
diperlukan dan tidak boleh dihilangkan. Versi Android mendatang diharapkan akan membuat beberapa (tetapi tidak semua)
komponen ini bersifat opsional, bersama dengan alat yang sesuai bagi developer pihak ketiga untuk menangani
perubahan ini.
4. Contoh Aplikasi
Dokumen Definisi Kompatibilitas untuk versi Android mendatang akan menyertakan daftar aplikasi yang lebih luas dan
representatif daripada yang tercantum di Bagian 4, di atas. Untuk Android 1.6, aplikasi
yang tercantum di Bagian 4 harus diuji.
5. Layar Sentuh
Versi Compatibility Definition mendatang mungkin mengizinkan atau tidak mengizinkan perangkat untuk menghilangkan layar sentuh.
Namun, saat ini sebagian besar implementasi framework Android mengasumsikan adanya
layar sentuh; menghilangkan layar sentuh akan merusak semua aplikasi Android pihak ketiga saat ini secara substansial,
sehingga di Android 1.6, layar sentuh diperlukan untuk kompatibilitas.

6. Performa
Versi CTS mendatang juga akan mengukur penggunaan CPU dan performa komponen
implementasi berikut:
• Grafis 2D
• Grafis 3D
• Putar video
• Putar audio
• Putar A2DP Bluetooth

Definisi Kompatibilitas Android 1.6

Kerangka Dokumen