Perubahan perilaku: semua aplikasi

Android 9 (API level 28) memperkenalkan banyak perubahan pada sistem Android. Perubahan perilaku berikut berlaku untuk semua aplikasi ketika dijalankan pada platform Android 9, terlepas dari API level yang ditargetkannya. Semua developer harus meninjau perubahan ini dan memodifikasi aplikasi mereka untuk mendukungnya dengan benar, jika memungkinkan pada 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-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 untuk 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 ke aplikasi yang memerlukan akses ke informasi sensitif tentang panggilan telepon, seperti membaca rekaman panggilan telepon dan mengidentifikasi nomor telepon.

Jika aplikasi Anda 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 di 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 oleh kasus penggunaan aplikasi Anda.

Nomor telepon yang terkait dengan panggilan masuk dan keluar terlihat di 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 informasi lokasi dan koneksi Wi-Fi

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.

Pembatasan 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 panggilan memiliki izin berikut:

  • ACCESS_FINE_LOCATION atau ACCESS_COARSE_LOCATION
  • AKSES_NEGARA_WI-FI

Pengambilan SSID atau BSSID juga mengharuskan layanan lokasi diaktifkan di perangkat (dalam 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. Pembatasan ini berlaku baik jika 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, sebaiknya Anda mengejar strategi implementasi selain antarmuka yang dibatasi. Jika merasa bahwa tidak ada strategi alternatif yang dapat dilakukan, Anda dapat mengajukan bug untuk meminta pertimbangan ulang pembatasan tersebut.

Pembatasan pada Antarmuka Non-SDK berisi informasi penting lainnya. Anda harus meninjaunya untuk memastikan bahwa 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 penerapan dan penanganan algoritme kriptografi.

Implementasi Conscrypt parameter dan algoritma

Android 9 menyediakan implementasi tambahan parameter algoritma 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, masing-masing 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 Crypto Java Cryptography Architecture (JCA) telah dihapus. Akibatnya, jika aplikasi Anda memanggil SecureRandom.getInstance("SHA1PRNG", "Crypto"), NoSuchProviderException akan terjadi.
  • Jika aplikasi Anda mengurai kunci RSA dari buffering yang lebih besar dari struktur kunci, pengecualian tidak lagi terjadi.

Untuk mempelajari lebih lanjut tentang penggunaan kemampuan kriptografi Android, lihat Kriptografi.

File terenkripsi aman Android tidak lagi didukung

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

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 (API level 26) dan Android 8.1 (API level 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, contoh 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 ini 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 pemformatan dan penguraian android.icu perilaku untuk zona seperti "GMT", "Etc/GMT", "UTC", "Etc/UTC", dan "Zulu".

    • java.text.SimpleDateFormat kini menggunakan ICU guna memberikan nama tampilan untuk UTC /GMT, yang berarti:
      • Pemformatan zzzz akan menghasilkan string panjang yang dilokalkan untuk banyak lokalitas. Sebelumnya, alat ini menghasilkan "UTC" untuk UTC dan string seperti "GMT+00:00" untuk GMT.
      • Mengurai zzzz mengenali string seperti "Universal Coordinated Time", dan "Greenwich Mean Time".
      • Aplikasi mungkin mengalami masalah kompatibilitas jika menganggap "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 panjang. Varian nama zona waktu DST untuk zona UTC, seperti "UTC", "Etc/UTC", dan "Zulu", menjadi GMT+00:00, yang merupakan penggantian standar jika tidak ada nama yang tersedia, bukan 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 diselesaikan.
    • 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 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 menggunakan NumberFormat.parseCurrency, yang tersedia sejak Android 7.0 (API level 24), untuk teks mata uang bergaya 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 fleksibilitas yang lebih besar 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 untuk menyediakan argumen yang berjenis API tersembunyi, sehingga API tersebut 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 dengan lebih ketat daripada versi sebelumnya. Perubahan tersebut meliputi:

  • Format tidak terpendek UTF-8, seperti <C0, AF>, dianggap tidak baik.
  • Format pengganti UTF-8, seperti U+D800..U+DFFF, dianggap tidak baik.
  • Subbagian maksimal diganti dengan satu U+FFFD. Misalnya, pada 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 dari "F4 80 80 80", tetapi "C0" tidak boleh menjadi suburutan awal dari urutan unit kode yang tersusun dengan baik. Dengan demikian, output-nya seharusnya "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 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 dan oleh karena itu 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 yang 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 lama 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 soket yang dikirim ke proses lain, Anda dapat memanggil untagSocket() sebelum mengirim soket.

Jumlah byte tersedia yang dilaporkan dalam soket

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 kepada pengguna aplikasi. Misalnya, memeriksa NET_CAPABILITY_NOT_METERED tidak akan menentukan apakah jaringan yang mendasarinya berbayar atau tidak.

Di Android 9 dan yang lebih tinggi, saat VPN memanggil metode setUnderlyingNetworks(), sistem Android akan 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 di folder xt_qtaguid tidak lagi tersedia untuk aplikasi

Mulai Android 9, aplikasi tidak diizinkan untuk memiliki akses baca langsung ke file di folder /proc/net/xt_qtaguid. Alasannya adalah untuk memastikan konsistensi pada 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— pada 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 flag intent FLAG_ACTIVITY_NEW_TASK. Jika Anda mencoba memulai aktivitas tanpa meneruskan flag ini, aktivitas tidak akan dimulai, dan sistem akan mencetak pesan ke log.

Perubahan rotasi layar

Mulai Android 9, ada perubahan signifikan pada mode rotasi potret. Di Android 8.0 (API level 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 berada dalam mode kunci rotasi, pengguna dapat mengunci layar ke rotasi apa pun yang didukung oleh Activity teratas yang terlihat. Activity tidak boleh berasumsi bahwa itu akan selalu dirender dalam mode potret. Jika Aktivitas teratas dapat dirender dalam beberapa rotasi dalam mode putar otomatis, opsi yang sama akan 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 disetel di tingkat Aktivitas dalam Manifes Android, atau secara terprogram dengan setRequestOrientation().

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

  • Saat pengguna menerima saran rotasi, preferensi rotasi akan berubah menjadi saran.
  • 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
pengguna, tidak ditentukan Dalam putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam mode potret atau lanskap (dan sebaliknya). Mendukung layout potret dan lanskap.
userLanskap Dalam putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam mode lanskap atau lanskap terbalik. Mendukung hanya layout lanskap.
userPortrait Dalam putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam mode potret atau potret terbalik. Mendukung hanya layout potret.
penggunalengkap Dalam 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 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 ini 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 perlu mendelegasikan ke app ClassLoader saat mencari class di org.apache.http.*. Jika didelegasikan ke ClassLoader sistem, aplikasi akan gagal di Android 9 atau yang lebih baru 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 mengetahui daftar kamera, memeriksa karakteristik setiap kamera, dan memutuskan kamera mana yang akan ditampilkan kepada pengguna.