Definisi Kompatibilitas Android 2.2

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

Daftar Isi

1. Pengantar
2. Referensi
3. Software
4. Referensi Kompatibilitas Software
5. Kompatibilitas Pengemasan Aplikasi
6. Kompatibilitas Multimedia
7. Kompatibilitas Alat Developer
8. Kompatibilitas Hardware
9. Kompatibilitas Performa
10. Kompatibilitas Model Keamanan
11. Compatibility Test Suite
12. Software yang Dapat Diupdate
13. Hubungi Kami
Lampiran A - Prosedur Pengujian Bluetooth

1. Pengantar

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

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

Seperti yang digunakan dalam dokumen ini, "penerapkan perangkat" atau "penerapkan" adalah orang atau organisasi yang mengembangkan solusi hardware/software yang menjalankan Android 2.2. "Penerapan perangkat" atau "penerapan" adalah solusi hardware/software 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 disertakan melalui referensi.
  • HARUS lulus Compatibility Test Suite (CTS) Android versi terbaru yang tersedia pada saat software implementasi perangkat selesai. (CTS tersedia sebagai bagian dari Project Open Source Android [Referensi, 2].) CTS menguji banyak, tetapi tidak semua, komponen yang diuraikan dalam dokumen ini.

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

2. Referensi

  1. Level Persyaratan IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  2. Ringkasan Program Kompatibilitas Android: http://source.android.com/docs/compatibility/index.html
  3. Project Open Source Android: http://source.android.com/
  4. Definisi dan dokumentasi API: http://developer.android.com/reference/packages.html
  5. Referensi Izin Android: http://developer.android.com/reference/android/Manifest.permission.html
  6. Referensi android.os.Build: http://developer.android.com/reference/android/os/Build.html
  7. String versi yang diizinkan Android 2.2: http://source.android.com/docs/compatibility/2.2/versions.html
  8. Class 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 Virtual Machine Dalvik: tersedia dalam kode sumber Android, di dalvik/docs
  11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  12. Notifikasi: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  13. Resource Aplikasi: http://code.google.com/android/reference/available-resources.html
  14. Panduan gaya ikon Status Bar: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  15. Pengelola Penelusuran: http://developer.android.com/reference/android/app/SearchManager.html
  16. Toast: http://developer.android.com/reference/android/widget/Toast.html
  17. Wallpaper Animasi: https://android-developers.googleblog.com/2010/02/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 Monkey: https://developer.android.com/studio/test/other-testing-tools/monkey
  23. Daftar Fitur Hardware Android: http://developer.android.com/reference/android/content/pm/PackageManager.html
  24. Mendukung Beberapa 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 resource ini berasal secara langsung atau tidak langsung dari Android 2.2 SDK, dan akan identik secara fungsional dengan informasi dalam dokumentasi SDK tersebut. Jika Definisi Kompatibilitas ini atau Compatibility Test Suite tidak sesuai dengan dokumentasi SDK, dokumentasi SDK dianggap kredibel. Setiap detail teknis yang diberikan dalam referensi yang disertakan di atas dianggap sebagai bagian dari Definisi Kompatibilitas ini.

3. Software

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

3.1. Kompatibilitas API Terkelola

Lingkungan eksekusi terkelola (berbasis Dalvik) adalah kendaraan utama untuk aplikasi Android. Application programming interface (API) Android adalah kumpulan antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan VM terkelola. Implementasi perangkat HARUS menyediakan implementasi lengkap, termasuk semua perilaku yang didokumentasikan, dari API yang didokumentasikan yang diekspos oleh Android 2.2 SDK [Referensi, 4].

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

3.2. Kompatibilitas Soft API

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

3.2.1. Izin

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

3.2.2. Parameter Build

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

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

3.2.3. Kompatibilitas Intent

Android menggunakan Intent untuk mencapai integrasi yang terikat longgar antar-aplikasi. Bagian ini menjelaskan persyaratan terkait pola Intent yang HARUS dipatuhi oleh implementasi perangkat. Dengan "dihormati", dimaksudkan bahwa implementator perangkat HARUS menyediakan Aktivitas atau Layanan Android yang menentukan filter Intent yang cocok dan mengikat serta menerapkan perilaku yang benar untuk setiap pola Intent yang ditentukan.

3.2.3.1. Intent Aplikasi Inti

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

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

Aplikasi berikut dianggap sebagai aplikasi sistem Android inti:

  • Jam Meja
  • Browser
  • Kalender
  • Kalkulator
  • Kamera
  • Kontak
  • Email
  • Galeri
  • GlobalSearch
  • Peluncur
  • LivePicker (yaitu, aplikasi pemilih Wallpaper Animasi; DAPAT dihilangkan jika perangkat tidak mendukung Wallpaper Animasi, sesuai dengan Bagian 3.8.5.)
  • Pesan (AKA "MMS")
  • Musik
  • Ponsel
  • Setelan
  • SoundRecorder

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

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

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

3.2.3.2. Penggantian Intent

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

3.2.3.3. Namespace Intent

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

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

3.2.3.4. Intent Siaran

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

3.3. Kompatibilitas API Native

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

  • libc (library C)
  • libm (library matematika)
  • Antarmuka JNI
  • libz (Kompresi Zlib)
  • liblog (logging Android)
  • Dukungan minimal untuk C++
  • Dukungan untuk OpenGL, seperti yang dijelaskan di bawah

Implementasi perangkat HARUS mendukung OpenGL ES 1.0. Perangkat yang tidak memiliki akselerasi hardware HARUS menerapkan OpenGL ES 1.0 menggunakan perender software. Implementasi perangkat HARUS mengimplementasikan OpenGL ES 1.1 sebanyak yang didukung hardware perangkat. Implementasi perangkat HARUS menyediakan implementasi untuk OpenGL ES 2.0, jika hardware mampu memberikan performa yang wajar pada API tersebut.

Library ini HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk arsitektur prosesor tertentu) dengan versi yang disediakan di Bionic oleh project Open Source Android. Karena implementasi Bionic tidak sepenuhnya kompatibel dengan implementasi lain seperti library GNU C, implementator perangkat HARUS menggunakan implementasi Android. Jika implementator perangkat menggunakan implementasi library yang berbeda, mereka HARUS memastikan kompatibilitas header, biner, dan perilaku.

Implementasi perangkat HARUS melaporkan Application Binary Interface (ABI) native yang didukung oleh perangkat secara akurat, melalui android.os.Build.CPU_ABI API. ABI HARUS merupakan 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 native sangat sulit. Oleh karena itu, perlu diulang bahwa pengimplementasi perangkat SANGAT disarankan untuk menggunakan implementasi upstream library yang tercantum di atas untuk membantu memastikan kompatibilitas.

3.4. Kompatibilitas Web

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

3.4.1. Kompatibilitas WebView

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

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

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

3.4.2. Kompatibilitas Browser

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

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

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

3.5. Kompatibilitas Perilaku API

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

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

Daftar di atas tidak lengkap, dan tanggung jawabnya ada pada pengimplementasi perangkat untuk memastikan kompatibilitas perilaku. Oleh karena itu, implementer perangkat HARUS menggunakan kode sumber yang tersedia melalui Project Open Source Android jika memungkinkan, bukan menerapkan ulang bagian penting sistem.

Compatibility Test Suite (CTS) menguji sebagian besar platform untuk kompatibilitas perilaku, tetapi tidak semuanya. Implementer bertanggung jawab untuk memastikan kompatibilitas perilaku dengan Project Open Source Android.

3.6. Namespace API

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

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

Modifikasi yang dilarang mencakup:

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

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

Implementator perangkat DAPAT menambahkan API kustom, tetapi API tersebut TIDAK BOLEH berada dalam namespace yang dimiliki oleh atau merujuk ke organisasi lain. Misalnya, implementer perangkat TIDAK BOLEH menambahkan API ke namespace com.google.* atau yang serupa; hanya Google yang dapat melakukannya. Demikian pula, Google TIDAK BOLEH menambahkan API ke namespace perusahaan lain.

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

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

3.7. Kompatibilitas Virtual Machine

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

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

3.8. Kompatibilitas Antarmuka Pengguna

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

3.8.1. Widget

Android menentukan jenis komponen serta API dan siklus proses yang sesuai yang memungkinkan aplikasi mengekspos "AppWidget" kepada pengguna akhir [Referensi, 11]. Rilis referensi Open Source Android menyertakan aplikasi Peluncur yang menyertakan elemen antarmuka pengguna yang memungkinkan pengguna menambahkan, melihat, dan menghapus AppWidget dari layar utama.

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

3.8.2. Notifikasi

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

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

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

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

Implementasi perangkat DAPAT mengirimkan antarmuka pengguna penelusuran alternatif, tetapi HARUS menyertakan tombol penelusuran khusus yang keras atau lunak, yang dapat digunakan kapan saja dalam aplikasi apa pun untuk memanggil framework penelusuran, dengan perilaku yang disediakan dalam dokumentasi API.

3.8.4. Toast

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

3.8.5. Wallpaper Animasi

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

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

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

4. Kompatibilitas Software Referensi

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

  • Kalkulator (disertakan dalam SDK)
  • Lunar Lander (disertakan dalam SDK)
  • Aplikasi "Aplikasi untuk Android" [Referensi, 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 dengan benar pada penerapan, agar penerapan dianggap kompatibel.

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

  • ApiDemos (disertakan dalam SDK)
  • ManualSmokeTests (disertakan dalam CTS)

Setiap kasus pengujian dalam aplikasi di atas HARUS berjalan dengan benar pada penerapan perangkat.

5. Kompatibilitas Pengemasan Aplikasi

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

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

6. Kompatibilitas Multimedia

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

6.1. Codec Media

Implementasi perangkat HARUS mendukung codec multimedia berikut. Semua codec ini disediakan sebagai implementasi software dalam implementasi Android yang dipilih dari Project Open Source Android.

Perlu diketahui bahwa baik Google maupun Open Handset Alliance tidak membuat pernyataan apa pun bahwa codec ini tidak terikat oleh paten pihak ketiga. Bagi yang ingin menggunakan kode sumber ini dalam produk hardware atau software, sebaiknya implementasi kode ini, termasuk dalam software open source atau shareware, mungkin memerlukan lisensi paten dari pemegang paten yang relevan.

Audio
Nama Encoder Decoder Detail Format File/Penampung
AAC LC/LTP   X Konten Mono/Stereo dalam kombinasi kecepatan bit standar apa pun hingga 160 kbps dan frekuensi sampling antara 8 hingga 48 kHz 3GPP (.3gp) dan MPEG-4 (.mp4, .m4a). Tidak ada dukungan untuk AAC mentah (.aac)
HE-AACv1 (AAC+)   X
HE-AACv2 (AAC+ ditingkatkan)   X
AMR-NB X X 4,75 hingga 12,2 kbps dengan sampel @ 8 kHz 3GPP (.3gp)
AMR-WB   X 9 frekuensi dari 6,60 kbit/dtk hingga 23,85 kbit/dtk dengan sampel @ 16 kHz 3GPP (.3gp)
MP3   X Mono/Stereo 8-320 Kbps konstan (CBR) atau kecepatan bit variabel (VBR) MP3 (.mp3)
MIDI   X MIDI Jenis 0 dan 1. DLS Versi 1 dan 2. XMF dan Mobile XMF. Dukungan untuk format nada dering RTTTL/RTX, OTA, dan iMelody Jenis 0 dan 1 (.mid, .xmf, .mxmf). Juga RTTTL/RTX (.rtttl, .rtx), OTA (.ota), dan iMelody (.imy)
Ogg Vorbis   X   Ogg (.ogg)
PCM   X PCM linear 8- dan 16-bit (frekuensi hingga batas hardware) WAVE (.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 tertentu untuk sebagian besar codec video. Alasannya adalah dalam praktiknya, hardware perangkat saat ini tidak selalu mendukung kecepatan bit yang dipetakan persis dengan kecepatan bit yang diperlukan yang ditentukan oleh standar yang relevan. Sebagai gantinya, penerapan perangkat HARUS mendukung kecepatan bit tertinggi yang praktis pada hardware, hingga batas yang ditentukan oleh spesifikasi.

6.2. Perekaman Audio

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

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

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

6.3. Latensi Audio

Latensi audio secara luas didefinisikan sebagai interval antara saat aplikasi meminta operasi perekaman atau pemutaran audio, dan saat implementasi perangkat benar-benar memulai operasi. Banyak class aplikasi mengandalkan latensi yang singkat, untuk mencapai efek real-time seperti efek suara atau komunikasi VOIP. Implementasi perangkat HARUS memenuhi semua persyaratan latensi audio yang diuraikan di bagian ini.

Untuk tujuan bagian ini:

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

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

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

Catatan: meskipun 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 bersifat opsional di Android 2.2, tetapi akan diperlukan oleh versi mendatang. Perangkat lama dan baru yang menjalankan Android 2.2 sangat disarankan untuk memenuhi persyaratan ini di Android 2.2, atau perangkat tersebut tidak akan dapat mencapai kompatibilitas Android saat diupgrade ke versi mendatang.

7. Kompatibilitas Alat Developer

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

  • Android Debug Bridge (dikenal sebagai adb) [Referensi, 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.
  • Dalvik Debug Monitor Service (dikenal sebagai ddms) [Referensi, 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 Android Debug Bridge, seperti di atas.
  • Monkey [Resources, 22]
    Implementasi perangkat HARUS menyertakan framework Monkey, dan membuatnya tersedia untuk digunakan aplikasi.

8. Kompatibilitas Hardware

Android ditujukan untuk mendukung pengimplementasi perangkat yang membuat faktor bentuk dan konfigurasi yang inovatif. Pada saat yang sama, developer Android mengharapkan hardware, sensor, dan API tertentu di semua perangkat Android. Bagian ini mencantumkan fitur hardware yang harus didukung oleh semua perangkat yang kompatibel dengan Android 2.2.

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

  • definisi class untuk API komponen HARUS ada
  • perilaku API HARUS diimplementasikan sebagai no-ops dengan cara yang wajar
  • Metode API HARUS menampilkan nilai null jika diizinkan oleh dokumentasi SDK
  • Metode API HARUS menampilkan implementasi no-op class jika nilai null tidak diizinkan oleh dokumentasi SDK

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

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

8.1. Tampilan

Android 2.2 menyertakan fasilitas yang melakukan operasi penskalaan dan transformasi otomatis tertentu dalam beberapa situasi, untuk memastikan aplikasi pihak ketiga berjalan cukup baik di berbagai konfigurasi hardware [Referensi, 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 class 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 resource dalam .apk yang tidak memiliki penentu kepadatan sebagai default ke "medium" (dikenal sebagai "mdpi" dalam dokumentasi SDK.)
  • Saat beroperasi di layar dengan kepadatan "rendah", implementasi perangkat HARUS menurunkan skala aset medium/mdpi dengan faktor 0,75.
  • Saat beroperasi di layar dengan kepadatan "tinggi", implementasi perangkat HARUS meningkatkan skala aset medium/mdpi dengan faktor 1,5.
  • Implementasi perangkat TIDAK BOLEH menskalakan aset dalam rentang kepadatan, dan HARUS menskalakan aset dengan faktor-faktor ini persis di antara rentang kepadatan.

8.1.2. Konfigurasi Layar Non-Standar

Konfigurasi tampilan yang tidak cocok dengan salah satu konfigurasi standar yang tercantum di Bagian 8.1.1 memerlukan pertimbangan dan upaya tambahan agar kompatibel. Implementator perangkat HARUS menghubungi Tim Kompatibilitas Android seperti yang dijelaskan di Bagian 13 untuk mendapatkan klasifikasi untuk bucket ukuran layar, kepadatan, dan faktor penskalaan. Jika diberikan informasi ini, penerapan perangkat HARUS menerapkannya seperti yang ditentukan.

Perhatikan bahwa beberapa konfigurasi layar (seperti layar yang sangat besar atau sangat kecil, dan beberapa rasio aspek) pada dasarnya tidak kompatibel dengan Android 2.2; oleh karena itu, pengimplementasi perangkat dianjurkan untuk menghubungi Tim Kompatibilitas Android sedini mungkin dalam proses pengembangan.

8.1.3. Metrik Display

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

8.1.4. Dukungan Layar yang Dideklarasikan

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

8.2. Keyboard

Implementasi perangkat:

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

8.3. Navigasi Non-sentuh

Implementasi perangkat:

  • DAPAT menghilangkan opsi navigasi non-sentuh (yaitu, dapat menghilangkan trackball, d-pad, atau roda)
  • HARUS melaporkan nilai yang benar untuk android.content.res.Configuration.navigation [Resources, 25]

8.4. Orientasi Layar

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

Perangkat HARUS melaporkan nilai yang benar untuk orientasi perangkat saat ini, setiap kali dikueri melalui android.content.res.Configuration.orientation, android.view.Display.getOrientation(), atau API lainnya.

8.5. Input layar sentuh

Implementasi perangkat:

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

8.6. USB

Implementasi perangkat:

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

8.7. Tombol navigasi

Fungsi Beranda, Menu, dan Kembali sangat penting untuk paradigma navigasi Android. Implementasi perangkat HARUS menyediakan fungsi ini kepada pengguna setiap saat, terlepas dari status aplikasi. Fungsi ini HARUS diterapkan melalui tombol khusus. Fitur ini DAPAT diterapkan menggunakan software, gestur, panel sentuh, dll., tetapi jika demikian, fitur ini HARUS selalu dapat diakses dan tidak menyembunyikan atau mengganggu area tampilan aplikasi yang tersedia.

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

8.8. Jaringan Data Nirkabel

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

Jika implementasi perangkat menyertakan modalitas tertentu yang Android SDK-nya 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 berkabel (seperti Ethernet), tetapi HARUS menyertakan setidaknya satu bentuk konektivitas nirkabel, seperti di atas.

8.9. Kamera

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

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

Implementasi perangkat HARUS menerapkan perilaku berikut untuk API terkait kamera:

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

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

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

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

8.10. Akselerometer

Implementasi perangkat HARUS menyertakan akselerometer 3 sumbu dan HARUS dapat mengirim peristiwa pada 50 Hz atau lebih tinggi. Sistem koordinat yang digunakan oleh akselerometer HARUS mematuhi sistem koordinat sensor Android seperti yang dijelaskan di Android API (lihat [Referensi, 28]).

8.11. Kompas

Implementasi perangkat HARUS menyertakan kompas 3 sumbu dan HARUS dapat mengirim peristiwa 10 Hz atau lebih tinggi. Sistem koordinat yang digunakan oleh kompas HARUS mematuhi sistem koordinat sensor Android seperti yang ditentukan dalam Android API (lihat [Referensi, 28]).

8.12. GPS

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

8.13. Telepon

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

Lihat juga Bagian 8.8, Jaringan Data Nirkabel.

8.14. Memori dan Penyimpanan

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

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

Selain persyaratan di atas, implementasi perangkat HARUS memiliki setidaknya memori 128 MB yang tersedia untuk kernel dan ruang pengguna, selain memori yang didedikasikan untuk komponen hardware yang tidak berada di bawah kontrol kernel. Implementasi perangkat HARUS memiliki penyimpanan non-volatil setidaknya 1 GB yang tersedia untuk data pengguna. Perhatikan bahwa persyaratan yang lebih tinggi ini direncanakan untuk menjadi minimum mutlak dalam versi Android mendatang. Penerapan perangkat sangat dianjurkan untuk memenuhi persyaratan ini sekarang, atau mungkin tidak memenuhi syarat untuk kompatibilitas dengan versi Android mendatang.

8.15. Penyimpanan Bersama Aplikasi

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

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

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

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

Terlepas dari bentuk penyimpanan bersama yang digunakan, penyimpanan bersama HARUS menerapkan penyimpanan massal USB, seperti yang dijelaskan di Bagian 8.6. Seperti yang dikirimkan dari kotak, penyimpanan bersama HARUS dipasang dengan sistem file FAT.

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

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

8.16. Bluetooth

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

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

9. Kompatibilitas Performa

Salah satu sasaran Program Kompatibilitas Android adalah untuk memungkinkan pengalaman aplikasi yang konsisten bagi konsumen. Implementasi yang kompatibel harus memastikan bahwa aplikasi tidak hanya berjalan dengan benar di perangkat, tetapi juga berjalan dengan performa yang wajar dan pengalaman pengguna yang baik secara keseluruhan. Implementasi perangkat HARUS memenuhi metrik performa utama perangkat yang kompatibel dengan Android 2.2 yang ditentukan dalam tabel di bawah:

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

10. Kompatibilitas Model Keamanan

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

10.1. Izin

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

10.2. Isolasi UID dan Proses

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

10.3. Izin Sistem File

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

10.4. Lingkungan Eksekusi Alternatif

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

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

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

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

Runtime alternatif HARUS mematuhi model sandbox Android. Khususnya:

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

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

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

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

11. Compatibility Test Suite (CTS)

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

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

12. Software yang Dapat Diupdate

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

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

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

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

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

13. Hubungi Kami

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

Lampiran A - Prosedur Pengujian Bluetooth

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

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

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

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

Penyiapan dan Pemasangan

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

Menguji Kontrol Bluetooth oleh Aplikasi

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

Menguji Penyambungan dan Komunikasi

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

Menguji Penyambungan dan Komunikasi dalam Arah Terbalik

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

Pengujian Peluncuran Ulang

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

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