Definisi Kompatibilitas Android 2.1

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

1. Pengantar

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

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

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

Agar dianggap kompatibel dengan Android 2.1, 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. Tingkat Persyaratan IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  2. Ringkasan Program Kompatibilitas Android: http://source.android.com/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.1: http://source.android.com/docs/compatibility/2.1/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. Referensi 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. Mendukung Beberapa Layar: http://developer.android.com/guide/practices/screens_support.html
  24. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  25. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  26. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  27. Ruang koordinat sensor: http://developer.android.com/reference/android/hardware/SensorEvent.html
  28. Referensi Keamanan dan Izin Android: http://developer.android.com/guide/topics/security/security.html
  29. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

Banyak resource ini berasal secara langsung atau tidak langsung dari Android 2.1 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.1 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.1. 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.1, kolom ini HARUS memiliki nilai bilangan bulat 7.
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 dikirimkan kepada 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.1-update1/ERC77/3359:userdebug/test-keys
Sidik jari TIDAK BOLEH berisi spasi. Jika kolom lain yang disertakan dalam template di atas memiliki spasi, kolom tersebut HARUS diganti dengan karakter garis bawah ASCII ("_") dalam sidik jari.
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 ditentukan di aplikasi sistem inti 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.

Catatan: bagian ini diubah oleh Erratum EX6580.

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 API

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. Implementasi Open Source Android menggunakan mesin rendering WebKit untuk menerapkan WebView.

Karena tidak memungkinkan untuk mengembangkan rangkaian pengujian yang komprehensif untuk browser web, pengimplementasi perangkat HARUS menggunakan build upstream WebKit tertentu dalam implementasi WebView. Khususnya:

  • WebView HARUS menggunakan build WebKit 530.17 dari hierarki Android Open Source upstream untuk Android 2.1. Build ini mencakup serangkaian fungsi dan perbaikan keamanan tertentu untuk WebView.
  • String agen pengguna yang dilaporkan oleh WebView HARUS dalam format ini:
    Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17
    • 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

Implementasi DAPAT mengirimkan string agen pengguna kustom di aplikasi browser mandiri. Selain itu, Browser mandiri DAPAT didasarkan pada teknologi browser alternatif (seperti Firefox, Opera, dll.) Namun, meskipun aplikasi Browser alternatif dikirimkan, komponen WebView yang disediakan untuk aplikasi pihak ketiga HARUS didasarkan pada WebKit, seperti di atas.

Konfigurasi WebView HARUS menyertakan dukungan untuk database HTML5, cache aplikasi, dan API geolokasi [Referensi, 9]. WebView HARUS menyertakan dukungan untuk tag <video> HTML5 dalam beberapa bentuk. Aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream atau pengganti pihak ketiga) HARUS menyertakan dukungan untuk fitur HTML5 yang sama yang baru saja tercantum untuk WebView.

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 HARUS mengonfigurasi Dalvik untuk mengalokasikan setidaknya 16 MB memori ke setiap aplikasi di perangkat dengan layar yang diklasifikasikan sebagai kepadatan sedang atau rendah. Implementasi perangkat HARUS mengonfigurasi Dalvik untuk mengalokasikan setidaknya memori 24 MB ke setiap aplikasi di perangkat dengan layar yang diklasifikasikan sebagai padat. Perhatikan bahwa implementasi perangkat DAPAT mengalokasikan lebih banyak memori daripada angka ini, tetapi tidak diwajibkan.

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].

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

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.1.

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.

8.1. Tampilan

Android 2.1 menyertakan fasilitas yang melakukan operasi penskalaan dan transformasi otomatis tertentu dalam beberapa situasi, untuk memastikan bahwa aplikasi pihak ketiga berjalan cukup baik di berbagai konfigurasi hardware [Referensi, 23]. Perangkat HARUS menerapkan perilaku ini dengan benar, seperti yang dijelaskan di bagian ini.

Untuk Android 2.1, 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 disediakan di Bagian 12 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 tampilan (seperti layar yang sangat besar atau sangat kecil, dan beberapa rasio aspek) pada dasarnya tidak kompatibel dengan Android 2.1; 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 [Resource, 25].

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, 24] (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, 24]

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, 24] yang mencerminkan jenis layar sentuh tertentu di perangkat

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

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. Kamera yang disertakan:

  • HARUS memiliki resolusi minimal 2 megapiksel
  • HARUS memiliki fokus otomatis hardware, atau fokus otomatis software yang diterapkan di driver kamera (transparan untuk software aplikasi)
  • DAPAT memiliki hardware fokus tetap atau EDOF (extended depth of field)
  • DAPAT menyertakan flash. Jika Kamera menyertakan flash, lampu flash TIDAK 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 menerapkan Camera API lengkap yang disertakan dalam dokumentasi Android 2.1 SDK [Referensi, 26]), 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, kecuali jika konstanta diawali dengan string yang menunjukkan nama implementor perangkat. Artinya, implementasi perangkat HARUS mendukung semua parameter Kamera standar jika hardware mengizinkan, dan TIDAK BOLEH mendukung jenis parameter Kamera kustom kecuali nama parameter ditunjukkan dengan jelas melalui awalan string agar tidak standar.

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, 27]).

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, 27]).

8.12. GPS

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

8.13. Telepon

Android 2.1 DAPAT digunakan di perangkat yang tidak menyertakan hardware telefoni. Artinya, Android 2.1 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.

Catatan: bagian ini diubah oleh Erratum EX6580.

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 dan dipasang di /sdcard (atau /sdcard HARUS berupa link simbolis ke lokasi fisik jika dipasang di tempat lain.)

Catatan: bagian ini ditambahkan oleh Erratum EX6580.

8.16. Bluetooth

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

Catatan: bagian ini ditambahkan oleh Erratum EX6580.

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.1 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, 28] 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, 28]. 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, 28].

10.3. Izin Sistem File

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

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.1. 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.