Definisi Kompatibilitas Android 5.1

1. Perkenalan

Dokumen ini merinci persyaratan yang harus dipenuhi agar perangkat kompatibel dengan Android 5.1.

Penggunaan “HARUS”, “TIDAK HARUS”, “WAJIB”, “HARUS”, “TIDAK AKAN”, “HARUS”, “TIDAK BOLEH”, “DIANJURKAN”, “BOLEH”, dan “OPSIONAL” sesuai dengan IETF standar yang ditentukan 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 5.1. Sebuah “implementasi perangkat” atau “implementasi adalah solusi perangkat keras/perangkat lunak yang dikembangkan.

Agar dianggap kompatibel dengan Android 5.1, implementasi perangkat HARUS memenuhi persyaratan yang disajikan dalam Definisi Kompatibilitas ini, termasuk dokumen apa pun yang dimasukkan melalui referensi.

Jika definisi ini atau pengujian perangkat lunak yang dijelaskan di bagian 10 tidak jelas, ambigu, atau tidak lengkap, maka pelaksana perangkat bertanggung jawab untuk memastikan kompatibilitas dengan implementasi yang ada.

Karena alasan ini, Proyek Sumber Terbuka Android [ Sumber Daya, 2 ] merupakan referensi dan implementasi Android yang disukai. Implementasi perangkat sangat dianjurkan untuk mendasarkan implementasi mereka semaksimal mungkin pada kode sumber “upstream” yang tersedia dari Proyek Sumber Terbuka Android. Meskipun beberapa komponen secara hipotetis dapat diganti dengan implementasi alternatif, praktik ini sangat tidak disarankan, karena lulus pengujian perangkat lunak 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.

Banyak sumber daya yang tercantum di bagian 14 berasal langsung atau tidak langsung dari Android SDK, dan fungsinya akan sama 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 dalam bagian 14 dianggap sebagai bagian dari Definisi Kompatibilitas ini.

2. Jenis Perangkat

Meskipun Proyek Sumber Terbuka Android telah digunakan dalam implementasi berbagai jenis perangkat dan faktor bentuk, banyak aspek arsitektur dan persyaratan kompatibilitas yang dioptimalkan untuk perangkat genggam. Mulai dari Android 5.0, Proyek Sumber Terbuka Android bertujuan untuk mencakup lebih banyak variasi jenis perangkat seperti yang dijelaskan di bagian ini.

Perangkat Genggam Android mengacu pada implementasi perangkat Android yang biasanya digunakan dengan memegangnya di tangan, seperti pemutar mp3, ponsel, dan tablet. Implementasi perangkat Genggam Android:

• HARUS memiliki layar sentuh yang tertanam di perangkat.
• HARUS memiliki sumber listrik yang memberikan mobilitas, seperti baterai.

Perangkat Televisi Android mengacu pada implementasi perangkat Android yang merupakan antarmuka hiburan untuk menikmati media digital, film, game, aplikasi, dan/atau siaran langsung TV bagi pengguna yang duduk sekitar sepuluh kaki jauhnya (“antarmuka pengguna bersandar” atau “antarmuka 10 kaki ”). Perangkat Televisi Android:

• HARUS memiliki layar tertanam ATAU menyertakan port output video, seperti VGA, HDMI, atau port nirkabel untuk tampilan.
• HARUS mendeklarasikan fitur android.software.leanback dan android.hardware.type.television [ Sumberdaya, 3 ].

Perangkat Android Watch mengacu pada implementasi perangkat Android yang dimaksudkan untuk dikenakan di tubuh, mungkin di pergelangan tangan, dan:

• HARUS memiliki layar dengan panjang diagonal fisik berkisar antara 1,1 hingga 2,5 inci.
• HARUS mendeklarasikan fitur android.hardware.type.watch.
• HARUS mendukung uiMode = UI_MODE_TYPE_WATCH [ Sumber Daya, 4 ].

Implementasi Android Automotive mengacu pada head unit kendaraan yang menjalankan Android sebagai sistem operasi untuk sebagian atau seluruh fungsi sistem dan/atau infotainment. Implementasi Android Automotive HARUS mendukung uiMode = UI_MODE_TYPE_CAR [ Sumber Daya, 111 ].

Semua implementasi perangkat Android yang tidak cocok dengan salah satu jenis perangkat di atas tetap HARUS memenuhi semua persyaratan dalam dokumen ini agar kompatibel dengan Android 5.1, kecuali persyaratan tersebut dijelaskan secara eksplisit untuk hanya berlaku pada jenis perangkat Android tertentu di atas.

2.1 Konfigurasi Perangkat

Ini adalah ringkasan perbedaan utama dalam konfigurasi perangkat keras berdasarkan jenis perangkat. (Sel kosong menunjukkan “MEI”). Tidak semua konfigurasi tercakup dalam tabel ini; lihat bagian perangkat keras yang relevan untuk detail lebih lanjut.

3. Perangkat Lunak

3.1. Kompatibilitas API Terkelola

Lingkungan eksekusi bytecode Dalvik yang dikelola adalah sarana utama untuk aplikasi Android. Antarmuka pemrograman aplikasi (API) Android adalah kumpulan antarmuka platform Android yang diekspos ke aplikasi yang berjalan di lingkungan runtime terkelola. Implementasi perangkat HARUS menyediakan implementasi lengkap, termasuk semua perilaku yang terdokumentasi, dari setiap API terdokumentasi yang diekspos oleh Android SDK [ Sumber Daya, 5 ] atau API apa pun yang diberi penanda “@SystemApi” di kode sumber Android upstream.

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.

Definisi Kompatibilitas ini mengizinkan beberapa jenis perangkat keras yang Android menyertakan API untuk dihilangkan oleh implementasi perangkat. Dalam kasus seperti ini, API HARUS tetap ada dan berperilaku wajar. Lihat bagian 7 untuk persyaratan khusus untuk skenario ini.

3.2. Kompatibilitas API Lunak

Selain API terkelola dari bagian 3.1 , Android juga menyertakan API “lunak” khusus waktu proses yang signifikan, dalam bentuk hal-hal seperti maksud, izin, dan aspek serupa dari aplikasi Android yang tidak dapat diterapkan pada waktu kompilasi aplikasi.

3.2.1. Izin

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

3.2.2. Parameter Bangun

Android API menyertakan sejumlah konstanta pada kelas android.os.Build [ Resources, 7 ] 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.

3.2.3. Kompatibilitas Maksud

Implementasi perangkat HARUS mengikuti sistem loose-coupling Android, seperti yang dijelaskan pada bagian di bawah ini. Yang dimaksud dengan “terhormat” adalah bahwa pelaksana perangkat HARUS menyediakan Aktivitas atau Layanan Android yang menentukan filter maksud yang cocok yang mengikat dan mengimplementasikan perilaku yang benar untuk setiap pola maksud yang ditentukan.

3.2.3.1. Maksud Aplikasi Inti

Maksud Android memungkinkan komponen aplikasi meminta fungsionalitas dari komponen Android lainnya. Proyek upstream Android mencakup daftar aplikasi yang dianggap sebagai aplikasi inti Android, yang mengimplementasikan beberapa pola maksud untuk melakukan tindakan umum. Aplikasi inti Android adalah:

• Jam Meja
• Peramban
• Kalender
• Kontak
• Galeri
• Pencarian Global
• Peluncur
• Musik
• Pengaturan

Implementasi perangkat HARUS menyertakan aplikasi inti Android sebagaimana mestinya, namun HARUS menyertakan komponen yang menerapkan pola maksud yang sama yang ditentukan oleh semua komponen Aktivitas atau Layanan “publik” dari aplikasi inti Android ini. Perhatikan bahwa komponen Aktivitas atau Layanan dianggap “publik” jika atribut android:exported tidak ada atau bernilai true.

3.2.3.2. Penggantian Niat

Karena Android adalah platform yang dapat diperluas, implementasi perangkat HARUS mengizinkan setiap pola maksud yang dirujuk di bagian 3.2.3.1 diganti oleh aplikasi pihak ketiga. Implementasi open source Android upstream mengizinkan hal ini secara default; pelaksana perangkat TIDAK BOLEH memberikan hak istimewa khusus pada penggunaan pola maksud 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 “Pemilih” yang memungkinkan pengguna memilih di antara beberapa aplikasi yang semuanya menangani pola maksud yang sama.

Namun, penerapan perangkat MUNGKIN menyediakan aktivitas default untuk pola URI tertentu (misalnya http://play.google.com) jika aktivitas default menyediakan filter yang lebih spesifik untuk URI data. Misalnya, filter maksud yang menentukan URI data “http://www.android.com” lebih spesifik dibandingkan filter browser untuk “http://”. Implementasi perangkat HARUS menyediakan antarmuka pengguna bagi pengguna untuk mengubah aktivitas default untuk maksud.

3.2.3.3. Ruang Nama Maksud

Implementasi perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mengikuti pola maksud baru atau maksud siaran apa pun menggunakan ACTION, CATEGORY, atau string kunci lainnya di namespace android.* atau com.android.*. Implementer perangkat TIDAK BOLEH menyertakan komponen Android apa pun yang mengikuti pola maksud baru atau maksud siaran apa pun menggunakan TINDAKAN, KATEGORI, atau string kunci lainnya dalam ruang paket milik organisasi lain. Pelaksana perangkat TIDAK BOLEH mengubah atau memperluas pola maksud apa pun yang digunakan oleh aplikasi inti yang tercantum di bagian 3.2.3.1 . Implementasi perangkat MUNGKIN mencakup pola maksud menggunakan namespace yang jelas dan jelas terkait dengan organisasinya sendiri. Larangan ini serupa dengan yang ditentukan untuk kelas bahasa Java di bagian 3.6 .

3.2.3.4. Maksud Siaran

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

3.2.3.5. Pengaturan Aplikasi Default

Android menyertakan pengaturan yang memberi pengguna cara mudah untuk memilih aplikasi default mereka, misalnya untuk Layar Beranda atau SMS. Jika masuk akal, penerapan perangkat HARUS menyediakan menu pengaturan serupa dan kompatibel dengan pola filter maksud dan metode API yang dijelaskan dalam dokumentasi SDK di bawah.

Implementasi perangkat:

• HARUS menghormati maksud android.settings.HOME_SETTINGS untuk menampilkan menu pengaturan aplikasi default untuk Layar Beranda, jika implementasi perangkat melaporkan android.software.home_screen [ Sumber Daya, 10]
• HARUS menyediakan menu pengaturan yang akan memanggil maksud android.provider.Telephony.ACTION_CHANGE_DEFAULT untuk menampilkan dialog untuk mengubah aplikasi SMS default, jika implementasi perangkat melaporkan android.hardware.telephony [ Sumber Daya, 9 ]
• HARUS menghormati maksud android.settings.NFC_PAYMENT_SETTINGS untuk menampilkan menu pengaturan aplikasi default untuk Ketuk dan Bayar, jika implementasi perangkat melaporkan android.hardware.nfc.hce [ Sumber Daya, 10]

3.3. Kompatibilitas API Asli

3.3.1. Antarmuka Biner Aplikasi

Bytecode Dalvik yang dikelola dapat memanggil kode asli yang disediakan dalam file .apk aplikasi sebagai file ELF .so yang dikompilasi untuk arsitektur perangkat keras perangkat yang sesuai. Karena kode asli sangat bergantung pada teknologi prosesor yang mendasarinya, Android mendefinisikan sejumlah Antarmuka Biner Aplikasi (ABI) di Android NDK. Implementasi perangkat HARUS kompatibel dengan satu atau beberapa ABI yang ditentukan, dan HARUS mengimplementasikan kompatibilitas dengan Android NDK, seperti di bawah ini.

Jika implementasi perangkat menyertakan dukungan untuk Android ABI, maka:

• HARUS menyertakan dukungan untuk kode yang berjalan di lingkungan terkelola untuk memanggil kode asli, menggunakan semantik Java Native Interface (JNI) standar
• HARUS kompatibel dengan sumber (yaitu kompatibel dengan header) dan kompatibel dengan biner (untuk ABI) dengan setiap pustaka yang diperlukan dalam daftar di bawah
• HARUS mendukung ABI 32-bit yang setara jika ada ABI 64-bit yang didukung
• HARUS melaporkan secara akurat Antarmuka Biner Aplikasi (ABI) asli yang didukung oleh perangkat, melalui parameter android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, dan android.os.Build.SUPPORTED_64_BIT_ABIS, masing-masing dalam daftar yang dipisahkan koma ABI diurutkan dari yang paling disukai hingga yang paling tidak disukai
• HARUS melaporkan, melalui parameter di atas, hanya ABI yang didokumentasikan dalam versi terbaru Android NDK, “Panduan Programmer NDK | Manajemen ABI” di direktori docs/
• HARUS dibuat menggunakan kode sumber dan file header yang tersedia di Proyek Sumber Terbuka Android upstream

API kode asli berikut HARUS tersedia untuk aplikasi yang menyertakan kode asli:

• libc (perpustakaan C)
• libm (perpustakaan matematika)
• Dukungan minimal untuk C++
• antarmuka JNI
• liblog (pencatatan Android)
• libz (kompresi Zlib)
• libdl (penghubung dinamis)
• libGLESv1_CM.so (OpenGL ES 1.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• libEGL.so (manajemen permukaan OpenGL asli)
• libjnigraphics.so
• libOpenSLES.so (dukungan audio OpenSL ES 1.0.1)
• libOpenMAXAL.so (dukungan OpenMAX AL 1.0.1)
• libandroid.so (dukungan aktivitas Android asli)
• libmediandk.so (dukungan API media asli)
• Dukungan untuk OpenGL, seperti dijelaskan di bawah

Perlu diperhatikan bahwa rilis Android NDK di masa mendatang mungkin memperkenalkan dukungan untuk ABI tambahan. Jika implementasi perangkat tidak kompatibel dengan ABI yang telah ditentukan sebelumnya, maka implementasi tersebut TIDAK BOLEH melaporkan dukungan untuk ABI apa pun sama sekali.

Perhatikan bahwa implementasi perangkat HARUS menyertakan libGLESv3.so dan HARUS menghubungkan simbol (tautan simbolis) ke libGLESv2.so. pada gilirannya, HARUS mengekspor semua simbol fungsi OpenGL ES 3.1 dan Android Extension Pack [ Resources, 11 ] seperti yang ditentukan dalam rilis NDK android-21. Meskipun semua simbol harus ada, hanya fungsi terkait untuk versi OpenGL ES dan ekstensi yang benar-benar didukung oleh perangkat yang harus diterapkan sepenuhnya.

Kompatibilitas kode asli merupakan suatu tantangan. Oleh karena itu, pelaksana perangkat sangat dianjurkan untuk menggunakan implementasi pustaka yang tercantum di atas dari Proyek Sumber Terbuka Android hulu.

3.3.2. Kompatibilitas Kode Asli ARM 32-bit

Arsitektur ARMv8 tidak lagi menggunakan beberapa operasi CPU, termasuk beberapa operasi yang digunakan dalam kode asli yang sudah ada. Pada perangkat ARM 64-bit, operasi yang tidak berlaku lagi berikut ini HARUS tetap tersedia untuk kode ARM asli 32-bit, baik melalui dukungan CPU asli atau melalui emulasi perangkat lunak:

• Instruksi SWP dan SWPB
• instruksi SETEND
• Operasi penghalang CP15ISB, CP15DSB, dan CP15DMB

Versi lama Android NDK menggunakan /proc/cpuinfo untuk menemukan fitur CPU dari kode asli ARM 32-bit. Agar kompatibel dengan aplikasi yang dibuat menggunakan NDK ini, perangkat HARUS menyertakan baris berikut di /proc/cpuinfo saat dibaca oleh aplikasi ARM 32-bit:

• "Fitur:", diikuti dengan daftar fitur CPU ARMv7 opsional yang didukung oleh perangkat
• "Arsitektur CPU:", diikuti dengan bilangan bulat yang menjelaskan arsitektur ARM tertinggi yang didukung perangkat (misalnya, "8" untuk perangkat ARMv8)

Persyaratan ini hanya berlaku ketika /proc/cpuinfo dibaca oleh aplikasi ARM 32-bit. Perangkat TIDAK BOLEH mengubah /proc/cpuinfo saat dibaca oleh aplikasi ARM atau non-ARM 64-bit.

3.4. Kompatibilitas Web

3.4.1. Kompatibilitas Tampilan Web

Fitur platform android.software.webview HARUS dilaporkan pada perangkat apa pun yang menyediakan implementasi lengkap API android.webkit.WebView, dan TIDAK HARUS dilaporkan pada perangkat tanpa implementasi API yang lengkap. Implementasi Android Open Source menggunakan kode dari Proyek Chromium untuk mengimplementasikan android.webkit.WebView [ Resources, 12 ]. Karena tidak layak untuk mengembangkan rangkaian pengujian komprehensif untuk sistem rendering web, pelaksana perangkat HARUS menggunakan versi hulu Chromium yang spesifik dalam implementasi WebView. Secara khusus:

• Implementasi perangkat android.webkit.WebView HARUS didasarkan pada build Chromium dari Proyek Sumber Terbuka Android upstream untuk Android 5.1. Versi ini mencakup serangkaian fungsionalitas dan perbaikan keamanan khusus untuk WebView [ Sumber Daya, 13 ].
• String agen pengguna yang dilaporkan oleh WebView HARUS dalam format ini:

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)$(WEBVIEW)) AppleWebKit/537.36 (KHTML, seperti Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • Nilai string $(VERSION) HARUS sama dengan nilai untuk android.os.Build.VERSION.RELEASE.
  • String $(WEBVIEW) MUNGKIN dihilangkan, tetapi jika disertakan HARUS "; wv" untuk diperhatikan bahwa ini adalah tampilan web
  • Nilai string $(MODEL) HARUS sama dengan nilai untuk android.os.Build.MODEL.
  • Nilai string $(BUILD) HARUS sama dengan nilai untuk android.os.Build.ID.
  • Nilai string $(CHROMIUM_VER) HARUS versi Chromium di Proyek Sumber Terbuka Android upstream.
  • Implementasi perangkat MUNGKIN menghilangkan Seluler dalam string agen pengguna.

Komponen WebView HARUS menyertakan dukungan untuk sebanyak mungkin fitur HTML5 dan jika mendukung fitur tersebut HARUS sesuai dengan spesifikasi HTML5 [ Sumberdaya, 14 ].

3.4.2. Kompatibilitas Peramban

Browser mandiri MUNGKIN didasarkan pada teknologi browser selain WebKit. Namun, meskipun aplikasi Browser alternatif digunakan, komponen android.webkit.WebView yang disediakan untuk aplikasi pihak ketiga HARUS berbasis WebKit, seperti dijelaskan di bagian 3.4.1 .

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

Aplikasi Browser mandiri (baik berdasarkan aplikasi Browser WebKit upstream atau pengganti pihak ketiga) HARUS menyertakan dukungan untuk HTML5 sebanyak mungkin [ Sumber Daya, 14 ] . Minimal, implementasi perangkat HARUS mendukung setiap API yang terkait dengan HTML5 berikut:

• cache aplikasi/operasi offline [ Sumber Daya, 15 ]
• tag <video> [ Sumber Daya, 16 ]
• geolokasi [ Sumber Daya, 17 ]

Selain itu, implementasi perangkat HARUS mendukung API penyimpanan web HTML5/W3C [ Sumber Daya, 18 ], dan HARUS mendukung API IndexedDB HTML5/W3C [ Sumber Daya, 19 ]. Perlu diperhatikan bahwa seiring dengan transisi badan standar pengembangan web yang lebih mengutamakan IndexedDB dibandingkan penyimpanan web, IndexedDB diperkirakan akan menjadi komponen wajib dalam versi Android mendatang.

3.5. Kompatibilitas Perilaku API

Perilaku masing-masing jenis API (terkelola, lunak, asli, dan web) harus konsisten dengan implementasi pilihan Proyek Sumber Terbuka Android upstream [ Sumber Daya, 2 ]. Beberapa area kompatibilitas tertentu adalah:

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

Daftar di atas tidak lengkap. 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. 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.

3.6. Ruang Nama API

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

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

Modifikasi yang dilarang antara lain :

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

“Elemen yang diekspos secara publik” adalah konstruksi apa pun yang tidak dihiasi dengan penanda “@hide” seperti yang digunakan dalam 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 boleh melakukannya. Demikian pula, Google TIDAK BOLEH menambahkan API ke namespace perusahaan lain. Selain itu, jika implementasi perangkat menyertakan API khusus di luar namespace Android standar, API tersebut HARUS dikemas dalam pustaka bersama Android sehingga hanya aplikasi yang menggunakannya secara eksplisit (melalui mekanisme <uses-library>) yang terpengaruh oleh peningkatan penggunaan memori API tersebut.

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 Waktu Proses

Implementasi perangkat HARUS mendukung format penuh Dalvik Executable (DEX) serta spesifikasi bytecode dan semantik Dalvik [ Sumber Daya, 20 ]. Pelaksana perangkat HARUS menggunakan ART, implementasi hulu referensi dari Dalvik Executable Format, dan sistem manajemen paket implementasi referensi.

Implementasi perangkat HARUS mengonfigurasi runtime Dalvik untuk mengalokasikan memori sesuai dengan platform Android upstream, dan sebagaimana ditentukan dalam tabel berikut. (Lihat bagian 7.1.1 untuk mengetahui ukuran layar dan definisi kepadatan layar.)

Perhatikan bahwa nilai memori yang ditentukan di bawah ini dianggap sebagai nilai minimum dan implementasi perangkat MUNGKIN mengalokasikan lebih banyak memori per aplikasi.

3.8. Kompatibilitas Antarmuka Pengguna

3.8.1. Peluncur (Layar Utama)

Android menyertakan aplikasi peluncur (layar beranda) dan dukungan aplikasi pihak ketiga untuk menggantikan peluncur perangkat (layar beranda). Implementasi perangkat yang memungkinkan aplikasi pihak ketiga menggantikan layar beranda perangkat HARUS mendeklarasikan fitur platform android.software.home_screen.

3.8.2. Widget

Android mendefinisikan jenis komponen dan API serta siklus hidup terkait yang memungkinkan aplikasi mengekspos “AppWidget” kepada pengguna akhir [ Sumber Daya, 21 ] sebuah fitur yang sangat DIREKOMENDASIKAN untuk didukung pada implementasi Perangkat Genggam. Implementasi perangkat yang mendukung penyematan widget di layar beranda HARUS memenuhi persyaratan berikut dan menyatakan dukungan untuk fitur platform android.software.app_widgets.

• Peluncur perangkat HARUS menyertakan dukungan bawaan untuk AppWidgets, dan memaparkan kemampuan antarmuka pengguna untuk menambah, mengonfigurasi, melihat, dan menghapus AppWidgets langsung di dalam Peluncur.
• Implementasi perangkat HARUS mampu merender widget berukuran 4 x 4 dalam ukuran grid standar. Lihat Pedoman Desain Widget Aplikasi dalam dokumentasi Android SDK [ Sumber Daya, 21 ] untuk detailnya.
• Implementasi perangkat yang menyertakan dukungan untuk layar kunci MUNGKIN mendukung widget aplikasi di layar kunci.

3.8.3. Pemberitahuan

Android menyertakan API yang memungkinkan pengembang memberi tahu pengguna tentang peristiwa penting [ Sumber Daya, 22 ], menggunakan fitur perangkat keras dan perangkat lunak perangkat.

Beberapa API memungkinkan aplikasi melakukan notifikasi atau menarik perhatian menggunakan perangkat keras—khususnya suara, getaran, dan cahaya. Implementasi perangkat HARUS mendukung notifikasi yang menggunakan fitur perangkat keras, seperti yang dijelaskan dalam dokumentasi SDK, dan sedapat mungkin dengan perangkat keras implementasi perangkat. Misalnya, jika implementasi perangkat menyertakan vibrator, maka perangkat tersebut HARUS mengimplementasikan API getaran dengan benar. Jika implementasi perangkat tidak memiliki perangkat keras, API terkait HARUS diimplementasikan sebagai tanpa operasi. Perilaku ini dirinci lebih lanjut di bagian 7 .

Selain itu, penerapannya HARUS merender dengan benar semua sumber daya (ikon, file animasi, dll.) yang disediakan dalam API [ Sumber Daya, 23 ], atau dalam panduan gaya ikon Bilah Status/Sistem [ Sumber Daya, 24 ], yang dalam kasus Perangkat Android Television menyertakan kemungkinan untuk tidak menampilkan notifikasi. 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 dukungan untuk berbagai notifikasi, seperti:

• Notifikasi yang kaya . Tampilan Interaktif untuk notifikasi yang sedang berlangsung.
• Notifikasi pendahuluan . Pengguna Tampilan Interaktif dapat menindaklanjuti atau menutupnya tanpa meninggalkan aplikasi saat ini.
• Notifikasi layar kunci . Pemberitahuan ditampilkan melalui layar kunci dengan kontrol granular pada visibilitas.

Implementasi perangkat Android, ketika notifikasi tersebut dibuat terlihat, HARUS menjalankan notifikasi Rich dan Heads-up dengan benar dan menyertakan judul/nama, ikon, teks seperti yang didokumentasikan dalam Android API [Resources, 25] .

Android menyertakan API Layanan Pemroses Notifikasi yang memungkinkan aplikasi (setelah diaktifkan secara eksplisit oleh pengguna) menerima salinan semua notifikasi saat diposkan atau diperbarui. Implementasi perangkat HARUS mengirimkan pemberitahuan secara keseluruhan dengan benar dan segera ke semua layanan pendengar yang diinstal dan diaktifkan oleh pengguna, termasuk setiap dan semua metadata yang dilampirkan ke objek Pemberitahuan.

3.8.4. Mencari

Android menyertakan API [ Sumber Daya, 26 ] 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 Android HARUS mencakup penelusuran global, antarmuka pengguna penelusuran tunggal, bersama, di 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 yang mengimplementasikan antarmuka pencarian global 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.

3.8.5. Bersulang

Aplikasi dapat menggunakan API “Toast” untuk menampilkan string non-modal pendek kepada pengguna akhir, yang hilang setelah periode waktu singkat [ Sumberdaya, 27 ]. Implementasi perangkat HARUS menampilkan Toast dari aplikasi ke pengguna akhir dengan cara yang terlihat jelas.

3.8.6. Tema

Android menyediakan “tema” sebagai mekanisme bagi aplikasi untuk menerapkan gaya di seluruh Aktivitas atau aplikasi.

Android menyertakan rangkaian tema “Holo” sebagai sekumpulan gaya yang ditentukan untuk digunakan pengembang aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema Holo seperti yang ditentukan oleh Android SDK [ Sumber Daya, 28 ]. Implementasi perangkat TIDAK BOLEH mengubah atribut tema Holo apa pun yang diekspos ke aplikasi [ Sumber Daya, 29 ].

Android menyertakan rangkaian tema “Material” sebagai sekumpulan gaya yang ditentukan untuk digunakan pengembang aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema desain di berbagai jenis perangkat Android yang berbeda. Implementasi perangkat HARUS mendukung rangkaian tema “Material” dan TIDAK BOLEH mengubah atribut tema Material atau asetnya yang diekspos ke aplikasi [ Sumberdaya, 30 ].

Android juga menyertakan rangkaian tema “Device Default” sebagai sekumpulan gaya yang ditentukan untuk digunakan pengembang aplikasi jika mereka ingin mencocokkan tampilan dan nuansa tema perangkat seperti yang ditentukan oleh pelaksana perangkat. Implementasi perangkat MUNGKIN mengubah atribut tema Default Perangkat yang diekspos ke aplikasi [ Sumber Daya, 29 ].

Android mendukung tema varian baru dengan bilah sistem tembus pandang, yang memungkinkan pengembang aplikasi mengisi area di belakang bilah status dan navigasi dengan konten aplikasi mereka. Untuk memungkinkan pengalaman pengembang yang konsisten dalam konfigurasi ini, gaya ikon bilah status harus dipertahankan di berbagai implementasi perangkat. Oleh karena itu, implementasi perangkat Android HARUS menggunakan warna putih untuk ikon status sistem (seperti kekuatan sinyal dan level baterai) dan notifikasi yang dikeluarkan oleh sistem, kecuali ikon tersebut menunjukkan status bermasalah [ Sumber Daya, 29 ].

3.8.7. Wallpaper Hidup

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

Perangkat keras dianggap mampu menjalankan wallpaper hidup dengan andal jika dapat menjalankan semua wallpaper hidup, tanpa batasan fungsionalitas, pada kecepatan bingkai yang wajar tanpa efek 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 OpenGL 2.0 atau 3.x 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 mengimplementasikan wallpaper hidup, dan ketika diterapkan HARUS melaporkan tanda fitur platform android.software.live_wallpaper.

3.8.8. Peralihan Aktivitas

Kode sumber Android hulu mencakup layar ikhtisar [ Sumber Daya, 32 ], antarmuka pengguna tingkat sistem untuk peralihan tugas dan menampilkan aktivitas dan tugas yang baru diakses menggunakan gambar mini status grafis aplikasi pada saat pengguna terakhir kali meninggalkan aplikasi. Implementasi perangkat termasuk tombol navigasi fungsi terkini sebagaimana dirinci di bagian 7.2.3 , MUNGKIN mengubah antarmuka tetapi HARUS memenuhi persyaratan berikut:

• HARUS menampilkan afiliasi terbaru sebagai grup yang bergerak bersama.
• HARUS mendukung setidaknya hingga 20 aktivitas yang ditampilkan.
• Setidaknya HARUS menampilkan judul 4 aktivitas sekaligus.
• HARUS menampilkan warna highlight, ikon, judul layar terkini.
• HARUS menerapkan perilaku penyematan layar [ Sumber Daya, 33 ] dan menyediakan menu pengaturan kepada pengguna untuk mengaktifkan fitur tersebut.
• HARUS menampilkan keterjangkauan penutup ("x") tetapi MUNGKIN menundanya hingga pengguna berinteraksi dengan layar.

Implementasi perangkat SANGAT DIANJURKAN untuk menggunakan antarmuka pengguna Android upstream (atau antarmuka berbasis thumbnail serupa) untuk layar ikhtisar.

3.8.9. Manajemen Masukan

Android menyertakan dukungan untuk Manajemen Input dan dukungan untuk editor metode input pihak ketiga [ Sumber Daya, 34 ]. Implementasi perangkat yang memungkinkan pengguna menggunakan metode masukan pihak ketiga pada perangkat HARUS mendeklarasikan fitur platform android.software.input_methods dan mendukung API IME sebagaimana ditentukan dalam dokumentasi Android SDK.

Implementasi perangkat yang mendeklarasikan fitur android.software.input_methods HARUS menyediakan mekanisme yang dapat diakses pengguna untuk menambahkan dan mengonfigurasi metode input pihak ketiga. Implementasi perangkat HARUS menampilkan antarmuka pengaturan sebagai respons terhadap maksud android.settings.INPUT_METHOD_SETTINGS.

3.8.10. Kontrol Media Layar Kunci

API Klien Kontrol Jarak Jauh tidak digunakan lagi di Android 5.0 dan digantikan dengan Templat Pemberitahuan Media yang memungkinkan aplikasi media berintegrasi dengan kontrol pemutaran yang ditampilkan di layar kunci [ Sumber Daya, 35 ]. Implementasi perangkat yang mendukung layar kunci, kecuali implementasi Android Automotive atau Watch, HARUS menampilkan Notifikasi Lockscreen termasuk Template Notifikasi Media.

3.8.11. Mimpi

Android menyertakan dukungan untuk screensaver interaktif yang disebut Dreams [ Resources, 36 ]. Dreams memungkinkan pengguna untuk berinteraksi dengan aplikasi saat perangkat yang terhubung ke sumber listrik dalam keadaan idle atau dipasang di dok meja. Perangkat Android Watch MUNGKIN mengimplementasikan Dreams, namun jenis implementasi perangkat lainnya HARUS menyertakan dukungan untuk Dreams dan memberikan opsi setelan bagi pengguna untuk mengonfigurasi Dreams sebagai respons terhadap maksud android.settings.DREAM_SETTINGS.

3.8.12. Lokasi

Ketika perangkat memiliki sensor perangkat keras (misalnya GPS) yang mampu memberikan koordinat lokasi, mode lokasi HARUS ditampilkan di menu Lokasi dalam Pengaturan [ Sumber Daya, 37 ].

3.8.13. Unicode dan Font

Android menyertakan dukungan untuk karakter emoji berwarna. Jika implementasi perangkat Android menyertakan IME, perangkat HARUS memberikan metode masukan kepada pengguna untuk karakter Emoji yang ditentukan di Unicode 6.1 [ Sumber Daya, 38 ]. Semua perangkat HARUS mampu menampilkan karakter emoji ini dalam mesin terbang berwarna.

Android menyertakan dukungan untuk font Roboto 2 dengan bobot berbeda—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light—yang HARUS disertakan untuk bahasa yang tersedia di perangkat dan cakupan penuh Unicode 7.0 Latin, Yunani, dan Sirilik, termasuk rentang Latin Extended A, B, C, dan D, dan semua mesin terbang di blok simbol mata uang Unicode 7.0.

3.9. Administrasi Perangkat

Android menyertakan fitur yang memungkinkan aplikasi yang sadar keamanan menjalankan fungsi administrasi perangkat di tingkat sistem, seperti menerapkan kebijakan kata sandi atau melakukan penghapusan jarak jauh, melalui Android Device Administration API [ Sumber Daya, 39 ]. Implementasi perangkat HARUS menyediakan implementasi kelas DevicePolicyManager [ Sumber Daya, 40 ]. Implementasi perangkat yang menyertakan dukungan untuk layar kunci berbasis PIN (numerik) atau PASSWORD (alfanumerik) HARUS mendukung seluruh kebijakan administrasi perangkat yang ditentukan dalam dokumentasi Android SDK [ Sumber Daya, 39 ] dan melaporkan fitur platform android.software.device_admin.

Implementasi perangkat MUNGKIN memiliki aplikasi terinstal yang menjalankan fungsi administrasi perangkat tetapi aplikasi ini TIDAK HARUS ditetapkan sebagai aplikasi Pemilik Perangkat default [ Sumber Daya, 41 ].

3.10. Aksesibilitas

Android menyediakan lapisan aksesibilitas yang membantu pengguna penyandang disabilitas menavigasi perangkat mereka dengan lebih mudah. Selain itu, Android menyediakan API platform yang memungkinkan implementasi layanan aksesibilitas menerima callback untuk kejadian pengguna dan sistem serta menghasilkan mekanisme masukan alternatif, seperti text-to-speech, masukan haptik, dan navigasi trackball/d-pad [ Sumber Daya, 42 ].

Implementasi perangkat mencakup persyaratan berikut:

• Implementasi Android Automotive HARUS menyediakan implementasi framework aksesibilitas Android yang konsisten dengan implementasi Android default.
• Implementasi perangkat (tidak termasuk Android Automotive) HARUS menyediakan implementasi framework aksesibilitas Android yang konsisten dengan implementasi Android default.
• Implementasi perangkat (tidak termasuk Android Automotive) HARUS mendukung implementasi layanan aksesibilitas pihak ketiga melalui API android.accessibilityservice [ Sumber Daya, 43 ]
• Implementasi perangkat (tidak termasuk Android Automotive) HARUS menghasilkan AccessibilityEvents dan mengirimkan peristiwa ini ke semua implementasi AccessibilityService yang terdaftar dengan cara yang konsisten dengan implementasi Android default
• Implementasi perangkat (perangkat Android Automotive dan Android Watch tanpa pengecualian output audio), HARUS menyediakan mekanisme yang dapat diakses pengguna untuk mengaktifkan dan menonaktifkan layanan aksesibilitas, dan HARUS menampilkan antarmuka ini sebagai respons terhadap maksud android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

Selain itu, implementasi perangkat HARUS menyediakan implementasi layanan aksesibilitas pada perangkat, dan HARUS menyediakan mekanisme bagi pengguna untuk mengaktifkan layanan aksesibilitas selama penyiapan perangkat. Implementasi layanan aksesibilitas sumber terbuka tersedia dari proyek Eyes Free [ Sumber Daya, 44 ].

3.11. Teks pidato

Android menyertakan API yang memungkinkan aplikasi menggunakan layanan text-to-speech (TTS) dan memungkinkan penyedia layanan menyediakan implementasi layanan TTS [ Sumber Daya, 45 ]. Implementasi perangkat yang melaporkan fitur android.hardware.audio.output HARUS memenuhi persyaratan berikut terkait dengan framework Android TTS.

Implementasi Android Otomotif:

• HARUS mendukung API kerangka Android TTS.
• MUNGKIN mendukung pemasangan mesin TTS pihak ketiga. Jika didukung, mitra HARUS menyediakan antarmuka yang dapat diakses pengguna yang memungkinkan pengguna memilih mesin TTS untuk digunakan pada tingkat sistem.

Semua implementasi perangkat lainnya:

• HARUS mendukung API kerangka Android TTS dan HARUS menyertakan mesin TTS yang mendukung bahasa yang tersedia di perangkat. Perhatikan bahwa perangkat lunak sumber terbuka Android hulu menyertakan implementasi mesin TTS berfitur lengkap.
• HARUS mendukung pemasangan mesin TTS pihak ketiga
• HARUS menyediakan antarmuka yang dapat diakses pengguna yang memungkinkan pengguna memilih mesin TTS untuk digunakan pada tingkat sistem

3.12. Kerangka Masukan TV

Android Television Input Framework (TIF) menyederhanakan pengiriman konten langsung ke perangkat Android Television. TIF menyediakan API standar untuk membuat modul input yang mengontrol perangkat Android Television. Implementasi perangkat Android Television HARUS mendukung Television Input Framework [ Sumber Daya, 46 ].

Implementasi perangkat yang mendukung TIF HARUS mendeklarasikan fitur platform android.software.live_tv.

4. Kompatibilitas Kemasan Aplikasi

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

Implementasi perangkat TIDAK HARUS memperluas format bytecode .apk [ Resources, 48 ​​], Android Manifest [ Resources, 49 ], Dalvik bytecode [ Resources, 20 ], atau RenderScript sedemikian rupa sehingga mencegah file tersebut diinstal dan dijalankan dengan benar di perangkat lain yang kompatibel.

5. Kompatibilitas Multimedia

5.1. Codec Media

Implementasi perangkat HARUS mendukung format media inti yang ditentukan dalam dokumentasi Android SDK [ Sumber Daya, 50 ] kecuali jika diizinkan secara eksplisit dalam dokumen ini. Secara khusus, implementasi perangkat HARUS mendukung format media, encoder, decoder, jenis file, dan format kontainer yang ditentukan dalam tabel di bawah dan dilaporkan melalui MediaCodecList [ Resources,112 ]. Implementasi perangkat HARUS juga dapat memecahkan kode semua profil yang dilaporkan dalam CamcorderProfile [ Sumber Daya, 113 ]. Semua codec ini disediakan sebagai implementasi perangkat lunak dalam implementasi Android pilihan dari Proyek Sumber Terbuka Android.

Harap diperhatikan bahwa baik Google maupun Open Handset Alliance tidak menyatakan bahwa codec ini bebas dari 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.

5.1.1. Codec Audio

1 Diperlukan untuk implementasi perangkat yang mendefinisikan android.hardware.microphone tetapi opsional untuk implementasi perangkat Android Watch.

2 Hanya diperlukan downmix konten 5.0/5.1; merekam atau merender lebih dari 2 saluran adalah opsional.

3 Diperlukan untuk implementasi perangkat Genggam Android.

4 Diperlukan untuk implementasi perangkat yang mendefinisikan android.hardware.microphone, termasuk implementasi perangkat Android Watch.

5.1.2. Codec Gambar

5.1.3. Codec Video

Codec video bersifat opsional untuk penerapan perangkat Android Watch.

1 Diperlukan untuk implementasi perangkat yang menyertakan hardware kamera dan menentukan android.hardware.camera atau android.hardware.camera.front.

2 Diperlukan untuk implementasi perangkat kecuali perangkat Android Watch.

3 Untuk kualitas streaming video web dan layanan konferensi video yang dapat diterima, implementasi perangkat HARUS menggunakan codec VP8 perangkat keras yang memenuhi persyaratan dalam [ Sumber Daya, 51 ].

4 Implementasi perangkat HARUS mendukung penulisan file Matroska WebM.

5 Sangat disarankan untuk Android Automotive, opsional untuk Android Watch, dan wajib untuk semua jenis perangkat lainnya.

5.2. Pengkodean Video

Implementasi perangkat Android dengan dukungan codec H.264, HARUS mendukung Profil Dasar Level 3 dan profil pengkodean video SD (Definisi Standar) berikut dan HARUS mendukung Profil Utama Level 4 dan profil pengkodean video HD (Definisi Tinggi) berikut. Perangkat Televisi Android SANGAT DIREKOMENDASIKAN untuk menyandikan video HD 1080p pada 30 fps.

1 Bila didukung oleh perangkat keras, namun SANGAT DIANJURKAN untuk perangkat Android Television.

Implementasi perangkat Android dengan dukungan codec VP8 HARUS mendukung profil pengkodean video SD dan HARUS mendukung profil pengkodean video HD (Definisi Tinggi) berikut.

1 Bila didukung oleh perangkat keras.

5.3. Penguraian Video

Implementasi perangkat HARUS mendukung peralihan resolusi video dinamis dalam aliran yang sama untuk semua codec VP8, VP9, ​​H.264, dan H.265 yang diekspos ke pengembang melalui API Android standar.

Implementasi perangkat Android dengan decoder H.264, HARUS mendukung Profil Dasar Level 3 dan profil decoding video SD berikut dan HARUS mendukung profil decoding HD. Perangkat Televisi Android HARUS mendukung Profil Tinggi Level 4.2 dan profil decoding HD 1080p.

1 Diperlukan untuk implementasi perangkat Android Television, namun hanya untuk jenis perangkat lain jika didukung oleh perangkat keras.

2 Diperlukan untuk implementasi perangkat Android Television.

Implementasi perangkat Android ketika mendukung codec VP8 seperti dijelaskan di bagian 5.1.3 , HARUS mendukung profil decoding SD berikut dan HARUS mendukung profil decoding HD. Perangkat Televisi Android HARUS mendukung profil decoding HD 1080p.

1 Diperlukan untuk implementasi perangkat Android Television, namun untuk perangkat jenis lain hanya jika didukung oleh perangkat keras.

2 Diperlukan untuk implementasi perangkat Android Television.

Implementasi perangkat Android, ketika mendukung codec VP9 seperti dijelaskan di bagian 5.1.3 , HARUS mendukung profil decoding video SD berikut dan HARUS mendukung profil decoding HD. Perangkat Android Television SANGAT DIANJURKAN untuk mendukung profil decoding HD 1080p dan HARUS mendukung profil decoding UHD. Jika profil decoding video UHD didukung, profil tersebut HARUS mendukung kedalaman warna 8 bit.

1 Diperlukan untuk implementasi perangkat Android Television, namun untuk perangkat jenis lain hanya jika didukung oleh perangkat keras.

2 SANGAT DIREKOMENDASIKAN untuk implementasi perangkat Android Television bila didukung oleh perangkat keras.

Implementasi perangkat Android, ketika mendukung codec H.265 seperti yang dijelaskan di bagian 5.1.3 , HARUS mendukung Profil Utama Tingkat Utama 3 dan profil decoding video SD berikut dan HARUS mendukung profil decoding HD. Perangkat Televisi Android HARUS mendukung profil Tingkat Utama Main10 Level 5 dan profil decoding UHD. Perangkat Android Television SANGAT DIANJURKAN untuk mendukung profil decoding HD 1080p. Jika profil decoding HD 1080p didukung, profil tersebut HARUS mendukung Tingkat Utama Profil Utama Level 4.1

1 Diperlukan untuk implementasi perangkat Android Television, tetapi untuk perangkat jenis lain hanya jika didukung oleh perangkat keras.

2 SANGAT DIREKOMENDASIKAN untuk implementasi perangkat Android Television bila didukung oleh perangkat keras.

5.4. Rekaman audio

Meskipun beberapa persyaratan yang diuraikan dalam bagian ini dinyatakan sebagai HARUS sejak Android 4.3, Definisi Kompatibilitas untuk versi mendatang direncanakan akan mengubahnya menjadi HARUS. Perangkat Android lama dan baru SANGAT DIREKOMENDASIKAN untuk memenuhi persyaratan yang dinyatakan sebagai HARUS ini, atau perangkat tersebut tidak akan dapat memperoleh kompatibilitas Android saat ditingkatkan ke versi mendatang.

5.4.1. Pengambilan Audio Mentah

Implementasi perangkat yang mendeklarasikan android.hardware.microphone HARUS mengizinkan pengambilan konten audio mentah dengan karakteristik berikut:

• Format : PCM Linier, 16-bit
• Tingkat pengambilan sampel : 8000, 11025, 16000, 44100
• Saluran : Mono

Implementasi perangkat yang mendeklarasikan android.hardware.microphone HARUS mengizinkan pengambilan konten audio mentah dengan karakteristik berikut:

• Format : PCM Linier, 16-bit
• Tingkat pengambilan sampel : 22050, 48000
• Saluran : Stereo

5.4.2. Tangkap untuk Pengenalan Suara

Selain spesifikasi perekaman di atas, ketika aplikasi sudah mulai merekam streaming audio menggunakan sumber audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

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

Jika platform mendukung teknologi penindasan kebisingan yang disetel untuk pengenalan suara, efeknya harus dapat dikendalikan dari android.media.Audiofx.noisesuppressor API. Selain itu, bidang UUID untuk deskriptor efek penekan kebisingan harus secara unik mengidentifikasi setiap implementasi teknologi penindasan kebisingan.

5.4.3. Tangkap untuk Mengubah Rute Pemutaran

Kelas Android.Mediarecorder.Audiosource mencakup sumber audio Remote_submix. Perangkat yang mendeklarasikan android.hardware.audio.output harus mengimplementasikan sumber audio Remote_submix dengan benar sehingga ketika suatu aplikasi menggunakan android.media.Audiorecord API untuk merekam dari sumber audio ini, ia dapat menangkap campuran semua aliran audio kecuali untuk yang berikut ini :

• Stream_ring
• Stream_alarm
• Stream_notification

5.5. Pemutaran Audio

Implementasi perangkat yang mendeklarasikan android.hardware.audio.output harus sesuai dengan persyaratan di bagian ini.

5.5.1. Pemutaran Audio Mentah

Perangkat harus memungkinkan pemutaran konten audio mentah dengan karakteristik berikut:

• Format : PCM linier, 16-bit
• Tingkat pengambilan sampel : 8000, 11025, 16000, 22050, 32000, 44100
• Saluran : mono, stereo

Perangkat harus memungkinkan pemutaran konten audio mentah dengan karakteristik berikut:

• Tingkat pengambilan sampel : 24000, 48000

5.5.2. Efek Audio

Android menyediakan API untuk efek audio untuk implementasi perangkat [ sumber daya, 52 ]. Implementasi perangkat yang mendeklarasikan fitur android.hardware.audio.output:

• Harus mendukung implementasi Effect_type_eqelializer dan Effect_type_loudness_enhancer yang dapat dikendalikan melalui subkelas Equalizer Audioeffect, Firingnessenhancer.
• Harus mendukung implementasi API Visualisasi, dapat dikendalikan melalui kelas Visualisasi.
• Harus mendukung efek_type_bass_boost, efek_type_env_reverb, Effect_type_preset_reverb, dan implementasi Effect_type_virtuzer yang dapat dikendalikan melalui sub-kelas AudioEffect BassBoost, EnvironmentalReverB, Presetreverb, dan Virtualizer.

5.5.3. Volume Keluaran Audio

Implementasi perangkat televisi Android harus mencakup dukungan untuk volume master sistem dan atenuasi volume output audio digital pada output yang didukung, kecuali untuk output passthrough audio terkompresi (di mana tidak ada decoding audio yang dilakukan pada perangkat).

5.6. Latensi Audio

Latensi audio adalah penundaan waktu ketika sinyal audio melewati sistem. Banyak kelas aplikasi bergantung pada latensi pendek, untuk mencapai efek suara real-time.

Untuk keperluan bagian ini, gunakan definisi berikut:

• latensi keluaran . Interval antara ketika suatu aplikasi menulis bingkai data kode-PCM dan ketika suara yang sesuai dapat didengar oleh pendengar eksternal atau diamati oleh transduser.
• latensi keluaran dingin . Latensi output untuk bingkai pertama, ketika sistem output audio telah menganggur dan dimatikan sebelum permintaan.
• latensi keluaran berkelanjutan . Latensi output untuk frame berikutnya, setelah perangkat bermain audio.
• latensi input . Interval antara ketika suara eksternal disajikan ke perangkat dan ketika aplikasi membaca bingkai yang sesuai dari data kode PCM.
• latensi input dingin . Jumlah waktu input yang hilang dan latensi input untuk bingkai pertama, ketika sistem input audio telah menganggur dan ditenagai sebelum permintaan.
• latensi input berkelanjutan . Latensi input untuk bingkai berikutnya, saat perangkat menangkap audio.
• Jitter output dingin . Varians di antara pengukuran terpisah dari nilai latensi output dingin.
• Jitter input dingin . Varians di antara pengukuran terpisah dari nilai latensi input dingin.
• latensi perjalanan pulang-pergi yang berkelanjutan . Jumlah latensi input kontinu ditambah latensi output kontinu ditambah 5 milidetik.
• OpenSl ES PCM Buffer Antrian API . Set OpenSl ES terkait PCM dalam Android NDK; Lihat NDK_ROOT/DOCS/OPENSLES/INDEX.html.

Implementasi perangkat yang mendeklarasikan android.hardware.audio.output harus memenuhi atau melampaui persyaratan output audio ini:

• latensi output dingin 100 milidetik atau kurang
• Latensi keluaran terus menerus dari 45 milidetik atau kurang
• meminimalkan jitter output dingin

Jika implementasi perangkat memenuhi persyaratan bagian ini setelah kalibrasi awal saat menggunakan OpenSl ES PCM Buffer Queue API, untuk latensi output berkelanjutan dan latensi output dingin pada setidaknya satu perangkat output audio yang didukung, itu dapat melaporkan dukungan untuk audio latensi rendah rendah latensi rendah , dengan melaporkan fitur android.hardware.audio.low_latency melalui android.content.pm.packagemanager kelas [ sumber daya, 53 ]. Sebaliknya, jika implementasi perangkat tidak memenuhi persyaratan ini, ia tidak boleh melaporkan dukungan untuk audio latensi rendah.

Implementasi perangkat yang termasuk android.hardware.microphone harus memenuhi persyaratan audio input ini:

• latensi input dingin 100 milidetik atau kurang
• latensi input kontinu 30 milidetik atau kurang
• latensi pulang-pergi terus menerus dari 50 milidetik atau kurang
• meminimalkan jitter input dingin

5.7. Protokol Jaringan

Perangkat harus mendukung protokol jaringan media untuk pemutaran audio dan video sebagaimana ditentukan dalam dokumentasi Android SDK [ Resources, 50 ]. Secara khusus, perangkat harus mendukung protokol jaringan media berikut:

• RTSP (RTP, SDP)
• Http (s) streaming progresif
• HTTP (S) Live Streaming Draft Protocol, Versi 3 [ Sumber Daya, 54 ]

5.8. Media Aman

Implementasi perangkat yang mendukung output video yang aman dan mampu mendukung permukaan yang aman harus menyatakan dukungan untuk display.flag_secure. Implementasi perangkat yang mendeklarasikan dukungan untuk display.flag_secure, jika mereka mendukung protokol tampilan nirkabel, harus mengamankan tautan dengan mekanisme yang kuat secara kriptografis seperti HDCP 2.x atau lebih tinggi untuk tampilan nirkabel miracast. Demikian pula jika mereka mendukung tampilan eksternal kabel, implementasi perangkat harus mendukung HDCP 1.2 atau lebih tinggi. Implementasi perangkat televisi Android harus mendukung HDCP 2.2 untuk perangkat yang mendukung resolusi 4K dan HDCP 1.4 atau lebih untuk resolusi yang lebih rendah. Implementasi sumber terbuka Android hulu mencakup dukungan untuk tampilan nirkabel (miracast) dan kabel (HDMI) yang memenuhi persyaratan ini.

6. Kompatibilitas Alat Pengembang dan Opsi

6.1. Alat pengembang

Implementasi perangkat harus mendukung alat pengembang Android yang disediakan di Android SDK. Perangkat yang kompatibel Android harus kompatibel dengan:

• Android Debug Bridge (ADB) [ Sumber Daya, 55 ]

Implementasi perangkat harus mendukung semua fungsi ADB seperti yang didokumentasikan dalam SDK Android termasuk DUMPSYS [ Sumber Daya, 56 ]. Daemon ADB sisi perangkat harus tidak aktif secara default dan harus ada mekanisme yang dapat diakses pengguna untuk menghidupkan jembatan Android Debug. Jika implementasi perangkat menghilangkan mode periferal USB, ia harus mengimplementasikan jembatan Android Debug melalui jaringan area lokal (seperti Ethernet atau 802.11).

Android termasuk dukungan untuk ADB yang aman. Secure ADB Mengaktifkan ADB pada host yang diotentikasi yang diketahui. Implementasi perangkat harus mendukung ADB yang aman.

• Dalvik Debug Monitor Service (DDMS) [ Sumber Daya, 57 ]

Implementasi perangkat harus mendukung semua fitur DDMS seperti yang didokumentasikan dalam Android SDK. Karena DDMS menggunakan ADB, dukungan untuk DDMS harus tidak aktif secara default, tetapi harus didukung setiap kali pengguna mengaktifkan jembatan Android Debug, seperti di atas.

• Monyet [ Sumber Daya, 58 ]

Implementasi perangkat harus mencakup kerangka kerja monyet, dan membuatnya tersedia untuk aplikasi untuk digunakan.

• Systrace [ Sumber Daya, 59 ]

Implementasi perangkat harus mendukung alat Systrace seperti yang didokumentasikan dalam Android SDK. Systrace harus tidak aktif secara default, dan harus ada mekanisme yang dapat diakses pengguna untuk menyalakan Systrace.

Sebagian besar sistem berbasis Linux dan sistem Apple Macintosh mengenali perangkat Android menggunakan alat Android SDK standar, tanpa dukungan tambahan; Namun sistem Microsoft Windows biasanya memerlukan driver untuk perangkat Android baru. (Misalnya, ID vendor baru dan kadang -kadang ID perangkat baru memerlukan driver USB khusus untuk sistem Windows.) Jika implementasi perangkat tidak diakui oleh alat ADB sebagaimana disediakan dalam SDK Android standar, pelaksana perangkat harus menyediakan driver Windows yang memungkinkan pengembang untuk terhubung ke Perangkat menggunakan protokol ADB. Driver ini harus disediakan untuk Windows XP, Windows Vista, Windows 7, Windows 8, dan Windows 9 dalam versi 32-bit dan 64-bit.

6.2. Opsi Pengembang

Android termasuk dukungan bagi pengembang untuk mengonfigurasi pengaturan terkait pengembangan aplikasi. Implementasi perangkat harus menghormati Android.settings.application_development_settings Niat untuk menunjukkan pengaturan terkait pengembangan aplikasi [ Sumber Daya, 60 ]. Implementasi Android hulu menyembunyikan menu Opsi Pengembang secara default dan memungkinkan pengguna untuk meluncurkan opsi pengembang setelah menekan tujuh (7) kali pada pengaturan > tentang perangkat > Bangun item menu nomor . Implementasi perangkat harus memberikan pengalaman yang konsisten untuk opsi pengembang. Secara khusus, implementasi perangkat harus menyembunyikan opsi pengembang secara default dan harus memberikan mekanisme untuk memungkinkan opsi pengembang yang konsisten dengan implementasi Android hulu.

7. Kompatibilitas Perangkat Keras

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

• Definisi kelas lengkap (seperti yang didokumentasikan oleh SDK) untuk API komponen masih harus disajikan.
• Perilaku API harus diimplementasikan sebagai tidak ada ops dengan cara yang masuk akal.
• Metode API harus mengembalikan nilai nol jika diizinkan oleh dokumentasi SDK.
• Metode API harus mengembalikan implementasi kelas-kelas di mana nilai-nilai nol tidak diizinkan oleh dokumentasi SDK.
• Metode API tidak boleh melempar pengecualian yang tidak didokumentasikan oleh dokumentasi SDK.

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

Implementasi perangkat harus secara konsisten melaporkan informasi konfigurasi perangkat keras yang akurat melalui metode GetSystemAmailableFeatures () dan HassystemFeature (String) di kelas android.content.pm.packagemanager untuk sidik jari build yang sama. [ Sumber Daya, 53]

7.1. Tampilan dan Grafik

Android mencakup fasilitas yang secara otomatis menyesuaikan aset aplikasi dan tata letak UI secara tepat untuk perangkat, untuk memastikan bahwa aplikasi pihak ketiga berjalan dengan baik pada berbagai konfigurasi perangkat keras [ sumber daya, 61 ]. Perangkat harus mengimplementasikan API dan perilaku ini dengan benar, sebagaimana dirinci dalam bagian ini.

Unit yang dirujuk oleh persyaratan di bagian ini didefinisikan sebagai berikut:

• Ukuran diagonal fisik . Jarak dalam inci antara dua sudut yang berlawanan dari bagian layar yang diterangi.
• titik per inci (dpi) . Jumlah piksel yang dicakup oleh rentang horizontal atau vertikal linier 1 ”. Di mana nilai DPI terdaftar, baik DPI horizontal dan vertikal harus termasuk dalam kisaran.
• rasio aspek . Rasio piksel dari dimensi yang lebih panjang dengan dimensi layar yang lebih pendek. Misalnya, tampilan 480x854 piksel adalah 854/480 = 1.779, atau kira -kira “16: 9”.
• Pixel-independen-independen (DP) Unit piksel virtual dinormalisasi ke layar 160 dpi, dihitung sebagai: piksel = dps * (kepadatan/160).

7.1.1. Konfigurasi Layar

7.1.1.1. Ukuran layar

Kerangka kerja Android UI mendukung berbagai ukuran layar yang berbeda, dan memungkinkan aplikasi untuk menanyakan ukuran layar perangkat (alias "tata letak layar") melalui android.content.res.configuration.screenlayout dengan screenlayout_size_mask. Implementasi harus melaporkan ukuran layar yang benar. Sebagaimana didefinisikan dalam dokumentasi Android SDK [ Sumber Daya, 61 ] dan ditentukan oleh platform Android hulu. Secara khusus, implementasi perangkat harus melaporkan ukuran layar yang benar sesuai dengan dimensi layar piksel (DP) kepadatan logis berikut.

• Perangkat harus memiliki ukuran layar setidaknya 426 dp x 320 dp ('kecil'), kecuali itu adalah perangkat Android Watch.
• Perangkat yang melaporkan ukuran layar 'normal' harus memiliki ukuran layar setidaknya 480 dp x 320 dp.
• Perangkat yang melaporkan ukuran layar 'besar' harus memiliki ukuran layar setidaknya 640 dp x 480 dp.
• Perangkat yang melaporkan ukuran layar 'Xlarge' harus memiliki ukuran layar setidaknya 960 dp x 720 dp.

Selain itu,

• Perangkat Watch Android harus memiliki layar dengan ukuran diagonal fisik dalam kisaran dari 1,1 hingga 2,5 inci.
• Jenis lain dari implementasi perangkat Android, dengan layar yang terintegrasi secara fisik, harus memiliki layar setidaknya 2,5 inci dalam ukuran diagonal fisik.

Perangkat tidak boleh mengubah ukuran layar yang dilaporkan kapan saja.

Aplikasi secara opsional menunjukkan ukuran layar mana yang mereka dukung melalui atribut <sports-Screens> di file androidmanifest.xml. Implementasi perangkat harus menghormati aplikasi yang dinyatakan dengan benar untuk layar kecil, normal, besar, dan xlarge, seperti yang dijelaskan dalam dokumentasi Android SDK.

7.1.1.2. Rasio Aspek Layar

Rasio aspek layar harus bernilai dari 1.3333 (4: 3) hingga 1,86 (sekitar 16: 9), tetapi perangkat arloji Android mungkin memiliki rasio aspek 1.0 (1: 1) karena implementasi perangkat seperti itu akan menggunakan UI_MODE_TYPE_WATCH sebagai Android.content.res.configuration.uimode.

7.1.1.3. Kepadatan Layar

Kerangka kerja Android UI mendefinisikan serangkaian kepadatan logis standar untuk membantu pengembang aplikasi menargetkan sumber daya aplikasi. Implementasi perangkat harus melaporkan hanya salah satu dari kepadatan kerangka Android logis berikut melalui Android.util.DisplayMetrics API, dan harus menjalankan aplikasi pada kepadatan standar ini dan tidak boleh mengubah nilai pada kapan saja untuk tampilan default.

• 120dpi (ldpi)
• 160 dpi (mdpi)
• 213dpi (tvdpi)
• 240 dpi (HDPI)
• 280dpi (280dpi)
• 320 dpi (xhdpi)
• 400dpi (400dpi)
• 480 dpi (xxhdpi)
• 560dpi (560dpi)
• 640 dpi (xxxhdpi)

Implementasi perangkat harus menentukan kerapatan kerangka Android standar yang secara numerik terdekat dengan kepadatan fisik layar, kecuali kepadatan logis itu mendorong ukuran layar yang dilaporkan di bawah minimum yang didukung. Jika kepadatan kerangka Android standar yang paling dekat dengan kepadatan fisik menghasilkan ukuran layar yang lebih kecil dari ukuran layar kompatibel yang kompatibel dengan terkecil (lebar 320 dp), implementasi perangkat harus melaporkan kepadatan kerangka Android standar terendah berikutnya.

7.1.2. Metrik Tampilan

Implementasi perangkat harus melaporkan nilai yang benar untuk semua metrik tampilan yang ditentukan dalam android.util.displaymetrics [ sumber daya, 62 ] dan harus melaporkan nilai yang sama terlepas dari apakah layar tertanam atau eksternal digunakan sebagai tampilan default.

7.1.3. Orientasi layar

Perangkat harus melaporkan orientasi layar mana yang mereka dukung (android.hardware.screen.portrait dan/atau android.hardware.screen.landscape) dan harus melaporkan setidaknya satu orientasi yang didukung. Misalnya, perangkat dengan layar lansekap orientasi tetap, seperti televisi atau laptop, hanya harus melaporkan android.hardware.screen.landscape.

Perangkat yang melaporkan kedua orientasi layar harus mendukung orientasi dinamis berdasarkan aplikasi untuk orientasi potret atau lansekap layar. Artinya, perangkat harus menghormati permintaan aplikasi untuk orientasi layar tertentu. Implementasi perangkat dapat memilih orientasi potret atau lanskap sebagai default.

Perangkat harus melaporkan nilai yang benar untuk orientasi perangkat saat ini, kapan pun ditanya melalui android.content.res.configuration.orientation, android.view.display.getorientation (), atau API lainnya.

Perangkat tidak boleh mengubah ukuran atau kepadatan layar yang dilaporkan saat mengubah orientasi.

7.1.4. Akselerasi Grafik 2D dan 3D

Implementasi perangkat harus mendukung OpenGL ES 1.0 dan 2.0, sebagaimana diwujudkan dan dirinci dalam dokumentasi Android SDK. Implementasi perangkat harus mendukung OpenGL ES 3.0 atau 3.1 pada perangkat yang mampu mendukungnya. Implementasi perangkat juga harus mendukung Android RenderScript, sebagaimana dirinci dalam dokumentasi Android SDK [ Sumber Daya, 63 ].

Implementasi perangkat juga harus mengidentifikasi diri mereka dengan benar sebagai mendukung OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 atau OpenGL 3.1. Itu adalah:

• API yang dikelola (seperti melalui metode GLES10.GetString ()) harus melaporkan dukungan untuk OpenGL ES 1.0 dan OpenGL ES 2.0.
• API OpenGL C/C ++ asli (API tersedia untuk aplikasi melalui libgles_v1cm.so, libgles_v2.so, atau libegl.so) harus melaporkan dukungan untuk OpenGL ES 1.0 dan OpenGL ES 2.0.
• Implementasi perangkat yang mendeklarasikan dukungan untuk OpenGL ES 3.0 atau 3.1 harus mendukung API terkelola yang sesuai dan termasuk dukungan untuk API C/C ++ asli. Pada implementasi perangkat yang mendeklarasikan dukungan untuk OpenGL ES 3.0 atau 3.1, libglesv2.so harus mengekspor simbol fungsi yang sesuai selain simbol fungsi OpenGL ES 2.0.

Selain OpenGL ES 3.1, Android menyediakan paket ekstensi dengan antarmuka Java [ sumber daya, 64 ] dan dukungan asli untuk fungsionalitas grafis canggih seperti tessellation dan format kompresi tekstur ASTC. Implementasi perangkat Android dapat mendukung paket ekstensi ini, dan - hanya jika sepenuhnya diimplementasikan - harus mengidentifikasi dukungan melalui android.hardware.opengles.aep Feature Flag.

Juga, implementasi perangkat dapat menerapkan ekstensi OpenGL ES yang diinginkan. Namun, implementasi perangkat harus melaporkan melalui OpenGL ES yang dikelola dan API asli semua string ekstensi yang mereka dukung, dan sebaliknya tidak boleh melaporkan string ekstensi yang tidak mereka dukung.

Perhatikan bahwa Android mencakup dukungan untuk aplikasi untuk secara opsional menentukan bahwa mereka memerlukan format kompresi tekstur openGL tertentu. Format ini biasanya spesifik vendor. Implementasi perangkat tidak diperlukan oleh Android untuk mengimplementasikan format kompresi tekstur tertentu. Namun, mereka harus secara akurat melaporkan format kompresi tekstur apa pun yang mereka dukung, melalui metode getString () di API OpenGL.

Android mencakup mekanisme aplikasi untuk menyatakan bahwa mereka ingin mengaktifkan akselerasi perangkat keras untuk grafik 2D di level aplikasi, aktivitas, jendela, atau tampilan melalui penggunaan tag manifes Android: Hardwareaccelerated atau API panggilan API [ Sumber Daya, 65 ].

Implementasi perangkat harus mengaktifkan akselerasi perangkat keras secara default, dan harus menonaktifkan akselerasi perangkat keras jika pengembang jadi meminta dengan mengatur Android: HardWareAccelerated = "False" atau menonaktifkan akselerasi perangkat keras secara langsung melalui API tampilan Android.

Selain itu, implementasi perangkat harus menunjukkan perilaku yang konsisten dengan dokumentasi Android SDK tentang akselerasi perangkat keras [ Sumber Daya, 65 ].

Android termasuk objek TexturEview yang memungkinkan pengembang secara langsung mengintegrasikan tekstur OpenGl ES yang dipercepat dengan perangkat keras sebagai target render dalam hierarki UI. Implementasi perangkat harus mendukung API TextureView, dan harus menunjukkan perilaku yang konsisten dengan implementasi Android hulu.

Android termasuk dukungan untuk egl_android_recordable, atribut eglconfig yang menunjukkan apakah eglconfig mendukung rendering ke sebuah window anative yang merekam gambar ke video. Implementasi Perangkat harus mendukung ekstensi EGL_Android_Recordable [ Sumber Daya, 66 ].

7.1.5. Mode Kompatibilitas Aplikasi Lama

Android menentukan "mode kompatibilitas" di mana kerangka kerja beroperasi dalam mode ukuran layar 'normal' yang setara (lebar 320dp) untuk kepentingan aplikasi warisan yang tidak dikembangkan untuk versi lama Android yang pra-tanggal independensi ukuran layar.

• Android Automotive tidak mendukung mode kompatibilitas warisan.
• Semua implementasi perangkat lainnya harus mencakup dukungan untuk mode kompatibilitas aplikasi Legacy seperti yang diimplementasikan oleh kode sumber terbuka Android hulu. Artinya, implementasi perangkat tidak boleh mengubah pemicu atau ambang batas di mana mode kompatibilitas diaktifkan, dan tidak boleh mengubah perilaku mode kompatibilitas itu sendiri.

7.1.6. Teknologi Layar

Platform Android mencakup API yang memungkinkan aplikasi untuk membuat grafik yang kaya ke layar. Perangkat harus mendukung semua API ini sebagaimana didefinisikan oleh Android SDK kecuali diizinkan secara khusus dalam dokumen ini.

• Perangkat harus mendukung tampilan yang mampu memberikan grafik warna 16-bit dan harus mendukung tampilan yang mampu dari grafik warna 24-bit.
• Perangkat harus mendukung tampilan yang mampu membuat animasi.
• Teknologi tampilan yang digunakan harus memiliki rasio aspek piksel (PAR) antara 0,9 dan 1,15. Artinya, rasio aspek piksel harus dekat persegi (1.0) dengan toleransi 10 ~ 15%.

7.1.7. Tampilan Sekunder

Android termasuk dukungan untuk tampilan sekunder untuk memungkinkan kemampuan berbagi media dan API pengembang untuk mengakses tampilan eksternal. Jika perangkat mendukung tampilan eksternal baik melalui kabel, nirkabel, atau koneksi tampilan tambahan yang disematkan maka implementasi perangkat harus mengimplementasikan API Manajer Tampilan seperti yang dijelaskan dalam dokumentasi Android SDK [ Resources, 67 ].

7.2. Perangkat masukan

Perangkat harus mendukung layar sentuh atau memenuhi persyaratan yang tercantum dalam 7.2.2 untuk navigasi non-sentuhan.

7.2.1. Papan ketik

Implementasi perangkat:

• Harus mencakup dukungan untuk kerangka kerja manajemen input (yang memungkinkan pengembang pihak ketiga untuk membuat editor metode input-yaitu keyboard lunak) sebagaimana dirinci di http://developer.android.com .
• Harus memberikan setidaknya satu implementasi keyboard lunak (terlepas dari apakah ada keyboard yang keras) kecuali untuk perangkat Android Watch di mana ukuran layar membuatnya kurang masuk akal untuk memiliki keyboard lunak.
• Dapat menyertakan implementasi keyboard lunak tambahan.
• Mungkin termasuk keyboard perangkat keras.
• Tidak boleh menyertakan keyboard perangkat keras yang tidak cocok dengan salah satu format yang ditentukan dalam android.content.res.configuration.keyboard [ sumber daya, 68 ] (QWERTY atau 12-key).

7.2.2. Navigasi non-sentuh

Implementasi perangkat:

• Dapat menghilangkan opsi navigasi non-sentuh (trackball, d-pad, atau roda) jika implementasi perangkat bukan perangkat televisi Android.
• Harus melaporkan nilai yang benar untuk android.content.res.configuration.navigasi [ Sumber Daya, 68 ].
• Harus memberikan mekanisme antarmuka pengguna alternatif yang masuk akal untuk pemilihan dan pengeditan teks, kompatibel dengan mesin manajemen input. Implementasi sumber terbuka Android hulu mencakup mekanisme pemilihan yang cocok untuk digunakan dengan perangkat yang tidak memiliki input navigasi non-sentuhan.

7.2.3. Tombol Navigasi

Fungsi rumah, resents, dan punggung (dipetakan ke acara kunci keycode_home, keycode_app_switch, keycode_back, masing -masing) sangat penting untuk paradigma navigasi android dan karenanya:

• Implementasi perangkat genggam Android harus menyediakan fungsi rumah, istirahat, dan punggung.
• Implementasi perangkat televisi Android harus menyediakan fungsi rumah dan punggung.
• Implementasi perangkat Android Watch harus memiliki fungsi rumah yang tersedia untuk pengguna, dan fungsi kembali kecuali saat berada di UI_MODE_TYPE_WATCH.
• Implementasi otomotif Android harus menyediakan fungsi rumah dan dapat menyediakan fungsi kembali dan terbaru.
• Semua jenis implementasi perangkat lainnya harus menyediakan fungsi rumah dan punggung.

Fungsi -fungsi ini dapat diimplementasikan melalui tombol fisik khusus (seperti tombol sentuh mekanik atau kapasitif), atau dapat diimplementasikan menggunakan tombol perangkat lunak khusus pada bagian layar yang berbeda, gerakan, panel sentuh, dll. Android mendukung kedua implementasi. Semua fungsi ini harus dapat diakses dengan satu tindakan (misalnya tap, klik dua kali atau gerakan) saat terlihat.

Fungsi resent, jika disediakan, harus memiliki tombol atau ikon yang terlihat kecuali disembunyikan bersama dengan fungsi navigasi lainnya dalam mode layar penuh. Ini tidak berlaku untuk peningkatan perangkat dari versi Android sebelumnya yang memiliki tombol fisik untuk navigasi dan tidak ada kunci RESEN.

Fungsi rumah dan punggung, jika disediakan, masing-masing harus memiliki tombol atau ikon yang terlihat kecuali disembunyikan bersama dengan fungsi navigasi lainnya dalam mode layar penuh atau ketika UIMode UI_MODE_TYPE_MASK diatur ke UI_MODE_TYPE_WATCH.

Fungsi menu sudah usang mendukung bilah tindakan sejak Android 4.0. Oleh karena itu pengiriman implementasi perangkat baru dengan Android 5.0 dan yang lebih baru tidak boleh menerapkan tombol fisik khusus untuk fungsi menu. Implementasi perangkat yang lebih lama tidak boleh mengimplementasikan tombol fisik khusus untuk fungsi menu, tetapi jika tombol menu fisik diimplementasikan dan perangkat menjalankan aplikasi dengan TargetSDKVersion> 10, implementasi perangkat:

• Harus menampilkan tombol overflow Action pada bilah aksi saat terlihat dan popup menu overflow tindakan yang dihasilkan tidak kosong. Untuk implementasi perangkat yang diluncurkan sebelum Android 4.4 tetapi meningkatkan ke Android 5.1, ini disarankan.
• Tidak boleh memodifikasi posisi popup overflow aksi yang ditampilkan dengan memilih tombol overflow di bilah tindakan.
• Dapat membuat popup overflow aksi pada posisi yang dimodifikasi di layar saat ditampilkan dengan memilih tombol menu fisik.

Untuk kompatibilitas mundur, implementasi perangkat harus membuat fungsi menu tersedia untuk aplikasi ketika targetSDKVersion kurang dari 10, baik dengan tombol fisik, kunci perangkat lunak, atau gerakan. Fungsi menu ini harus disajikan kecuali disembunyikan bersama dengan fungsi navigasi lainnya.

Android mendukung tindakan bantuan [ sumber daya, 69 ]. Implementasi Perangkat Android Kecuali untuk perangkat Android Watch harus membuat tindakan bantuan tersedia untuk pengguna setiap saat saat menjalankan aplikasi. Tindakan assist harus diimplementasikan sebagai tekanan panjang pada tombol beranda atau gerakan gesek pada kunci home perangkat lunak. Fungsi ini dapat diimplementasikan melalui tombol fisik lain, kunci perangkat lunak, atau gerakan, tetapi harus dapat diakses dengan satu tindakan (misalnya tap, klik dua kali, atau gerakan) ketika kunci navigasi lainnya terlihat.

Implementasi perangkat dapat menggunakan bagian yang berbeda dari layar untuk menampilkan kunci navigasi, tetapi jika demikian, harus memenuhi persyaratan ini:

• Kunci navigasi implementasi perangkat harus menggunakan bagian yang berbeda dari layar, tidak tersedia untuk aplikasi, dan tidak boleh mengaburkan atau mengganggu bagian layar yang tersedia untuk aplikasi.
• Implementasi perangkat harus menyediakan sebagian tampilan ke aplikasi yang memenuhi persyaratan yang ditentukan dalam Bagian 7.1.1 .
• Implementasi perangkat harus menampilkan tombol navigasi ketika aplikasi tidak menentukan mode Sistem UI, atau menentukan System_UI_FLAG_VISIBLE.
• Implementasi perangkat harus menyajikan tombol navigasi dalam mode “low profile” (mis. Dimmed) yang tidak mencolok saat aplikasi menentukan System_UI_FLAG_LOW_PROFILE.
• Implementasi perangkat harus menyembunyikan tombol navigasi saat aplikasi menentukan System_UI_FLAG_HIDE_NAVIGASI.

7.2.4. Masukan Layar Sentuh

Implementasi perangkat harus memiliki sistem input pointer dari beberapa jenis (baik seperti mouse atau sentuhan). Namun, jika implementasi perangkat tidak mendukung sistem input pointer, ia tidak boleh melaporkan android.hardware.touchscreen atau android.hardware.faketouch fitur konstan. Implementasi perangkat yang mencakup sistem input pointer:

• Harus mendukung pointer yang dilacak secara independen sepenuhnya, jika sistem input perangkat mendukung beberapa pointer.
• Harus melaporkan nilai android.content.res.configuration.touchscreen [ sumber daya, 68 ] yang sesuai dengan jenis layar sentuh spesifik pada perangkat.

Android termasuk dukungan untuk berbagai layar sentuh, bantalan sentuh, dan perangkat input sentuh palsu. Implementasi perangkat berbasis layar sentuh dikaitkan dengan tampilan [ sumber daya, 70 ] sehingga pengguna memiliki kesan memanipulasi item secara langsung di layar. Karena pengguna secara langsung menyentuh layar, sistem tidak memerlukan biaya tambahan untuk menunjukkan objek yang dimanipulasi. Sebaliknya, antarmuka sentuh palsu menyediakan sistem input pengguna yang mendekati subset kemampuan layar sentuh. Misalnya, mouse atau remote control yang menggerakkan kursor di layar mendekati sentuhan, tetapi mengharuskan pengguna ke titik pertama atau fokus kemudian klik. Banyak perangkat input seperti mouse, trackpad, mouse udara berbasis gyro, gyro-pointer, joystick, dan trackpad multi-touch dapat mendukung interaksi sentuh palsu. Android mencakup fitur konstan android.hardware.faketouch, yang sesuai dengan perangkat input non-sentuh (pointer-berbasis pointer) yang tinggi seperti mouse atau trackpad yang dapat secara memadai meniru input berbasis sentuh (termasuk dukungan gesture dasar), dan menunjukkan bahwa perangkat mendukung subset yang ditiru dari fungsionalitas layar sentuh. Implementasi perangkat yang mendeklarasikan fitur sentuh palsu harus memenuhi persyaratan sentuh palsu di Bagian 7.2.5 .

Implementasi perangkat harus melaporkan fitur yang benar sesuai dengan jenis input yang digunakan. Implementasi perangkat yang menyertakan layar sentuh (sentuhan tunggal atau lebih baik) harus melaporkan fitur platform konstan android.hardware.touchscreen. Implementasi perangkat yang melaporkan fitur platform konstan android.hardware.touchscreen juga harus melaporkan fitur platform konstan android.hardware.faketouch. Implementasi perangkat yang tidak termasuk layar sentuh (dan hanya mengandalkan perangkat pointer) tidak boleh melaporkan fitur layar sentuh, dan hanya harus melaporkan android.hardware.faketouch jika mereka memenuhi persyaratan sentuh palsu di Bagian 7.2.5 .

7.2.5. Masukan Sentuhan Palsu

Implementasi perangkat yang mendeklarasikan dukungan untuk android.hardware.faketouch:

• Harus melaporkan posisi layar X dan Y absolut dari lokasi pointer dan menampilkan pointer visual di layar [ sumber daya, 71 ].
• Harus melaporkan acara sentuh dengan kode tindakan yang menentukan perubahan status yang terjadi pada penunjuk turun atau naik di layar [ sumber daya, 71 ].
• Harus mendukung pointer ke bawah dan naik pada objek di layar, yang memungkinkan pengguna untuk meniru ketuk pada objek di layar.
• Harus mendukung pointer ke bawah, pointer ke atas, pointer ke bawah lalu pointer ke atas di tempat yang sama pada objek di layar dalam ambang waktu, yang memungkinkan pengguna untuk meniru ketuk ganda pada objek pada layar [ sumber daya, 71 ].
• Harus mendukung pointer ke bawah pada titik sewenang -wenang di layar, pointer pindah ke titik sewenang -wenang lainnya di layar, diikuti oleh pointer ke atas, yang memungkinkan pengguna untuk meniru drag sentuhan.
• Harus mendukung Pointer ke bawah kemudian memungkinkan pengguna untuk dengan cepat memindahkan objek ke posisi yang berbeda di layar dan kemudian pointer ke atas di layar, yang memungkinkan pengguna untuk melemparkan objek di layar.

Perangkat yang menyatakan dukungan untuk android.hardware.faketouch.multitouch.dentinct harus memenuhi persyaratan untuk faketouch di atas, dan juga harus mendukung pelacakan berbeda dari dua atau lebih input pointer independen.

7.2.6. Dukungan Pengontrol Game

Implementasi perangkat televisi Android harus mendukung pemetaan tombol untuk pengontrol game seperti yang tercantum di bawah ini. Implementasi Android hulu mencakup implementasi untuk pengontrol game yang memenuhi persyaratan ini.

7.2.6.1. Pemetaan Tombol

Implementasi perangkat televisi Android harus mendukung pemetaan kunci berikut:

1 [ Resources, 72 ]

2 The above HID usages must be declared within a Game pad CA (0x01 0x0005).

3 This usage must have a Logical Minimum of 0, a Logical Maximum of 7, a Physical Minimum of 0, a Physical Maximum of 315, Units in Degrees, and a Report Size of 4. The logical value is defined to be the clockwise rotation away from the vertical axis; for example, a logical value of 0 represents no rotation and the up button being pressed, while a logical value of 1 represents a rotation of 45 degrees and both the up and left keys being pressed.

4 [ Resources, 71 ]

1 [ Resources, 71 ]

7.2.7. Kendali Jarak Jauh

Android Television device implementations SHOULD provide a remote control to allow users to access the TV interface. The remote control MAY be a physical remote or can be a software-based remote that is accessible from a mobile phone or tablet. The remote control MUST meet the requirements defined below.

• Search affordance . Device implementations MUST fire KEYCODE_SEARCH when the user invokes voice search either on the physical or software-based remote.
• Navigasi . All Android Television remotes MUST include Back, Home, and Select buttons and support for D-pad events [ Resources, 72 ].

7.3. Sensor

Android includes APIs for accessing a variety of sensor types. Devices implementations generally MAY omit these sensors, as provided for in the following subsections. If a device includes a particular sensor type that has a corresponding API for third-party developers, the device implementation MUST implement that API as described in the Android SDK documentation and the Android Open Source documentation on sensors [ Resources, 73 ]. For example, device implementations:

• MUST accurately report the presence or absence of sensors per the android.content.pm.PackageManager class [ Resources, 53] .
• MUST return an accurate list of supported sensors via the SensorManager.getSensorList() and similar methods.
• MUST behave reasonably for all other sensor APIs (for example, by returning true or false as appropriate when applications attempt to register listeners, not calling sensor listeners when the corresponding sensors are not present; etc.).
• MUST report all sensor measurements using the relevant International System of Units (metric) values for each sensor type as defined in the Android SDK documentation [ Resources, 74 ].
• SHOULD report the event time in nanoseconds as defined in the Android SDK documentation, representing the time the event happened and synchronized with the SystemClock.elapsedRealtimeNano() clock. Existing and new Android devices are very strongly encouraged to meet these requirement so they will be able to upgrade to the future platform releases where this might become a REQUIRED component. The synchronization error SHOULD be below 100 milliseconds [ Resources, 75 ].

The list above is not comprehensive; the documented behavior of the Android SDK and the Android Open Source Documentations on Sensors [ Resources, 73 ] is to be considered authoritative.

Some sensor types are composite, meaning they can be derived from data provided by one or more other sensors. (Examples include the orientation sensor, and the linear acceleration sensor.) Device implementations SHOULD implement these sensor types, when they include the prerequisite physical sensors as described in [ Resources, 76 ]. If a device implementation includes a composite sensor it MUST implement the sensor as described in the Android Open Source documentation on composite sensors [ Resources, 76 ].

Some Android sensors support a “continuous” trigger mode, which returns data continuously [ Resources, 77 ]. For any API indicated by the Android SDK documentation to be a continuous sensor, device implementations MUST continuously provide periodic data samples that SHOULD have a jitter below 3%, where jitter is defined as the standard deviation of the difference of the reported timestamp values between consecutive acara.

Note that the device implementations MUST ensure that the sensor event stream MUST NOT prevent the device CPU from entering a suspend state or waking up from a suspend state.

Finally, when several sensors are activated, the power consumption SHOULD NOT exceed the sum of the individual sensor's reported power consumption.

7.3.1. Akselerometer

Device implementations SHOULD include a 3-axis accelerometer. Android Handheld devices and Android Watch devices are strongly encouraged to include this sensor. If a device implementation does include a 3-axis accelerometer, it:

• MUST implement and report TYPE_ACCELEROMETER sensor [ Resources, 78 ].
• MUST be able to report events up to a frequency of at least 50 Hz for Android Watch devices as such devices have a stricter power constraint and 100 Hz for all other device types.
• SHOULD report events up to at least 200 Hz.
• MUST comply with the Android sensor coordinate system as detailed in the Android APIs [ Resources, 74 ].
• MUST be capable of measuring from freefall up to four times the gravity (4g) or more on any axis.
• MUST have a resolution of at least 8-bits and SHOULD have a resolution of at least 16-bits.
• SHOULD be calibrated while in use if the characteristics changes over the life cycle and compensated, and preserve the compensation parameters between device reboots.
• SHOULD be temperature compensated.
• MUST have a standard deviation no greater than 0.05 m/s^, where the standard deviation should be calculated on a per axis basis on samples collected over a period of at least 3 seconds at the fastest sampling rate.
• SHOULD implement the TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER composite sensors as described in the Android SDK document. Existing and new Android devices are very strongly encouraged to implement the TYPE_SIGNIFICANT_MOTION composite sensor. If any of these sensors are implemented, the sum of their power consumption MUST always be less than 4 mW and SHOULD each be below 2 mW and 0.5 mW for when the device is in a dynamic or static condition.
• If a gyroscope sensor is included, MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors and SHOULD implement the TYPE_GAME_ROTATION_VECTOR composite sensor. Existing and new Android devices are strongly encouraged to implement the TYPE_GAME_ROTATION_VECTOR sensor.
• SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if a gyroscope sensor and a magnetometer sensor is also included.

7.3.2. magnetometer

Device implementations SHOULD include a 3-axis magnetometer (compass). If a device does include a 3-axis magnetometer, it:

• MUST implement the TYPE_MAGNETIC_FIELD sensor and SHOULD also implement TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor. Existing and new Android devices are strongly encouraged to implement the TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor.
• MUST be able to report events up to a frequency of at least 10 Hz and SHOULD report events up to at least 50 Hz.
• MUST comply with the Android sensor coordinate system as detailed in the Android APIs [ Resources, 74 ].
• MUST be capable of measuring between -900 µT and +900 µT on each axis before saturating.
• MUST have a hard iron offset value less than 700 µT and SHOULD have a value below 200 µT, by placing the magnetometer far from dynamic (current-induced) and static (magnet-induced) magnetic fields.
• MUST have a resolution equal or denser than 0.6 µT and SHOULD have a resolution equal or denser than 0.2 µ.
• SHOULD be temperature compensated.
• MUST support online calibration and compensation of the hard iron bias, and preserve the compensation parameters between device reboots.
• MUST have the soft iron compensation applied—the calibration can be done either while in use or during the production of the device.
• SHOULD have a standard deviation, calculated on a per axis basis on samples collected over a period of at least 3 seconds at the fastest sampling rate, no greater than 0.5 µT.
• SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer sensor and a gyroscope sensor is also included.
• MAY implement the TYPE_GEOMAGNETIC_ROTATION_VECTOR sensor if an accelerometer sensor is also implemented. However if implemented, it MUST consume less than 10 mW and SHOULD consume less than 3 mW when the sensor is registered for batch mode at 10 Hz.

7.3.3. GPS

Device implementations SHOULD include a GPS receiver. If a device implementation does include a GPS receiver, it SHOULD include some form of“assisted GPS” technique to minimize GPS lock-on time.

7.3.4. Giroskop

Device implementations SHOULD include a gyroscope (angular change sensor). Devices SHOULD NOT include a gyroscope sensor unless a 3-axis accelerometer is also included. If a device implementation includes a gyroscope, it:

• MUST implement the TYPE_GYROSCOPE sensor and SHOULD also implement TYPE_GYROSCOPE_UNCALIBRATED sensor. Existing and new Android devices are strongly encouraged to implement the SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sensor.
• MUST be capable of measuring orientation changes up to 1,000 degrees per second.
• MUST be able to report events up to a frequency of at least 50 Hz for Android Watch devices as such devices have a stricter power constraint and 100 Hz for all other device types.
• SHOULD report events up to at least 200 Hz.
• MUST have a resolution of 12-bits or more and SHOULD have a resolution of 16-bits or more.
• MUST be temperature compensated.
• MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
• MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but must be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it should be no greater than 1e-7 rad^2/s^2.
• SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer sensor and a magnetometer sensor is also included.
• If an accelerometer sensor is included, MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors and SHOULD implement the TYPE_GAME_ROTATION_VECTOR composite sensor. Existing and new Android devices are strongly encouraged to implement the TYPE_GAME_ROTATION_VECTOR sensor.

7.3.5. Barometer

Device implementations SHOULD include a barometer (ambient air pressure sensor). If a device implementation includes a barometer, it:

• MUST implement and report TYPE_PRESSURE sensor.
• MUST be able to deliver events at 5 Hz or greater.
• MUST have adequate precision to enable estimating altitude.
• MUST be temperature compensated.

7.3.6. Termometer

Device implementations MAY include an ambient thermometer (temperature sensor). If present, it MUST be defined as SENSOR_TYPE_AMBIENT_TEMPERATURE and it MUST measure the ambient (room) temperature in degrees Celsius.

Device implementations MAY but SHOULD NOT include a CPU temperature sensor. If present, it MUST be defined as SENSOR_TYPE_TEMPERATURE, it MUST measure the temperature of the device CPU, and it MUST NOT measure any other temperature. Note the SENSOR_TYPE_TEMPERATURE sensor type was deprecated in Android 4.0.

7.3.7. Fotometer

Device implementations MAY include a photometer (ambient light sensor).

7.3.8. Sensor jarak

Device implementations MAY include a proximity sensor. Devices that can make a voice call and indicate any value other than PHONE_TYPE_NONE in getPhoneType SHOULD include a proximity sensor. If a device implementation does include a proximity sensor, it:

• MUST measure the proximity of an object in the same direction as the screen. That is, the proximity sensor MUST be oriented to detect objects close to the screen, as the primary intent of this sensor type is to detect a phone in use by the user. If a device implementation includes a proximity sensor with any other orientation, it MUST NOT be accessible through this API.
• MUST have 1-bit of accuracy or more.

7.4. Konektivitas Data

7.4.1. Telepon

“Telephony” as used by the Android APIs and this document refers specifically to hardware related to placing voice calls and sending SMS messages via a GSM or CDMA network. While these voice calls may or may not be packet-switched, they are for the purposes of Android considered independent of any data connectivity that may be implemented using the same network. In other words, the Android “telephony” functionality and APIs refer specifically to voice calls and SMS. For instance, device implementations that cannot place calls or send/receive SMS messages MUST NOT report the android.hardware.telephony feature or any subfeatures, regardless of whether they use a cellular network for data connectivity.

Android MAY be used on devices that do not include telephony hardware. That is, Android is compatible with devices that are not phones. However, if a device implementation does include GSM or CDMA telephony, it MUST implement full support for the API for that technology. Device implementations that do not include telephony hardware MUST implement the full APIs as no-ops.

7.4.2. IEEE 802.11 (Wi-Fi)

Android Television device implementations MUST include support for one or more forms of 802.11 (b/g/a/n, etc.) and other types of Android device implementation SHOULD include support for one or more forms of 802.11. If a device implementation does include support for 802.11 and exposes the functionality to a third-party application, it MUST implement the corresponding Android API and:

• MUST report the hardware feature flag android.hardware.wifi.
• MUST implement the multicast API as described in the SDK documentation [ Resources, 79 ].
• MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets (224.0.0.251) at any time of operation including when the screen is not in an active state.

7.4.2.1. Wi-Fi Langsung

Device implementations SHOULD include support for Wi-Fi Direct (Wi-Fi peer-to-peer). If a device implementation does include support for Wi-Fi Direct, it MUST implement the corresponding Android API as described in the SDK documentation [ Resources, 80 ]. If a device implementation includes support for Wi-Fi Direct, then it:

• MUST report the hardware feature android.hardware.wifi.direct.
• MUST support regular Wi-Fi operation.
• SHOULD support concurrent Wi-Fi and Wi-Fi Direct operation.

7.4.2.2. Pengaturan Tautan Langsung Terowongan Wi-Fi

Android Television device implementations MUST include support for Wi-Fi Tunneled Direct Link Setup (TDLS) and other types of Android device implementations SHOULD include support for Wi-Fi TDLS as described in the Android SDK Documentation [ Resources, 81 ]. If a device implementation does include support for TDLS and TDLS is enabled by the WiFiManager API, the device:

• SHOULD use TDLS only when it is possible AND beneficial.
• SHOULD have some heuristic and NOT use TDLS when its performance might be worse than going through the Wi-Fi access point.

7.4.3. Bluetooth

Android includes support for Bluetooth and Bluetooth Low Energy [ Resources, 82 ]. Device implementations that include support for Bluetooth and Bluetooth Low Energy MUST declare the relevant platform features (android.hardware.bluetooth and android.hardware.bluetooth_le respectively) and implement the platform APIs. Device implementations SHOULD implement relevant Bluetooth profiles such as A2DP, AVCP, OBEX, etc. as appropriate for the device. Android Television device implementations MUST support Bluetooth and Bluetooth LE.

Device implementations including support for Bluetooth Low Energy:

• MUST declare the hardware feature android.hardware.bluetooth_le.
• MUST enable the GATT (generic attribute profile) based Bluetooth APIs as described in the SDK documentation and [ Resources, 82 ].
• SHOULD support offloading of the filtering logic to the bluetooth chipset when implementing the ScanFilter API [ Resources, 83 ], and MUST report the correct value of where the filtering logic is implemented whenever queried via the android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() method.
• SHOULD support offloading of the batched scanning to the bluetooth chipset, but if not supported, MUST report 'false' whenever queried via the android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported() method.
• SHOULD support multi advertisement with at least 4 slots, but if not supported, MUST report 'false' whenever queried via the android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() method.

7.4.4. Komunikasi Jarak Dekat

Device implementations SHOULD include a transceiver and related hardware for Near-Field Communications (NFC). If a device implementation does include NFC hardware and plans to make it available to third-party apps, then it:

• MUST report the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 53 ].
• MUST be capable of reading and writing NDEF messages via the following NFC standards:
  • MUST be capable of acting as an NFC Forum reader/writer (as defined by the NFC Forum technical specification NFCForum-TS-DigitalProtocol-1.0) via the following NFC standards:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)
  • SHOULD be capable of reading and writing NDEF messages via the following NFC standards. Note that while the NFC standards below are stated as SHOULD, the Compatibility Definition for a future version is planned to change these to MUST. These standards are optional in this version but will be required in future versions. Existing and new devices that run this version of Android are very strongly encouraged to meet these requirements now so they will be able to upgrade to the future platform releases.
  • NfcV (ISO 15693)
  • MUST be capable of transmitting and receiving data via the following peer-to-peer standards and protocols:
    • ISO 18092
    • LLCP 1.0 (defined by the NFC Forum)
    • SDP 1.0 (defined by the NFC Forum)
    • NDEF Push Protocol [ Resources, 84 ]
    • SNEP 1.0 (defined by the NFC Forum)
  • MUST include support for Android Beam [ Resources, 85 ]:
    • MUST implement the SNEP default server. Valid NDEF messages received by the default SNEP server MUST be dispatched to applications using the android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam in settings MUST NOT disable dispatch of incoming NDEF message.
    • MUST honor the android.settings.NFCSHARING_SETTINGS intent to show NFC sharing settings [ Resources, 86 ].
    • MUST implement the NPP server. Messages received by the NPP server MUST be processed the same way as the SNEP default server.
    • MUST implement a SNEP client and attempt to send outbound P2P NDEF to the default SNEP server when Android Beam is enabled. If no default SNEP server is found then the client MUST attempt to send to an NPP server.
    • MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage, and android.nfc.NfcAdapter.setNdefPushMessageCallback, and android.nfc.NfcAdapter.enableForegroundNdefPush.
    • SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', before sending outbound P2P NDEF messages.
    • SHOULD enable Android Beam by default and MUST be able to send and receive using Android Beam, even when another proprietary NFC P2p mode is turned on.
    • MUST support NFC Connection handover to Bluetooth when the device supports Bluetooth Object Push Profile. Device implementations MUST support connection handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris, by implementing the “Connection Handover version 1.2” [ Resources, 87 ] and “Bluetooth Secure Simple Pairing Using NFC version 1.0” [ Resources, 88 ] specs from the NFC Forum. Such an implementation MUST implement the handover LLCP service with service name “urn:nfc:sn:handover” for exchanging the handover request/select records over NFC, and it MUST use the Bluetooth Object Push Profile for the actual Bluetooth data transfer. For legacy reasons (to remain compatible with Android 4.1 devices), the implementation SHOULD still accept SNEP GET requests for exchanging the handover request/select records over NFC. However an implementation itself SHOULD NOT send SNEP GET requests for performing connection handover.
  • MUST poll for all supported technologies while in NFC discovery mode.
  • SHOULD be in NFC discovery mode while the device is awake with the screen active and the lock-screen unlocked.

(Note that publicly available links are not available for the JIS, ISO, and NFC Forum specifications cited above.)

Android includes support for NFC Host Card Emulation (HCE) mode. If a device implementation does include an NFC controller chipset capable of HCE and Application ID (AID) routing, then it:

• MUST report the android.hardware.nfc.hce feature constant.
• MUST support NFC HCE APIs as defined in the Android SDK [ Resources, 10 ].

Additionally, device implementations MAY include reader/writer support for the following MIFARE technologies.

• MIFARE Klasik
• MIFARE Ultralight
• NDEF on MIFARE Classic

Note that Android includes APIs for these MIFARE types. If a device implementation supports MIFARE in the reader/writer role, it:

• MUST implement the corresponding Android APIs as documented by the Android SDK.
• MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() meth od [Resources, 53] . Note that this is not a standard Android feature and as such does not appear as a constant on the PackageManager class.
• MUST NOT implement the corresponding Android APIs nor report the com.nxp.mifare feature unless it also implements general NFC support as described in this section.

If a device implementation does not include NFC hardware, it MUST NOT declare the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 53] , and MUST implement the Android NFC API as a tidak ada operasi.

As the classes android.nfc.NdefMessage and android.nfc.NdefRecord represent a protocol-independent data representation format, device implementations MUST implement these APIs even if they do not include support for NFC or declare the android.hardware.nfc feature.

7.4.5. Kemampuan Jaringan Minimum

Device implementations MUST include support for one or more forms of data networking. Specifically, device implementations MUST include support for at least one data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN, etc.

Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (Wi-Fi).

Devices MAY implement more than one form of data connectivity.

7.4.6. Pengaturan Sinkronisasi

Device implementations MUST have the master auto-sync setting on by default so that the method getMasterSyncAutomatically() returns “true” [ Resources, 89 ].

7.5. Kamera

Device implementations SHOULD include a rear-facing camera and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

If a device implementation includes at least one camera, it SHOULD be possible for an application to simultaneously allocate 3 bitmaps equal to the size of the images produced by the largest-resolution camera sensor on the device.

7.5.1. Kamera Menghadap ke Belakang

Device implementations SHOULD include a rear-facing camera. If a device implementation includes at least one rear-facing camera, it:

• MUST report the feature flag android.hardware.camera and android.hardware.camera.any.
• MUST have a resolution of at least 2 megapixels.
• SHOULD have either hardware auto-focus or software auto-focus implemented in the camera driver (transparent to application software).
• MAY have fixed-focus or EDOF (extended depth of field) hardware.
• MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a Camera.Parameters object. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback.

7.5.2. Kamera Menghadap Depan

Device implementations MAY include a front-facing camera. If a device implementation includes at least one front-facing camera, it:

• MUST report the feature flag android.hardware.camera.any and android.hardware.camera.front.
• MUST have a resolution of at least VGA (640x480 pixels).
• MUST NOT use a front-facing camera as the default for the Camera API. The camera API in Android has specific support for front-facing cameras and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on the device.
• MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in section 7.5.1 .
• MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:
  • If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
  • If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation()[ Resources, 90 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
  • Otherwise, the preview MUST be mirrored along the device's default horizontal axis.
• MUST mirror the image displayed by the postview in the same manner as the camera preview image stream. If the device implementation does not support postview, this requirement obviously does not apply.
• MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage.

7.5.3. Kamera Eksternal

Device implementations with USB host mode MAY include support for an external camera that connects to the USB port. If a device includes support for an external camera, it:

• MUST declare the platform feature android.hardware.camera.external and android.hardware camera.any.
• MUST support USB Video Class (UVC 1.0 or higher).
• MAY support multiple cameras.

Video compression (such as MJPEG) support is RECOMMENDED to enable transfer of high-quality unencoded streams (ie raw or independently compressed picture streams). Camera-based video encoding MAY be supported. If so, a simultaneous unencoded/ MJPEG stream (QVGA or greater resolution) MUST be accessible to the device implementation.

7.5.4. Perilaku API Kamera

Android includes two API packages to access the camera, the newer android.hardware.camera2 API expose lower-level camera control to the app, including efficient zero-copy burst/streaming flows and per-frame controls of exposure, gain, white balance gains, color conversion, denoising, sharpening, and more.

The older API package, android.hardware.Camera, is marked as deprecated in Android 5.0 but as it should still be available for apps to use Android device implementations MUST ensure the continued support of the API as described in this section and in the Android SDK .

Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras:

• If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
• If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
• For android.hardware.Camera, device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)
• For android.hardware.camera2, device implementations must support the android.hardware.ImageFormat.YUV_420_888 and android.hardware.ImageFormat.JPEG formats as outputs through the android.media.ImageReader API.

Device implementations MUST still implement the full Camera API included in the Android SDK documentation [ Resources, 91 ], regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be “faked” as described.

Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters. That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 92 ].

Because not all device implementations can fully support all the features of the android.hardware.camera2 API, device implementations MUST report the proper level of support with the android.info.supportedHardwareLevel property as described in the Android SDK [ Resources, 93] and report the appropriate framework feature flags [ Resources, 94] .

Device implementations MUST also declare its Individual camera capabilities of android.hardware.camera2 via the android.request.availableCapabilities property and declare the appropriate feature flags [ Resources, 94] ; a device must define the feature flag if any of its attached camera devices supports the feature.

Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

7.5.5. Orientasi Kamera

Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

7.6. Memori dan Penyimpanan

7.6.1. Memori dan Penyimpanan Minimum

The memory available to the kernel and userspace on device implementations MUST be at least equal or larger than the minimum values specified by the following table. (See section 7.1.1 for screen size and density definitions.)

The minimum memory values MUST be in addition to any memory space already dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Device implementations with less than 512MB of memory available to the kernel and userspace, unless an Android Watch, MUST return the value "true" for ActivityManager.isLowRamDevice().

Android Television devices MUST have at least 5GB and other device implementations MUST have at least 1.5GB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 5GB for Android Television devices and at least 1.5GB for other device implementations. Device implementations that run Android are very strongly encouraged to have at least 3GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

The Android APIs include a Download Manager that applications MAY use to download data files [ Resources, 95 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default “cache" location.

7.6.2. Penyimpanan Bersama Aplikasi

Device implementations MUST offer shared storage for applications also often referred as “shared external storage”.

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

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital (SD) card slot. If this slot is used to satisfy the shared storage requirement, the device implementation:

• MUST implement a toast or pop-up user interface warning the user when there is no SD card.
• MUST include a FAT-formatted SD card 1GB in size or larger OR show on the box and other material available at time of purchase that the SD card has to be separately purchased.
• MUST mount the SD card by default.

Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps as included in the upstream Android Open Source Project; device implementations SHOULD use this configuration and software implementation. If a device implementation uses internal (non-removable) storage to satisfy the shared storage requirement, while that storage MAY share space with the application private data, it MUST be at least 1GB in size and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere).

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

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST allow only pre-installed and privileged Android applications with the WRITE_EXTERNAL_STORAGE permission to write to the secondary external storage, except when writing to their package-specific directories or within the URI returned by firing the ACTION_OPEN_DOCUMENT_TREE intent.

However, device implementations SHOULD expose content from both storage paths transparently through Android's media scanner service and android.provider.MediaStore.

Regardless of the form of shared storage used, if the device implementation has a USB port with USB peripheral mode support, it MUST provide some mechanism to access the contents of shared storage from a host computer. Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol to satisfy this requirement. If the device implementation supports Media Transfer Protocol, it:

• SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 96 ].
• SHOULD report a USB device class of 0x00.
• SHOULD report a USB interface name of 'MTP'.

7.7. USB

Device implementations SHOULD support USB peripheral mode and SHOULD support USB host mode.

If a device implementation includes a USB port supporting peripheral mode:

• The port MUST be connectable to a USB host that has a standard type-A or type -C USB port.
• The port SHOULD use micro-B, micro-AB or Type-C USB form factor. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
• The port SHOULD either be located on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
• It SHOULD implement the Android Open Accessory (AOA) API and specification as documented in the Android SDK documentation, and if it is an Android Handheld device it MUST implement the AOA API. Device implementations implementing the AOA specification:
  • MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 97 ].
  • MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 98 ].
• It SHOULD implement support to draw 1.5 A current during HS chirp and traffic as specified in the USB Battery Charging Specification, Revision 1.2 [ Resources, 99 ]. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to the future platform releases.
• The value of iSerialNumber in USB standard device descriptor MUST be equal to the value of android.os.Build.SERIAL.

If a device implementation includes a USB port supporting host mode, it:

• SHOULD use a type-C USB port, if the device implementation supports USB 3.1.
• MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to a standard type-A or type-C USB port.
• MAY use a micro-AB USB port, but if so SHOULD ship with a cable or cables adapting the port to a standard type-A or type-C USB port.
• is very strongly RECOMMENDED to implement the USB audio class as documented in the Android SDK documentation [ Resources, 98 ].
• MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 100 ].
• SHOULD support the Charging Downstream Port output current range of 1.5 A ~ 5 A as specified in the USB Battery Charging Specification, Revision 1.2 [ Resources, 99 ].

7.8. Audio

7.8.1. Mikropon

Device implementations MAY omit a microphone. However, if a device implementation omits a microphone, it MUST NOT report the android.hardware.microphone feature constant, and MUST implement the audio recording API at least as no-ops, per section 7 . Conversely, device implementations that do possess a microphone:

• MUST report the android.hardware.microphone feature constant
• MUST meet the audio recording requirements in section 5.4
• MUST meet the audio latency requirements in section 5.6

7.8.2. Keluaran Audio

Device implementations including a speaker or with an audio/multimedia output port for an audio output peripheral as a headset or an external speaker:

• MUST report the android.hardware.audio.output feature constant.
• MUST meet the audio playback requirements in section 5.5 .
• MUST meet the audio latency requirements in section 5.6 .

Conversely, if a device implementation does not include a speaker or audio output port, it MUST NOT report the android.hardware.audio output feature, and MUST implement the Audio Output related APIs as no-ops at least.

Android Watch device implementation MAY but SHOULD NOT have audio output, but other types of Android device implementations MUST have an audio output and declare android.hardware.audio.output.

7.8.2.1. Port Audio Analog

In order to be compatible with the headsets and other audio accessories using the 3.5mm audio plug across the Android ecosystem [ Resources, 101 ], if a device implementation includes one or more analog audio ports, at least one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device implementation has a 4 conductor 3.5mm audio jack, it:

• MUST support audio playback to stereo headphones and stereo headsets with a microphone, and SHOULD support audio recording from stereo headsets with a microphone.
• MUST support TRRS audio plugs with the CTIA pin-out order, and SHOULD support audio plugs with the OMTP pin-out order.
• MUST support the detection of microphone on the plugged in audio accessory, if the device implementation supports a microphone, and broadcast the android.intent.action.HEADSET_PLUG with the extra value microphone set as 1.
• SHOULD support the detection and mapping to the keycodes for the following 3 ranges of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 70 ohm or less : KEYCODE_HEADSETHOOK
  • 210-290 Ohm : KEYCODE_VOLUME_UP
  • 360-680 Ohm : KEYCODE_VOLUME_DOWN
• SHOULD support the detection and mapping to the keycode for the following range of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 110-180 Ohm: KEYCODE_VOICE_ASSIST
• MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all contacts on plug are touching their relevant segments on the jack.
• MUST be capable of driving at least 150mV +/- 10% of output voltage on a 32 Ohm speaker impedance.
• MUST have a microphone bias voltage between 1.8V ~ 2.9V.

8. Performance Compatibility

Some minimum performance criteria are critical to the user experience and impacts the baseline assumptions developers would have when developing an app. Android Watch devices SHOULD and other type of device implementations MUST meet the following criteria:

8.1. Konsistensi Pengalaman Pengguna

Device implementations MUST provide a smooth user interface by ensuring a consistent frame rate and response times for applications and games. Device implementations MUST meet the following requirements:

• Consistent frame latency . Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second.
• User interface latency . Device implementations MUST ensure low latency user experience by scrolling a list of 10K list entries as defined by the Android Compatibility Test Suite (CTS) in less than 36 secs.
• Peralihan tugas . When multiple applications have been launched, re-launching an already-running application after it has been launched MUST take less than 1 second.

8.2. Kinerja Akses I/O File

Device implementations MUST ensure internal storage file access performance consistency for read and write operations.

• Sequential write . Device implementations MUST ensure a sequential write performance of at least 5MB/s for a 256MB file using 10MB write buffer.
• Random write . Device implementations MUST ensure a random write performance of at least 0.5MB/s for a 256MB file using 4KB write buffer.
• Sequential read . Device implementations MUST ensure a sequential read performance of at least 15MB/s for a 256MB file using 10MB write buffer.
• Random read . Device implementations MUST ensure a random read performance of at least 3.5MB/s for a 256MB file using 4KB write buffer.

9. Kompatibilitas Model Keamanan

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

9.1. Izin

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

9.2. UID dan Isolasi Proses

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

9.3. Izin Sistem File

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

9.4. Lingkungan Eksekusi Alternatif

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

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

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

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

Alternate runtimes MUST abide by the Android sandbox model. Specifically, alternate runtimes:

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

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

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

9.5. Dukungan Multi-Pengguna

Android includes support for multiple users and provides support for full user isolation [ Resources, 103] . Device implementations MAY enable multiple users, but when enabled MUST meet the following requirements related to multi-user support [ Resources, 104 ]:

• Device implementations that do not declare the android.hardware.telephony feature flag MUST support restricted profiles, a feature that allows device owners to manage additional users and their capabilities on the device. With restricted profiles, device owners can quickly set up separate environments for additional users to work in, with the ability to manage finer-grained restrictions in the apps that are available in those environments.
• Conversely device implementations that declare the android.hardware.telephony feature flag MUST NOT support restricted profiles but MUST align with the AOSP implementation of controls to enable /disable other users from accessing the voice calls and SMS.
• Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 102 ].
• Device implementations MAY support creating users and managed profiles via the android.app.admin.DevicePolicyManager APIs, and if supported, MUST declare the platform feature flag android.software.managed_users.
• Device implementations that declare the feature flag android.software.managed_users MUST use the upstream AOSP icon badge to represent the managed applications and other badge UI elements like Recents & Notifications.
• Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the primary external storage APIs MUST encrypt the contents of the SD card if multiuser is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 105 ] for primary external storage.

9.6. Peringatan SMS Premium

Android includes support for warning users of any outgoing premium SMS message [ Resources, 106 ] . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement.

9.7. Fitur Keamanan Kernel

The Android Sandbox includes features that can use the Security-Enhanced Linux (SELinux) mandatory access control (MAC) system and other security features in the Linux kernel. SELinux or any other security features, if implemented below the Android framework:

• MUST maintain compatibility with existing applications.
• MUST NOT have a visible user interface when a security violation is detected and successfully blocked, but MAY have a visible user interface when an unblocked security violation occurs resulting in a successful exploit.
• SHOULD NOT be user or developer configurable.

If any API for configuration of policy is exposed to an application that can affect another application (such as a Device Administration API), the API MUST NOT allow configurations that break compatibility.

Devices MUST implement SELinux or an equivalent mandatory access control system if using a kernel other than Linux and meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

Implementasi perangkat:

• MUST support a SELinux policy that allows the SELinux mode to be set on a per-domain basis, and MUST configure all domains in enforcing mode. No permissive mode domains are allowed, including domains specific to a device/vendor.
• SHOULD load policy from /sepolicy file on the device.
• MUST NOT modify, omit, or replace the neverallow rules present within the sepolicy file provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow present, for both AOSP SELinux domains as well as device/vendor specific domains .
• MUST support dynamic updates of the SELinux policy file without requiring a system image update.

Device implementations SHOULD retain the default SELinux policy provided in the upstream Android Open Source Project, until they have first audited their additions to the SELinux policy. Device implementations MUST be compatible with the upstream Android Open Source Project.

9.8. Pribadi

If the device implements functionality in the system that captures the contents displayed on the screen and/or records the audio stream played on the device, it MUST continuously notify the user whenever this functionality is enabled and actively capturing/recording.

If a device implementation has a mechanism that routes network data traffic through a proxy server or VPN gateway by default (for example, preloading a VPN service with android.permission.CONTROL_VPN granted), the device implementation MUST ask for the user's consent before enabling that mekanisme.

9.9. Enkripsi Disk Penuh

If the device implementation supports a lock screen with PIN (numeric) or PASSWORD (alphanumeric), the device MUST support full-disk encryption of the application private data (/data partition), as well as the SD card partition if it is a permanent, non-removable part of the device [ Resources, 107 ]. For devices supporting full-disk encryption, the full-disk encryption SHOULD be enabled all the time after the user has completed the out-of-box experience. While this requirement is stated as SHOULD for this version of the Android platform, it is very strongly RECOMMENDED as we expect this to change to MUST in the future versions of Android. Encryption MUST use AES with a key of 128-bits (or greater) and a mode designed for storage (for example, AES-XTS, AES-CBC-ESSIV). The encryption key MUST NOT be written to storage at any time without being encrypted. Other than when in active use, the encryption key SHOULD be AES encrypted with the lockscreen passcode stretched using a slow stretching algorithm (eg PBKDF2 or scrypt). If the user has not specified a lockscreen passcode or has disabled use of the passcode for encryption, the system SHOULD use a default passcode to wrap the encryption key. If the device provides a hardware-backed keystore, the password stretching algorithm MUST be cryptographically bound to that keystore. The encryption key MUST NOT be sent off the device (even when wrapped with the user passcode and/or hardware bound key). The upstream Android Open Source project provides a preferred implementation of this feature based on the linux kernel feature dm-crypt.

9.10. Boot Terverifikasi

Verified boot is a feature that guarantees the integrity of the device software. If a device implementation supports the feature, it MUST:

• Declare the platform feature flag android.software.verified_boot
• Perform verification on every boot sequence
• Start verification from a hardware key that is the root of trust, and go all the way up to the system partition
• Implement each stage of verification to check the integrity and authenticity of all the bytes in the next stage before executing the code in the next stage
• Use verification algorithms as strong as current recommendations from NIST for hashing algorithms (SHA-256) and public key sizes (RSA-2048)

Device implementations SHOULD support verified boot for device integrity. While this requirement is SHOULD for this version of the Android platform, it is strongly RECOMMENDED as we expect this to change to MUST in future versions of Android. The upstream Android Open Source Project provides a preferred implementation of this feature based on the linux kernel feature dm-verity.

10. Pengujian Kompatibilitas Perangkat Lunak

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1. Rangkaian Uji Kompatibilitas

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

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

10.2. Pemverifikasi CTS

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware that they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verifier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

11. Perangkat Lunak yang Dapat Diperbarui

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

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

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

However, if the device implementation includes support for an unmetered data connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile:

• Android Automotive implementations SHOULD support OTA downloads with offline update via reboot.
• All other device implementations MUST support OTA downloads with offline update via reboot.

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

For device implementations that are launching with Android 5.1 and later, the update mechanism SHOULD support verifying that the system image is binary identical to expected result following an OTA. The block-based OTA implementation in the upstream Android Open Source Project, added since Android 5.1, satisfies this requirement.

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

12. Log Perubahan Dokumen

The following table contains a summary of the changes to the Compatibility Definition in this release.

13. Hubungi Kami

You can join the android-compatibility forum [Resources, 109 ] and ask for clarifications or bring up any issues that you think the document does not cover.

14. Sumber Daya

1. IETF RFC2119 Requirement Levels: http://www.ietf.org/rfc/rfc2119.txt

2. Android Open Source Project: http://source.android.com/

3. Android Television features: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Android Watch feature: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. API definitions and documentation: http://developer.android.com/reference/packages.html

6. Android Permissions reference: http://developer.android.com/reference/android/Manifest.permission.html

7. android.os.Build reference: http://developer.android.com/reference/android/os/Build.html

8. Android 5.1 allowed version strings: http://source.android.com/compatibility/5.1/versions.html

9. Telephony Provider: http://developer.android.com/reference/android/provider/Telephony.html

10. Host-based Card Emulation: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

11. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep

12. android.webkit.WebView class: http://developer.android.com/reference/android/webkit/WebView.html

13. WebView compatibility: http://www.chromium.org/

14. HTML5: http://html.spec.whatwg.org/multipage/

15. HTML5 offline capabilities: http://dev.w3.org/html5/spec/Overview.html#offline

16. HTML5 video tag: http://dev.w3.org/html5/spec/Overview.html#video

17. HTML5/W3C geolocation API: http://www.w3.org/TR/geolocation-API/

18. HTML5/W3C webstorage API: http://www.w3.org/TR/webstorage/

19. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/

20. Dalvik Executable Format and bytecode specification: available in the Android source code, at dalvik/docs

21. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

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

23. Application Resources: https://developer.android.com/guide/topics/resources/available-resources.html

24. Status Bar icon style guide: http://developer.android.com/design/style/iconography.html

25. Notifications Resources: https://developer.android.com/design/patterns/notifications.html

26. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html

27. Toasts: http://developer.android.com/reference/android/widget/Toast.html

28. Themes: http://developer.android.com/guide/topics/ui/themes.html

29. R.style class: http://developer.android.com/reference/android/R.style.html

30. Material design: http://developer.android.com/reference/android/R.style.html#Theme_Material

31. Live Wallpapers: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

32. Overview screen resources: http://developer.android.com/guide/components/recents.html

33. Screen pinning: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

34. Input methods: http://developer.android.com/guide/topics/text/creating-input-method.html

35. Media Notification: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

36. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html

37. Settings.Secure LOCATION_MODE:

http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

38. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

39. Android Device Administration: http://developer.android.com/guide/topics/admin/device-admin.html

40. DevicePolicyManager reference: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

41. Android Device Owner App:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

42. Android Accessibility Service APIs: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

43. Android Accessibility APIs: http://developer.android.com/reference/android/view/accessibility/package-summary.html

44. Eyes Free project: http://code.google.com/p/eyes-free

45. Text-To-Speech APIs: http://developer.android.com/reference/android/speech/tts/package-summary.html

46. Television Input Framework: /devices/tv/index.html

47. Reference tool documentation (for adb, aapt, ddms, systrace): http://developer.android.com/tools/help/index.html

48. Android apk file description: http://developer.android.com/guide/components/fundamentals.html

49. Manifest files: http://developer.android.com/guide/topics/manifest/manifest-intro.html

50. Android Media Formats: http://developer.android.com/guide/appendix/media-formats.html

51. RTC Hardware Coding Requirements: http://www.webmproject.org/hardware/rtc-coding-requirements/

52. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

53. Android android.content.pm.PackageManager class and Hardware Features List:

http://developer.android.com/reference/android/content/pm/PackageManager.html

54. HTTP Live Streaming Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

55. ADB: http://developer.android.com/tools/help/adb.html

56. Dumpsys: /devices/input/diagnostics.html

57. DDMS: http://developer.android.com/tools/debugging/ddms.html

58. Monkey testing tool: http://developer.android.com/tools/help/monkey.html

59. SysyTrace tool: http://developer.android.com/tools/help/systrace.html

60. Android Application Development-Related Settings:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

61. Supporting Multiple Screens: http://developer.android.com/guide/practices/screens_support.html

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

63. RenderScript: http://developer.android.com/guide/topics/renderscript/

64. Android extension pack for OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

65. Hardware Acceleration: http://developer.android.com/guide/topics/graphics/hardware-accel.html

66. EGL Extension-EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

67. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

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

69. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

70. Touch Input Configuration: http://source.android.com/devices/tech/input/touch-devices.html

71. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html

72. Key Event API: http://developer.android.com/reference/android/view/KeyEvent.html

73. Android Open Source sensors: http://source.android.com/devices/sensors

74. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

75. Timestamp sensor event: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

76. Android Open Source composite sensors: /devices/sensors/sensor-types.html#composite_sensor_type_summary

77. Continuous trigger mode: /docs/core/interaction/sensors/report-modes#continuous

78. Accelerometer sensor: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

79. Wi-Fi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

80. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

81. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html

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

83. Bluetooth ScanFilter API: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

84. NDEF Push Protocol: http://source.android.com/compatibility/ndef-push-protocol.pdf

85. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

86. Android NFC Sharing Settings:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

87. NFC Connection Handover: http://members.nfc-forum.org/specs/spec_list/#conn_handover

88. Bluetooth Secure Simple Pairing Using NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

89. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html

90. Camera orientation API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

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

92. Camera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

93. Camera hardware level: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

94. Camera version support: http://source.android.com/devices/camera/versioning.html

95. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html

96. Android File Transfer: http://www.android.com/filetransfer

97. Android Open Accessories: http://developer.android.com/guide/topics/connectivity/usb/accessory.html

98. Android USB Audio: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

99. USB Charging Specification: http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf

100. USB Host API: http://developer.android.com/guide/topics/connectivity/usb/host.html

101. Wired audio headset: http://source.android.com//docs/core/interaction/accessories/headset/plug-headset-spec.html

102. Android Security and Permissions reference: http://developer.android.com/guide/topics/security/permissions.html

103. UserManager reference: http://developer.android.com/reference/android/os/UserManager.html

104. External Storage reference: http://source.android.com/docs/core/storage

105. External Storage APIs: http://developer.android.com/reference/android/os/Environment.html

106. SMS Short Code: http://en.wikipedia.org/wiki/Short_code

107. Android Open Source Encryption: http://source.android.com/docs/security/features/encryption

108. Android Compatibility Program Overview: http://source.android.com//docs/compatibility

109. Android Compatibility forum: https://groups.google.com/forum/#!forum/android-compatibility

110. WebM project: http://www.webmproject.org/

111. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

112. Android MediaCodecList API: http://developer.android.com/reference/android/media/MediaCodecList.html

113. Android CamcorderProfile API: http://developer.android.com/reference/android/media/CamcorderProfile.html

Many of these resources are derived directly or indirectly from the Android SDK, and will be functionally identical to the information in that SDK's documentation. In any cases where this Compatibility Definition or the Compatibility Test Suite disagrees with the SDK documentation, the SDK documentation is considered authoritative. Any technical details provided in the references included above are considered by inclusion to be part of this Compatibility Definition.