Perubahan perilaku: semua aplikasi

Android 9 (API level 28) memperkenalkan banyak perubahan pada sistem Android. Perubahan perilaku berikut berlaku untuk semua aplikasi saat dijalankan di platform Android 9, terlepas dari API level yang ditargetkan. Semua developer harus meninjau perubahan ini dan memodifikasi aplikasi mereka untuk mendukung perubahan dengan benar, jika memungkinkan untuk aplikasi.

Untuk perubahan yang hanya memengaruhi aplikasi yang menargetkan API level 28 atau yang lebih tinggi, lihat Perubahan perilaku: aplikasi yang menargetkan API Level 28+.

Pengelolaan daya

Android 9 memperkenalkan fitur baru untuk meningkatkan pengelolaan daya perangkat. Perubahan ini, beserta fitur yang sudah ada sebelum Android 9, membantu memastikan bahwa resource sistem tersedia untuk aplikasi yang paling membutuhkannya.

Untuk mengetahui detailnya, lihat Pengelolaan daya.

Perubahan privasi

Untuk meningkatkan privasi pengguna, Android 9 memperkenalkan beberapa perubahan perilaku, seperti membatasi akses aplikasi latar belakang ke sensor perangkat, membatasi informasi yang diambil dari pemindaian Wi-Fi, serta aturan izin dan grup izin baru yang terkait dengan panggilan telepon, status ponsel, dan pemindaian Wi-Fi.

Perubahan ini memengaruhi semua aplikasi yang berjalan di Android 9, terlepas dari versi SDK target.

Akses terbatas ke sensor di latar belakang

Android 9 membatasi kemampuan aplikasi latar belakang untuk mengakses input pengguna dan data sensor. Jika aplikasi Anda berjalan di latar belakang pada perangkat yang menjalankan Android 9, sistem akan menerapkan pembatasan berikut pada aplikasi Anda:

  • Aplikasi Anda tidak dapat mengakses mikrofon atau kamera.
  • Sensor yang menggunakan mode pelaporan berkelanjutan, seperti akselerometer dan giroskop, tidak menerima peristiwa.
  • Sensor yang menggunakan mode pelaporan on-change atau one-shot tidak menerima peristiwa.

Jika aplikasi Anda perlu mendeteksi peristiwa sensor pada perangkat yang menjalankan Android 9, gunakan layanan latar depan.

Akses terbatas ke log panggilan

Android 9 memperkenalkan grup izin CALL_LOG dan memindahkan izin READ_CALL_LOG, WRITE_CALL_LOG, dan PROCESS_OUTGOING_CALLS ke dalam grup ini. Di versi Android sebelumnya, izin ini berada di grup izin PHONE.

Grup izin CALL_LOG ini memberi pengguna kontrol dan visibilitas yang lebih baik terhadap aplikasi yang memerlukan akses ke informasi sensitif tentang panggilan telepon, seperti membaca rekaman panggilan telepon dan mengidentifikasi nomor telepon.

Jika aplikasi memerlukan akses ke log panggilan atau perlu memproses panggilan keluar, Anda harus secara eksplisit meminta izin ini dari grup izin CALL_LOG. Jika tidak, SecurityException akan terjadi.

Catatan: Karena izin ini telah mengubah grup dan diberikan saat runtime, pengguna dapat menolak akses aplikasi Anda ke informasi log panggilan telepon. Dalam hal ini, aplikasi Anda harus dapat menangani kurangnya akses ke informasi dengan baik.

Jika sudah mengikuti praktik terbaik izin runtime, aplikasi Anda dapat menangani perubahan dalam grup izin.

Akses terbatas ke nomor telepon

Aplikasi yang berjalan di Android 9 tidak dapat membaca nomor telepon atau status ponsel tanpa terlebih dahulu mendapatkan izin READ_CALL_LOG, selain izin lain yang diperlukan kasus penggunaan aplikasi Anda.

Nomor telepon yang terkait dengan panggilan masuk dan keluar terlihat dalam siaran status ponsel, seperti untuk panggilan masuk dan keluar serta dapat diakses dari class PhoneStateListener. Namun, tanpa izin READ_CALL_LOG, kolom nomor telepon yang disediakan dalam siaran PHONE_STATE_CHANGED dan melalui PhoneStateListener akan kosong.

Untuk membaca nomor telepon dari status ponsel, update aplikasi untuk meminta izin yang diperlukan berdasarkan kasus penggunaan Anda:

Akses terbatas ke lokasi Wi-Fi dan informasi koneksi

Di Android 9, persyaratan izin bagi aplikasi untuk melakukan pemindaian Wi-Fi lebih ketat daripada versi sebelumnya. Untuk mengetahui detailnya, lihat Pembatasan pemindaian Wi-Fi.

Batasan serupa juga berlaku untuk metode getConnectionInfo(), yang menampilkan objek WifiInfo yang menjelaskan koneksi Wi-Fi saat ini. Anda hanya dapat menggunakan metode objek ini untuk mengambil nilai SSID dan BSSID jika aplikasi pemanggil memiliki izin berikut:

  • ACCESS_FINE_LOCATION atau ACCESS_COARSE_LOCATION
  • AKSES_WI-FI_STATE

Pengambilan SSID atau BSSID juga mengharuskan layanan lokasi diaktifkan pada perangkat (di bagian Setelan > Lokasi).

Informasi yang dihapus dari metode layanan Wi-Fi

Di Android 9, peristiwa dan siaran berikut tidak menerima informasi tentang lokasi pengguna atau data identitas pribadi:

Siaran sistem NETWORK_STATE_CHANGED_ACTION dari Wi-Fi tidak lagi berisi SSID (sebelumnya EXTRA_SSID), BSSID (sebelumnya EXTRA_BSSID), atau informasi koneksi (sebelumnya EXTRA_NETWORK_INFO). Jika aplikasi Anda memerlukan informasi ini, panggil getConnectionInfo().

Informasi telepon kini bergantung pada setelan lokasi perangkat

Jika pengguna telah menonaktifkan lokasi perangkat pada perangkat yang menjalankan Android 9, metode berikut tidak akan memberikan hasil:

Batasan penggunaan antarmuka non-SDK

Untuk membantu memastikan stabilitas dan kompatibilitas aplikasi, platform ini membatasi penggunaan beberapa metode dan kolom non-SDK; batasan ini berlaku baik saat Anda mencoba mengakses metode dan kolom ini secara langsung, melalui refleksi, atau menggunakan JNI. Di Android 9, aplikasi Anda dapat terus mengakses antarmuka yang dibatasi ini; platform ini menggunakan toast dan entri log untuk menarik perhatian Anda. Jika aplikasi Anda menampilkan toast seperti itu, Anda harus menjalankan strategi implementasi selain antarmuka yang dibatasi. Jika merasa bahwa tidak ada strategi alternatif yang bisa dilakukan, Anda dapat melaporkan bug untuk meminta pertimbangan ulang atas pembatasan tersebut.

Pembatasan Antarmuka Non-SDK berisi informasi penting lainnya. Anda harus meninjaunya untuk memastikan aplikasi Anda terus berfungsi dengan baik.

Perubahan perilaku keamanan

Perubahan keamanan perangkat

Android 9 menambahkan beberapa kemampuan yang meningkatkan keamanan aplikasi, apa pun versi yang ditargetkan aplikasi Anda.

Perubahan penerapan TLS

Implementasi TLS sistem telah mengalami beberapa perubahan di Android 9:

Untuk mempelajari lebih lanjut cara membuat permintaan web yang aman di aplikasi Android, lihat Contoh HTTPS.

Filter SECCOMP yang lebih ketat

Android 9 membatasi lebih jauh panggilan sistem yang tersedia untuk aplikasi. Perilaku ini merupakan ekstensi dari filter SECCOMP yang disertakan dalam Android 8.0 (API level 26).

Perubahan kriptografi

Android 9 memperkenalkan beberapa perubahan pada implementasi dan penanganan algoritma kriptografi.

Mengenkripsi implementasi parameter dan algoritma

Android 9 menyediakan implementasi tambahan parameter algoritme di Conscrypt. Parameter ini mencakup: AES, DESEDE, OAEP, dan EC. Versi Bouncy Castle parameter ini dan banyak algoritma tidak digunakan lagi mulai Android 9.

Jika aplikasi menargetkan Android 8.1 (API level 27) atau yang lebih rendah, Anda akan menerima peringatan saat meminta implementasi Bouncy Castle dari salah satu algoritma yang tidak digunakan lagi ini. Namun, jika Anda menargetkan Android 9, setiap permintaan ini akan menampilkan NoSuchAlgorithmException.

Perubahan lainnya

Android 9 memperkenalkan beberapa perubahan lain yang terkait dengan kriptografi:

  • Saat menggunakan kunci PBE, jika Bouncy Castle mengharapkan vektor inisialisasi (IV) dan aplikasi Anda tidak menyediakannya, Anda akan menerima peringatan.
  • Implementasi Conscrypt cipher ARC4 memungkinkan Anda menentukan ARC4/ECB/NoPadding atau ARC4/NONE/NoPadding.
  • Penyedia Java Cryptography Architecture (JCA) Kripto telah dihapus. Akibatnya, jika aplikasi Anda memanggil SecureRandom.getInstance("SHA1PRNG", "Crypto"), NoSuchProviderException akan terjadi.
  • Jika aplikasi Anda mengurai kunci RSA dari buffer yang lebih besar dari struktur kunci, pengecualian tidak akan terjadi lagi.

Untuk mempelajari lebih lanjut cara menggunakan kemampuan kriptografi Android, lihat Kriptografi.

File terenkripsi aman Android tidak lagi didukung

Android 9 menghapus dukungan sepenuhnya untuk file terenkripsi aman Android (ASEC).

Di Android 2.2 (API level 8), Android memperkenalkan ASEC untuk mendukung fungsi aplikasi di kartu SD. Di Android 6.0 (API level 23), platform ini memperkenalkan teknologi perangkat penyimpanan yang dapat diadopsi yang dapat digunakan developer sebagai pengganti ASEC.

Update pada library ICU

Android 9 menggunakan versi 60 library ICU. Android 8.0 (level API 26) dan Android 8.1 (level API 27) menggunakan ICU 58.

ICU digunakan untuk menyediakan API publik di bawah android.icu package dan digunakan secara internal di platform Android untuk dukungan internasionalisasi. Misalnya, class ini digunakan untuk mengimplementasikan class Android di java.util, java.text, dan android.text.format.

Update untuk ICU 60 berisi banyak perubahan kecil tetapi berguna, termasuk dukungan data Emoji 5.0 dan format tanggal/waktu yang ditingkatkan, seperti yang didokumentasikan dalam catatan rilis ICU 59 dan ICU 60.

Perubahan penting dalam update ini:

  • Cara platform menangani zona waktu telah berubah.
    • Platform menangani GMT dan UTC dengan lebih baik; UTC tidak lagi sama dengan GMT.

      ICU sekarang memberikan nama zona yang diterjemahkan untuk GMT dan UTC. Perubahan ini memengaruhi perilaku pemformatan dan penguraian android.icu untuk zona seperti "GMT", "Etc/GMT", "UTC", "Etc/UTC", dan "Zulu".

    • java.text.SimpleDateFormat sekarang menggunakan ICU guna memberikan nama tampilan untuk UTC /GMT, yang berarti:
      • Memformat zzzz menghasilkan string panjang yang dilokalkan untuk banyak lokalitas. Sebelumnya, metode ini menghasilkan "UTC" untuk UTC dan string seperti "GMT+00:00" untuk GMT.
      • Mengurai zzzz akan mengenali string seperti "Waktu Universal Terkoordinasi", dan "Waktu Greenwich".
      • Aplikasi mungkin mengalami masalah kompatibilitas jika berasumsi bahwa "UTC" atau "GMT+00:00" adalah output untuk zzzz dalam semua bahasa.
    • Perilaku java.text.DateFormatSymbols.getZoneStrings() telah berubah:
      • Seperti halnya SimpleDateFormat, UTC dan GMT kini memiliki nama yang panjang. Varian nama zona waktu DST untuk zona UTC, seperti "UTC", "Etc/UTC", dan "Zulu", menjadi GMT+00:00, yang merupakan penggantian standar saat tidak ada nama yang tersedia, selain string UTC yang di-hard code.
      • Beberapa ID zona dikenali dengan benar sebagai sinonim untuk zona lain, sehingga Android akan menemukan string untuk ID zona kuno, seperti Eire, yang sebelumnya tidak dapat di-resolve.
    • Asia/Hanoi bukan lagi zona yang diakui. Karena alasan ini, java.util.TimeZones.getAvailableIds() tidak menampilkan nilai ini, dan java.util.TimeZone.getTimeZone() tidak mengenalinya. Perilaku ini konsisten dengan perilaku android.icu yang sudah ada.
  • Metode android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) dapat menampilkan ParseException bahkan saat mengurai teks mata uang yang sah. Hindari masalah ini dengan menggunakan NumberFormat.parseCurrency, tersedia sejak Android 7.0 (level API 24), untuk teks mata uang gaya PLURALCURRENCYSTYLE.

Perubahan Android Test

Android 9 memperkenalkan beberapa perubahan pada struktur class dan library framework Android Test. Perubahan ini membantu developer menggunakan API publik yang didukung framework, tetapi perubahan ini juga memungkinkan lebih banyak fleksibilitas dalam mem-build dan menjalankan pengujian menggunakan library pihak ketiga atau logika kustom.

Library dihapus dari framework

Android 9 menyusun ulang class berbasis JUnit menjadi tiga library: android.test.base, android.test.runner, dan android.test.mock. Perubahan ini memungkinkan Anda menjalankan pengujian terhadap versi JUnit yang paling sesuai dengan dependensi project Anda. Versi JUnit ini mungkin berbeda dari yang disediakan android.jar.

Untuk mempelajari lebih lanjut cara class berbasis JUnit diatur ke dalam library ini, serta cara menyiapkan project aplikasi untuk menulis dan menjalankan pengujian, lihat Menyiapkan project untuk Pengujian Android.

Perubahan build test suite

Metode addRequirements() di class TestSuiteBuilder telah dihapus, dan class TestSuiteBuilder itu sendiri sudah tidak digunakan lagi. Metode addRequirements() mengharuskan developer menyediakan argumen yang berjenis API tersembunyi, sehingga API menjadi tidak valid.

Decoder UTF Java

UTF-8 adalah charset default dalam Android. Urutan byte UTF-8 dapat didekode oleh konstruktor String, seperti String(byte[] bytes).

Decoder UTF-8 di Android 9 mengikuti standar Unicode secara lebih ketat daripada versi sebelumnya. Perubahan tersebut meliputi:

  • Format tidak terpendek UTF-8, seperti <C0, AF>, dianggap tidak baik.
  • Bentuk pengganti UTF-8, seperti U+D800..U+DFFF, dianggap tidak baik.
  • Subbagian maksimal diganti dengan satu U+FFFD. Misalnya, dalam urutan byte "41 C0 AF 41 F4 80 80 41", subbagian maksimalnya adalah "C0", "AF", dan "F4 80 80". "F4 80 80" dapat menjadi suburutan awal "F4 80 80 80", tetapi "C0" tidak dapat menjadi suburutan awal dari urutan unit kode yang terbentuk dengan baik. Dengan demikian, output-nya harus "A\ufffd\ufffdA\ufffdA".
  • Untuk mendekode urutan UTF-8 / CESU-8 yang dimodifikasi dalam Android 9 atau yang lebih baru, gunakan metode DataInputStream.readUTF() atau metode JNI NewStringUTF().

Verifikasi nama host menggunakan sertifikat

RFC 2818 menjelaskan dua metode untuk mencocokkan nama domain dengan sertifikat—menggunakan nama yang tersedia dalam ekstensi subjectAltName (SAN), atau jika tidak ada ekstensi SAN, kembali ke commonName (CN).

Namun, penggantian ke CN tidak digunakan lagi dalam RFC 2818. Karena alasan ini, Android tidak lagi beralih kembali menggunakan CN. Untuk memverifikasi nama host, server harus memberikan sertifikat dengan SAN yang cocok. Sertifikat yang tidak berisi SAN yang cocok dengan nama host tidak lagi dipercaya.

Pencarian alamat jaringan dapat menyebabkan pelanggaran jaringan

Pencarian alamat jaringan yang memerlukan resolusi nama dapat melibatkan I/O jaringan, sehingga dianggap sebagai operasi pemblokiran. Operasi pemblokiran pada thread utama dapat menyebabkan jeda atau jank.

Class StrictMode adalah alat pengembangan yang membantu developer mendeteksi masalah dalam kode mereka.

Di Android 9 dan yang lebih tinggi, StrictMode mendeteksi pelanggaran jaringan yang disebabkan oleh pencarian alamat jaringan yang memerlukan resolusi nama.

Anda tidak boleh mengirimkan aplikasi dengan StrictMode diaktifkan. Jika Anda melakukannya, aplikasi Anda dapat mengalami pengecualian, seperti NetworkOnMainThreadException saat menggunakan metode detectNetwork() atau detectAll() untuk mendapatkan kebijakan yang mendeteksi pelanggaran jaringan.

Menyelesaikan alamat IP numerik tidak dianggap sebagai operasi pemblokiran. Resolusi alamat IP numerik berfungsi sama seperti versi sebelum Android 9.

Pemberian tag soket

Pada versi platform yang lebih rendah dari Android 9, jika soket diberi tag menggunakan metode setThreadStatsTag(), soket akan dihapus tagnya saat dikirim ke proses lain menggunakan binder IPC dengan penampung ParcelFileDescriptor.

Di Android 9 dan yang lebih tinggi, tag soket disimpan saat dikirim ke proses lain menggunakan binder IPC. Perubahan ini dapat memengaruhi statistik traffic jaringan, misalnya, saat menggunakan metode queryDetailsForUidTag().

Jika ingin mempertahankan perilaku versi sebelumnya, yang menghapus tag pada soket yang dikirim ke proses lain, Anda dapat memanggil untagSocket() sebelum mengirim soket.

Jumlah byte yang tersedia dalam soket yang dilaporkan

Metode available() menampilkan 0 saat dipanggil setelah memanggil metode shutdownInput().

Pelaporan kemampuan jaringan yang lebih mendetail untuk VPN

Di Android 8.1 (API level 27) dan yang lebih rendah, class NetworkCapabilities hanya melaporkan sekumpulan informasi terbatas untuk VPN, seperti TRANSPORT_VPN, tetapi menghilangkan NET_CAPABILITY_NOT_VPN. Informasi terbatas ini menyulitkan untuk menentukan apakah penggunaan VPN akan menimbulkan biaya bagi pengguna aplikasi. Misalnya, memeriksa NET_CAPABILITY_NOT_METERED tidak akan menentukan apakah jaringan dasarnya berbayar atau tidak.

Di Android 9 dan yang lebih tinggi, saat VPN memanggil metode setUnderlyingNetworks(), sistem Android menggabungkan transpor dan kemampuan jaringan dasar dan menampilkan hasilnya sebagai kemampuan jaringan yang efektif dari jaringan VPN.

Di Android 9 dan yang lebih tinggi, aplikasi yang sudah memeriksa NET_CAPABILITY_NOT_METERED akan menerima kemampuan jaringan VPN dan jaringan dasar.

File dalam folder xt_qtaguid tidak lagi tersedia untuk aplikasi

Mulai Android 9, aplikasi tidak diizinkan memiliki akses baca langsung ke file dalam folder /proc/net/xt_qtaguid. Alasannya adalah untuk memastikan konsistensi dengan beberapa perangkat yang tidak memiliki file ini sama sekali.

API publik yang mengandalkan file ini, TrafficStats dan NetworkStatsManager, akan terus berfungsi sebagaimana mestinya. Namun, fungsi cutils yang tidak didukung, seperti qtaguid_tagSocket(), mungkin tidak berfungsi seperti yang diharapkan—atau tidak berfungsi sama sekali— di perangkat yang berbeda.

Persyaratan FLAG_ACTIVITY_NEW_TASK sekarang diterapkan

Dengan Android 9, Anda tidak dapat memulai aktivitas dari konteks non-aktivitas kecuali jika Anda meneruskan tanda intent FLAG_ACTIVITY_NEW_TASK. Jika Anda mencoba memulai aktivitas tanpa meneruskan flag ini, aktivitas tidak akan dimulai, dan sistem mencetak pesan ke log.

Perubahan rotasi layar

Mulai Android 9, ada perubahan signifikan pada mode rotasi potret. Di Android 8.0 (level API 26), pengguna dapat beralih antara mode rotasi putar otomatis dan potret menggunakan kartu Quicksettings atau setelan Display. Mode potret telah diganti namanya menjadi kunci rotasi dan aktif saat putar otomatis dinonaktifkan. Tidak ada perubahan pada mode putar otomatis.

Saat perangkat dalam mode kunci rotasi, pengguna dapat mengunci layar ke rotasi apa pun yang didukung oleh Aktivitas teratas yang terlihat. Activity tidak boleh berasumsi bahwa aktivitas akan selalu dirender dalam mode potret. Jika Aktivitas teratas dapat dirender dalam beberapa rotasi dalam mode putar otomatis, opsi yang sama harus tersedia dalam mode terkunci rotasi, dengan beberapa pengecualian berdasarkan setelan screenOrientation Aktivitas (lihat tabel di bawah).

Aktivitas yang meminta orientasi tertentu (misalnya, screenOrientation=landscape) mengabaikan preferensi kunci pengguna dan berperilaku dengan cara yang sama seperti di Android 8.0.

Preferensi orientasi layar dapat ditetapkan di tingkat Aktivitas dalam Manifes Android, atau secara terprogram dengan setRequestOrientation().

Mode kunci rotasi berfungsi dengan menetapkan preferensi rotasi pengguna yang digunakan WindowManager saat menangani rotasi Aktivitas. Preferensi rotasi pengguna dapat diubah dalam kasus berikut. Perhatikan bahwa ada bias untuk kembali ke rotasi alami perangkat, yang biasanya potret untuk perangkat faktor bentuk ponsel:

  • Saat pengguna menerima saran rotasi, preferensi rotasi akan berubah menjadi saran tersebut.
  • Saat pengguna beralih ke aplikasi potret paksa (termasuk layar kunci atau peluncur), preferensi rotasi akan berubah menjadi potret.

Tabel berikut merangkum perilaku rotasi untuk orientasi layar umum:

Orientasi Layar Perilaku
tidak ditentukan, pengguna Dalam fitur putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam mode potret atau lanskap (dan sebaliknya). Mendukung layout potret dan lanskap.
penggunaLanskap Dalam fitur putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam mode lanskap atau lanskap terbalik. Mendukung hanya layout lanskap.
Potret pengguna Dalam fitur putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam mode potret atau potret terbalik. Mendukung hanya layout potret.
penggunapenuh Dalam fitur putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam mode potret atau lanskap (dan sebaliknya). Mendukung tata letak potret dan lanskap.

Pengguna kunci rotasi akan diberi opsi untuk mengunci ke potret terbalik, sering kali 180o.
sensor, fullSensor, sensorPortrait, sensorLandscape Preferensi mode kunci rotasi diabaikan dan diperlakukan seolah-olah putar otomatis aktif. Hanya gunakan ini dalam keadaan tidak biasa dengan pertimbangan UX yang sangat hati-hati.

Penghentian klien HTTP Apache memengaruhi aplikasi dengan ClassLoader non-standar

Dengan Android 6.0, kami menghapus dukungan untuk klien HTTP Apache. Perubahan ini tidak berpengaruh pada sebagian besar aplikasi yang tidak menargetkan Android 9 atau yang lebih tinggi. Namun, perubahan tersebut dapat memengaruhi aplikasi tertentu yang menggunakan struktur ClassLoader non-standar, meskipun aplikasi tidak menargetkan Android 9 atau yang lebih tinggi.

Aplikasi dapat terpengaruh jika menggunakan ClassLoader non-standar yang secara eksplisit mendelegasikan ke ClassLoader sistem. Aplikasi ini harus mendelegasikan ke aplikasi ClassLoader saat mencari class di org.apache.http.*. Jika mendelegasikan ke ClassLoader sistem, aplikasi akan gagal di Android 9 atau yang lebih tinggi dengan NoClassDefFoundError, karena class tersebut tidak lagi diketahui oleh ClassLoader sistem. Untuk mencegah masalah serupa di masa mendatang, aplikasi secara umum harus memuat class melalui ClassLoader aplikasi, bukan mengakses ClassLoader sistem secara langsung.

Menghitung kamera

Aplikasi yang berjalan di perangkat Android 9 dapat menemukan setiap kamera yang tersedia dengan memanggil getCameraIdList(). Aplikasi tidak boleh berasumsi bahwa perangkat hanya memiliki satu kamera belakang atau hanya satu kamera depan.

Misalnya, jika aplikasi Anda memiliki tombol untuk beralih antara kamera depan dan belakang, mungkin ada lebih dari satu kamera depan atau belakang yang dapat dipilih. Anda harus mempelajari daftar kamera, memeriksa karakteristik setiap kamera, dan memutuskan kamera mana yang akan diperlihatkan kepada pengguna.