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

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

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

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

Perhatikan bahwa Definisi Kompatibilitas ini dikeluarkan untuk sesuai dengan update 2.3.3 ke Android, yaitu API level 10. Definisi ini tidak berlaku lagi dan menggantikan Definisi Kompatibilitas untuk versi Android 2.3 sebelum 2.3.3. (Artinya, versi 2.3.1 dan 2.3.2 tidak digunakan lagi.) Perangkat yang kompatibel dengan Android mendatang yang menjalankan Android 2.3 HARUS dikirim dengan versi 2.3.3 atau yang lebih baru.

2. Referensi

Level Persyaratan IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt

Ringkasan Program Kompatibilitas Android: http://source.android.com/docs/compatibility/index.html

Project Open Source Android: http://source.android.com/

Definisi dan dokumentasi API: http://developer.android.com/reference/packages.html

Referensi Izin Android: http://developer.android.com/reference/android/Manifest.permission.html

Referensi android.os.Build: http://developer.android.com/reference/android/os/Build.html

String versi yang diizinkan Android 2.3: http://source.android.com/docs/compatibility/2.3/versions.html

Class android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

Kemampuan offline HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

Tag video HTML5: http://dev.w3.org/html5/spec/Overview.html#video

Geolocation API HTML5/W3C: http://www.w3.org/TR/geolocation-API/

API webdatabase HTML5/W3C: http://www.w3.org/TR/webdatabase/

HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/

Spesifikasi Virtual Machine Dalvik: tersedia dalam kode sumber Android, di dalvik/docs

AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

Notifikasi: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

Resource Aplikasi: http://code.google.com/android/reference/available-resources.html

Panduan gaya ikon Status Bar: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure

Pengelola Penelusuran: http://developer.android.com/reference/android/app/SearchManager.html

Toast: http://developer.android.com/reference/android/widget/Toast.html

Wallpaper Animasi: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

Dokumentasi alat referensi (untuk adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html

Deskripsi file apk Android: http://developer.android.com/guide/topics/fundamentals.html

File manifes: http://developer.android.com/guide/topics/manifest/manifest-intro.html

Alat pengujian Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey

Daftar Fitur Hardware Android: http://developer.android.com/reference/android/content/pm/PackageManager.html

Mendukung Beberapa Layar: http://developer.android.com/guide/practices/screens_support.html

android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

Ruang koordinat sensor: http://developer.android.com/reference/android/hardware/SensorEvent.html

Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

Protokol Push NDEF: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

API orientasi kamera: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

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

Referensi Keamanan dan Izin Android: http://developer.android.com/guide/topics/security/security.html

Aplikasi untuk Android: http://code.google.com/p/apps-for-android

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

3. Software

Platform Android mencakup sekumpulan API terkelola, sekumpulan API native, dan kumpulan API yang disebut "soft" seperti sistem Intent 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 2.3 SDK [Referensi, 4].

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

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

3.2. Kompatibilitas Soft API

Selain API terkelola dari Bagian 3.1, Android juga menyertakan API "soft" khusus runtime yang signifikan, dalam bentuk hal-hal seperti Intent, izin, dan aspek serupa dari aplikasi Android yang tidak dapat diterapkan pada waktu kompilasi aplikasi. Bagian ini menjelaskan API "soft" dan perilaku sistem yang diperlukan untuk kompatibilitas dengan Android 2.3. Implementasi perangkat HARUS memenuhi semua persyaratan yang disajikan di bagian ini.

3.2.1. Izin

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

3.2.2. Parameter Build

Android API menyertakan sejumlah konstanta pada class android.os.Build [Resources, 6] yang dimaksudkan untuk mendeskripsikan perangkat saat ini. Untuk memberikan nilai yang konsisten dan bermakna di seluruh implementasi perangkat, tabel di bawah menyertakan batasan tambahan pada format nilai ini yang HARUS sesuai dengan implementasi perangkat.

Parameter	Komentar
android.os.Build.VERSION.RELEASE	Versi sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Kolom ini HARUS memiliki salah satu nilai string yang ditentukan di [Referensi, 7].
android.os.Build.VERSION.SDK	Versi sistem Android yang sedang dieksekusi, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 2.3, kolom ini HARUS memiliki nilai bilangan bulat 9.
android.os.Build.VERSION.INCREMENTAL	Nilai yang dipilih oleh implementator perangkat yang menetapkan build tertentu sistem Android yang sedang dieksekusi, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build yang berbeda yang tersedia bagi pengguna akhir. Penggunaan umum kolom ini adalah untuk menunjukkan nomor build atau ID perubahan kontrol sumber yang digunakan untuk membuat build. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
android.os.Build.BOARD	Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi hardware internal tertentu yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan kolom ini adalah untuk menunjukkan revisi spesifik dari board yang memberi daya pada perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.BRAND	Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi nama perusahaan, organisasi, individu, dll. yang memproduksi perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan kolom ini adalah untuk menunjukkan OEM dan/atau operator yang menjual perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.DEVICE	Nilai yang dipilih oleh implementator perangkat yang mengidentifikasi konfigurasi atau revisi tertentu dari bodi (terkadang disebut "desain industri") perangkat. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.FINGERPRINT	String yang mengidentifikasi build ini secara unik. File ini HARUS dapat dibaca manusia dengan cukup baik. Template ini HARUS mengikuti template ini: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Misalnya: `acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys` Sidik jari TIDAK BOLEH menyertakan karakter spasi kosong. Jika kolom lain yang disertakan dalam template di atas memiliki karakter spasi kosong, kolom tersebut HARUS diganti dalam sidik jari build dengan karakter lain, seperti karakter garis bawah ("_"). Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit.
android.os.Build.HOST	String yang secara unik mengidentifikasi host tempat build dibuat, dalam format yang dapat dibaca manusia. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
android.os.Build.ID	ID yang dipilih oleh implementator perangkat untuk merujuk ke rilis tertentu, dalam format yang dapat dibaca manusia. Kolom ini dapat sama dengan android.os.Build.VERSION.INCREMENTAL, tetapi HARUS berupa nilai yang cukup bermakna bagi pengguna akhir untuk membedakan build software. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.MODEL	Nilai yang dipilih oleh implementator perangkat yang berisi nama perangkat seperti yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama yang digunakan untuk memasarkan dan menjual perangkat kepada pengguna akhir. Tidak ada persyaratan pada format khusus kolom ini, kecuali bahwa kolom ini TIDAK BOLEH null atau string kosong ("").
android.os.Build.PRODUCT	Nilai yang dipilih oleh implementator perangkat yang berisi nama pengembangan atau nama kode perangkat. HARUS dapat dibaca manusia, tetapi tidak selalu dimaksudkan untuk dilihat oleh pengguna akhir. Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.TAGS	Daftar tag yang dipisahkan koma yang dipilih oleh implementer perangkat yang lebih lanjut membedakan build. Misalnya, "unsigned,debug". Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.TIME	Nilai yang mewakili stempel waktu saat build terjadi.
android.os.Build.TYPE	Nilai yang dipilih oleh implementator perangkat yang menentukan konfigurasi runtime build. Kolom ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android standar: "user", "userdebug", atau "eng". Nilai kolom ini HARUS dapat dienkode sebagai ASCII 7-bit dan cocok dengan ekspresi reguler `"^[a-zA-Z0-9.,_-]+$"`.
android.os.Build.USER	Nama atau ID pengguna (atau pengguna otomatis) yang membuat build. Tidak ada persyaratan pada format khusus kolom ini, kecuali kolom ini TIDAK BOLEH null atau string kosong ("").

3.2.3. Kompatibilitas Intent

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", dimaksudkan bahwa implementator perangkat HARUS menyediakan Aktivitas atau Layanan Android yang menentukan filter Intent yang cocok dan mengikat serta menerapkan perilaku yang benar untuk setiap pola Intent yang ditentukan.

3.2.3.1. Intent Aplikasi Inti

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

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

Aplikasi berikut dianggap sebagai aplikasi sistem Android inti:

Jam Meja
Browser
Kalender
Kalkulator
Kontak
Email
Galeri
GlobalSearch
Peluncur
Musik
Setelan

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

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

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

3.2.3.2. Penggantian Intent

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

3.2.3.3. Namespace Intent

Implementator perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola Intent baru atau Intent Siaran menggunakan ACTION, KATEGORI, atau string kunci lainnya di namespace android.*. Implementer perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mematuhi pola Intent atau Intent Siaran baru menggunakan ACTION, CATEGORY, atau string kunci lainnya di ruang paket milik organisasi lain. Implementator perangkat TIDAK BOLEH mengubah atau memperluas salah satu pola Intent yang digunakan oleh aplikasi inti yang tercantum di Bagian 3.2.3.1.

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

3.2.3.4. Intent Siaran

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

3.3. Kompatibilitas API Native

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

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

HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode native, menggunakan semantik Java Native Interface (JNI) standar.
HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk ABI) dengan setiap library yang diperlukan dalam daftar di bawah
HARUS melaporkan Antarmuka Biner Aplikasi (ABI) native yang didukung oleh perangkat secara akurat, melalui android.os.Build.CPU_ABI API
HARUS hanya melaporkan ABI yang didokumentasikan dalam versi terbaru Android NDK, dalam file docs/CPU-ARCH-ABIS.txt
HARUS dibuat menggunakan kode sumber dan file header yang tersedia di project open source Android upstream

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

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

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

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

3.4. Kompatibilitas Web

Banyak developer dan aplikasi mengandalkan perilaku class android.webkit.WebView [Resources, 8] untuk antarmuka pengguna mereka, sehingga implementasi WebView harus kompatibel di seluruh implementasi Android. Demikian pula, browser web lengkap dan modern adalah inti dari pengalaman pengguna Android. Implementasi perangkat HARUS menyertakan versi android.webkit.WebView yang konsisten dengan software Android upstream, dan HARUS menyertakan browser modern yang kompatibel dengan HTML5, seperti yang dijelaskan di bawah.

3.4.1. Kompatibilitas WebView

Implementasi Open Source Android menggunakan mesin rendering WebKit untuk menerapkan android.webkit.WebView. Karena tidak memungkinkan untuk mengembangkan rangkaian pengujian yang komprehensif untuk sistem rendering web, implementer perangkat HARUS menggunakan build upstream WebKit tertentu dalam implementasi WebView. Khususnya:

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

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

cache aplikasi/operasi offline [Referensi, 10]
tag <video> [Referensi, 11]
geolocation [Referensi, 12]

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

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

3.4.2. Kompatibilitas Browser

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

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

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

cache aplikasi/operasi offline [Referensi, 10]
tag <video> [Referensi, 11]
geolocation [Referensi, 12]

3.5. Kompatibilitas Perilaku API

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

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

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

3.6. Namespace API

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

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

Modifikasi yang dilarang mencakup:

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

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

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

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

Perhatikan bahwa batasan di atas sesuai dengan konvensi standar untuk memberi nama API dalam bahasa pemrograman Java; bagian ini hanya bertujuan untuk memperkuat konvensi tersebut dan membuatnya mengikat melalui penyertaan dalam definisi kompatibilitas ini.

3.7. Kompatibilitas Virtual Machine

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

Implementasi perangkat dengan layar yang diklasifikasikan sebagai kepadatan sedang atau rendah HARUS mengonfigurasi Dalvik untuk mengalokasikan memori minimal 16 MB ke setiap aplikasi. Implementasi perangkat dengan layar yang diklasifikasikan sebagai kepadatan tinggi atau kepadatan ekstra tinggi HARUS mengonfigurasi Dalvik untuk mengalokasikan memori minimal 24 MB ke setiap aplikasi. Perhatikan bahwa penerapan perangkat DAPAT mengalokasikan lebih banyak memori daripada angka ini.

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, 16]. Rilis referensi Open Source Android menyertakan aplikasi Peluncur yang menyertakan elemen antarmuka pengguna yang memungkinkan pengguna menambahkan, melihat, dan menghapus AppWidget dari layar utama.

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

3.8.2. Notifikasi

Android menyertakan API yang memungkinkan developer memberi tahu pengguna tentang peristiwa penting [Referensi, 17]. Implementator perangkat HARUS memberikan dukungan untuk setiap class notifikasi yang ditentukan; khususnya: suara, getaran, lampu, dan status bar.

Selain itu, implementasi HARUS merender semua resource (ikon, file suara, dll.) dengan benar yang disediakan di API [Referensi, 18], atau di panduan gaya ikon Status Bar [Referensi, 19]. Implementer perangkat DAPAT memberikan pengalaman pengguna alternatif untuk notifikasi selain yang disediakan oleh implementasi Open Source Android referensi; namun, sistem notifikasi alternatif tersebut HARUS mendukung resource notifikasi yang ada, seperti di atas.

3.8.3. Telusuri

Android menyertakan API [Referensi, 20] 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. API Android memungkinkan developer menggunakan kembali antarmuka ini untuk menyediakan penelusuran dalam aplikasi mereka sendiri, dan memungkinkan developer menyediakan hasil ke antarmuka pengguna penelusuran global umum.

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

Implementasi perangkat DAPAT mengirimkan antarmuka pengguna penelusuran alternatif, tetapi HARUS menyertakan tombol penelusuran khusus yang 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 API "Toast" (ditentukan dalam [Referensi, 21]) untuk menampilkan string non-modal singkat kepada pengguna akhir, yang menghilang setelah periode waktu singkat. Implementasi perangkat HARUS menampilkan Toast dari aplikasi ke pengguna akhir dengan cara yang sangat terlihat.

3.8.5. Wallpaper Animasi

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

Hardware dianggap mampu menjalankan wallpaper hidup dengan andal jika dapat menjalankan semua wallpaper hidup, tanpa batasan fungsi, pada framerate yang wajar tanpa dampak buruk pada aplikasi lain. Jika batasan pada hardware menyebabkan wallpaper dan/atau aplikasi mengalami error, malfungsi, menggunakan daya CPU atau baterai secara berlebihan, atau berjalan dengan kecepatan frame yang tidak dapat diterima, hardware dianggap tidak dapat menjalankan wallpaper live. Misalnya, beberapa wallpaper hidup dapat menggunakan konteks Open GL 1.0 atau 2.0 untuk merender kontennya. Wallpaper hidup tidak akan berjalan dengan andal di hardware yang tidak mendukung beberapa konteks OpenGL karena penggunaan wallpaper hidup dari konteks OpenGL dapat bertentangan dengan aplikasi lain yang juga menggunakan konteks OpenGL.

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

4. Kompatibilitas Pengemasan Aplikasi

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

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

5. Kompatibilitas Multimedia

Implementasi perangkat HARUS menerapkan semua API multimedia sepenuhnya. Implementasi perangkat HARUS menyertakan dukungan untuk semua codec multimedia yang dijelaskan di bawah, dan HARUS memenuhi panduan pemrosesan suara yang dijelaskan di bawah. Implementasi perangkat HARUS menyertakan minimal satu bentuk output audio, seperti speaker, jack headphone, koneksi speaker eksternal, dll.

5.1. Codec Media

Implementasi perangkat HARUS mendukung codec multimedia seperti yang dijelaskan di bagian berikut. Semua codec ini disediakan sebagai implementasi software dalam implementasi Android yang diinginkan dari Project Open-Source Android.

Perlu diketahui 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.

Tabel di bawah tidak mencantumkan persyaratan kecepatan bit tertentu untuk sebagian besar codec video. Alasannya adalah dalam praktiknya, hardware perangkat saat ini tidak selalu mendukung kecepatan bit yang dipetakan persis dengan kecepatan bit yang diperlukan yang ditentukan oleh standar yang relevan. Sebagai gantinya, penerapan perangkat HARUS mendukung kecepatan bit tertinggi yang praktis pada hardware, hingga batas yang ditentukan oleh spesifikasi.

5.1.1. Decoder Media

Implementasi perangkat HARUS menyertakan implementasi dekoder untuk setiap codec dan format yang dijelaskan dalam tabel di bawah. Perhatikan bahwa dekoder untuk setiap jenis media ini disediakan oleh Project Open-Source Android upstream.

Audio
	Nama	Detail	Format File/Penampung
	AAC LC/LTP	Konten Mono/Stereo dalam kombinasi kecepatan bit standar apa pun hingga 160 kbps dan frekuensi sampling antara 8 hingga 48 kHz	3GPP (.3gp) dan MPEG-4 (.mp4, .m4a). Tidak ada dukungan untuk AAC mentah (.aac)
	HE-AACv1 (AAC+)
	HE-AACv2 (AAC+ ditingkatkan)
	AMR-NB	4,75 hingga 12,2 kbps dengan sampel @ 8 kHz	3GPP (.3gp)
	AMR-WB	9 frekuensi dari 6,60 kbit/dtk hingga 23,85 kbit/dtk dengan sampel @ 16 kHz	3GPP (.3gp)
	MP3	Mono/Stereo 8-320 Kbps konstan (CBR) atau kecepatan bit variabel (VBR)	MP3 (.mp3)
	MIDI	MIDI Jenis 0 dan 1. DLS Versi 1 dan 2. XMF dan Mobile XMF. Dukungan untuk format nada dering RTTTL/RTX, OTA, dan iMelody	Jenis 0 dan 1 (.mid, .xmf, .mxmf). Juga RTTTL/RTX (.rtttl, .rtx), OTA (.ota), dan iMelody (.imy)
	Ogg Vorbis		Ogg (.ogg)
	PCM	PCM linear 8- dan 16-bit (frekuensi hingga batas hardware)	WAVE (.wav)
Gambar
	JPEG	dasar+progresif
	GIF
	PNG
	BMP
Video
	H.263		File 3GPP (.3gp)
	H.264		File 3GPP (.3gp) dan MPEG-4 (.mp4)
	Profil Sederhana MPEG4		File 3GPP (.3gp)

5.1.2. Encoder Media

Implementasi perangkat HARUS menyertakan encoder untuk sebanyak mungkin format media yang tercantum di Bagian 5.1.1. Namun, beberapa encoder tidak cocok untuk perangkat yang tidak memiliki hardware opsional tertentu; misalnya, encoder untuk video H.263 tidak cocok, jika perangkat tidak memiliki kamera. Oleh karena itu, implementasi perangkat HARUS mengimplementasikan encoder media sesuai dengan kondisi yang dijelaskan dalam tabel di bawah.

Lihat Bagian 7 untuk mengetahui detail tentang kondisi saat hardware dapat dihilangkan oleh implementasi perangkat.

Audio
	Nama	Detail	Format File/Penampung	Kondisi
	AMR-NB	4,75 hingga 12,2 kbps dengan sampel @ 8 kHz	3GPP (.3gp)	Implementasi perangkat yang menyertakan hardware mikrofon dan menentukan `android.hardware.microphone` HARUS menyertakan encoder untuk format audio ini.
	AMR-WB	9 frekuensi dari 6,60 kbit/dtk hingga 23,85 kbit/dtk dengan sampel @ 16 kHz	3GPP (.3gp)
	AAC LC/LTP	Konten Mono/Stereo dalam kombinasi kecepatan bit standar apa pun hingga 160 kbps dan frekuensi sampling antara 8 hingga 48 kHz	3GPP (.3gp) dan MPEG-4 (.mp4, .m4a).
Gambar	JPEG	dasar+progresif		Semua implementasi perangkat HARUS menyertakan encoder untuk format gambar ini, karena Android 2.3 menyertakan API yang dapat digunakan aplikasi untuk membuat file jenis ini secara terprogram.
Gambar	PNG
Video	H.263		File 3GPP (.3gp)	Implementasi perangkat yang menyertakan hardware kamera dan menentukan `android.hardware.camera` atau `android.hardware.camera.front` HARUS menyertakan encoder untuk format video ini.

Selain encoder yang tercantum di atas, implementasi perangkat HARUS menyertakan encoder H.264. Perhatikan bahwa Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubah persyaratan ini menjadi "HARUS". Artinya, encoding H.264 bersifat opsional di Android 2.3, tetapi akan diperlukan oleh versi mendatang. Perangkat lama dan baru yang menjalankan Android 2.3 sangat disarankan untuk memenuhi persyaratan ini di Android 2.3, atau perangkat tersebut tidak akan dapat mencapai kompatibilitas Android saat diupgrade ke versi mendatang.

5.2. Perekaman Audio

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

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

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

5.3. Latensi Audio

Latensi audio secara luas didefinisikan sebagai interval antara saat aplikasi meminta operasi perekaman atau pemutaran audio, dan saat implementasi perangkat benar-benar memulai operasi. Banyak class aplikasi mengandalkan latensi yang 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 tentang kondisi saat hardware mikrofon dapat dihilangkan oleh implementasi perangkat.

Untuk tujuan bagian ini:

"latensi output dingin" ditentukan sebagai interval antara saat aplikasi meminta pemutaran audio dan saat suara mulai diputar, saat sistem audio tidak ada aktivitas dan dimatikan sebelum permintaan
"latensi output hangat" ditentukan 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, senyap)
"latensi output berkelanjutan" ditentukan sebagai interval antara saat aplikasi mengeluarkan sampel untuk diputar dan saat speaker secara fisik memutar suara yang sesuai, saat perangkat sedang memutar audio
"latensi input dingin" ditentukan sebagai interval antara saat aplikasi meminta perekaman audio dan saat sampel pertama dikirim ke aplikasi melalui callback-nya, saat sistem audio dan mikrofon tidak ada aktivitas dan dimatikan sebelum permintaan
"latensi input berkelanjutan" ditentukan saat suara sekitar terjadi dan saat sampel yang sesuai dengan suara tersebut dikirim ke aplikasi perekaman melalui callback-nya, saat perangkat dalam mode perekaman

Dengan menggunakan definisi di atas, implementasi perangkat HARUS menampilkan setiap properti ini:

latensi output cold 100 milidetik atau kurang
latensi output pemanasan 10 milidetik atau kurang
latensi output kontinu sebesar 45 milidetik atau kurang
latensi input cold 100 milidetik atau kurang
latensi input berkelanjutan sebesar 50 milidetik atau kurang

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. [Referensi, 27] Sebaliknya, jika implementasi perangkat tidak memenuhi persyaratan ini, perangkat TIDAK BOLEH melaporkan dukungan untuk audio latensi rendah.

6. Kompatibilitas Alat Developer

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

Android Debug Bridge (dikenal sebagai adb) [Referensi, 23]
Implementasi perangkat HARUS mendukung semua fungsi adb seperti yang didokumentasikan di 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 (dikenal sebagai ddms) [Resources, 23]
Implementasi perangkat HARUS mendukung semua fitur ddms seperti yang didokumentasikan dalam Android SDK. Karena ddms menggunakan adb, dukungan untuk ddms HARUS tidak aktif secara default, tetapi HARUS didukung setiap kali pengguna mengaktifkan Android Debug Bridge, seperti di atas.
Monkey [Referensi, 26]
Implementasi perangkat HARUS menyertakan framework Monkey, dan membuatnya tersedia untuk digunakan aplikasi.

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

7. Kompatibilitas Hardware

Android dimaksudkan untuk memungkinkan pengimplementasi perangkat membuat konfigurasi dan faktor bentuk yang inovatif. Pada saat yang sama, developer Android menulis aplikasi inovatif yang mengandalkan berbagai hardware dan fitur yang tersedia melalui Android API. Persyaratan di bagian ini menyeimbangkan inovasi yang tersedia untuk pengimplementasi perangkat, dan kebutuhan developer untuk memastikan aplikasi mereka hanya tersedia untuk perangkat tempat aplikasi tersebut akan berjalan dengan benar.

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

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

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

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

7.1. Layar dan Grafis

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

7.1.1. Konfigurasi Layar

Implementasi perangkat DAPAT menggunakan layar dengan dimensi piksel apa pun, asalkan memenuhi persyaratan berikut:

layar HARUS berukuran diagonal fisik minimal 2,5 inci
kepadatan HARUS minimal 100 dpi
rasio aspek HARUS antara 1,333 (4:3) dan 1,779 (16:9)
teknologi layar yang digunakan terdiri dari piksel persegi

Implementasi perangkat dengan layar yang memenuhi persyaratan di atas dianggap kompatibel, dan tidak diperlukan tindakan tambahan. Implementasi framework Android secara otomatis menghitung karakteristik tampilan seperti bucket ukuran layar dan bucket kepadatan. Dalam sebagian besar kasus, keputusan framework adalah keputusan yang benar. Jika komputasi framework default digunakan, Anda tidak perlu melakukan tindakan tambahan. Implementer perangkat yang ingin mengubah setelan default, atau menggunakan layar yang tidak memenuhi persyaratan di atas HARUS menghubungi Tim Kompatibilitas Android untuk mendapatkan panduan, seperti yang disediakan di Bagian 12.

Unit yang digunakan oleh persyaratan di atas ditentukan sebagai berikut:

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

Implementasi perangkat HARUS hanya menggunakan layar dengan satu konfigurasi statis. Artinya, implementasi perangkat TIDAK BOLEH mengaktifkan beberapa konfigurasi layar. Misalnya, karena televisi biasa mendukung beberapa resolusi seperti 1080p, 720p, dan sebagainya, konfigurasi ini tidak kompatibel dengan Android 2.3. (Namun, dukungan untuk konfigurasi tersebut sedang diselidiki dan direncanakan untuk versi Android mendatang.)

7.1.2. Metrik Display

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

7.1.3. Dukungan Layar yang Dideklarasikan

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

7.1.4. Orientasi Layar

Perangkat yang kompatibel HARUS mendukung orientasi dinamis oleh aplikasi untuk orientasi layar potret atau lanskap. Artinya, perangkat harus mengikuti permintaan aplikasi untuk orientasi layar tertentu. Implementasi perangkat DAPAT memilih orientasi potret atau lanskap sebagai default. Perangkat yang tidak dapat diputar secara fisik DAPAT memenuhi persyaratan ini dengan aplikasi "letterboxing" yang meminta mode potret, hanya menggunakan sebagian layar yang tersedia.

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.

7.1.5. Akselerasi Grafis 3D

Implementasi perangkat HARUS mendukung OpenGL ES 1.0, seperti yang diperlukan oleh Android 2.3 API. Untuk perangkat yang tidak memiliki hardware akselerasi 3D, implementasi software OpenGL ES 1.0 disediakan oleh Project Open-Source Android upstream. Implementasi perangkat HARUS mendukung OpenGL ES 2.0.

Implementasi DAPAT menghilangkan dukungan Open GL ES 2.0; tetapi jika dukungan dihilangkan, implementasi perangkat TIDAK BOLEH melaporkan sebagai mendukung OpenGL ES 2.0. Secara khusus, jika implementasi perangkat tidak memiliki dukungan OpenGL ES 2.0:

API terkelola (seperti melalui metode GLES10.getString()) TIDAK BOLEH melaporkan dukungan untuk OpenGL ES 2.0
API OpenGL C/C++ native (yaitu, yang tersedia untuk aplikasi melalui libGLES_v1CM.so, libGLES_v2.so, atau libEGL.so) TIDAK BOLEH melaporkan dukungan untuk OpenGL ES 2.0.

Sebaliknya, jika implementasi perangkat mendukung OpenGL ES 2.0, implementasi tersebut HARUS melaporkan dukungan tersebut secara akurat melalui rute yang baru saja tercantum.

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

7.2. Perangkat Masukan

Android 2.3 mendukung sejumlah modalitas untuk input pengguna. Implementasi perangkat HARUS mendukung perangkat input pengguna seperti yang disediakan di bagian ini.

7.2.1. Keyboard

Implementasi perangkat:

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

Implementasi perangkat:

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

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 menyembunyikan atau mengganggu area tampilan aplikasi yang tersedia.

Implementator perangkat JUGA HARUS menyediakan kunci penelusuran khusus. Implementator perangkat JUGA DAPAT menyediakan tombol kirim dan akhiri untuk panggilan telepon.

7.2.4. Input layar sentuh

Implementasi perangkat:

HARUS memiliki layar sentuh
MUNGKIN memiliki layar sentuh kapasitif atau resistif
HARUS melaporkan nilai android.content.res.Configuration [Resources, 30] yang mencerminkan jenis layar sentuh tertentu di perangkat
HARUS mendukung pointer yang dilacak sepenuhnya secara independen, jika layar sentuh mendukung beberapa pointer

7.3. Sensor

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

HARUS melaporkan keberadaan atau ketiadaan sensor secara akurat sesuai class android.content.pm.PackageManager. [Referensi, 27]
HARUS menampilkan daftar sensor yang didukung secara akurat melalui SensorManager.getSensorList() dan metode serupa
HARUS berperilaku wajar untuk semua API sensor lainnya (misalnya, dengan menampilkan true atau false sebagaimana mestinya saat aplikasi mencoba mendaftarkan pemroses, tidak memanggil pemroses sensor saat sensor yang sesuai tidak ada; dll.)

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

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

API Android 2.3 memperkenalkan konsep sensor "streaming", yang menampilkan data secara terus-menerus, bukan hanya saat data berubah. Implementasi perangkat HARUS terus memberikan sampel data berkala untuk API apa pun yang ditunjukkan oleh dokumentasi Android 2.3 SDK sebagai sensor streaming.

7.3.1. Akselerometer

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

HARUS dapat mengirimkan peristiwa pada 50 Hz atau lebih
HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan di Android API (lihat [Referensi, 31])
HARUS dapat mengukur dari jatuh bebas hingga dua kali gravitasi (2g) atau lebih pada vektor tiga dimensi apa pun
HARUS memiliki akurasi 8-bit atau lebih
HARUS memiliki deviasi standar tidak lebih dari 0,05 m/s^2

7.3.2. Magnetometer

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

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

7.3.3. GPS

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

7.3.4. Giroskop

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

HARUS dapat mengukur perubahan orientasi hingga 5, 5*Pi radian/detik (yaitu,sekitar 1.000 derajat per detik)
HARUS dapat mengirimkan peristiwa pada 100 Hz atau lebih tinggi
HARUS memiliki akurasi 8-bit atau lebih

7.3.5. Barometer

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

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

7.3.7. Thermometer

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

7.3.7. Fotometer

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

7.3.8. Sensor Kedekatan

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

7.4. Konektivitas Data

Konektivitas jaringan dan akses ke Internet adalah fitur penting Android. Sementara itu, interaksi perangkat ke perangkat menambahkan nilai yang signifikan ke perangkat dan aplikasi Android. Penerapan perangkat HARUS memenuhi persyaratan konektivitas data di bagian ini.

7.4.1. Telepon

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

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

7.4.2. IEEE 802.11 (Wi-Fi)

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

7.4.3. Bluetooth

Implementasi perangkat HARUS menyertakan transceiver Bluetooth. Implementasi perangkat yang menyertakan transceiver Bluetooth HARUS mengaktifkan Bluetooth API berbasis RFCOMM seperti yang dijelaskan dalam dokumentasi SDK [Referensi, 32]. Implementasi perangkat HARUS menerapkan profil Bluetooth yang relevan, seperti A2DP, AVRCP, OBEX, dll. sesuai dengan perangkat.

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

7.4.4. Komunikasi Nirkabel Jarak Dekat

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

HARUS melaporkan fitur android.hardware.nfc dari metode android.content.pm.PackageManager.hasSystemFeature(). [Referensi, 27]

HARUS dapat membaca dan menulis pesan NDEF melalui standar NFC berikut:

HARUS dapat bertindak sebagai pembaca/penulis Forum NFC (sebagaimana ditentukan oleh spesifikasi teknis Forum NFC NFCForum-TS-DigitalProtocol-1.0) melalui standar NFC berikut:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS 6319-4)
- NfcV (ISO 15693)
- IsoDep (ISO 14443-4)
- Jenis Tag NFC Forum 1, 2, 3, 4 (ditentukan oleh NFC Forum)
HARUS dapat mengirimkan dan menerima data melalui standar dan protokol peer-to-peer berikut:
- ISO 18092
- LLCP 1.0 (ditentukan oleh NFC Forum)
- SDP 1.0 (ditentukan oleh NFC Forum)
- NDEF Push Protocol [Referensi, 33]
HARUS memindai semua teknologi yang didukung saat dalam mode penemuan NFC.
HARUS dalam mode penemuan NFC saat perangkat aktif dengan layar aktif.

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

Selain itu, implementasi perangkat HARUS mendukung teknologi MIFARE berikut yang di-deploy secara luas.

MIFARE Classic (NXP MF1S503x [Referensi, 34], MF1S703x [Referensi, 35])
MIFARE Ultralight (NXP MF0ICU1 [Referensi, 36], MF0ICU2 [Referensi, 37])
NDEF di MIFARE Classic (NXP AN130511 [Referensi, 38], AN130411 [Referensi, 39])

Perhatikan bahwa Android 2.3.3 menyertakan API untuk jenis MIFARE ini. Jika penerapan perangkat mendukung MIFARE, penerapan tersebut:

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

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

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

7.4.5. Kemampuan Jaringan Minimum

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

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

Perangkat DAPAT menerapkan lebih dari satu bentuk konektivitas data.

7.5. Kamera

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

7.5.1. Kamera Belakang

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

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

7.5.2. Kamera Depan

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

HARUS memiliki resolusi minimal VGA (yaitu, 640x480 piksel)
TIDAK BOLEH menggunakan kamera depan sebagai default untuk Camera API. Artinya, API kamera di Android 2.3 memiliki dukungan khusus untuk kamera depan, dan implementasi perangkat TIDAK BOLEH mengonfigurasi API untuk memperlakukan kamera depan sebagai kamera belakang default, meskipun itu satu-satunya kamera di perangkat.
DAPAT menyertakan fitur (seperti fokus otomatis, flash, dll.) yang tersedia untuk kamera belakang seperti yang dijelaskan dalam Pasal 7.5.1.
HARUS mencerminkan (yaitu mencerminkan) streaming secara horizontal yang ditampilkan oleh aplikasi di CameraPreview, sebagai berikut:

Jika implementasi perangkat dapat diputar oleh pengguna (seperti otomatis melalui akselerometer atau secara manual melalui input pengguna), pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi perangkat saat ini.
Jika aplikasi saat ini telah secara eksplisit meminta agar tampilan Kamera diputar melalui panggilan ke metode android.hardware.Camera.setDisplayOrientation() [Resources, 40], pratinjau kamera HARUS dicerminkan secara horizontal relatif terhadap orientasi yang ditentukan oleh aplikasi.
Jika tidak, pratinjau HARUS dicerminkan di sepanjang sumbu horizontal default perangkat.

HARUS mencerminkan data gambar yang ditampilkan ke pengendali callback kamera "postview", dengan cara yang sama seperti streaming gambar pratinjau kamera. (Jika penerapan perangkat tidak mendukung callback postview, persyaratan ini jelas tidak berlaku.)
TIDAK BOLEH mencerminkan gambar diam atau streaming video akhir yang diambil dan ditampilkan ke callback aplikasi atau di-commit ke penyimpanan media

7.5.3. Perilaku Camera API

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

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.
Jika aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() saat format pratinjau adalah YCbCr_420_SP, data dalam byte[] yang diteruskan ke onPreviewFrame() harus lebih lanjut dalam format encoding NV21. Artinya, NV21 HARUS menjadi default.
Implementasi perangkat HARUS mendukung format YV12 (seperti yang ditunjukkan oleh konstanta android.graphics.ImageFormat.YV12) untuk pratinjau kamera untuk kamera depan dan belakang. Perhatikan bahwa Definisi Kompatibilitas untuk versi mendatang direncanakan untuk mengubah persyaratan ini menjadi "HARUS". Artinya, dukungan YV12 bersifat opsional di Android 2.3, tetapi akan diperlukan oleh versi mendatang. Perangkat lama dan baru yang menjalankan Android 2.3 sangat disarankan untuk memenuhi persyaratan ini di Android 2.3, atau perangkat tersebut tidak akan dapat mencapai kompatibilitas Android saat diupgrade ke versi mendatang.

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

Implementasi perangkat HARUS mengenali dan mematuhi setiap nama parameter yang ditentukan sebagai konstanta pada class android.hardware.Camera.Parameters, jika hardware yang mendasarinya mendukung fitur tersebut. Jika hardware perangkat tidak mendukung fitur, API harus berperilaku seperti yang didokumentasikan. Sebaliknya, implementasi Perangkat TIDAK BOLEH mematuhi atau mengenali konstanta string yang diteruskan ke metode android.hardware.Camera.setParameters() selain yang didokumentasikan sebagai konstanta di android.hardware.Camera.Parameters. Artinya, penerapan perangkat HARUS mendukung semua parameter Kamera standar jika hardware mengizinkan, dan TIDAK BOLEH mendukung jenis parameter Kamera kustom.

7.5.4. Orientasi Kamera

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

7.6. Memori dan Penyimpanan

Fungsi dasar Android 2.3 adalah menjalankan aplikasi. Implementasi perangkat HARUS memenuhi persyaratan bagian ini, untuk memastikan penyimpanan dan memori yang memadai agar aplikasi dapat berjalan dengan benar.

7.6.1. Memori dan Penyimpanan Minimum

Implementasi perangkat HARUS memiliki memori minimal 128 MB yang tersedia untuk kernel dan ruang pengguna. 128 MB HARUS merupakan tambahan dari memori apa pun yang didedikasikan untuk komponen hardware seperti radio, memori, dan sebagainya yang tidak berada di bawah kontrol kernel.

Implementasi perangkat HARUS memiliki penyimpanan non-volatil setidaknya 150 MB yang tersedia untuk data pengguna. Artinya, partisi /data HARUS setidaknya 150 MB.

Selain persyaratan di atas, implementasi perangkat HARUS memiliki setidaknya penyimpanan non-volatil sebesar 1 GB yang tersedia untuk data pengguna. Perhatikan bahwa persyaratan yang lebih tinggi ini direncanakan untuk menjadi minimum mutlak dalam versi Android mendatang. Implementasi perangkat sangat dianjurkan untuk memenuhi persyaratan ini sekarang, atau mungkin tidak memenuhi syarat untuk kompatibilitas versi Android mendatang.

Android API menyertakan Pengelola Download yang dapat digunakan aplikasi untuk mendownload file data. Implementasi Download Manager HARUS dapat mendownload setiap file berukuran 55 MB, atau lebih besar. Implementasi Download Manager HARUS dapat mendownload file berukuran 100 MB, atau lebih besar.

7.6.2. Penyimpanan Bersama Aplikasi

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

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

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

Implementasi perangkat DAPAT memiliki hardware untuk penyimpanan yang dapat dilepas dan diakses pengguna, seperti kartu Secure Digital. Atau, implementasi perangkat DAPAT mengalokasikan penyimpanan internal (tidak dapat dilepas) sebagai penyimpanan bersama untuk aplikasi.

Terlepas dari bentuk penyimpanan bersama yang digunakan, implementasi perangkat HARUS menyediakan beberapa mekanisme untuk mengakses konten penyimpanan bersama dari komputer host, seperti penyimpanan massal USB atau Media Transfer Protocol.

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

Implementasi perangkat yang menyertakan beberapa jalur penyimpanan bersama (seperti slot kartu SD dan penyimpanan internal bersama) HARUS mengubah aplikasi inti seperti pemindai media dan ContentProvider untuk mendukung file yang ditempatkan di kedua lokasi secara transparan.

7.7. USB

Implementasi perangkat:

HARUS menerapkan klien USB, yang dapat dihubungkan ke host USB dengan port USB-A standar
HARUS menerapkan Android Debug Bridge melalui USB (seperti yang dijelaskan di Bagian 7)
HARUS menerapkan spesifikasi penyimpanan massal USB, untuk mengizinkan host yang terhubung ke perangkat mengakses konten volume /sdcard
HARUS menggunakan faktor bentuk USB mikro di sisi perangkat
DAPAT menyertakan port non-standar di sisi perangkat, tetapi jika demikian, HARUS dikirim dengan kabel yang dapat menghubungkan pinout kustom ke port USB-A standar

8. Kompatibilitas Performa

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 2.3 yang ditentukan dalam tabel di bawah:

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

9. Kompatibilitas Model Keamanan

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

9.1. Izin

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

9.2. Isolasi UID dan Proses

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

9.3. Izin Sistem File

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

9.4. Lingkungan Eksekusi Alternatif

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

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

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

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

Runtime alternatif HARUS mematuhi model sandbox Android. Khususnya:

Runtime alternatif HARUS menginstal aplikasi melalui PackageManager ke dalam sandbox Android terpisah (yaitu, ID pengguna Linux, dll.)
Runtime alternatif DAPAT menyediakan satu sandbox Android yang digunakan bersama oleh semua aplikasi yang menggunakan runtime alternatif.
Runtime alternatif dan aplikasi terinstal yang menggunakan runtime alternatif TIDAK BOLEH menggunakan kembali sandbox aplikasi lain yang diinstal di perangkat, kecuali melalui mekanisme Android standar untuk ID pengguna bersama dan sertifikat penandatanganan
Runtime alternatif TIDAK BOLEH diluncurkan dengan, memberikan, atau diberi akses ke sandbox yang sesuai dengan aplikasi Android lainnya.

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

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

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

10. Pengujian Kompatibilitas Software

Project Open Source Android menyertakan berbagai alat pengujian untuk memverifikasi bahwa implementasi perangkat kompatibel. Implementasi perangkat HARUS lulus semua pengujian yang dijelaskan di bagian ini.

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

10.1. Compatibility Test Suite (CTS)

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

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

HARUS lulus Compatibility Test Suite (CTS) Android versi terbaru yang tersedia pada saat software implementasi perangkat selesai. (CTS tersedia sebagai bagian dari Project Open Source Android [Referensi, 2].) CTS menguji banyak, tetapi tidak semua, komponen yang diuraikan dalam dokumen ini.

10.2. Pemverifikasi CTS

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

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

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

10.3. Aplikasi Referensi

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

Aplikasi "Aplikasi untuk Android" [Referensi, 43].
Replica Island (tersedia di Android Market; hanya diperlukan untuk implementasi perangkat yang mendukung OpenGL ES 2.0)

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

11. Software yang Dapat Diupdate

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

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

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

Mekanisme update yang digunakan HARUS mendukung update tanpa menghapus data pengguna. Perhatikan bahwa software Android upstream menyertakan mekanisme update yang memenuhi persyaratan ini.

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

12. Hubungi Kami

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

Lampiran A - Prosedur Pengujian Bluetooth

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

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

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

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

Penyiapan dan Pemasangan

Build BluetoothChat.apk melalui 'make samples' dari hierarki kode sumber Android.
Instal BluetoothChat.apk di perangkat yang diketahui baik.
Instal BluetoothChat.apk di perangkat kandidat.

Menguji Kontrol Bluetooth oleh Aplikasi

Luncurkan BluetoothChat di perangkat kandidat, saat Bluetooth dinonaktifkan.
Pastikan perangkat kandidat mengaktifkan Bluetooth, atau meminta pengguna dengan dialog untuk mengaktifkan Bluetooth.

Menguji Penyambungan dan Komunikasi

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

Menguji Penyambungan dan Komunikasi dalam Arah Terbalik

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

Pengujian Peluncuran Ulang

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

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

Definisi Kompatibilitas Android 2.3 Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Daftar Isi

1. Pengantar

2. Referensi

3. Software

3.1. Kompatibilitas API Terkelola

3.2. Kompatibilitas Soft API

3.2.1. Izin

3.2.2. Parameter Build

3.2.3. Kompatibilitas Intent

3.2.3.1. Intent Aplikasi Inti

3.2.3.2. Penggantian Intent

3.2.3.3. Namespace Intent

3.2.3.4. Intent Siaran

3.3. Kompatibilitas API Native

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. Wallpaper Animasi

4. Kompatibilitas Pengemasan Aplikasi

5. Kompatibilitas Multimedia

5.1. Codec Media

5.1.1. Decoder Media

5.1.2. Encoder Media

5.2. Perekaman Audio

5.3. Latensi Audio

6. Kompatibilitas Alat Developer

7. Kompatibilitas Hardware

7.1. Layar dan Grafis

7.1.1. Konfigurasi Layar

7.1.2. Metrik Display

7.1.3. Dukungan Layar yang Dideklarasikan

7.1.4. Orientasi Layar

7.1.5. Akselerasi Grafis 3D

7.2. Perangkat Masukan

7.2.1. Keyboard

7.2.2. Navigasi Non-sentuh

7.2.3. Tombol navigasi

7.2.4. Input layar sentuh

7.3. Sensor

7.3.1. Akselerometer

7.3.2. Magnetometer

7.3.3. GPS

7.3.4. Giroskop

7.3.5. Barometer

7.3.7. Thermometer

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.3. Bluetooth

7.4.4. Komunikasi Nirkabel Jarak Dekat

7.4.5. Kemampuan Jaringan Minimum

7.5. Kamera

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. Isolasi UID dan Proses

9.3. Izin Sistem File

9.4. Lingkungan Eksekusi Alternatif

10. Pengujian Kompatibilitas Software

10.1. Compatibility Test Suite (CTS)

10.2. Pemverifikasi CTS

Definisi Kompatibilitas Android 2.3
Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.