Definisi Kompatibilitas Android 2.1

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

1. Perkenalan

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

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

Seperti yang digunakan dalam dokumen ini, "implementer perangkat" atau "implementer" adalah orang atau organisasi yang mengembangkan solusi perangkat keras/perangkat lunak yang menjalankan Android 2.1. Sebuah "implementasi perangkat" atau "implementasi" adalah solusi perangkat keras/perangkat lunak 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 digabungkan melalui referensi.
  • HARUS lulus versi terbaru dari Android Compatibility Test Suite (CTS) yang tersedia pada saat perangkat lunak implementasi perangkat selesai. (CTS tersedia sebagai bagian dari Proyek Sumber Terbuka Android [ Sumber Daya, 2 ].) CTS menguji banyak, namun tidak semua, komponen yang diuraikan dalam dokumen ini.

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

2. Sumber Daya
  • Tingkat Persyaratan IETF RFC2119: http://www.ietf.org/rfc/rfc2119.txt
  • Ikhtisar Program Kompatibilitas Android: http://source.android.com/compatibility/index.html
  • Proyek Sumber Terbuka Android: http: //source.android.com/
  • Definisi dan dokumentasi API: http://developer.android.com/reference/packages.html
  • Referensi Izin Android: http://developer.android.com/reference/android/Manifest.permission. html
  • referensi android.os.Build: http://developer.android.com/reference/android/os/Build.html
  • Android 2.1 string versi yang diizinkan: http://source.android.com/docs/compatibility/2.1/versions .html
  • kelas android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5: http://www.whatwg.org/specs/web-apps/current-work/ multihalaman/
  • Spesifikasi Mesin Virtual Dalvik: tersedia dalam kode sumber Android, di dalvik/docs
    •
  • AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  • Pemberitahuan: http://developer.android.com /guide/topics/ui/notifiers/notifications.html
  • Sumber Daya Aplikasi: http://code.google.com/android/reference/available-resources.html
  • Panduan gaya ikon Bilah Status: http://developer.android.com/ guide/practices/ui_guideline /icon_design.html#statusbarstructure
  • Manajer Pencarian: http://developer.android.com/reference/android/app/SearchManager.html
  • Bersulang: http://developer.android.com/reference/android/widget /Toast.html
  • Wallpaper Animasi: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  • Aplikasi untuk Android: http://code.google.com/p/apps-for-android
  • Referensi dokumentasi alat (untuk adb, aapt, ddms): http://developer.android.com/guide/developing/tools/index.html
  • Deskripsi file apk Android: http://developer.android.com/guide/topics/fundamentals .html
  • File manifes: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  • Alat pengujian monyet: https://developer.android.com/studio/test/other-testing-tools/ monyet
  • Mendukung Banyak Layar: http://developer.android.com/guide/practices/screens_support.html
  • android.content.res.Konfigurasi: http://developer.android.com/reference/android/content/res/Configuration. html
  • android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  • android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera. html
  • Ruang koordinat sensor: http://developer.android.com/reference/android/hardware/SensorEvent.html
  • Referensi Keamanan dan Izin Android: http://developer.android.com/guide/topics/security/security.html
  • Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

    3. Perangkat Lunak

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

    3.1. Kompatibilitas API Terkelola

    Lingkungan eksekusi terkelola (berbasis Dalvik) adalah sarana utama untuk aplikasi Android. Antarmuka pemrograman aplikasi (API) Android adalah kumpulan antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan VM terkelola. Implementasi perangkat HARUS menyediakan implementasi lengkap, termasuk semua perilaku yang terdokumentasi, dari setiap API terdokumentasi yang diekspos oleh Android 2.1 SDK [ Sumber Daya, 4 ].

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

    3.2. Kompatibilitas API Lunak

    Selain API yang dikelola dari Bagian 3.1, Android juga menyertakan API "lunak" khusus runtime yang signifikan, dalam bentuk hal-hal seperti Intent, izin, dan aspek serupa dari aplikasi Android yang tidak dapat diterapkan pada aplikasi waktu kompilasi. Bagian ini merinci API "lunak" 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

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

    3.2.2. Parameter Build

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

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

    3.2.3. Kompatibilitas Intent

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

    3.2.3.1. Maksud Aplikasi Inti

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

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

    Aplikasi berikut dianggap sebagai aplikasi inti sistem Android:

    • Jam Meja
    • Browser
    • Kalender
    • Kalkulator
    • Kamera
    • Kontak
    • Galeri
    • Email
    • Peluncur
    • GlobalSearch
    • LivePicker (yaitu, aplikasi pemilih Wallpaper Animasi; MUNGKIN dihilangkan jika perangkat tidak mendukung Wallpaper Animasi, sesuai Bagian 3.8.5. )
    • Perpesanan (AKA "Mms")
    • Musik
    • Pengaturan
    • Telepon
    • SoundRecorder

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

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

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

    3.2.3.2. Penggantian Intent

    Karena Android adalah platform yang dapat diperluas, pelaksana perangkat HARUS mengizinkan setiap pola Intent yang ditentukan dalam aplikasi sistem inti untuk diganti oleh aplikasi pihak ketiga. Proyek sumber terbuka Android hulu mengizinkan hal ini secara default; pelaksana perangkat TIDAK BOLEH memberikan hak istimewa khusus pada penggunaan pola Intent ini oleh aplikasi sistem, atau mencegah aplikasi pihak ketiga mengikat dan mengambil kendali atas pola ini. Larangan ini secara khusus mencakup namun tidak terbatas pada menonaktifkan antarmuka pengguna "Chooser" yang memungkinkan pengguna memilih di antara beberapa aplikasi yang semuanya menangani pola Intent yang sama.

    Catatan: bagian ini telah dimodifikasi oleh Erratum EX6580.

    3.2.3.3. Namespace Intent

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

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

    3.2.3.4. Intent Siaran

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

    3.3. Kompatibilitas API Asli

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

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

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

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

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

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

    3.4. Kompatibilitas API Web

    Banyak pengembang dan aplikasi mengandalkan perilaku kelas android.webkit.WebView [ Resources, 8 ] untuk antarmuka penggunanya, sehingga implementasi WebView harus kompatibel dengan seluruh implementasi Android. Implementasi Android Open Source menggunakan mesin rendering WebKit untuk mengimplementasikan WebView.

    Karena tidak layak untuk mengembangkan rangkaian pengujian komprehensif untuk browser web, pelaksana perangkat HARUS menggunakan versi hulu WebKit yang spesifik dalam implementasi WebView. Khususnya:

    • WebView HARUS menggunakan build WebKit 530.17 dari pohon Open Source Android upstream untuk Android 2.1. Versi ini mencakup serangkaian fungsionalitas dan perbaikan keamanan khusus 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
      • dari String $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE
      • Nilai string $(LOCALE) HARUS mengikuti konvensi ISO untuk kode negara dan bahasa, dan HARUS mengacu pada lokal yang dikonfigurasi saat ini perangkat
      • 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
      • android.os.Build.ID

    MUNGKIN mengirimkan string agen pengguna khusus dalam aplikasi Browser mandiri. Terlebih lagi, Browser mandiri MUNGKIN 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 [ Sumber Daya, 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 dicantumkan untuk WebView.

    3.5. Kompatibilitas Perilaku API

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

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

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

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

    3.6. Namespace API

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

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

    Modifikasi yang dilarang meliputi:

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

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

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

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

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

    3.7. Kompatibilitas Mesin Virtual

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

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

    3.8. Kompatibilitas Antarmuka Pengguna

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

    3.8.1. Widget

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

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

    3.8.2. Notifikasi

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

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

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

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

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

    3.8.4.

    Aplikasi

    Toasts

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

    3.8.5. Wallpaper Live

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

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

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

    4. Referensi Kompatibilitas

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

    • Kalkulator (termasuk dalam SDK)
    • Lunar Lander (termasuk dalam SDK)
    • Aplikasi "Aplikasi untuk Android" [ Sumber Daya, 18 ].

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

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

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

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

    5. Kompatibilitas Pengemasan Aplikasi

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

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

    6. Kompatibilitas Multimedia

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

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

    File/Kontainer Kecepatan
    Detail Dekoder Enkoder Nama Audio
    Format
    AAC LC/LTP   X Konten Mono/Stereo dalam kombinasi kecepatan bit standar hingga 160 kbps dan kecepatan pengambilan sampel antara 8 hingga 48kHz 3GPP (.3gp) dan MPEG-4 (.mp4, .m4a). Tidak ada dukungan untuk AAC mentah (.aac)
    HE-AACv1 (AAC+)   X
    HE-AACv2 (AAC+ yang ditingkatkan)   X
    AMR-NB X X 4,75 hingga 12,2 kbps sampel @ 8kHz 3GPP (.3gp)
    AMR-WB  X 9 dari 6,60 kbit/s hingga 23,85 kbit/s sampel @ 16kHz 3GPP (.3gp)
    MP3   X Mono/Stereo 8-320Kbps konstan (CBR) atau kecepatan bit variabel (VBR) MP3 (.mp3)
    MIDI   X MIDI Tipe 0 dan 1. DLS Versi 1 dan 2. XMF dan Mobile XMF. Dukungan untuk format nada dering RTTTL/RTX, OTA, dan iMelody Type 0 dan 1 (.mid, .xmf, .mxmf). Juga RTTTL/RTX (.rtttl, .rtx), OTA (.ota), dan iMelody (.imy)
    Ogg Vorbis   X   Ogg (.ogg)
    PCM   X PCM linier 8- dan 16-bit (kecepatan hingga batas perangkat keras) WAVE (.wav)
    Gambar
    JPEG X X dasar+progresif  
    GIF   X   
    PNGXX _ _   
    BMP   X   
    Video
    H.263XX _ _   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 bitrate spesifik untuk sebagian besar codec video. Alasannya adalah dalam praktiknya, perangkat keras perangkat saat ini belum tentu mendukung bitrate yang dipetakan secara tepat ke bitrate yang diperlukan dan ditentukan oleh standar terkait. Sebaliknya, implementasi perangkat HARUS mendukung bitrate tertinggi pada perangkat keras, hingga batas yang ditentukan oleh spesifikasi.

    7. Kompatibilitas Alat Pengembang

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

    • Android Debug Bridge (dikenal sebagai adb) [ Sumber Daya, 19 ]
      Implementasi perangkat HARUS mendukung semua fungsi adb seperti yang didokumentasikan dalam Android SDK. Daemon adb sisi perangkat HARUS tidak aktif secara default, namun HARUS ada mekanisme yang dapat diakses pengguna untuk mengaktifkan Android Debug Bridge.
    • Layanan Monitor Debug Dalvik (dikenal sebagai ddms) [ Sumber Daya, 19 ]
      Implementasi perangkat HARUS mendukung semua fitur ddms seperti yang didokumentasikan dalam Android SDK. Karena ddms menggunakan adb , dukungan untuk ddms HARUS tidak aktif secara default, namun HARUS didukung setiap kali pengguna mengaktifkan Android Debug Bridge, seperti di atas.
    • Monyet [ Sumber Daya, 22 ]
      Implementasi perangkat HARUS menyertakan kerangka Monkey, dan membuatnya tersedia untuk digunakan oleh aplikasi.

    8. Kompatibilitas Perangkat Keras

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

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

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

    Contoh umum skenario yang menerapkan persyaratan ini adalah API telepon: bahkan pada non -perangkat telepon, API ini harus diterapkan sebagai larangan operasi yang wajar.

    Implementasi perangkat HARUS melaporkan informasi konfigurasi perangkat keras yang akurat melalui metode getSystemAvailableFeatures() dan hasSystemFeature(String) pada kelas android.content.pm.PackageManager .

    8.1. Tampilan

    Android 2.1 mencakup fasilitas yang melakukan operasi penskalaan dan transformasi otomatis tertentu dalam keadaan tertentu, untuk memastikan bahwa aplikasi pihak ketiga berjalan cukup baik pada berbagai konfigurasi perangkat keras [ Sumber Daya, 23 ]. Perangkat HARUS menerapkan perilaku ini dengan benar, sebagaimana dijelaskan secara rinci di bagian ini.

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

    WVGA 480 Implementasi
    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
    800 4,8 - 5,5 Besar Sedang
    FWVGA 480 854 5.0 - 5.8Perangkat Menengah

    Besar sesuai dengan salah satu konfigurasi standar di atas HARUS dikonfigurasi untuk melaporkan ukuran layar yang ditunjukkan ke aplikasi melalui kelas android.content.res.Configuration [ Resources, 24 ] .

    Beberapa paket .apk memiliki manifes yang tidak mengidentifikasi paket tersebut mendukung rentang kepadatan tertentu. Saat menjalankan aplikasi tersebut, batasan berikut berlaku:

    • Implementasi perangkat HARUS menafsirkan sumber daya dalam .apk yang tidak memiliki kualifikasi kepadatan sebagai default ke "medium" (dikenal sebagai "mdpi" dalam dokumentasi SDK.)
    • Saat beroperasi pada kepadatan "rendah" layar, implementasi perangkat HARUS menurunkan skala aset medium/mdpi sebanyak 0,75 kali.
    • Saat beroperasi pada layar dengan kepadatan "tinggi", implementasi perangkat HARUS meningkatkan skala aset medium/mdpi sebanyak 1,5 kali.
    • Implementasi perangkat TIDAK HARUS menskalakan aset dalam rentang kepadatan, dan HARUS menskalakan aset berdasarkan faktor-faktor ini di antara rentang kepadatan.

    8.1.2. Konfigurasi Tampilan Non-Standar

    Konfigurasi tampilan yang tidak cocok dengan salah satu konfigurasi standar yang tercantum di Bagian 8.1.1 memerlukan pertimbangan tambahan dan berupaya agar kompatibel. Pelaksana perangkat HARUS menghubungi Tim Kompatibilitas Android sebagaimana diatur dalam Bagian 12 untuk mendapatkan klasifikasi untuk kelompok ukuran layar, kepadatan, dan faktor penskalaan. Ketika diberikan informasi ini, implementasi perangkat HARUS mengimplementasikannya sebagaimana ditentukan.

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

    8.1.3. Metrik Tampilan

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

    8.2.

    Implementasi Perangkat

    Keyboard

    :

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

    8.3.

    Implementasi Perangkat

    Navigasi Non-sentuh

    :

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

    8.4. Orientasi Layar

    Perangkat yang kompatibel HARUS mendukung orientasi dinamis dengan aplikasi untuk orientasi layar potret atau lanskap. Artinya, perangkat harus mematuhi permintaan aplikasi untuk orientasi layar tertentu. Penerapan perangkat MUNGKIN memilih orientasi potret atau lanskap sebagai default.

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

    8.5. Input layar sentuh

    Implementasi perangkat:

    • HARUS memiliki layar sentuh
    • MUNGKIN memiliki layar sentuh kapasitif atau resistif
    • HARUS melaporkan nilai android.content.res.Configuration [ Sumber Daya, 24 ] yang mencerminkan jenis layar sentuh tertentu pada perangkat

    8.6.

    Implementasi Perangkat

    USB

      :
    • HARUS mengimplementasikan klien USB, dapat dihubungkan ke host USB dengan port USB-A standar
    • HARUS mengimplementasikan Android Debug Bridge melalui USB (seperti yang dijelaskan di Bagian 7)
    • HARUS mengimplementasikan spesifikasi penyimpanan massal USB, untuk memungkinkan host terhubung ke perangkat untuk mengakses konten volume /sdcard
    • HARUS menggunakan faktor bentuk micro USB di sisi perangkat
    • MUNGKIN menyertakan port non-standar di sisi perangkat, tetapi jika demikian HARUS dikirimkan dengan kabel yang mampu menghubungkan pinout khusus ke port USB-A standar

    8.7. Tombol navigasi

    Fungsi Beranda, Menu, dan Kembali sangat penting dalam paradigma navigasi Android. Implementasi perangkat HARUS membuat fungsi-fungsi ini tersedia bagi pengguna setiap saat, apa pun status aplikasinya. Fungsi-fungsi ini HARUS diterapkan melalui tombol khusus. Mereka MUNGKIN diimplementasikan menggunakan perangkat lunak, gerakan, panel sentuh, dll., namun jika demikian, mereka HARUS selalu dapat diakses dan tidak mengaburkan atau mengganggu area tampilan aplikasi yang tersedia.

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

    8.8.

    Implementasi Perangkat

    Jaringan Data Nirkabel

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

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

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

    8.9.

    Implementasi Perangkat

    Kamera

    HARUS menyertakan kamera. Kamera yang disertakan:

    • HARUS memiliki resolusi minimal 2 megapiksel
    • HARUS memiliki fokus otomatis perangkat keras, atau fokus otomatis perangkat lunak yang diterapkan pada driver kamera (transparan ke perangkat lunak aplikasi)
    • MUNGKIN memiliki fokus tetap atau EDOF (kedalaman bidang yang diperluas) perangkat keras
    • MUNGKIN termasuk flash. Jika Kamera menyertakan flash, lampu flash TIDAK HARUS menyala saat instance android.hardware.Camera.PreviewCallback telah didaftarkan pada permukaan pratinjau Kamera, kecuali aplikasi telah secara eksplisit mengaktifkan flash dengan mengaktifkan atribut FLASH_MODE_AUTO atau FLASH_MODE_ON dari a Objek Camera.Parameters . Perhatikan bahwa batasan ini tidak berlaku untuk aplikasi kamera sistem bawaan perangkat, namun 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), maka perangkat HARUS menggunakan android.hardware.PixelFormat.YCbCr_420_SP untuk data pratinjau yang diberikan kepada panggilan balik aplikasi.
    2. Jika aplikasi mendaftarkan instance android.hardware.Camera.PreviewCallback dan sistem memanggil metode onPreviewFrame() ketika format pratinjaunya adalah YCbCr_420_SP, data dalam byte[] yang diteruskan ke onPreviewFrame() selanjutnya harus dalam format pengkodean NV21. (Ini adalah format yang digunakan secara asli oleh keluarga perangkat keras 7k.) Artinya, NV21 HARUS menjadi default.

    Implementasi perangkat HARUS mengimplementasikan API Kamera lengkap yang disertakan dalam dokumentasi SDK Android 2.1 [ Sumber Daya, 26 ]), terlepas dari apakah perangkat menyertakan fokus otomatis perangkat keras atau kemampuan lainnya. Misalnya, kamera yang tidak memiliki autofocus masih harus memanggil android.hardware.Camera.AutoFocusCallback yang terdaftar (meskipun ini tidak memiliki relevansi dengan kamera non-autofokus.)

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

    8.10.

    Implementasi perangkat

    Accelerometer

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

    8.11.

    Implementasi perangkat

    kompas

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

    8.12.

    Implementasi perangkat

    GPS

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

    8.13. Telephony

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

    Lihat juga Bagian 8.8, jaringan data nirkabel.

    8.14.

    Implementasi perangkat

    memori dan penyimpanan

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

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

    Catatan: Bagian ini dimodifikasi oleh ERratum EX6580.

    8.15.

    Implementasi Perangkat

    Penyimpanan Bersama Aplikasi

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

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

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

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

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

    Ini adalah ilustratif untuk mempertimbangkan dua contoh umum. Jika implementasi perangkat mencakup slot kartu SD untuk memenuhi persyaratan penyimpanan bersama, ukuran kartu SD 2GB yang diformat lemak atau lebih besar harus disertakan dengan perangkat seperti yang dijual kepada pengguna, dan harus dipasang secara default. Atau, jika implementasi perangkat menggunakan penyimpanan tetap internal untuk memenuhi persyaratan ini, penyimpanan harus berukuran 2GB atau lebih besar dan dipasang pada /sdcard (atau /sdcard harus menjadi tautan simbolik ke lokasi fisik jika dipasang di tempat lain.)

    Catatan : Bagian ini ditambahkan oleh erratum EX6580.

    8.16.

    Implementasi perangkat

    Bluetooth

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

    Catatan: Bagian ini ditambahkan oleh ERratum EX6580.

    9. Kompatibilitas Kinerja

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

    Luncurkan
    Metrik Kinerja Ambang Komentar
    Waktu Peluncuran Aplikasi Aplikasi berikut harus diluncurkan dalam waktu yang ditentukan.
    • Browser: kurang dari 1300ms
    • mms/sms: kurang dari 700ms
    • alarmclock: kurang dari 650ms
    		 waktu peluncuran diukur sebagai total waktu untuk menyelesaikan pemuatan aktivitas default untuk aplikasi, termasuk waktu yang diperlukan untuk memulai proses Linux, memuat Android Paket ke Dalvik VM, dan hubungi OnCreate.
    Aplikasi Simultan Ketika beberapa aplikasi telah diluncurkan, meluncurkan kembali aplikasi yang sudah berjalan setelah diluncurkan harus membutuhkan waktu kurang dari waktu peluncuran asli.  

    10. Implementasi Perangkat Kompatibilitas Model Keamanan

    harus mengimplementasikan model keamanan yang konsisten dengan model keamanan platform Android sebagaimana didefinisikan dalam dokumen referensi keamanan dan izin di API [ sumber daya, 28 ] dalam dokumentasi pengembang Android. Implementasi perangkat harus mendukung pemasangan aplikasi yang ditandatangani sendiri tanpa memerlukan izin/sertifikat tambahan dari pihak ketiga/otoritas mana pun. Secara khusus, perangkat yang kompatibel harus mendukung mekanisme keamanan yang dijelaskan dalam sub-bagian berikut.

    10.1.

    Implementasi perangkat

    izin

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

    10.2.

    Implementasi perangkat

    isolasi UID dan proses

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

    10.3.

    Implementasi perangkat

    izin sistem file

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

    11. Implementasi perangkat tes kompatibilitas

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

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

    12.

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

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

    • unduhan over-the-air (OTA) dengan pembaruan offline melalui reboot
    • "Tethered" pembaruan melalui USB dari pembaruan "offline" host PC
    • melalui reboot dan pembaruan dari file di Penyimpanan yang Dapat Dihapus

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

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

    13. Hubungi kami,

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