Penggunaan "harus", "tidak boleh", "wajib", "harus", "tidak boleh", "seharusnya", "tidak boleh", "direkomendasikan", "boleh" dan "opsional" sesuai dengan standar IETF didefinisikan dalam RFC2119 [ Sumber Daya, 1 ].

Seperti yang digunakan dalam dokumen ini, "implementer perangkat" atau "implementer" adalah orang atau organisasi yang mengembangkan solusi perangkat keras/perangkat lunak yang menjalankan Android 2.2. Sebuah "implementasi perangkat" atau "implementasi" adalah solusi perangkat keras/perangkat lunak yang dikembangkan.

Agar dianggap kompatibel dengan Android 2.2, implementasi perangkat:

HARUS memenuhi persyaratan yang disajikan dalam Definisi Kompatibilitas ini, termasuk dokumen apa pun yang digabungkan melalui referensi.
HARUS lulus versi terbaru dari Android Compatibility Test Suite (CTS) yang tersedia pada saat perangkat lunak implementasi perangkat selesai. (CTS tersedia sebagai bagian dari Proyek Sumber Terbuka Android [ Sumber Daya, 2 ].) CTS menguji banyak, namun tidak semua, komponen yang diuraikan dalam dokumen ini.

Apabila definisi atau CTS ini tidak jelas, ambigu, atau tidak lengkap, maka merupakan tanggung jawab pelaksana perangkat untuk memastikan kompatibilitas dengan implementasi yang ada. Karena alasan ini, Proyek Sumber Terbuka Android [ Sumber Daya, 3 ] merupakan referensi dan implementasi Android yang disukai. Implementasi perangkat sangat dianjurkan untuk mendasarkan implementasinya pada kode sumber "upstream" yang tersedia dari Proyek Sumber Terbuka Android. Meskipun beberapa komponen secara hipotetis dapat diganti dengan penerapan alternatif, praktik ini sangat tidak disarankan, karena kelulusan tes CTS akan menjadi jauh lebih sulit. Implementer bertanggung jawab untuk memastikan kompatibilitas penuh perilaku dengan implementasi Android standar, termasuk dan di luar Compatibility Test Suite. Terakhir, perhatikan bahwa penggantian dan modifikasi komponen tertentu secara eksplisit dilarang oleh dokumen ini.

2. Sumber Daya

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

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

Proyek Sumber Terbuka 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.2: http://source.android.com/docs/compatibility/2.2/versions.html

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

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

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

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

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

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

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

Manajer Pencarian: http://developer.android.com/reference/android/app/SearchManager.html

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

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

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

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 monyet: https://developer.android.com/studio/test/other-testing-tools/monkey

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

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

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

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

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

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

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

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

Banyak dari sumber daya ini yang diturunkan secara langsung atau tidak langsung dari Android 2.2 SDK, dan secara fungsional akan identik dengan informasi dalam dokumentasi SDK tersebut. Jika Definisi Kompatibilitas atau Rangkaian Uji Kompatibilitas ini tidak sesuai dengan dokumentasi SDK, dokumentasi SDK dianggap resmi. Detail teknis apa pun yang diberikan dalam referensi yang disertakan di atas dianggap sebagai bagian dari Definisi Kompatibilitas ini.

3. Perangkat Lunak

Platform Android mencakup sekumpulan API terkelola, sekumpulan API asli, dan sekumpulan API yang disebut "lunak" seperti sistem Intent dan API aplikasi web. Bagian ini merinci API keras dan lunak yang merupakan bagian integral dari kompatibilitas, serta perilaku teknis dan antarmuka pengguna tertentu yang relevan. Implementasi perangkat HARUS mematuhi semua persyaratan di bagian ini.

3.1. Kompatibilitas API Terkelola

Lingkungan eksekusi terkelola (berbasis Dalvik) adalah sarana utama untuk aplikasi Android. Antarmuka pemrograman aplikasi (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 terdokumentasi, dari setiap API terdokumentasi yang diekspos oleh Android 2.2 SDK [ Sumber Daya, 4 ].

Implementasi perangkat TIDAK BOLEH menghilangkan API terkelola apa pun, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang terdokumentasi, atau menyertakan larangan pengoperasian, kecuali jika diizinkan secara khusus oleh Definisi Kompatibilitas ini.

3.2. Kompatibilitas API Lunak

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

3.2.1. Izin

Pelaksana perangkat HARUS mendukung dan menegakkan semua konstanta izin seperti yang didokumentasikan oleh halaman referensi Izin [ Sumber Daya, 5 ]. Perhatikan bahwa Bagian 10 mencantumkan persyaratan tambahan terkait model keamanan Android.

3.2.2. Parameter Bangun

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

Parameter	Komentar
android.os.Build.VERSION.RELEASE	Versi sistem Android yang sedang dijalankan, dalam format yang dapat dibaca manusia. Bidang ini HARUS memiliki salah satu nilai string yang ditentukan di [ Sumber Daya, 7 ].
android.os.Build.VERSION.SDK	Versi sistem Android yang sedang dijalankan, dalam format yang dapat diakses oleh kode aplikasi pihak ketiga. Untuk Android 2.2, kolom ini HARUS memiliki nilai integer 8.
android.os.Build.VERSION.INCREMENTAL	Nilai yang dipilih oleh pelaksana perangkat yang menunjuk build spesifik sistem Android yang sedang dijalankan, dalam format yang dapat dibaca manusia. Nilai ini TIDAK BOLEH digunakan kembali untuk build berbeda yang tersedia untuk pengguna akhir. Penggunaan umum bidang ini adalah untuk menunjukkan nomor build atau pengidentifikasi perubahan kontrol sumber mana yang digunakan untuk menghasilkan build. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.BOARD	Nilai yang dipilih oleh pelaksana perangkat yang mengidentifikasi perangkat keras internal spesifik yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan bidang ini adalah untuk menunjukkan revisi spesifik pada papan yang memberi daya pada perangkat. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.MEREK	Nilai yang dipilih oleh pelaksana perangkat yang mengidentifikasi nama perusahaan, organisasi, individu, dll. yang memproduksi perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan bidang ini adalah untuk menunjukkan OEM dan/atau operator yang menjual perangkat. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.DEVICE	Nilai yang dipilih oleh pelaksana perangkat yang mengidentifikasi konfigurasi spesifik atau revisi bodi (terkadang disebut "desain industri") perangkat. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.FINGERPRINT	Sebuah string yang secara unik mengidentifikasi bangunan ini. Itu HARUS dapat dibaca manusia secara wajar. Itu HARUS mengikuti templat ini: `$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` Misalnya: `acme/mydevice/generic/generic:2.2/ERC77/3359:userdebug/test-keys` Sidik jari TIDAK HARUS menyertakan karakter spasi. Jika kolom lain yang disertakan dalam template di atas memiliki karakter spasi, maka kolom tersebut HARUS diganti di sidik jari build dengan karakter lain, misalnya karakter garis bawah ("_").
android.os.Build.HOST	Sebuah string yang secara unik mengidentifikasi host tempat build dibangun, dalam format yang dapat dibaca manusia. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.ID	Pengidentifikasi yang dipilih oleh pelaksana perangkat untuk merujuk pada rilis tertentu, dalam format yang dapat dibaca manusia. Kolom ini bisa sama dengan android.os.Build.VERSION.INCREMENTAL, namun HARUS berupa nilai yang cukup bermakna bagi pengguna akhir untuk membedakan build perangkat lunak. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.MODEL	Nilai yang dipilih oleh pelaksana perangkat yang berisi nama perangkat yang diketahui oleh pengguna akhir. Nama ini HARUS sama dengan nama perangkat yang dipasarkan dan dijual kepada pengguna akhir. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.PRODUK	Nilai yang dipilih oleh pelaksana perangkat yang berisi nama pengembangan atau nama kode perangkat. HARUS dapat dibaca manusia, namun tidak dimaksudkan untuk dilihat oleh pengguna akhir. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").
android.os.Build.TAGS	Daftar tag yang dipisahkan koma yang dipilih oleh pelaksana perangkat yang selanjutnya membedakan build. Misalnya, "tidak ditandatangani,debug". Bidang ini TIDAK HARUS berupa null atau string kosong (""), tetapi satu tag (seperti "rilis") tidak masalah.
android.os.Build.TIME	Nilai yang mewakili stempel waktu saat pembangunan terjadi.
android.os.Build.TYPE	Nilai yang dipilih oleh pelaksana perangkat yang menentukan konfigurasi runtime build. Bidang ini HARUS memiliki salah satu nilai yang sesuai dengan tiga konfigurasi runtime Android pada umumnya: "user", "userdebug", atau "eng".
android.os.Build.USER	Nama atau ID pengguna dari pengguna (atau pengguna otomatis) yang menghasilkan build. Tidak ada persyaratan mengenai format spesifik bidang ini, kecuali TIDAK HARUS berupa null atau string kosong ("").

3.2.3. Kompatibilitas Maksud

Android menggunakan Intent untuk mencapai integrasi yang longgar antar aplikasi. Bagian ini menjelaskan persyaratan terkait pola Intent yang HARUS dipenuhi oleh implementasi perangkat. Yang dimaksud dengan "dihormati" adalah bahwa pelaksana perangkat HARUS menyediakan Aktivitas atau Layanan Android yang menentukan filter Intent yang cocok dan mengikat serta mengimplementasikan perilaku yang benar untuk setiap pola Intent yang ditentukan.

3.2.3.1. Maksud Aplikasi Inti

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

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

Aplikasi berikut ini dianggap sebagai aplikasi inti sistem Android:

Jam Meja
Peramban
Kalender
Kalkulator
Kamera
Kontak
Surel
Galeri
Pencarian Global
Peluncur
LivePicker (yaitu, aplikasi pemilih Wallpaper Animasi; MUNGKIN dihilangkan jika perangkat tidak mendukung Wallpaper Animasi, sesuai Bagian 3.8.5.)
Pesan (AKA "Mms")
Musik
Telepon
Pengaturan
Perekam suara

Aplikasi inti sistem Android 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 bertipe sama yang mengimplementasikan filter Intent yang sama pola sebagai aplikasi sistem Android inti.

Dengan kata lain, implementasi perangkat MUNGKIN menggantikan aplikasi inti sistem Android; namun, jika ya, penerapan perangkat HARUS mendukung semua pola Intent yang ditentukan oleh setiap aplikasi sistem Android inti yang diganti.

3.2.3.2. Penggantian Niat

Karena Android adalah platform yang dapat diperluas, pelaksana perangkat HARUS mengizinkan setiap pola Intent yang dirujuk di Bagian 3.2.3.1 diganti oleh aplikasi pihak ketiga. Proyek sumber terbuka Android hulu mengizinkan hal ini secara default; pelaksana perangkat TIDAK BOLEH memberikan hak istimewa khusus pada penggunaan pola Intent ini oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga mengikat dan mengambil kendali atas pola ini. Larangan ini secara khusus mencakup namun 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. Ruang Nama Maksud

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

Larangan ini serupa dengan yang ditentukan untuk kelas bahasa Java di Bagian 3.6.

3.2.3.4. Maksud Siaran

Aplikasi pihak ketiga mengandalkan platform untuk menyiarkan Intent tertentu guna memberi tahu mereka tentang perubahan dalam lingkungan perangkat keras atau perangkat lunak. Perangkat yang kompatibel dengan Android HARUS menyiarkan Intent siaran publik sebagai respons terhadap kejadian sistem yang sesuai. Intent Siaran dijelaskan dalam dokumentasi SDK.

3.3. Kompatibilitas API Asli

Kode terkelola yang berjalan di Dalvik dapat memanggil kode asli yang disediakan dalam file .apk aplikasi sebagai file ELF .so yang dikompilasi untuk arsitektur perangkat keras perangkat yang sesuai. Implementasi perangkat HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode asli, menggunakan semantik Java Native Interface (JNI) standar. API berikut HARUS tersedia untuk kode asli:

libc (perpustakaan C)
libm (perpustakaan matematika)
antarmuka JNI
libz (kompresi Zlib)
liblog (pencatatan Android)
Dukungan minimal untuk C++
Dukungan untuk OpenGL, seperti dijelaskan di bawah

Implementasi perangkat HARUS mendukung OpenGL ES 1.0. Perangkat yang tidak memiliki akselerasi perangkat keras HARUS mengimplementasikan OpenGL ES 1.0 menggunakan perangkat lunak penyaji. Implementasi perangkat HARUS mengimplementasikan OpenGL ES 1.1 sebanyak yang didukung perangkat keras perangkat. Implementasi perangkat HARUS menyediakan implementasi untuk OpenGL ES 2.0, jika perangkat keras mampu memberikan kinerja yang wajar pada API tersebut.

Pustaka ini HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk arsitektur prosesor tertentu) dengan versi yang disediakan di Bionic oleh proyek Sumber Terbuka Android. Karena implementasi Bionic tidak sepenuhnya kompatibel dengan implementasi lain seperti pustaka GNU C, pelaksana perangkat HARUS menggunakan implementasi Android. Jika pelaksana perangkat menggunakan implementasi berbeda dari pustaka ini, mereka HARUS memastikan kompatibilitas header, biner, dan perilaku.

Implementasi perangkat HARUS melaporkan secara akurat Application Binary Interface (ABI) asli yang didukung oleh perangkat, melalui android.os.Build.CPU_ABI API. ABI HARUS berupa salah satu entri yang didokumentasikan dalam versi terbaru Android NDK, dalam file docs/CPU-ARCH-ABIS.txt . Perlu diperhatikan bahwa rilis tambahan Android NDK mungkin memperkenalkan dukungan untuk ABI tambahan.

Kompatibilitas kode asli merupakan suatu tantangan. Oleh karena itu, harus diulangi bahwa pelaksana perangkat SANGAT dianjurkan untuk menggunakan implementasi hulu dari perpustakaan yang tercantum di atas untuk membantu memastikan kompatibilitas.

3.4. Kompatibilitas Web

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

3.4.1. Kompatibilitas Tampilan Web

Implementasi Android Open Source menggunakan mesin rendering WebKit untuk mengimplementasikan android.webkit.WebView . Karena tidak layak untuk mengembangkan rangkaian pengujian komprehensif untuk sistem rendering web, pelaksana perangkat HARUS menggunakan versi hulu WebKit yang spesifik dalam implementasi WebView. Secara khusus:

Implementasi android.webkit.WebView implementasi perangkat HARUS didasarkan pada build WebKit 533.1 dari pohon Sumber Terbuka Android upstream untuk Android 2.2. Versi ini mencakup serangkaian fungsionalitas dan perbaikan keamanan khusus untuk WebView. Pelaksana perangkat MUNGKIN menyertakan penyesuaian pada implementasi WebKit; namun, penyesuaian apa pun 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 mengacu pada konfigurasi lokal perangkat 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

Konfigurasi WebView HARUS menyertakan dukungan untuk database HTML5, cache aplikasi, dan API geolokasi [ Sumber Daya, 9 ]. WebView HARUS menyertakan dukungan untuk tag <video> HTML5. API HTML5, seperti semua API JavaScript, HARUS dinonaktifkan secara default di WebView, kecuali jika pengembang secara eksplisit mengaktifkannya melalui API Android biasa.

3.4.2. Kompatibilitas Peramban

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

Implementasi MUNGKIN mengirimkan string agen pengguna khusus dalam aplikasi Browser mandiri.

Aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream atau pengganti pihak ketiga) HARUS menyertakan dukungan untuk HTML5 sebanyak mungkin [ Sumber Daya, 9 ] . Minimal, implementasi perangkat HARUS mendukung geolokasi HTML5, cache aplikasi, dan API database serta tag <video> di aplikasi Browser mandiri.

3.5. Kompatibilitas Perilaku API

Perilaku masing-masing jenis API (terkelola, lunak, asli, dan web) harus konsisten dengan implementasi pilihan proyek sumber terbuka Android hulu [ Sumber Daya, 3 ]. Beberapa area kompatibilitas tertentu adalah:

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

Daftar di atas tidak lengkap, dan tanggung jawab ada pada pelaksana perangkat untuk memastikan kompatibilitas perilaku. Oleh karena itu, pelaksana perangkat HARUS menggunakan kode sumber yang tersedia melalui Proyek Sumber Terbuka Android jika memungkinkan, daripada mengimplementasikan ulang bagian penting dari sistem.

Compatibility Test Suite (CTS) menguji sebagian besar platform untuk kompatibilitas perilaku, namun tidak semuanya. Implementer bertanggung jawab memastikan kompatibilitas perilaku dengan Proyek Sumber Terbuka Android.

3.6. Ruang Nama API

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

Jawa.*
javax.*
matahari.*
android.*
com.android.*

Modifikasi yang dilarang antara lain:

Implementasi perangkat TIDAK BOLEH mengubah API yang diekspos secara publik di platform Android dengan mengubah metode atau tanda tangan kelas apa pun, atau dengan menghapus kelas atau kolom kelas.
Pelaksana perangkat MUNGKIN memodifikasi implementasi dasar API, namun modifikasi tersebut TIDAK BOLEH berdampak pada perilaku yang dinyatakan dan tanda tangan bahasa Java dari API apa pun yang diekspos secara publik.
Pelaksana perangkat TIDAK BOLEH menambahkan elemen apa pun yang diekspos secara publik (seperti kelas atau antarmuka, atau bidang atau metode ke kelas atau antarmuka yang ada) ke API di atas.

"Elemen yang diekspos secara publik" adalah konstruksi apa pun yang tidak dihiasi dengan penanda "@hide" di kode sumber Android upstream. Dengan kata lain, pelaksana perangkat TIDAK BOLEH mengekspos API baru atau mengubah API yang sudah ada di namespace yang disebutkan di atas. Pelaksana perangkat MUNGKIN melakukan modifikasi internal saja, namun modifikasi tersebut TIDAK BOLEH diiklankan atau diekspos ke pengembang.

Pelaksana perangkat MUNGKIN menambahkan API khusus, namun API tersebut TIDAK BOLEH berada dalam namespace yang dimiliki atau mengacu pada organisasi lain. Misalnya, pelaksana perangkat TIDAK BOLEH menambahkan API ke com.google.* atau namespace serupa; hanya Google yang dapat melakukannya. Demikian pula, Google TIDAK BOLEH menambahkan API ke namespace perusahaan lain.

Jika pelaksana perangkat mengusulkan untuk meningkatkan salah satu namespace paket di atas (misalnya dengan menambahkan fungsi baru yang berguna ke API yang sudah ada, atau menambahkan API baru), pelaksana HARUS mengunjungi source.android.com dan memulai proses untuk memberikan kontribusi perubahan dan kode, menurut informasi di situs itu.

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 menjadikannya mengikat melalui penyertaan dalam definisi kompatibilitas ini.

3.7. Kompatibilitas Mesin Virtual

Implementasi perangkat HARUS mendukung spesifikasi bytecode Dalvik Executable (DEX) penuh dan semantik Mesin Virtual Dalvik [ Sumber Daya, 10 ].

Implementasi perangkat dengan layar yang diklasifikasikan sebagai kepadatan sedang atau rendah HARUS mengkonfigurasi Dalvik untuk mengalokasikan setidaknya 16MB memori untuk setiap aplikasi. Implementasi perangkat dengan layar yang diklasifikasikan sebagai kepadatan tinggi HARUS mengkonfigurasi Dalvik untuk mengalokasikan setidaknya 24MB memori untuk setiap aplikasi. Perhatikan bahwa implementasi perangkat MUNGKIN mengalokasikan lebih banyak memori daripada angka-angka ini.

3.8. Kompatibilitas Antarmuka Pengguna

Platform Android menyertakan beberapa API pengembang yang memungkinkan pengembang terhubung ke antarmuka pengguna sistem. Implementasi perangkat HARUS menggabungkan API UI standar ini ke dalam antarmuka pengguna khusus yang mereka kembangkan, seperti yang dijelaskan di bawah.

3.8.1. Widget

Android mendefinisikan tipe komponen dan API serta siklus hidup terkait yang memungkinkan aplikasi mengekspos "AppWidget" ke pengguna akhir [ Sumber Daya, 11 ]. Rilis referensi Sumber Terbuka Android mencakup aplikasi Peluncur yang menyertakan elemen antarmuka pengguna yang memungkinkan pengguna untuk menambah, melihat, dan menghapus AppWidgets dari layar beranda.

Pelaksana perangkat MUNGKIN mengganti alternatif dengan Peluncur referensi (yaitu layar beranda). Peluncur Alternatif HARUS menyertakan dukungan bawaan untuk AppWidgets, dan mengekspos elemen antarmuka pengguna untuk menambah, mengonfigurasi, melihat, dan menghapus AppWidgets langsung di dalam Peluncur. Peluncur Alternatif MUNGKIN menghilangkan elemen antarmuka pengguna ini; namun, jika dihilangkan, pelaksana perangkat HARUS menyediakan aplikasi terpisah yang dapat diakses dari Peluncur yang memungkinkan pengguna untuk menambah, mengonfigurasi, melihat, dan menghapus AppWidgets.

3.8.2. Pemberitahuan

Android menyertakan API yang memungkinkan pengembang memberi tahu pengguna tentang peristiwa penting [ Sumber Daya, 12 ]. Pelaksana perangkat HARUS memberikan dukungan untuk setiap kelas notifikasi yang ditentukan; khususnya: suara, getaran, cahaya dan bilah status.

Selain itu, penerapannya HARUS merender dengan benar semua sumber daya (ikon, file suara, dll.) yang disediakan dalam API [ Sumber Daya, 13 ], atau dalam panduan gaya ikon Bilah Status [ Sumber Daya, 14 ]. Implementer perangkat MUNGKIN memberikan pengalaman pengguna alternatif untuk notifikasi selain yang disediakan oleh referensi penerapan Sumber Terbuka Android; namun, sistem notifikasi alternatif tersebut HARUS mendukung sumber notifikasi yang ada, seperti di atas.

3.8.3. Mencari

Android menyertakan API [ Sumber Daya, 15 ] yang memungkinkan pengembang memasukkan penelusuran ke dalam aplikasi mereka, dan mengekspos data aplikasi mereka ke dalam penelusuran sistem global. Secara umum, fungsi ini terdiri dari antarmuka pengguna tunggal di seluruh sistem yang memungkinkan pengguna memasukkan kueri, menampilkan saran saat pengguna mengetik, dan menampilkan hasil. API Android memungkinkan pengembang untuk menggunakan kembali antarmuka ini untuk menyediakan pencarian dalam aplikasi mereka sendiri, dan memungkinkan pengembang untuk memberikan hasil ke antarmuka pengguna pencarian global yang umum.

Implementasi perangkat HARUS mencakup antarmuka pengguna pencarian tunggal, bersama, dan seluruh sistem yang mampu memberikan saran secara real-time sebagai respons terhadap masukan pengguna. Implementasi perangkat HARUS mengimplementasikan API yang memungkinkan pengembang menggunakan kembali antarmuka pengguna ini untuk menyediakan pencarian dalam aplikasi mereka sendiri. Implementasi perangkat HARUS mengimplementasikan API yang memungkinkan aplikasi pihak ketiga menambahkan saran ke kotak pencarian ketika dijalankan dalam mode pencarian global. Jika tidak ada aplikasi pihak ketiga yang diinstal yang menggunakan fungsi ini, perilaku default HARUS menampilkan hasil dan saran mesin pencari web.

Implementasi perangkat MUNGKIN mengirimkan antarmuka pengguna pencarian alternatif, namun HARUS menyertakan tombol pencarian khusus keras atau lunak, yang dapat digunakan kapan saja dalam aplikasi apa pun untuk menjalankan kerangka pencarian, dengan perilaku yang disediakan dalam dokumentasi API.

3.8.4. Bersulang

Aplikasi dapat menggunakan API "Toast" (didefinisikan di [ Sumberdaya, 16 ]) untuk menampilkan string non-modal pendek kepada pengguna akhir, yang hilang setelah beberapa saat. Implementasi perangkat HARUS menampilkan Toast dari aplikasi ke pengguna akhir dengan cara yang terlihat jelas.

3.8.5. Wallpaper Hidup

Android mendefinisikan jenis komponen dan API serta siklus hidup terkait yang memungkinkan aplikasi mengekspos satu atau lebih "Wallpaper Animasi" kepada pengguna akhir [ Sumber Daya, 17 ]. Wallpaper Animasi adalah animasi, pola, atau gambar serupa dengan kemampuan masukan terbatas yang ditampilkan sebagai wallpaper, di belakang aplikasi lain.

Perangkat keras dianggap mampu menjalankan wallpaper hidup dengan andal jika dapat menjalankan semua wallpaper hidup, tanpa batasan fungsionalitas, pada framerate wajar tanpa dampak buruk pada aplikasi lain. Jika keterbatasan pada perangkat keras menyebabkan wallpaper dan/atau aplikasi mogok, tidak berfungsi, menghabiskan daya CPU atau baterai secara berlebihan, atau berjalan pada kecepatan bingkai yang sangat rendah, perangkat keras tersebut dianggap tidak mampu menjalankan wallpaper hidup. Sebagai contoh, beberapa wallpaper animasi mungkin menggunakan konteks Open GL 1.0 atau 2.0 untuk merender kontennya. Wallpaper hidup tidak akan berjalan dengan andal pada perangkat keras yang tidak mendukung beberapa konteks OpenGL karena penggunaan wallpaper hidup dalam konteks OpenGL mungkin bertentangan dengan aplikasi lain yang juga menggunakan konteks OpenGL.

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

4. Referensi Kompatibilitas Perangkat Lunak

Pelaksana perangkat HARUS menguji kompatibilitas implementasi menggunakan aplikasi sumber terbuka berikut:

Kalkulator (termasuk dalam SDK)
Pendarat Bulan (termasuk dalam SDK)
Aplikasi "Aplikasi untuk Android" [ Sumberdaya, 18 ].
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 benar pada implementasinya, agar implementasinya dianggap kompatibel.

Selain itu, implementasi perangkat HARUS menguji setiap item menu (termasuk semua submenu) dari masing-masing aplikasi pengujian asap berikut:

ApiDemos (termasuk dalam SDK)
ManualSmokeTests (termasuk dalam CTS)

Setiap test case pada aplikasi di atas HARUS berjalan dengan benar pada implementasi perangkat.

5. Kompatibilitas Kemasan Aplikasi

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

Implementasi perangkat TIDAK HARUS memperluas format .apk [ Resources, 20 ], Android Manifest [ Resources, 21 ], atau Dalvik bytecode [ Resources, 10 ] sedemikian rupa sehingga mencegah file tersebut diinstal dan dijalankan dengan benar di perangkat lain yang kompatibel . Pelaksana perangkat HARUS menggunakan implementasi referensi hulu Dalvik, dan sistem manajemen paket implementasi referensi.

6. Kompatibilitas Multimedia

Implementasi perangkat harus sepenuhnya mengimplementasikan semua API multimedia. Implementasi perangkat harus mencakup dukungan untuk semua codec multimedia yang dijelaskan di bawah ini, dan harus memenuhi pedoman pemrosesan suara yang dijelaskan di bawah ini.

6.1. Codec Media

Implementasi perangkat harus mendukung codec multimedia berikut. Semua codec ini disediakan sebagai implementasi perangkat lunak dalam implementasi Android yang disukai dari proyek open source Android.

Harap dicatat bahwa Google maupun aliansi handset terbuka tidak membuat representasi bahwa codec ini tidak terbebani oleh paten pihak ketiga. Mereka yang bermaksud menggunakan kode sumber ini dalam produk perangkat keras atau perangkat lunak disarankan agar implementasi kode ini, termasuk dalam perangkat lunak open source atau shareware, mungkin memerlukan lisensi paten dari pemegang paten yang relevan.

Audio
	Nama	Pembuat enkode	Dekoder	Detail	Format file/kontainer
	AAC LC/LTP		X	Konten mono/stereo dalam kombinasi tarif bit standar hingga 160 kbps dan tingkat pengambilan sampel antara 8 hingga 48kHz	3GPP (.3GP) dan MPEG-4 (.mp4, .m4a). Tidak ada dukungan untuk AAC mentah (.AAC)
	DIA-AACv1 (AAC+)		X
	HE-AACv2 (AAC+ yang ditingkatkan)		X
	AMR-NB	X	X	Sampel 4,75 hingga 12,2 kbps @ 8kHz	3GPP (.3gp)
	AMR-WB		X	9 kecepatan dari 6,60 kbit/s hingga 23,85 kbit/s sampel @ 16kHz	3GPP (.3gp)
	MP3		X	Konstanta Mono/Stereo 8-320Kbps (CBR) atau kecepatan bit variabel (VBR)	Mp3 (.mp3)
	MIDI		X	MIDI Tipe 0 dan 1. DLS Versi 1 dan 2. XMF dan Mobile XMF. Dukungan untuk format nada dering RTTTL/RTX, OTA, dan iMelody	Tipe 0 dan 1 (.mid, .xmf, .mxmf). Juga rtttl/rtx (.rtttl, .rtx), ota (.ota), dan imelody (.imy)
	Ogg Vorbis		X		OGG (.OGG)
	PCM		X	PCM linier 8- dan 16-bit (tarif hingga batas perangkat keras)	Wave (.wav)
Gambar
	jpeg	X	X	basis+progresif
	GIF		X
	PNG	X	X
	BMP		X
Video
	H.263	X	X		File 3GPP (.3GP)
	H.264		X		File 3GPP (.3GP) dan MPEG-4 (.mp4)
	MPEG4 Profil Sederhana		X		File 3GPP (.3GP)

Perhatikan bahwa tabel di atas tidak mencantumkan persyaratan bitrate spesifik untuk sebagian besar codec video. Alasan untuk ini adalah bahwa dalam praktiknya, perangkat keras perangkat saat ini tidak selalu mendukung bitrate yang memetakan persis ke bitrat yang diperlukan yang ditentukan oleh standar yang relevan. Sebaliknya, implementasi perangkat harus mendukung bitrate tertinggi praktis pada perangkat keras, hingga batas yang ditentukan oleh spesifikasi.

6.2. Rekaman audio

Ketika aplikasi telah menggunakan android.media.AudioRecord API untuk mulai merekam aliran audio, implementasi perangkat harus mencicipi dan merekam audio dengan masing -masing perilaku ini:

Pemrosesan pengurangan kebisingan, jika ada, harus dinonaktifkan.
Kontrol gain otomatis, jika ada, harus dinonaktifkan.
Perangkat harus menunjukkan kira -kira amplitudo datar versus karakteristik frekuensi; Secara khusus, ± 3 dB, dari 100 Hz hingga 4000 Hz
Sensitivitas input audio harus ditetapkan sedemikian rupa sehingga sumber daya daya 90 dB (SPL) pada 1000 Hz menghasilkan RMS 5000 untuk sampel 16-bit.
Level amplitudo PCM harus secara linier melacak perubahan input SPL pada setidaknya kisaran 30 dB dari -18 dB hingga +12 dB Re 90 dB SPL di mikrofon.
Distorsi harmonik total harus kurang dari 1% dari 100 Hz hingga 4000 Hz pada tingkat input SPL 90 dB.

Catatan: Sementara persyaratan yang diuraikan di atas dinyatakan sebagai "harus" untuk Android 2.2, definisi kompatibilitas untuk versi masa depan direncanakan untuk mengubah ini menjadi "harus". Artinya, persyaratan ini opsional di Android 2.2 tetapi akan diminta oleh versi masa depan. Perangkat yang ada dan baru yang menjalankan Android 2.2 Android sangat dianjurkan untuk memenuhi persyaratan ini di Android 2.2 , atau mereka tidak akan dapat mencapai kompatibilitas Android ketika ditingkatkan ke versi masa depan.

6.3. Latensi Audio

Latensi audio secara luas didefinisikan sebagai interval antara ketika aplikasi meminta pemutaran audio atau operasi rekaman, dan ketika implementasi perangkat benar -benar memulai operasi. Banyak kelas aplikasi bergantung pada latensi pendek, untuk mencapai efek waktu nyata seperti efek suara atau komunikasi VoIP. Implementasi perangkat harus memenuhi semua persyaratan latensi audio yang diuraikan dalam bagian ini.

Untuk keperluan bagian ini:

"Latensi Output Dingin" didefinisikan sebagai interval antara ketika aplikasi meminta pemutaran audio dan ketika suara mulai diputar, ketika sistem audio telah menganggur dan bertenaga sebelum permintaan
"Latensi keluaran hangat" didefinisikan sebagai interval antara ketika aplikasi meminta pemutaran audio dan ketika suara mulai diputar, ketika sistem audio baru -baru ini digunakan tetapi saat ini menganggur (yaitu, diam)
"Latensi Keluaran Berkelanjutan" didefinisikan sebagai interval antara ketika suatu aplikasi mengeluarkan sampel yang akan dimainkan dan ketika speaker secara fisik memainkan suara yang sesuai, sementara perangkat saat ini memutar kembali audio
"Latensi Input Dingin" didefinisikan sebagai interval antara ketika suatu aplikasi meminta perekaman audio dan ketika sampel pertama dikirim ke aplikasi melalui panggilan baliknya, ketika sistem audio dan mikrofon telah menganggur dan bertenaga sebelum permintaan tersebut
"Latensi Input Berkelanjutan" didefinisikan ketika suara ambient terjadi dan ketika sampel yang sesuai dengan suara itu dikirim ke aplikasi perekaman melalui panggilan baliknya, saat perangkat dalam mode perekaman

Menggunakan definisi di atas, implementasi perangkat harus menunjukkan masing -masing properti ini:

latensi output dingin 100 milidetik atau kurang
latensi output hangat 10 milidetik atau kurang
Latensi keluaran terus menerus dari 45 milidetik atau kurang
latensi input dingin 100 milidetik atau kurang
latensi input kontinu 50 milidetik atau kurang

7. Kompatibilitas Alat Pengembang

Implementasi perangkat harus mendukung alat pengembang Android yang disediakan di Android SDK. Secara khusus, perangkat yang kompatibel dengan Android harus kompatibel dengan:

Android Debug Bridge (dikenal sebagai ADB) [ Sumber Daya, 19 ]
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 menyalakan jembatan debug Android.
Layanan Monitor Debug Dalvik (dikenal sebagai DDMS) [ Sumber Daya, 19 ]
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 jembatan Android Debug, seperti di atas.
Monyet [ Sumber Daya, 22 ]
Implementasi perangkat harus mencakup kerangka kerja monyet, dan membuatnya tersedia untuk aplikasi untuk digunakan.

8. Kompatibilitas perangkat keras

Android dimaksudkan untuk mendukung pelaksana perangkat yang menciptakan faktor dan konfigurasi bentuk inovatif. Pada saat yang sama pengembang Android mengharapkan perangkat keras, sensor, dan API tertentu di semua perangkat Android. Bagian ini mencantumkan fitur perangkat keras yang harus didukung oleh semua perangkat yang kompatibel dengan Android 2.2.

Jika perangkat menyertakan komponen perangkat keras tertentu yang memiliki API yang sesuai untuk pengembang pihak ketiga, implementasi perangkat harus mengimplementasikan API tersebut sebagaimana didefinisikan dalam dokumentasi Android SDK. Jika API di SDK berinteraksi dengan komponen perangkat keras yang dinyatakan sebagai opsional dan implementasi perangkat tidak memiliki komponen itu:

Definisi kelas untuk API komponen harus ada
Perilaku API harus diimplementasikan sebagai tidak ada ops dengan cara yang masuk akal
Metode API harus mengembalikan nilai nol jika diizinkan oleh dokumentasi SDK
Metode API Harus Mengembalikan Implementasi Kelas No-Op di mana nilai nol tidak diizinkan oleh dokumentasi SDK

Contoh khas dari skenario di mana persyaratan ini berlaku adalah API Telephony: Bahkan pada perangkat non-telepon, API ini harus diimplementasikan sebagai no-op yang masuk akal.

Implementasi Perangkat harus secara akurat melaporkan informasi konfigurasi perangkat keras yang akurat melalui metode getSystemAvailableFeatures() dan hasSystemFeature(String) di kelas android.content.pm.PackageManager . [ Sumber Daya, 23 ]

8.1. Menampilkan

Android 2.2 mencakup fasilitas yang melakukan penskalaan otomatis dan operasi transformasi tertentu dalam beberapa keadaan, untuk memastikan bahwa aplikasi pihak ketiga berjalan cukup baik pada berbagai konfigurasi perangkat keras [ Sumber Daya, 24 ]. Perangkat harus mengimplementasikan perilaku ini dengan benar, sebagaimana dirinci dalam bagian ini.

Untuk Android 2.2, ini adalah konfigurasi tampilan yang paling umum:

Tipe Layar	Lebar (piksel)	Tinggi (piksel)	Rentang panjang diagonal (inci)	Grup ukuran layar	Grup kepadatan layar
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 kelas android.content.res.Configuration [ sumber daya, 24 ].

Beberapa paket .apk telah memanifestasikan yang tidak mengidentifikasi mereka sebagai mendukung rentang kepadatan tertentu. Saat menjalankan aplikasi tersebut, kendala berikut berlaku:

Implementasi perangkat harus menafsirkan sumber daya dalam .apk yang tidak memiliki kualifikasi kepadatan sebagai default ke "medium" (dikenal sebagai "MDPI" dalam dokumentasi SDK.)
Saat beroperasi pada layar kerapatan "rendah", implementasi perangkat harus mengurangi aset menengah/MDPI dengan faktor 0,75.
Saat beroperasi pada layar kepadatan "tinggi", implementasi perangkat harus meningkatkan aset menengah/MDPI dengan faktor 1,5.
Implementasi perangkat tidak boleh skala aset dalam kisaran kepadatan, dan harus mengukur aset dengan tepatnya faktor -faktor antara rentang kepadatan ini.

8.1.2. Konfigurasi tampilan non-standar

Konfigurasi tampilan yang tidak cocok dengan salah satu konfigurasi standar yang tercantum dalam Bagian 8.1.1 memerlukan pertimbangan tambahan dan pekerjaan untuk menjadi kompatibel. Implement perangkat harus menghubungi tim kompatibilitas Android seperti yang dijelaskan dalam Bagian 13 untuk mendapatkan klasifikasi untuk ember ukuran layar, kepadatan, dan faktor penskalaan. Ketika diberikan informasi ini, implementasi perangkat harus mengimplementasikannya sebagaimana ditentukan.

Perhatikan bahwa beberapa konfigurasi tampilan (seperti layar yang sangat besar atau sangat kecil, dan beberapa rasio aspek) pada dasarnya tidak kompatibel dengan Android 2.2; Oleh karena itu pelaksana perangkat didorong untuk menghubungi tim kompatibilitas Android sedini mungkin dalam proses pengembangan.

8.1.3. Metrik Tampilan

Implementasi perangkat harus melaporkan nilai yang benar untuk semua metrik tampilan yang didefinisikan dalam android.util.DisplayMetrics [ sumber daya, 26 ].

8.1.4. Dukungan layar yang dinyatakan

Aplikasi dapat menunjukkan ukuran layar mana yang mereka dukung melalui atribut <supports-screens> dalam file androidmanifest.xml. Implementasi perangkat harus menghormati aplikasi yang dinyatakan dengan benar untuk layar kecil, menengah, dan besar, seperti yang dijelaskan dalam dokumentasi Android SDK.

8.2. Papan ketik

Implementasi Perangkat:

Harus mencakup dukungan untuk kerangka kerja manajemen input (yang memungkinkan pengembang pihak ketiga untuk membuat mesin manajemen input - yaitu keyboard lunak) sebagaimana dirinci di pengembang.android.com
Harus memberikan setidaknya satu implementasi keyboard lunak (terlepas dari apakah ada keyboard yang keras)
Mungkin termasuk implementasi keyboard lunak tambahan
Mungkin termasuk keyboard perangkat keras
Tidak boleh menyertakan keyboard perangkat keras yang tidak cocok dengan salah satu format yang ditentukan dalam android.content.res.Configuration.keyboard [ Sumber Daya, 25 ] (yaitu, QWERTY, atau 12-KUNCI)

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 [ Sumber Daya, 25 ]

8.4. Orientasi layar

Perangkat yang kompatibel harus mendukung orientasi dinamis berdasarkan aplikasi untuk orientasi layar potret atau lansekap. Artinya, perangkat harus menghormati 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, kapan pun ditanya melalui android.content.res.configuration.orientation, android.view.display.getorientation (), atau API lainnya.

8.5. Masukan layar sentuh

Implementasi Perangkat:

Harus memiliki layar sentuh
Mungkin memiliki layar sentuh kapasatif atau resistif
Harus melaporkan nilai android.content.res.Configuration [ sumber daya, 25 ] yang mencerminkan sesuai dengan jenis layar sentuh spesifik pada perangkat
Harus mendukung pointer yang dilacak sepenuhnya secara mandiri, jika layar sentuh mendukung beberapa pointer

8.6. USB

Implementasi Perangkat:

Harus mengimplementasikan klien USB, dapat dihubungkan ke host USB dengan port USB-A standar
Harus mengimplementasikan jembatan debug Android melalui USB (seperti yang dijelaskan dalam Bagian 7)
Harus mengimplementasikan spesifikasi penyimpanan massal USB, untuk memungkinkan host yang terhubung ke perangkat untuk mengakses isi volume /sdcard
Harus menggunakan faktor bentuk mikro USB di sisi perangkat
Mungkin termasuk port non-standar di sisi perangkat, tetapi jika demikian harus dikirimkan dengan kabel yang mampu menghubungkan pinout khusus ke port USB-A standar
Harus menerapkan dukungan untuk spesifikasi penyimpanan massal USB (sehingga penyimpanan yang dapat dilepas atau tetap pada perangkat dapat diakses dari PC host)

Fungsi rumah, menu, dan punggung sangat penting untuk paradigma navigasi Android. Implementasi perangkat harus membuat fungsi -fungsi ini tersedia untuk pengguna setiap saat, terlepas dari status aplikasi. Fungsi -fungsi ini harus diimplementasikan melalui tombol khusus. Mereka dapat diimplementasikan menggunakan perangkat lunak, gerakan, panel sentuh, dll., Tetapi jika demikian, mereka harus selalu dapat diakses dan tidak mengaburkan atau mengganggu area tampilan aplikasi yang tersedia.

Implement perangkat juga harus menyediakan kunci pencarian khusus. Pelaksana perangkat juga dapat menyediakan kunci pengiriman dan akhir untuk panggilan telepon.

8.8. Jaringan Data Nirkabel

Implementasi perangkat harus mencakup dukungan untuk jaringan data berkecepatan tinggi nirkabel. Secara khusus, implementasi perangkat harus mencakup dukungan untuk setidaknya satu standar data nirkabel yang mampu 200kbit/detik atau lebih besar. Contoh teknologi yang memenuhi persyaratan ini termasuk EDGE, HSPA, EV-DO, 802.11g, dll.

Jika implementasi perangkat mencakup modalitas tertentu yang Android SDK menyertakan API (yaitu, WiFi, GSM, atau CDMA), implementasi harus mendukung API.

Perangkat dapat menerapkan lebih dari satu bentuk konektivitas data nirkabel. Perangkat dapat menerapkan konektivitas data kabel (seperti Ethernet), tetapi tetap harus mencakup setidaknya satu bentuk konektivitas nirkabel, seperti di atas.

8.9. Kamera

Implementasi perangkat harus menyertakan kamera yang menghadap ke belakang. Kamera yang disertakan menghadap ke belakang:

Harus memiliki resolusi setidaknya 2 megapiksel
Harus memiliki fokus otomatis perangkat keras, atau fokus otomatis perangkat lunak yang diimplementasikan di driver kamera (transparan ke perangkat lunak aplikasi)
Mungkin memiliki fokus tetap atau perangkat keras EDOF (kedalaman panjang bidang)
Mungkin termasuk flash. Jika kamera menyertakan FLASH_MODE_AUTO FLASH_MODE_ON lampu flash tidak boleh menyala saat instance android Objek Camera.Parameters . Perhatikan bahwa kendala ini tidak berlaku untuk aplikasi kamera sistem bawaan perangkat, tetapi hanya untuk aplikasi pihak ketiga menggunakan Camera.PreviewCallback .

Implementasi perangkat harus mengimplementasikan perilaku berikut untuk API terkait kamera:

Jika suatu aplikasi tidak pernah memanggil android.hardware.camera.parameters.setPreviewFormat (int), maka perangkat harus menggunakan android.hardware.pixelformat.ycbcr_420_sp untuk data pratinjau yang disediakan untuk panggilan balik aplikasi.
Jika suatu aplikasi mendaftarkan instance Android.hardware.camera.previewCallback dan sistem memanggil metode OnPreviewFrame () ketika format pratinjau adalah ycbcr_420_sp, data dalam byte [] diteruskan ke onPreviewFrame () harus lebih jauh dalam format encoding NV21. (Ini adalah format yang digunakan secara asli oleh keluarga perangkat keras 7K.) Yaitu, NV21 harus default.

Implementasi perangkat harus mengimplementasikan API kamera lengkap yang termasuk dalam dokumentasi Android 2.2 SDK [ Sumber Daya, 27 ]), terlepas dari apakah perangkat tersebut menyertakan fokus perangkat keras atau kemampuan lainnya. Misalnya, kamera yang tidak memiliki autofocus masih harus memanggil instance android.hardware.Camera.AutoFocusCallback terdaftar apa pun (meskipun ini tidak memiliki relevansi dengan kamera non-autofokus.)

Implementasi perangkat harus mengenali dan menghormati setiap nama parameter yang didefinisikan sebagai konstan pada kelas android.hardware.Camera.Parameters , jika perangkat keras yang mendasarinya mendukung fitur tersebut. Jika perangkat keras perangkat tidak mendukung fitur, API harus berperilaku seperti yang didokumentasikan. Sebaliknya, implementasi perangkat tidak boleh menghormati atau mengenali konstanta string yang diteruskan ke metode android.hardware.Camera.setParameters() selain yang didokumentasikan sebagai konstanta di android.hardware.Camera.Parameters . Artinya, implementasi perangkat harus mendukung semua parameter kamera standar jika perangkat keras memungkinkan, dan tidak boleh mendukung jenis parameter kamera khusus.

Implementasi perangkat dapat mencakup kamera yang menghadap ke depan. Namun, jika implementasi perangkat mencakup kamera yang menghadap ke depan, API kamera seperti yang diimplementasikan pada perangkat tidak boleh menggunakan kamera yang menghadap ke depan secara default. Artinya, API kamera di Android 2.2 hanya untuk kamera yang menghadap ke belakang, dan implementasi perangkat tidak boleh menggunakan kembali atau membebani API untuk bertindak pada kamera yang menghadap ke depan, jika ada yang ada. Perhatikan bahwa API khusus yang ditambahkan oleh pelaksana perangkat untuk mendukung kamera yang menghadap ke depan harus mematuhi bagian 3.5 dan 3.6; Misalnya, jika subkelas android.hardware.Camera atau Camera.Parameters . Perhatikan bahwa dimasukkannya kamera yang menghadap ke depan tidak memenuhi persyaratan bahwa perangkat menyertakan kamera yang menghadap ke belakang.

8.10. Akselerometer

Implementasi perangkat harus mencakup accelerometer 3-sumbu dan harus dapat memberikan acara pada 50 Hz atau lebih besar. Sistem koordinat yang digunakan oleh accelerometer harus mematuhi sistem koordinat sensor android sebagaimana dirinci dalam API Android (lihat [ Sumber Daya, 28 ]).

8.11. Kompas

Implementasi perangkat harus mencakup kompas 3-sumbu dan harus dapat memberikan acara 10 Hz atau lebih besar. Sistem koordinat yang digunakan oleh kompas harus mematuhi sistem koordinat sensor android sebagaimana didefinisikan dalam API Android (lihat [ Sumber Daya, 28 ]).

8.12. GPS

Implementasi perangkat harus mencakup penerima GPS, dan harus mencakup beberapa bentuk teknik "GPS" untuk meminimalkan waktu penguncian GPS.

8.13. Telepon

Android 2.2 dapat digunakan pada perangkat yang tidak termasuk perangkat keras telepon. Artinya, Android 2.2 kompatibel dengan perangkat yang bukan telepon. Namun, jika implementasi perangkat mencakup telepon GSM atau CDMA, ia harus menerapkan dukungan penuh untuk API untuk teknologi itu. Implementasi perangkat yang tidak termasuk perangkat keras telepon harus mengimplementasikan API penuh sebagai tidak ada ops.

Lihat juga Bagian 8.8, jaringan data nirkabel.

8.14. Memori dan Penyimpanan

Implementasi perangkat harus memiliki setidaknya 92MB memori yang tersedia untuk kernel dan ruang pengguna. 92MB harus merupakan tambahan untuk memori apa pun yang didedikasikan untuk komponen perangkat keras seperti radio, memori, dan sebagainya tidak ada di bawah kendali kernel.

Implementasi perangkat harus memiliki setidaknya 150MB penyimpanan yang tidak mudah menguap untuk data pengguna. Artinya, partisi /data harus setidaknya 150MB.

Di luar persyaratan di atas, implementasi perangkat harus memiliki setidaknya 128MB memori yang tersedia untuk kernel dan ruang pengguna, di samping memori apa pun yang didedikasikan untuk komponen perangkat keras yang tidak berada di bawah kendali kernel. Implementasi perangkat harus memiliki setidaknya 1GB penyimpanan yang tidak mudah menguap untuk data pengguna. Perhatikan bahwa persyaratan yang lebih tinggi ini direncanakan menjadi minimum yang sulit dalam versi Android di masa mendatang. Implementasi perangkat sangat dianjurkan untuk memenuhi persyaratan ini sekarang, atau mereka mungkin tidak memenuhi syarat untuk kompatibilitas untuk versi Android di masa depan.

8.15. Penyimpanan Bersama Aplikasi

Implementasi perangkat harus menawarkan penyimpanan bersama untuk aplikasi. Penyimpanan bersama yang disediakan harus berukuran setidaknya 2GB.

Implementasi perangkat harus dikonfigurasi dengan penyimpanan bersama yang dipasang secara default, "di luar kotak". Jika penyimpanan bersama tidak dipasang pada jalur Linux /sdcard , maka perangkat harus menyertakan tautan simbolik Linux dari /sdcard ke titik pemasangan yang sebenarnya.

Implementasi perangkat harus menegakkan seperti yang didokumentasikan izin android.permission.WRITE_EXTERNAL_STORAGE pada penyimpanan bersama ini. Penyimpanan bersama harus dapat ditulis dengan aplikasi apa pun yang memperoleh izin itu.

Implementasi perangkat mungkin memiliki perangkat keras untuk penyimpanan yang dapat dilepas yang dapat diakses pengguna, seperti kartu digital yang aman. Atau, implementasi perangkat dapat mengalokasikan penyimpanan internal (tidak dapat dilepas) sebagai penyimpanan bersama untuk aplikasi.

Terlepas dari bentuk penyimpanan bersama yang digunakan, penyimpanan bersama harus menerapkan penyimpanan massal USB, seperti yang dijelaskan dalam Bagian 8.6. Saat dikirim keluar dari kotak, penyimpanan bersama harus dipasang dengan sistem file lemak.

Ini adalah ilustratif untuk mempertimbangkan dua contoh umum. Jika implementasi perangkat mencakup slot kartu SD untuk memenuhi persyaratan penyimpanan bersama, ukuran kartu SD 2GB yang diformat lemak atau lebih besar harus 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 harus berukuran 2GB atau lebih besar, diformat sebagai lemak, dan dipasang pada /sdcard (OR /sdcard harus menjadi tautan simbolik ke lokasi fisik jika ada dipasang di tempat lain.)

Implementasi perangkat yang mencakup beberapa jalur penyimpanan bersama (seperti slot kartu SD dan penyimpanan internal bersama) harus memodifikasi aplikasi inti seperti pemindai media dan contentProvider untuk mendukung file yang ditempatkan di kedua lokasi secara transparan.

8.16. Bluetooth

Implementasi perangkat harus mencakup transceiver Bluetooth. Implementasi perangkat harus memungkinkan Bluetooth API berbasis RFCOMM seperti yang dijelaskan dalam dokumentasi SDK [ Sumber Daya, 30 ]. Implementasi perangkat harus mengimplementasikan profil Bluetooth yang relevan, seperti A2DP, AVRCP, OBEX, dll. Sesuai untuk perangkat.

Rangkaian uji kompatibilitas mencakup kasus yang mencakup operasi dasar API Android RFComm Bluetooth. Namun, karena Bluetooth adalah protokol komunikasi antar perangkat, ia tidak dapat sepenuhnya diuji dengan unit tes yang berjalan pada satu perangkat. Akibatnya, implementasi perangkat juga harus melewati prosedur uji Bluetooth yang digerakkan manusia yang dijelaskan dalam Lampiran A.

9. Kompatibilitas Kinerja

Salah satu tujuan dari program kompatibilitas Android adalah untuk memungkinkan pengalaman aplikasi yang konsisten bagi konsumen. Implementasi yang kompatibel harus memastikan tidak hanya bahwa aplikasi berjalan dengan benar pada perangkat, tetapi mereka melakukannya dengan kinerja yang wajar dan pengalaman pengguna yang baik secara keseluruhan. Implementasi perangkat harus memenuhi metrik kinerja utama perangkat kompatibel Android 2.2 yang ditentukan dalam tabel di bawah ini:

Metrik	Ambang kinerja	Komentar
Waktu peluncuran aplikasi	Aplikasi berikut harus diluncurkan dalam waktu yang ditentukan. Browser: kurang dari 1300ms MMS/SMS: Kurang dari 700ms Alarmclock: kurang dari 650ms	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 Dalvik VM, dan memanggil OnCreate.
Aplikasi simultan	Ketika beberapa aplikasi telah diluncurkan, meluncurkan kembali aplikasi yang sudah berjalan setelah diluncurkan harus memakan waktu kurang dari waktu peluncuran asli.

10. Kompatibilitas Model Keamanan

Implementasi perangkat harus mengimplementasikan model keamanan yang konsisten dengan model keamanan platform Android sebagaimana didefinisikan dalam dokumen referensi keamanan dan izin di API [ Sumber Daya, 29 ] dalam dokumentasi pengembang Android. Implementasi perangkat harus mendukung pemasangan 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 dalam sub-bagian berikut.

10.1. Izin

Implementasi perangkat harus mendukung model izin Android sebagaimana didefinisikan dalam dokumentasi pengembang Android [ Sumber Daya, 29 ]. Secara khusus, implementasi harus menegakkan setiap izin yang ditentukan seperti yang dijelaskan dalam dokumentasi SDK; Tidak ada izin yang dapat dihilangkan, diubah, atau diabaikan. Implementasi dapat menambahkan izin tambahan, asalkan string ID izin baru tidak ada di Android.* Namespace.

10.2. UID dan proses isolasi

Implementasi perangkat harus mendukung model Sandbox Aplikasi Android, di mana setiap aplikasi berjalan sebagai UID gaya Unix yang unik dan dalam proses yang terpisah. Implementasi perangkat harus mendukung menjalankan beberapa aplikasi sebagai ID pengguna Linux yang sama, asalkan aplikasi ditandatangani dan dibangun dengan benar, sebagaimana didefinisikan dalam referensi keamanan dan izin [ Sumber Daya, 29 ].

10.3. Izin Sistem File

Implementasi perangkat harus mendukung model izin akses file Android sebagaimana didefinisikan dalam sebagaimana didefinisikan dalam referensi keamanan dan izin [ Sumber Daya, 29 ].

10.4. Lingkungan eksekusi alternatif

Implementasi perangkat dapat mencakup lingkungan runtime yang menjalankan aplikasi menggunakan beberapa perangkat lunak atau teknologi lain selain mesin virtual Dalvik atau kode asli. Namun, lingkungan eksekusi alternatif seperti itu tidak boleh mengkompromikan model keamanan Android atau keamanan aplikasi Android yang diinstal, seperti yang dijelaskan dalam bagian ini.

Runtime alternatif harus sendiri aplikasi Android, dan mematuhi model keamanan Android standar, seperti yang dijelaskan di tempat lain di bagian 10.

Runtime alternatif tidak boleh diberikan akses ke sumber daya yang dilindungi oleh izin yang tidak diminta dalam file runtime androidmanifest.xml melalui mekanisme <uses-permission> .

Runtime alternatif tidak boleh mengizinkan aplikasi untuk menggunakan fitur yang dilindungi oleh izin android yang terbatas pada aplikasi sistem.

Runtime alternatif harus mematuhi model Android Sandbox. Secara khusus:

Alternatif RunTimes harus menginstal aplikasi melalui PackageManager ke kotak pasir Android yang terpisah (yaitu, ID Pengguna Linux, dll.)
Alternatif runtime dapat memberikan kotak pasir android tunggal yang dibagikan oleh semua aplikasi menggunakan runtime alternatif.
Alternatif runtime dan aplikasi yang diinstal menggunakan runtime alternatif tidak boleh menggunakan kembali kotak pasir dari aplikasi lain yang diinstal pada perangkat, kecuali melalui mekanisme android standar ID pengguna bersama dan sertifikat penandatanganan
Runtime alternatif tidak boleh diluncurkan dengan, memberikan, atau diberikan akses ke kotak pasir yang sesuai dengan aplikasi Android lainnya.

Runtime alternatif tidak boleh diluncurkan dengan, diberikan, atau diberikan kepada aplikasi lain setiap hak istimewa superuser (root), atau ID pengguna lainnya.

File .apk dari runtime alternatif dapat dimasukkan dalam gambar 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 persetujuan pengguna untuk izin Android yang digunakan oleh aplikasi. Yaitu, jika aplikasi perlu memanfaatkan sumber daya perangkat yang ada izin Android yang sesuai (seperti kamera, GPS, dll.), Runtime alternatif harus memberi tahu pengguna bahwa aplikasi akan dapat mengakses sumber daya itu . Jika lingkungan runtime tidak merekam kemampuan aplikasi dengan cara ini, lingkungan runtime harus mencantumkan semua izin yang dipegang oleh runtime itu sendiri saat menginstal aplikasi apa pun menggunakan runtime itu.

11. Suite Uji Kompatibilitas

Implementasi perangkat harus melewati Android Compatibility Test Suite (CTS) [ Sumber Daya, 2 ] yang tersedia dari proyek Open Source Android, menggunakan perangkat lunak pengiriman akhir pada perangkat. Selain itu, pelaksana perangkat harus menggunakan implementasi referensi di pohon open source Android sebanyak mungkin, dan harus memastikan kompatibilitas dalam kasus ambiguitas dalam CTS dan untuk setiap penerimaan kembali bagian -bagian dari kode sumber referensi.

CTS dirancang untuk dijalankan pada perangkat yang sebenarnya. Seperti halnya perangkat lunak apa pun, CTS itu sendiri mungkin mengandung bug. CTS akan diversi secara independen dari definisi kompatibilitas ini, dan beberapa revisi CTS dapat dirilis untuk Android 2.2. Implementasi perangkat harus lulus versi CTS terbaru yang tersedia pada saat perangkat lunak perangkat selesai.

12. Perangkat lunak yang dapat diperbarui

Implementasi perangkat harus mencakup mekanisme untuk menggantikan keseluruhan perangkat lunak sistem. Mekanisme tidak perlu melakukan peningkatan "langsung" - yaitu, perangkat restart mungkin diperlukan.

Metode apa pun dapat digunakan, asalkan dapat menggantikan keseluruhan perangkat lunak yang diinstal pada perangkat. Misalnya, salah satu dari pendekatan berikut akan memenuhi persyaratan ini:

Unduhan over-the-air (OTA) dengan pembaruan offline melalui reboot
Pembaruan "tertambat" melalui USB dari pc host
Pembaruan "offline" melalui reboot dan perbarui dari file di penyimpanan yang dapat dilepas

Mekanisme pembaruan yang digunakan harus mendukung pembaruan tanpa menyeka data pengguna. Perhatikan bahwa perangkat lunak Android hulu mencakup mekanisme pembaruan yang memenuhi persyaratan ini.

Jika kesalahan ditemukan dalam implementasi perangkat setelah telah dirilis tetapi dalam masa pakai produk yang wajar yang ditentukan dalam konsultasi dengan tim kompatibilitas Android untuk mempengaruhi kompatibilitas aplikasi partai, pelaksana perangkat harus memperbaiki kesalahan melalui perangkat lunak Pembaruan tersedia yang dapat diterapkan sesuai mekanisme yang baru saja dijelaskan.

13. Hubungi Kami

Anda dapat menghubungi penulis dokumen di kompatibilitas@android.com untuk klarifikasi dan untuk memunculkan masalah yang menurut Anda tidak mencakup dokumen tersebut.

Lampiran A - Prosedur Uji Bluetooth

Prosedur pengujian didasarkan pada aplikasi sampel BluetoothChat yang termasuk dalam pohon proyek open-source Android. Prosedur ini membutuhkan dua perangkat:

Implementasi perangkat kandidat yang menjalankan perangkat lunak yang akan diuji
Implementasi perangkat terpisah yang sudah diketahui kompatibel, dan model dari implementasi perangkat yang diuji - yaitu, implementasi perangkat yang "baik"

Prosedur pengujian di bawah ini masing -masing menyebut perangkat ini sebagai perangkat "kandidat" dan "diketahui baik".

Pengaturan dan Instalasi

Bangun bluetoothchat.apk melalui 'Buat Sampel' dari pohon kode sumber Android.
Instal bluetoothchat.apk pada perangkat yang dikenal baik.
Instal bluetoothchat.apk pada perangkat kandidat.

Uji kontrol bluetooth dengan aplikasi

Luncurkan Bluetoothchat di perangkat kandidat, sementara Bluetooth dinonaktifkan.
Pastikan perangkat kandidat menyalakan Bluetooth, atau meminta pengguna dengan dialog untuk menyalakan Bluetooth.

Uji pasangan dan komunikasi

Luncurkan aplikasi obrolan Bluetooth di kedua perangkat.
Buat perangkat yang dikenal baik dapat ditemukan dari dalam bluetoothchat (menggunakan menu).
Pada perangkat kandidat, pindai untuk perangkat Bluetooth dari dalam BluetoothChat (menggunakan menu) dan pasangkan dengan perangkat yang dikenal baik.
Send 10 or more messages from each device, and verify that the other device receives them correctly.
Close the BluetoothChat app on both devices by pressing Home .
Unpair each device from the other, using the device Settings app.

Test Pairing and Communication in the Reverse Direction

Launch the Bluetooth Chat app on both devices.
Make the candidate device discoverable from within BluetoothChat (using the Menu).
On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
Send 10 or messages from each device, and verify that the other device receives them correctly.
Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

Test Re-Launches

Re-launch the Bluetooth Chat app on both devices.
Send 10 or messages from each device, and verify that the other device receives them correctly.

Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.