Halaman ini diterjemahkan oleh Cloud Translation API.

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 level API yang ditargetkannya. Semua developer harus meninjau perubahan ini dan memodifikasi aplikasi mereka untuk mendukungnya dengan benar, jika berlaku 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, bersama dengan 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 batasan berikut ke 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 sesuai perubahan atau sekaligus tidak menerima peristiwa.

Jika aplikasi Anda perlu mendeteksi peristiwa sensor di 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 Android versi 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 catatan 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 dalam grup izin.

Akses terbatas ke nomor telepon

Aplikasi yang berjalan di Android 9 tidak dapat membaca nomor telepon atau status ponsel tanpa mendapatkan izin READ_CALL_LOG terlebih dahulu, selain izin lain yang diperlukan 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 diberikan dalam siaran PHONE_STATE_CHANGED dan melalui PhoneStateListener akan kosong.

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

Untuk membaca angka dari tindakan intent PHONE_STATE, Anda memerlukan izin READ_CALL_LOG dan izin READ_PHONE_STATE.
Untuk membaca angka dari onCallStateChanged(), Anda hanya memerlukan izin READ_CALL_LOG. Anda tidak memerlukan izin READ_PHONE_STATE.

Akses terbatas ke informasi koneksi dan lokasi Wi-Fi

Di Android 9, persyaratan izin untuk aplikasi agar dapat melakukan pemindaian Wi-Fi lebih ketat daripada di versi sebelumnya. Untuk mengetahui detailnya, lihat Batasan 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 panggilan memiliki izin berikut:

ACCESS_FINE_LOCATION atau ACCESS_COARSE_LOCATION
ACCESS_WIFI_STATE

Pengambilan SSID atau BSSID juga memerlukan layanan lokasi yang diaktifkan di 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:

Metode getScanResults() dan getConnectionInfo() dari WifiManager.
Metode discoverServices() dan addServiceRequest() dari WifiP2pManager.
Siaran NETWORK_STATE_CHANGED_ACTION.

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 di perangkat yang menjalankan Android 9, metode berikut tidak akan memberikan hasil:

Pembatasan penggunaan antarmuka non-SDK

Untuk membantu memastikan stabilitas dan kompatibilitas aplikasi, platform 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 terbatas ini; platform menggunakan toast dan entri log untuk menarik perhatian Anda. Jika aplikasi Anda menampilkan toast tersebut, Anda harus mengejar strategi penerapan selain antarmuka yang dibatasi. Jika merasa bahwa tidak ada strategi alternatif yang memungkinkan, Anda dapat melaporkan bug untuk meminta pertimbangan ulang atas pembatasan tersebut.

Pembatasan pada Antarmuka Non-SDK berisi informasi penting lebih lanjut. 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 Anda, terlepas dari versi yang ditargetkan aplikasi Anda.

Perubahan penerapan TLS

Implementasi TLS sistem telah mengalami beberapa perubahan di Android 9:

Jika instance SSLSocket gagal terhubung saat sedang dibuat, sistem akan menampilkan IOException, bukan NullPointerException.
Class SSLEngine menangani pemberitahuan close_notify yang terjadi dengan rapi.

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 adalah ekstensi dari filter SECCOMP yang disertakan Android 8.0 (API level 26).

Perubahan kriptografi

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

Implementasi parameter dan algoritma Conscrypt

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 Anda menargetkan Android 8.1 (API level 27) atau yang lebih rendah, Anda akan menerima peringatan saat meminta penerapan Bouncy Castle untuk 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 dari 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 buffering 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 sepenuhnya menghapus dukungan 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 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, class ini digunakan untuk mengimplementasikan class Android di java.util, java.text, dan android.text.format.

Update ke 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 menjadi sinonim untuk 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 kini menggunakan ICU untuk memberikan nama tampilan untuk UTC /GMT, yang berarti:
  - Pemformatan zzzz menghasilkan string panjang yang dilokalkan untuk banyak lokalitas. Sebelumnya, fungsi 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 dapat mengalami masalah kompatibilitas jika mengasumsikan bahwa "UTC" atau "GMT+00:00" adalah output untuk zzzz dalam semua bahasa.
- Perilaku java.text.DateFormatSymbols.getZoneStrings() telah berubah:
  - Seperti SimpleDateFormat, UTC dan GMT kini memiliki nama panjang. Varian DST dari nama zona waktu 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 hard code UTC.
  - Beberapa ID zona dikenali dengan benar sebagai sinonim untuk zona lain, sehingga Android menemukan string untuk ID zona kuno, seperti Eire, yang sebelumnya tidak dapat di-resolve.
- Asia/Hanoi tidak lagi menjadi zona yang dikenali. 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 meskipun saat mengurai teks mata uang yang sah. Hindari masalah ini dengan menggunakan NumberFormat.parseCurrency, yang tersedia sejak Android 7.0 (API level 24), untuk teks mata uang bergaya PLURALCURRENCYSTYLE.

Perubahan Pengujian Android

Android 9 memperkenalkan beberapa perubahan pada library dan struktur class 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 mengatur 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 cocok dengan dependensi project Anda. Versi JUnit ini mungkin berbeda dengan versi 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 Android Test.

Menguji perubahan build rangkaian pengujian

Metode addRequirements() di class TestSuiteBuilder telah dihapus, dan class TestSuiteBuilder itu sendiri tidak digunakan lagi. Metode addRequirements() mengharuskan developer untuk memberikan argumen yang jenisnya adalah 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).

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

Bentuk UTF-8 yang bukan terpendek, seperti <C0, AF>, diperlakukan sebagai tidak terbentuk dengan baik.
Bentuk pengganti UTF-8, seperti U+D800..U+DFFF, diperlakukan sebagai tidak terbentuk dengan baik.
Subbagian maksimum diganti dengan satu U+FFFD. Misalnya, dalam urutan byte "41 C0 AF 41 F4 80 80 41", subbagian maksimum adalah "C0", "AF", dan "F4 80 80". "F4 80 80" dapat berupa suburutan awal "F4 80 80 80", tetapi "C0" tidak dapat berupa suburutan awal dari urutan unit kode yang terbentuk dengan baik. Dengan demikian, output-nya harus berupa "A\ufffd\ufffdA\ufffdA".
Untuk mendekode urutan UTF-8 / CESU-8 yang dimodifikasi di 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 di RFC 2818. Karena alasan ini, Android tidak lagi kembali menggunakan CN. Untuk memverifikasi nama host, server harus menampilkan 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 karenanya dianggap sebagai operasi pemblokiran. Operasi pemblokiran di 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.

Me-resolve alamat IP numerik tidak dianggap sebagai operasi pemblokiran. Resolusi alamat IP numerik berfungsi sama seperti pada 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 IPC binder. Perubahan ini dapat memengaruhi statistik traffic jaringan, misalnya, saat menggunakan metode queryDetailsForUidTag().

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

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 kumpulan informasi terbatas untuk VPN, seperti TRANSPORT_VPN, tetapi menghilangkan NET_CAPABILITY_NOT_VPN. Informasi terbatas ini mempersulit untuk menentukan apakah penggunaan VPN akan menghasilkan tagihan kepada pengguna aplikasi. Misalnya, memeriksa NET_CAPABILITY_NOT_METERED tidak akan menentukan apakah jaringan yang mendasarinya diukur atau tidak.

Di Android 9 dan yang lebih baru, saat VPN memanggil metode setUnderlyingNetworks(), sistem Android akan menggabungkan transpor dan kemampuan jaringan pokok 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 yang mendasarinya.

File dalam 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 dengan beberapa perangkat yang tidak memiliki file ini sama sekali.

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

Persyaratan FLAG_ACTIVITY_NEW_TASK kini 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 tanda 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 otomatis dan potret menggunakan kartu Setelan cepat atau setelan Tampilan. 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 yang terlihat di bagian atas. Aktivitas tidak boleh mengasumsikan bahwa aktivitas akan selalu dirender dalam potret. Jika Aktivitas teratas dapat dirender dalam beberapa rotasi dalam mode putar otomatis, opsi yang sama akan tersedia dalam mode rotasi terkunci, 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 seperti di Android 8.0.

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

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 berupa potret untuk perangkat faktor bentuk ponsel:

Saat pengguna menyetujui 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 putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam potret atau lanskap (dan sebaliknya). Mendukung layout potret dan lanskap.
userLandscape	Dalam putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam lanskap atau lanskap terbalik. Mendukung hanya layout lanskap.
userPortrait	Dalam putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam potret atau potret terbalik. Mendukung hanya layout potret.
fullUser	Dalam putar otomatis dan kunci rotasi, Aktivitas dapat dirender dalam potret atau lanskap (dan sebaliknya). Dukung tata letak potret dan lanskap. Pengguna kunci rotasi akan diberi opsi untuk mengunci ke potret terbalik, biasanya 180º.
sensor, fullSensor, sensorPortrait, sensorLandscape	Preferensi mode kunci rotasi diabaikan dan diperlakukan seolah-olah rotasi otomatis aktif. Hanya gunakan ini dalam keadaan tidak biasa dengan pertimbangan UX yang sangat hati-hati.

Penghentian penggunaan klien HTTP Apache memengaruhi aplikasi dengan ClassLoader non-standar

Dengan Android 6.0, kami menghapus dukungan untuk klien HTTP Apache. Perubahan ini tidak memengaruhi sebagian besar aplikasi yang tidak menargetkan Android 9 atau yang lebih tinggi. Namun, perubahan ini dapat memengaruhi aplikasi tertentu yang menggunakan struktur ClassLoader nonstandar, 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 ClassLoader aplikasi 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.

Mengenumerasi kamera

Aplikasi yang berjalan di perangkat Android 9 dapat menemukan setiap kamera yang tersedia dengan memanggil getCameraIdList(). Aplikasi tidak boleh mengasumsikan 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 melihat daftar kamera, memeriksa karakteristik setiap kamera, dan memutuskan kamera mana yang akan ditampilkan kepada pengguna.