Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Definisi Kompatibilitas Android 2.2

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

Hak Cipta © 2010, Google Inc. Semua hak dilindungi undang-undang.
compatibility@android.com

Daftar isi

1. Perkenalan
2. Sumber Daya
3. Perangkat Lunak
4. Kompatibilitas Perangkat Lunak Referensi
5. Kompatibilitas Kemasan Aplikasi
6. Kompatibilitas Multimedia
7. Kompatibilitas Alat Pengembang
8. Kompatibilitas Perangkat Keras
9. Kompatibilitas Kinerja
10. Kompatibilitas Model Keamanan
11. Suite Uji Kompatibilitas
12. Perangkat Lunak yang Dapat Diperbarui
13. Hubungi Kami
Lampiran A - Prosedur Tes Bluetooth

1. Perkenalan

Dokumen ini menyebutkan persyaratan yang harus dipenuhi agar ponsel kompatibel dengan Android 2.2.

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

Seperti yang digunakan dalam dokumen ini, "pelaksana perangkat" atau "pelaksana" 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/lunak yang dikembangkan sedemikian rupa.

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 Android Open Source Project [ Resources, 2 ].) CTS menguji banyak, tetapi tidak semua, komponen yang diuraikan dalam dokumen ini.

Jika definisi ini atau CTS tidak jelas, ambigu, atau tidak lengkap, merupakan tanggung jawab pelaksana perangkat untuk memastikan kompatibilitas dengan implementasi yang ada. Untuk alasan ini, Proyek Sumber Terbuka Android [ Resources, 3 ] merupakan referensi dan implementasi pilihan Android. Implementer perangkat sangat dianjurkan untuk mendasarkan implementasi mereka pada kode sumber "upstream" yang tersedia dari Android Open Source Project. Sementara beberapa komponen secara hipotetis dapat diganti dengan implementasi alternatif, praktik ini sangat tidak disarankan, karena lulus tes CTS akan menjadi jauh lebih sulit. Ini adalah tanggung jawab pelaksana untuk memastikan kompatibilitas perilaku penuh 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

  1. Tingkat Persyaratan IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  2. Ikhtisar Program Kompatibilitas Android: http://source.android.com/compatibility/index.html
  3. Proyek Sumber Terbuka Android: http://source.android.com/
  4. Definisi dan dokumentasi API: http://developer.android.com/reference/packages.html
  5. Referensi Izin Android: http://developer.android.com/reference/android/Manifest.permission.html
  6. referensi android.os.Build: http://developer.android.com/reference/android/os/Build.html
  7. String versi Android 2.2 yang diizinkan: http://source.android.com/compatibility/2.2/versions.html
  8. kelas android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  10. Spesifikasi Mesin Virtual Dalvik: tersedia dalam kode sumber Android, di dalvik/docs
  11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  12. Pemberitahuan: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  13. Sumber Daya Aplikasi: http://code.google.com/android/reference/available-resources.html
  14. Panduan gaya ikon Bilah Status: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  15. Manajer Pencarian: http://developer.android.com/reference/android/app/SearchManager.html
  16. Roti panggang: http://developer.android.com/reference/android/widget/Toast.html
  17. Wallpaper Hidup: http://developer.android.com/resources/articles/live-wallpapers.html
  18. Aplikasi untuk Android: http://code.google.com/p/apps-for-android
  19. Dokumentasi alat referensi (untuk adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  20. Deskripsi file apk Android: http://developer.android.com/guide/topics/fundamentals.html
  21. File manifes: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. Alat pengujian monyet: http://developer.android.com/guide/developing/tools/monkey.html
  23. Daftar Fitur Perangkat Keras Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
  24. Mendukung Banyak Layar: http://developer.android.com/guide/practices/screens_support.html
  25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  28. Ruang koordinat sensor: http://developer.android.com/reference/android/hardware/SensorEvent.html
  29. Referensi Keamanan dan Izin Android: http://developer.android.com/guide/topics/security/security.html
  30. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

Banyak dari sumber daya ini diturunkan secara langsung atau tidak langsung dari Android 2.2 SDK, dan secara fungsional akan identik dengan informasi dalam dokumentasi SDK tersebut. Dalam kasus apa pun di mana Definisi Kompatibilitas atau Suite Uji Kompatibilitas ini tidak setuju dengan dokumentasi SDK, dokumentasi SDK dianggap otoritatif. Detail teknis apa pun yang diberikan dalam referensi yang disertakan di atas dianggap dengan penyertaan sebagai bagian dari Definisi Kompatibilitas ini.

3. Perangkat Lunak

Platform Android mencakup satu set API terkelola, satu set API asli, dan badan yang disebut API "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 lainnya yang relevan. Implementasi perangkat HARUS mematuhi semua persyaratan di bagian ini.

3.1. Kompatibilitas API Terkelola

Lingkungan eksekusi yang dikelola (berbasis Dalvik) adalah kendaraan utama untuk aplikasi Android. Antarmuka pemrograman aplikasi Android (API) 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 semua API terdokumentasi yang diekspos oleh Android 2.2 SDK [ Resources, 4 ].

Implementasi perangkat TIDAK HARUS menghilangkan API terkelola, mengubah antarmuka atau tanda tangan API, menyimpang dari perilaku yang didokumentasikan, atau menyertakan larangan operasi, 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 hal-hal seperti Maksud, 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 menerapkan semua konstanta izin seperti yang didokumentasikan oleh halaman referensi Izin [ Sumber Daya, 5 ]. Perhatikan bahwa Bagian 10 mencantumkan persyaratan tambahan yang terkait dengan model keamanan Android.

3.2.2. Membangun Parameter

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 implementasi perangkat, tabel di bawah ini menyertakan batasan tambahan pada format nilai ini yang HARUS dipatuhi oleh implementasi 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 [ Resources, 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, bidang ini HARUS memiliki nilai integer 8.
android.os.Build.VERSION.INCREMENTAL Nilai yang dipilih oleh pelaksana perangkat yang menetapkan build spesifik dari sistem Android yang saat ini dijalankan, dalam format yang dapat dibaca manusia. Nilai ini TIDAK HARUS digunakan kembali untuk berbagai build yang tersedia untuk pengguna akhir. Penggunaan khas bidang ini adalah untuk menunjukkan nomor build atau pengidentifikasi perubahan kontrol sumber mana yang digunakan untuk menghasilkan build. Tidak ada persyaratan pada format khusus bidang ini, kecuali bahwa itu TIDAK BOLEH null atau string kosong ("").
android.os.Build.BOARD Nilai yang dipilih oleh pelaksana perangkat yang mengidentifikasi perangkat keras internal tertentu yang digunakan oleh perangkat, dalam format yang dapat dibaca manusia. Kemungkinan penggunaan bidang ini adalah untuk menunjukkan revisi spesifik dari papan yang memberi daya pada perangkat. Tidak ada persyaratan pada format khusus bidang ini, kecuali bahwa itu TIDAK BOLEH null atau string kosong ("").
android.os.Build.BRAND 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 pada format khusus bidang ini, kecuali bahwa itu TIDAK BOLEH 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 pada format khusus bidang ini, kecuali bahwa itu TIDAK BOLEH null atau string kosong ("").
android.os.Build.FINGERPRINT String yang secara unik mengidentifikasi build ini. Ini HARUS cukup dapat dibaca manusia. Ini HARUS mengikuti template ini:
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
Sebagai contoh:
acme/mydevice/generic/generic:2.2/ERC77/3359:userdebug/test-keys
Sidik jari TIDAK HARUS menyertakan karakter spasi putih. Jika bidang lain yang disertakan dalam template di atas memiliki karakter spasi, bidang tersebut HARUS diganti dalam sidik jari build dengan karakter lain, seperti karakter garis bawah ("_").
android.os.Build.HOST String yang secara unik mengidentifikasi host tempat build dibangun, dalam format yang dapat dibaca manusia. Tidak ada persyaratan pada format khusus bidang ini, kecuali bahwa itu TIDAK BOLEH null atau string kosong ("").
android.os.Build.ID Pengidentifikasi yang dipilih oleh pelaksana perangkat untuk merujuk ke rilis tertentu, dalam format yang dapat dibaca manusia. Bidang ini bisa sama dengan android.os.Build.VERSION.INCREMENTAL, tetapi HARUS menjadi nilai yang cukup berarti bagi pengguna akhir untuk membedakan antara pembuatan perangkat lunak. Tidak ada persyaratan pada format khusus bidang ini, kecuali bahwa itu TIDAK BOLEH null atau string kosong ("").
android.os.Build.MODEL Nilai yang dipilih oleh pelaksana perangkat yang berisi nama perangkat yang diketahui pengguna akhir. Ini HARUS dengan nama yang sama di mana perangkat dipasarkan dan dijual kepada pengguna akhir. Tidak ada persyaratan pada format khusus bidang ini, kecuali bahwa itu TIDAK BOLEH null atau string kosong ("").
android.os.Build.PRODUCT Nilai yang dipilih oleh pelaksana perangkat yang berisi nama pengembangan atau nama kode perangkat. HARUS dapat dibaca manusia, tetapi tidak dimaksudkan untuk dilihat oleh pengguna akhir. Tidak ada persyaratan pada format khusus bidang ini, kecuali bahwa itu TIDAK BOLEH null atau string kosong ("").
android.os.Build.TAGS Daftar tag yang dipisahkan koma yang dipilih oleh pelaksana perangkat yang lebih lanjut 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 build terjadi.
android.os.Build.TYPE Nilai yang dipilih oleh pelaksana perangkat yang menentukan konfigurasi waktu proses 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 pengguna (atau pengguna otomatis) yang membuat build. Tidak ada persyaratan pada format khusus bidang ini, kecuali bahwa itu TIDAK BOLEH null atau string kosong ("").

3.2.3. Kompatibilitas Niat

Android menggunakan Intents untuk mencapai integrasi yang digabungkan secara longgar antar aplikasi. Bagian ini menjelaskan persyaratan yang terkait dengan pola Intent yang HARUS dipenuhi oleh implementasi perangkat. Dengan "dihormati", ini berarti bahwa pelaksana perangkat HARUS menyediakan Aktivitas atau Layanan Android yang menetapkan 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 MUNGKIN mengganti aplikasi ini dengan versi alternatif.

Namun, versi alternatif seperti itu HARUS menghormati pola Intent yang sama yang disediakan oleh proyek upstream. 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 dianggap sebagai aplikasi inti sistem Android:

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

Aplikasi sistem Android inti mencakup berbagai Aktivitas, atau komponen 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 mengimplementasikan filter Intent yang sama pola sebagai aplikasi sistem Android inti.

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

3.2.3.2. Penimpaan Intent

Karena Android adalah platform yang dapat diperluas, pelaksana perangkat HARUS mengizinkan setiap pola Intent yang dirujuk di Bagian 3.2.3.1 untuk diganti oleh aplikasi pihak ketiga. Proyek open source Android hulu memungkinkan ini secara default; pelaksana perangkat TIDAK HARUS melampirkan hak istimewa khusus untuk 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 penonaktifan antarmuka pengguna "Pemilih" yang memungkinkan pengguna untuk memilih di antara beberapa aplikasi yang semuanya menangani pola Intent yang sama.

3.2.3.3. Ruang Nama Niat

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

Larangan ini analog 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 untuk memberi tahu mereka tentang perubahan di lingkungan perangkat keras atau perangkat lunak. Perangkat yang kompatibel dengan Android HARUS menyiarkan Intent siaran publik sebagai respons terhadap peristiwa sistem yang sesuai. Maksud 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 .so ELF 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 yang dijelaskan di bawah ini

Implementasi perangkat HARUS mendukung OpenGL ES 1.0. Perangkat yang tidak memiliki akselerasi perangkat keras HARUS mengimplementasikan OpenGL ES 1.0 menggunakan perender perangkat lunak. 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 Android Open Source. Karena implementasi Bionic tidak sepenuhnya kompatibel dengan implementasi lain seperti pustaka GNU C, pelaksana perangkat HARUS menggunakan implementasi Android. Jika pelaksana perangkat menggunakan implementasi yang berbeda dari pustaka ini, mereka HARUS memastikan kompatibilitas header, biner, dan perilaku.

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

Kompatibilitas kode asli menantang. Untuk alasan ini, harus diulangi bahwa pelaksana perangkat SANGAT dianjurkan untuk menggunakan implementasi upstream dari library yang tercantum di atas untuk membantu memastikan kompatibilitas.

3.4. Kompatibilitas Web

Banyak pengembang dan aplikasi mengandalkan perilaku kelas android.webkit.WebView [ Sumber Daya, 8 ] untuk antarmuka pengguna mereka, sehingga implementasi WebView harus kompatibel di seluruh implementasi Android. Demikian pula, pengalaman web lengkap sangat penting bagi 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 yang 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 yang komprehensif untuk sistem rendering web, pelaksana perangkat HARUS menggunakan versi hulu WebKit yang spesifik dalam implementasi WebView. Secara khusus:

  • Implementasi perangkat android.webkit.WebView implementasi HARUS didasarkan pada 533.1 WebKit build dari hierarki Android Open Source upstream untuk Android 2.2. Build ini mencakup serangkaian fungsionalitas dan perbaikan keamanan khusus untuk WebView. Pelaksana perangkat MUNGKIN menyertakan penyesuaian untuk implementasi WebKit; namun, penyesuaian tersebut TIDAK HARUS 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 lokal 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

Konfigurasi WebView HARUS menyertakan dukungan untuk database HTML5, cache aplikasi, dan API geolokasi [ Resources, 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 didasarkan pada WebKit, seperti yang dijelaskan di Bagian 3.4.1.

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

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

3.5. Kompatibilitas Perilaku API

Perilaku setiap jenis API (dikelola, lunak, asli, dan web) harus konsisten dengan implementasi yang disukai dari proyek sumber terbuka Android hulu [ Sumber Daya, 3 ]. Beberapa area kompatibilitas tertentu adalah:

  • Perangkat TIDAK HARUS mengubah perilaku atau arti dari Intent standar
  • Perangkat TIDAK HARUS mengubah siklus hidup atau semantik siklus hidup dari jenis komponen sistem tertentu (seperti Layanan, Aktivitas, Penyedia Konten, dll.)
  • Perangkat TIDAK HARUS mengubah semantik izin tertentu

Daftar di atas tidak lengkap, dan tanggung jawab ada pada pelaksana perangkat untuk memastikan kompatibilitas perilaku. Untuk alasan ini, pelaksana perangkat HARUS menggunakan kode sumber yang tersedia melalui Android Open Source Project jika memungkinkan, daripada mengimplementasikan kembali bagian penting dari sistem.

Compatibility Test Suite (CTS) menguji sebagian besar platform untuk kompatibilitas perilaku, tetapi tidak semua. Ini adalah tanggung jawab pelaksana untuk memastikan kompatibilitas perilaku dengan Android Open Source Project.

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 HARUS melakukan modifikasi terlarang (lihat di bawah) pada ruang nama paket ini:

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

Modifikasi yang dilarang meliputi:

  • Implementasi perangkat TIDAK HARUS memodifikasi API yang diekspos secara publik pada platform Android dengan mengubah metode atau tanda tangan kelas apa pun, atau dengan menghapus kelas atau bidang kelas.
  • Pelaksana perangkat DAPAT memodifikasi implementasi API yang mendasarinya, tetapi modifikasi tersebut TIDAK HARUS berdampak pada perilaku yang dinyatakan dan tanda tangan bahasa Java dari API apa pun yang diekspos secara publik.
  • Pelaksana perangkat TIDAK HARUS menambahkan elemen apa pun yang terbuka 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 didekorasi dengan penanda "@hide" di kode sumber Android upstream. Dengan kata lain, pelaksana perangkat TIDAK HARUS mengekspos API baru atau mengubah API yang ada di ruang nama yang disebutkan di atas. Pelaksana perangkat DAPAT membuat modifikasi internal saja, tetapi modifikasi tersebut TIDAK HARUS diiklankan atau diekspos ke pengembang.

Pelaksana perangkat DAPAT menambahkan API khusus, tetapi API semacam itu TIDAK HARUS berada di ruang nama yang dimiliki oleh atau merujuk ke organisasi lain. Misalnya, pelaksana perangkat TIDAK HARUS menambahkan API ke com.google.* atau namespace serupa; hanya Google yang dapat melakukannya. Demikian pula, Google TIDAK HARUS menambahkan API ke ruang nama perusahaan lain.

Jika pelaksana perangkat mengusulkan untuk meningkatkan salah satu ruang nama paket di atas (seperti dengan menambahkan fungsionalitas baru yang berguna ke API yang ada, atau menambahkan API baru), pelaksana HARUS mengunjungi source.android.com dan memulai proses untuk memberikan kontribusi perubahan dan kode, sesuai dengan informasi di situs itu.

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

3.7. Kompatibilitas Mesin Virtual

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

Implementasi perangkat dengan layar yang diklasifikasikan sebagai kepadatan sedang atau rendah HARUS mengonfigurasi Dalvik untuk mengalokasikan setidaknya 16 MB memori ke setiap aplikasi. Implementasi perangkat dengan layar yang diklasifikasikan sebagai high-density HARUS mengonfigurasi Dalvik untuk mengalokasikan setidaknya 24MB memori ke 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 untuk menghubungkan 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 ini.

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 Android Open Source menyertakan aplikasi Launcher yang menyertakan elemen antarmuka pengguna yang memungkinkan pengguna untuk menambahkan, melihat, dan menghapus AppWidgets dari layar beranda.

Pelaksana perangkat DAPAT mengganti alternatif untuk Peluncur referensi (yaitu layar beranda). Peluncur Alternatif HARUS menyertakan dukungan bawaan untuk AppWidgets, dan memaparkan 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; khusus: suara, getaran, cahaya dan status bar.

Selain itu, implementasi 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 ]. Pelaksana perangkat MUNGKIN memberikan pengalaman pengguna alternatif untuk pemberitahuan daripada yang disediakan oleh implementasi Android Open Source referensi; namun, sistem notifikasi alternatif tersebut HARUS mendukung sumber notifikasi yang ada, seperti di atas.

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

Implementasi perangkat HARUS menyertakan antarmuka pengguna pencarian tunggal, bersama, di seluruh sistem yang mampu memberikan saran waktu nyata dalam menanggapi masukan pengguna. Implementasi perangkat HARUS mengimplementasikan API yang memungkinkan pengembang menggunakan kembali antarmuka pengguna ini untuk menyediakan penelusuran dalam aplikasi mereka sendiri. Implementasi perangkat HARUS mengimplementasikan API yang memungkinkan aplikasi pihak ketiga menambahkan saran ke kotak pencarian saat 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 telusur web.

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

3.8.4. bersulang

Aplikasi dapat menggunakan "Toast" API (didefinisikan dalam [ Resources, 16 ]) untuk menampilkan string non-modal pendek kepada pengguna akhir, yang menghilang setelah periode waktu yang singkat. Implementasi perangkat HARUS menampilkan Toast dari aplikasi ke pengguna akhir dalam beberapa cara visibilitas tinggi.

3.8.5. Wallpaper Hidup

Android mendefinisikan tipe komponen dan API serta siklus hidup yang sesuai yang memungkinkan aplikasi mengekspos satu atau lebih "Wallpaper Animasi" ke pengguna akhir [ Sumber Daya, 17 ]. Live Wallpaper adalah animasi, pola, atau gambar serupa dengan kemampuan input 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 yang wajar tanpa pengaruh buruk pada aplikasi lain. Jika keterbatasan pada perangkat keras menyebabkan wallpaper dan/atau aplikasi mogok, tidak berfungsi, menggunakan CPU atau daya baterai yang berlebihan, atau berjalan pada frekuensi gambar yang sangat rendah, perangkat keras dianggap tidak mampu menjalankan wallpaper hidup. Sebagai contoh, beberapa wallpaper hidup 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 banyak 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 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 HARUS menerapkan wallpaper hidup.

4. Kompatibilitas Perangkat Lunak Referensi

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

  • Kalkulator (termasuk dalam SDK)
  • Lunar Lander (termasuk dalam SDK)
  • Aplikasi "Aplikasi untuk Android" [ Sumberdaya, 18 ].
  • Pulau Replika (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 implementasi, agar implementasi dianggap kompatibel.

Selain itu, implementasi perangkat HARUS menguji setiap item menu (termasuk semua sub-menu) dari masing-masing aplikasi uji asap ini:

  • 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 ".apk" Android 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 file tersebut tidak dapat diinstal dan berjalan dengan benar di perangkat lain yang kompatibel . Pelaksana perangkat HARUS menggunakan implementasi hulu referensi Dalvik, dan sistem manajemen paket implementasi referensi.

6. Kompatibilitas Multimedia

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

6.1. Codec Media

Implementasi perangkat HARUS mendukung codec multimedia berikut. Semua codec ini disediakan sebagai implementasi perangkat lunak dalam implementasi Android pilihan dari Proyek Sumber Terbuka Android.

Harap perhatikan bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan apa pun bahwa codec ini tidak dibebani oleh paten pihak ketiga. Mereka yang ingin menggunakan kode sumber ini dalam produk perangkat keras atau perangkat lunak disarankan bahwa penerapan kode ini, termasuk dalam perangkat lunak sumber terbuka atau perangkat berbagi, mungkin memerlukan lisensi paten dari pemegang paten yang relevan.

audio
Nama pembuat enkode Dekoder rincian Format File/Kontainer
AAC LC/LTP X Konten Mono/Stereo dalam kombinasi kecepatan bit standar hingga 160 kbps dan kecepatan pengambilan sampel antara 8 hingga 48kHz 3GPP (.3gp) dan MPEG-4 (.mp4, .m4a). Tidak ada dukungan untuk AAC mentah (.aac)
HE-AACv1 (AAC+) X
HE-AACv2 (AAC+ yang disempurnakan) X
AMR-NB X X 4,75 hingga 12,2 kbps sampel @ 8kHz 3GPP (.3gp)
AMR-WB X 9 tingkat dari 6,60 kbit/dtk hingga 23,85 kbit/dtk sampel @ 16kHz 3GPP (.3gp)
MP3 X Mono/Stereo 8-320Kbps konstan (CBR) atau variabel bit-rate (VBR) MP3 (.mp3)
MIDI X MIDI Tipe 0 dan 1. DLS Versi 1 dan 2. XMF dan XMF Seluler. Dukungan untuk format nada dering RTTTL/RTX, OTA, dan iMelody Ketik 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 (bernilai hingga batas perangkat keras) GELOMBANG (.wav)
Gambar
JPEG X X dasar + 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)
Profil Sederhana MPEG4 X File 3GPP (.3gp)

Perhatikan bahwa tabel di atas tidak mencantumkan persyaratan kecepatan bit khusus untuk sebagian besar codec video. Alasan untuk ini adalah bahwa dalam praktiknya, perangkat keras perangkat saat ini tidak selalu mendukung bitrate yang memetakan persis dengan bitrate yang diperlukan yang ditentukan oleh standar yang relevan. Sebaliknya, implementasi perangkat HARUS mendukung praktik bitrate tertinggi pada perangkat keras, hingga batas yang ditentukan oleh spesifikasi.

6.2. Rekaman audio

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

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

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

6.3. Latensi Audio

Latensi audio secara luas didefinisikan sebagai interval antara saat aplikasi meminta pemutaran audio atau operasi perekaman, dan saat 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 di bagian ini.

Untuk keperluan bagian ini:

  • "latensi keluaran dingin" didefinisikan sebagai interval antara saat aplikasi meminta pemutaran audio dan saat suara mulai diputar, saat sistem audio tidak digunakan dan dimatikan sebelum permintaan
  • "latensi keluaran hangat" didefinisikan sebagai interval antara saat aplikasi meminta pemutaran audio dan saat suara mulai diputar, saat sistem audio baru saja digunakan tetapi saat ini tidak digunakan (yaitu, diam)
  • "latensi keluaran berkelanjutan" didefinisikan 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" didefinisikan sebagai interval antara saat aplikasi meminta perekaman audio dan saat sampel pertama dikirim ke aplikasi melalui panggilan baliknya, saat sistem audio dan mikrofon tidak digunakan dan dimatikan sebelum permintaan
  • "latensi input berkelanjutan" didefinisikan ketika suara sekitar 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 keluaran dingin 100 milidetik atau kurang
  • latensi keluaran hangat 10 milidetik atau kurang
  • latensi keluaran terus menerus selama 45 milidetik atau kurang
  • latensi input dingin 100 milidetik atau kurang
  • latensi input terus menerus 50 milidetik atau kurang

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

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 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.
  • Layanan Monitor Debug Dalvik (dikenal sebagai ddms) [ Sumber Daya, 19 ]
    Implementasi perangkat HARUS mendukung semua fitur ddms seperti yang didokumentasikan di Android SDK. Karena ddms menggunakan adb , dukungan untuk ddms HARUS tidak aktif secara default, tetapi HARUS didukung setiap kali pengguna mengaktifkan Android Debug Bridge, seperti di atas.
  • Monyet [ Sumber Daya, 22 ]
    Implementasi perangkat HARUS menyertakan kerangka kerja Monkey, dan membuatnya tersedia untuk digunakan oleh aplikasi.

8. Kompatibilitas Perangkat Keras

Android ditujukan untuk mendukung pelaksana perangkat dalam menciptakan faktor bentuk dan konfigurasi yang 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 seperti yang didefinisikan dalam dokumentasi Android SDK. Jika API di SDK berinteraksi dengan komponen perangkat keras yang dinyatakan sebagai opsional dan implementasi perangkat tidak memiliki komponen tersebut:

  • definisi kelas untuk API komponen HARUS ada
  • perilaku API HARUS diimplementasikan sebagai tanpa operasi dengan cara yang wajar
  • Metode API HARUS mengembalikan nilai nol jika diizinkan oleh dokumentasi SDK
  • Metode API HARUS mengembalikan implementasi kelas tanpa operasi di mana nilai nol tidak diizinkan oleh dokumentasi SDK

Contoh umum skenario di mana persyaratan ini berlaku adalah API telepon: bahkan pada perangkat non-ponsel, API ini harus diimplementasikan sebagai larangan operasi yang wajar.

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

8.1. Menampilkan

Android 2.2 menyertakan fasilitas yang melakukan operasi penskalaan dan transformasi otomatis tertentu dalam beberapa keadaan, untuk memastikan bahwa aplikasi pihak ketiga berjalan dengan cukup baik pada berbagai konfigurasi perangkat keras [ Resources, 24 ]. Perangkat HARUS menerapkan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.

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

Jenis 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 [ Resources, 24 ].

Beberapa paket .apk memiliki manifes yang tidak mengidentifikasinya sebagai mendukung rentang kepadatan tertentu. Saat menjalankan aplikasi tersebut, batasan 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 kepadatan "rendah", implementasi perangkat HARUS mengurangi aset sedang/mdpi dengan faktor 0,75.
  • Saat beroperasi pada layar kepadatan "tinggi", implementasi perangkat HARUS meningkatkan aset medium/mdpi dengan faktor 1,5.
  • Implementasi perangkat TIDAK HARUS menskalakan aset dalam rentang kepadatan, dan HARUS menskalakan aset dengan tepat berdasarkan faktor-faktor ini di antara rentang kepadatan.

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 dan upaya tambahan agar kompatibel. Pelaksana perangkat HARUS menghubungi Tim Kompatibilitas Android seperti yang dijelaskan di Bagian 13 untuk mendapatkan klasifikasi bucket ukuran layar, kepadatan, dan faktor penskalaan. Saat diberikan informasi ini, implementasi perangkat HARUS mengimplementasikannya seperti yang 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 dihimbau 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 ditentukan di android.util.DisplayMetrics [ Sumber Daya, 26 ].

8.1.4. Dukungan Layar yang Dideklarasikan

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

8.2. Papan ketik

Implementasi perangkat:

  • HARUS menyertakan dukungan untuk Kerangka Manajemen Input (yang memungkinkan pengembang pihak ketiga untuk membuat Mesin Manajemen Input -- yaitu keyboard lunak) sebagaimana dirinci di developer.android.com
  • HARUS menyediakan setidaknya satu implementasi keyboard lunak (terlepas dari apakah keyboard keras ada)
  • MUNGKIN menyertakan implementasi keyboard lunak tambahan
  • MUNGKIN termasuk keyboard perangkat keras
  • TIDAK HARUS menyertakan keyboard perangkat keras yang tidak cocok dengan salah satu format yang ditentukan dalam android.content.res.Configuration.keyboard [ Resources, 25 ] (yaitu, QWERTY, atau 12-key)

8.3. Navigasi Non-sentuh

Implementasi perangkat:

  • MUNGKIN 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, 25 ]

8.4. Orientasi layar

Perangkat yang kompatibel HARUS mendukung orientasi dinamis oleh aplikasi ke orientasi layar potret atau lanskap. Artinya, perangkat harus menghormati permintaan aplikasi untuk orientasi layar tertentu. Implementasi perangkat MUNGKIN memilih orientasi potret atau lanskap sebagai default.

Perangkat HARUS melaporkan nilai yang benar untuk orientasi perangkat saat ini, setiap kali ditanyakan 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 kapasitif atau resistif
  • HARUS melaporkan nilai android.content.res.Configuration [ Resources, 25 ] yang sesuai dengan jenis layar sentuh tertentu pada perangkat
  • HARUS mendukung pointer yang dilacak sepenuhnya secara independen, jika layar sentuh mendukung banyak pointer

8.6. USB

Implementasi perangkat:

  • HARUS menerapkan klien USB, dapat dihubungkan ke host USB dengan port USB-A standar
  • HARUS mengimplementasikan Android Debug Bridge melalui USB (seperti yang dijelaskan di Bagian 7)
  • HARUS menerapkan spesifikasi penyimpanan massal USB, untuk memungkinkan 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 dikirimkan dengan kabel yang mampu menghubungkan pinout kustom ke port USB-A standar
  • HARUS menerapkan dukungan untuk spesifikasi Penyimpanan Massal USB (sehingga penyimpanan yang dapat dilepas atau disimpan pada perangkat dapat diakses dari PC host)

8.7. Tombol navigasi

Fungsi Home, Menu dan Back sangat penting untuk paradigma navigasi Android. Implementasi perangkat HARUS membuat fungsi ini tersedia bagi pengguna setiap saat, terlepas dari status aplikasi. Fungsi-fungsi ini HARUS diimplementasikan melalui tombol khusus. Mereka MUNGKIN 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.

Pelaksana perangkat HARUS juga menyediakan kunci pencarian khusus. Pelaksana perangkat MUNGKIN juga menyediakan tombol kirim dan akhiri untuk panggilan telepon.

8.8. Jaringan Data Nirkabel

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

Jika implementasi perangkat menyertakan modalitas tertentu di mana Android SDK menyertakan API (yaitu, WiFi, GSM, atau CDMA), implementasi HARUS mendukung API.

Perangkat MUNGKIN menerapkan lebih dari satu bentuk konektivitas data nirkabel. Perangkat MUNGKIN menerapkan konektivitas data kabel (seperti Ethernet), tetapi HARUS tetap menyertakan setidaknya satu bentuk konektivitas nirkabel, seperti di atas.

8.9. Kamera

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

  • HARUS memiliki resolusi minimal 2 megapiksel
  • HARUS memiliki fokus otomatis perangkat keras, atau fokus otomatis perangkat lunak yang diterapkan di driver kamera (transparan ke perangkat lunak aplikasi)
  • MUNGKIN memiliki perangkat keras fokus tetap atau EDOF (extended depth of field)
  • MUNGKIN termasuk flash. Jika Kamera menyertakan blitz, lampu blitz HARUS TIDAK menyala saat instance android.hardware.Camera.PreviewCallback telah didaftarkan pada permukaan pratinjau Kamera, kecuali jika aplikasi secara eksplisit mengaktifkan blitz dengan mengaktifkan atribut FLASH_MODE_AUTO atau FLASH_MODE_ON dari a Camera.Parameters . Objek Parameter. Perhatikan bahwa batasan ini tidak berlaku untuk aplikasi kamera sistem bawaan perangkat, tetapi hanya untuk aplikasi pihak ketiga yang menggunakan Camera.PreviewCallback .

Implementasi perangkat HARUS menerapkan perilaku berikut untuk API terkait kamera:

  1. Jika aplikasi tidak pernah memanggil android.hardware.Camera.Parameters.setPreviewFormat(int), maka perangkat HARUS menggunakan android.hardware.PixelFormat.YCbCr_420_SP untuk data pratinjau yang diberikan ke callback aplikasi.
  2. Jika aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() saat format pratinjau adalah YCbCr_420_SP, data dalam byte[] yang diteruskan ke onPreviewFrame() selanjutnya harus dalam format enkode NV21. (Ini adalah format asli yang digunakan oleh keluarga perangkat keras 7k.) Artinya, NV21 HARUS menjadi default.

Implementasi perangkat HARUS menerapkan API Kamera lengkap yang disertakan dalam dokumentasi Android 2.2 SDK [ Sumber Daya, 27 ]), terlepas dari apakah perangkat menyertakan fokus otomatis perangkat keras atau kemampuan lainnya. Misalnya, kamera yang tidak memiliki fokus otomatis HARUS tetap memanggil instance android.hardware.Camera.AutoFocusCallback yang terdaftar (meskipun ini tidak memiliki relevansi dengan kamera non-fokus otomatis.)

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

Implementasi perangkat MUNGKIN termasuk kamera menghadap ke depan. Namun, jika implementasi perangkat menyertakan kamera depan, API kamera seperti yang diterapkan pada perangkat TIDAK HARUS menggunakan kamera depan secara default. Artinya, API kamera di Android 2.2 hanya untuk kamera yang menghadap ke belakang, dan implementasi perangkat TIDAK HARUS menggunakan kembali atau membebani API untuk bertindak pada kamera yang menghadap ke depan, jika ada. Perhatikan bahwa setiap API khusus yang ditambahkan oleh pelaksana perangkat untuk mendukung kamera depan HARUS mematuhi bagian 3.5 dan 3.6; misalnya, jika subkelas android.hardware.Camera atau Camera.Parameters khusus disediakan untuk mendukung kamera menghadap ke depan, subkelas tersebut TIDAK HARUS ditempatkan di namespace yang ada, seperti yang dijelaskan oleh bagian 3.5 dan 3.6. Perhatikan bahwa penyertaan kamera menghadap ke depan tidak memenuhi persyaratan bahwa perangkat menyertakan kamera menghadap ke belakang.

8.10. Akselerometer

Implementasi perangkat HARUS menyertakan akselerometer 3-sumbu dan HARUS dapat mengirimkan peristiwa pada 50 Hz atau lebih besar. Sistem koordinat yang digunakan oleh akselerometer HARUS sesuai dengan sistem koordinat sensor Android seperti yang dijelaskan dalam API Android (lihat [ Sumberdaya, 28 ]).

8.11. Kompas

Implementasi perangkat HARUS menyertakan kompas 3-sumbu dan HARUS dapat mengirimkan peristiwa 10 Hz atau lebih besar. Sistem koordinat yang digunakan oleh kompas HARUS sesuai dengan sistem koordinat sensor Android seperti yang didefinisikan dalam Android API (lihat [ Sumberdaya, 28 ]).

8.12. GPS

Implementasi perangkat HARUS menyertakan penerima GPS, dan HARUS menyertakan beberapa bentuk teknik "GPS terbantu" untuk meminimalkan waktu penguncian GPS.

8.13. Telepon

Android 2.2 DAPAT digunakan pada perangkat yang tidak menyertakan perangkat keras telepon. Artinya, Android 2.2 kompatibel dengan perangkat yang bukan ponsel. Namun, jika implementasi perangkat menyertakan telepon GSM atau CDMA, perangkat tersebut HARUS menerapkan dukungan penuh untuk API untuk teknologi tersebut. Implementasi perangkat yang tidak menyertakan perangkat keras telepon HARUS mengimplementasikan API lengkap sebagai tanpa operasi.

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 sebagai tambahan untuk setiap memori yang didedikasikan untuk komponen perangkat keras seperti radio, memori, dan sebagainya yang tidak berada di bawah kendali kernel.

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

Di luar persyaratan di atas, implementasi perangkat HARUS memiliki setidaknya 128 MB memori yang tersedia untuk kernel dan ruang pengguna, selain memori yang didedikasikan untuk komponen perangkat keras yang tidak berada di bawah kendali kernel. Implementasi perangkat HARUS memiliki setidaknya 1 GB penyimpanan non-volatil yang tersedia untuk data pengguna. Perhatikan bahwa persyaratan yang lebih tinggi ini direncanakan untuk menjadi persyaratan minimum di versi Android yang akan datang. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

8.15. Application Shared Storage

Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 2GB in size.

Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps.

Regardless of the form of shared storage used, the shared storage MUST implement USB mass storage, as described in Section 8.6. As shipped out of the box, the shared storage MUST be mounted with the FAT filesystem.

It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 2GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 2GB in size or larger, formatted as FAT, and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

8.16. Bluetooth

Device implementations MUST include a Bluetooth transceiver. Device implementations MUST enable the RFCOMM-based Bluetooth API as described in the SDK documentation [ Resources, 30 ]. Device implementations SHOULD implement relevant Bluetooth profiles, such as A2DP, AVRCP, OBEX, etc. as appropriate for the device.

The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-driven Bluetooth test procedure described in Appendix A.

9. Performance Compatibility

One of the goals of the Android Compatibility Program is to enable consistent application experience to consumers. Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.2 compatible device defined in the table below:

Metric Performance Threshold Komentar
Application Launch Time The following applications should launch within the specified time.
  • Browser: less than 1300ms
  • MMS/SMS: less than 700ms
  • AlarmClock: less than 650ms
The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
Simultaneous Applications When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

10. Security Model Compatibility

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 29 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

10.1. Izin

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 29 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

10.2. UID and Process Isolation

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 29 ].

10.3. Filesystem Permissions

Device implementations MUST support the Android file access permissions model as defined in as defined in the Security and Permissions reference [ Resources, 29 ].

10.4. Alternate Execution Environments

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 10.

Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

Alternate runtimes MUST abide by the Android sandbox model. Secara khusus:

  • Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
  • Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime.
  • Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
  • Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications.

Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource. If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

11. Compatibility Test Suite

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 2.2. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

12. Updatable Software

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades -- that is, a device restart MAY be required.

Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

  • Over-the-air (OTA) downloads with offline update via reboot
  • "Tethered" updates over USB from a host PC
  • "Offline" updates via a reboot and update from a file on removable storage

The update mechanism used MUST support updates without wiping user data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of thid-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

13. Contact Us

You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.

Appendix A - Bluetooth Test Procedure

The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-driven Bluetooth test procedure described below.

The test procedure is based on the BluetoothChat sample app included in the Android open-source project tree. The procedure requires two devices:

  • a candidate device implementation running the software build to be tested
  • a separate device implementation already known to be compatible, and of a model from the device implementation being tested -- that is, a "known good" device implementation

The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

Setup and Installation

  1. Build BluetoothChat.apk via 'make samples' from an Android source code tree.
  2. Install BluetoothChat.apk on the known-good device.
  3. Install BluetoothChat.apk on the candidate device.

Test Bluetooth Control by Apps

  1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
  2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

Test Pairing and Communication

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
  3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
  4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
  5. Close the BluetoothChat app on both devices by pressing Home .
  6. Unpair each device from the other, using the device Settings app.

Test Pairing and Communication in the Reverse Direction

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

Test Re-Launches

  1. Re-launch the Bluetooth Chat app on both devices.
  2. 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.