Perubahan perilaku: semua aplikasi Android 9 (API level 28)

Android 9 (API level 28) memperkenalkan banyak perubahan pada sistem Android. Perubahan perilaku berikut berlaku untuk semua aplikasi ketika aplikasi itu dijalankan pada platform Android 9, apa pun API level yang ditargetkannya. Semua developer harus meninjau perubahan ini dan memodifikasi aplikasinya agar bisa mendukungnya dengan benar, bila 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+.

Manajemen daya

Android 9 memperkenalkan beberapa fitur baru untuk meningkatkan manajemen daya perangkat. Perubahan ini, beserta fitur yang sudah ada sebelum Android 9, membantu memastikan bahwa sumber daya sistem tersedia untuk aplikasi yang paling membutuhkan.
Untuk detailnya, lihat Manajemen 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, dan aturan izin serta grup izin baru yang terkait dengan panggilan ponsel, 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 masukan pengguna dan data sensor. Bila aplikasi Anda berjalan di latar belakang pada perangkat yang menjalankan Android 9, sistem menerapkan pembatasan berikut untuk aplikasi Anda:

• Aplikasi Anda tidak bisa mengakses mikrofon atau kamera.
• Sensor yang menggunakan mode laporan continuous , seperti akselerometer dan giroskop, tidak menerima event.
• Sensor yang menggunakan mode laporan on-change atau one-shot tidak menerima event.

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

Akses terbatas ke log panggilan

Android 9 memperkenalkan CALL_LOG grup izin 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 memberi pengguna kontrol dan visibilitas yang lebih baik bagi aplikasi yang membutuhkan akses ke informasi sensitif tentang panggilan ponsel, seperti membaca catatan panggilan ponsel dan mengidentifikasi nomor ponsel.
Bila aplikasi Anda membutuhkan akses ke log panggilan atau harus memproses panggilan keluar, Anda harus secara eksplisit meminta izin ini dari grup izin CALL_LOG. Jika tidak, akan terjadi SecurityException.

Catatan: Karena izin ini telah mengubah grup dan diberikan saat waktu proses, pengguna bisa menolak akses aplikasi ke informasi log panggilan ponsel. Ketika hal ini terjadi, aplikasi Anda harus bisa menangani kurangnya akses ke informasi dengan baik.
Bila aplikasi Anda sudah mengikuti praktik terbaik izin waktu proses, ia bisa menangani perubahan dalam grup izin.

Akses terbatas ke nomor ponsel

Aplikasi yang berjalan di Android 9 tidak bisa membaca nomor ponsel atau status ponsel tanpa terlebih dahulu memperoleh izin READ_CALL_LOG , selain izin lainnya yang dibutuhkan oleh kasus penggunaan aplikasi Anda.
Nomor ponsel yang terkait dengan panggilan masuk dan keluar bisa dilihat di siaran status ponsel, seperti untuk panggilan masuk dan keluar serta dapat diakses dari class PhoneStateListener. Namun, tanpa izin READ_CALL_LOG kolom nomor ponsel yang disediakan dalam siaran PHONE_STATE_CHANGED dan melalui PhoneStateListener akan kosong.
Untuk membaca nomor ponsel dari status ponsel, update aplikasi untuk meminta izin yang diperlukan berdasarkan kasus penggunaan Anda:

• Untuk membaca nomor dari PHONE_STATE aksi intent, Anda membutuhkan izin READ_CALL_LOG dan izin READ_PHONE_STATE.
• Untuk membaca nomor dari onCallStateChanged(), Anda hanya membutuhkan izin READ_CALL_LOG . Anda tidak membutuhkan izin READ_PHONE_STATE .

Akses terbatas ke lokasi dan informasi koneksi Wi-Fi

Dalam Android 9, persyaratan izin bagi aplikasi untuk melakukan pemindaian Wi-Fi lebih ketat daripada versi sebelumnya. Untuk detailnya, lihat pembatasan pemindaian Wi-Fi.
Pembatasan serupa juga berlaku untuk metode getConnectionInfo() , yang menampilkan objek WifiInfo yang menggambarkan koneksi Wi-Fi saat ini. Anda hanya bisa menggunakan metode objek ini untuk memperoleh nilai SSID dan BSSID bila aplikasi panggilan memiliki izin berikut:

• ACCESS_FINE_LOCATION atau ACCESS_COARSE_LOCATION
• ACCESS_WIFI_STATE

Memperoleh SSID atau BSSID juga membutuhkan layanan lokasi agar diaktifkan di perangkat (dalam Settings > Location).

Informasi dihapus dari metode layanan Wi-Fi

Dalam Android 9, event 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 memuat SSID (sebelumnya EXTRA_SSID), BSSID (sebelumnya EXTRA_BSSID), atau informasi koneksi (sebelumnya EXTRA_NETWORK_INFO). Bila aplikasi Anda membutuhkan informasi ini, panggil getConnectionInfo() sebagai gantinya.

Informasi telepon sekarang bergantung pada setelan lokasi perangkat

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

• getAllCellInfo()
• listen()
• getCellLocation()
• getNeighboringCellInfo()

Pembatasan pada penggunaan antarmuka non-SDK

Untuk membantu memastikan stabilitas dan kompatibilitas aplikasi, platform membatasi penggunaan beberapa kolom dan metode non-SDK; pembatasan ini berlaku saat Anda mencoba untuk mengakses metode dan kolom ini secara langsung, melalui refleksi, atau menggunakan JNI. Dalam Android 9, aplikasi Anda bisa terus mengakses antarmuka yang dibatasi ini; platform tersebut menggunakan toast dan entri log untuk membawa mereka ke perhatian. Bila aplikasi Anda menunjukkan toast, sebaiknya Anda mengejar strategi implementasi selain antarmuka yang dibatasi. Bila Anda merasa bahwa tidak ada strategi alternatif lain yang bisa dilakukan, Anda dapat melaporkan bug untuk meminta peninjauan kembali terhadap pembatasan tersebut.
Pembatasan pada Antarmuka Non-SDK berisi lebih banyak informasi penting. Anda harus memeriksanya untuk memastikan bahwa aplikasi Anda terus berfungsi dengan benar.

Perubahan perilaku keamanan

Perubahan keamanan perangkat

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

Perubahan implementasi TLS

Implementasi TLS sistem telah mengalami sejumlah perubahan di Android 9:

• Jika instance SSLSocket gagal terhubung saat sedang dibuat, sistem akan melontarkan sebuah IOException sebagai ganti NullPointerException.
• Class SSLEngine menangani semua pemberitahuan close_notify yang terjadi dengan baik.

Untuk mempelajari lebih lanjut tentang 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 Android 8.0 (API level 26).
Catatan: Perubahan ini hanya memengaruhi aplikasi yang menggunakan syscalls khusus.

Perubahan kriptografi

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

Implementasi Conscrypt parameter dan algoritme

Android 9 menyediakan implementasi tambahan parameter algoritme dalam Conscrypt. Parameter-parameter ini meliputi: AES, DESEDE, OAEP, dan EC. Versi Bouncy Castle dari parameter-parameter ini dan banyak algoritme tidak digunakan lagi di Android 9.
Catatan: Implementasi Conscrypt parameter EC hanya mendukung kurva bernama.
Bila aplikasi Anda menargetkan Android 8.1 (API level 27) atau lebih rendah, Anda menerima peringatan ketika meminta implementasi Bouncy Castle dari salah satu algoritme yang tidak digunakan lagi ini. Namun, bila Anda menargetkan Android 9, permintaan ini akan memunculkan NoSuchAlgorithmException.

Perubahan lainnya

Android 9 memperkenalkan beberapa perubahan lain yang terkait dengan kriptografi:

• Saat menggunakan kunci PBE, bila Bouncy Castle mengharapkan initialization vector (IV) dan aplikasi Anda tidak menyediakannya, Anda akan menerima peringatan.
• Implementasi Conscrypt cipher ARC4 memungkinkan Anda untuk menentukan salah satu dari ARC4/ECB/NoPadding atau ARC4/NONE/NoPadding.
• Provider Crypto Java Cryptography Architecture (JCA) telah dihapus. Akibatnya , bila aplikasi Anda memanggil SecureRandom.getInstance("SHA1PRNG", "Crypto"), akan terjadi NoSuchProviderException.
• Bila 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 enkripsi aman Android tidak lagi didukung

Android 9 menghapus semua dukungan untuk Android secure encrypted files (ASECs).
Pada Android 2.2 (API level 8), Android memperkenalkan ASECs untuk mendukung fungsionalitas apps-on-SD-card. Pada Android 6.0 (API level 23), platform ini memperkenalkan teknologi perangkat adoptable storage yang bisa digunakan oleh para developer sebagai pengganti ASECs.

Update untuk 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, 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 pemformatan android.icu dan mengurai perilaku untuk zona seperti "GMT", "Etc/GMT", "UTC", "Etc/UTC", dan "Zulu".
    
  • java.text.SimpleDateFormat sekarang menggunakan ICU untuk memberikan nama tampilan bagi UTC /GMT, yang berarti:
    • Memformat zzzz menghasilkan string dilokalkan yang panjang untuk banyak lokal. Sebelumnya, ia menghasilkan "UTC" untuk UTC dan string seperti "GMT+00:00" untuk GMT.
    • Mem-parse zzzz mengenali string seperti "Universal Coordinated Time", dan "Greenwich Mean Time".
    • Aplikasi mungkin mengalami masalah kompatibilitas bila mereka beranggapan bahwa "UTC" atau "GMT+00:00" adalah keluaran untuk zzzz dalam semua bahasa.
  • Perilaku java.text.DateFormatSymbols.getZoneStrings() telah berubah:
    • Seperti halnya SimpleDateFormat, UTC dan GMT sekarang memiliki nama panjang. Varian DST dari nama zona waktu untuk zona UTC, seperti "UTC", "Etc/UTC", dan "Zulu", akan menjadi GMT+00:00, yang merupakan pilihan standar ketika tidak ada nama yang tersedia, bukannya string hard-coded UTC.
    • Beberapa ID zona dengan tepat dikenali sebagai sinonim untuk zona lain, sehingga Android menemukan string untuk ID zona lama, seperti Eire, yang sebelumnya tidak bisa ditetapkan.
  • 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 memunculkan ParseException bahkan ketika mengurai teks mata uang yang sah. Hindari masalah ini dengan menggunakan NumberFormat.parseCurrency, tersedia sejak Android 7.0 (API level 24), untuk PLURALCURRENCYSTYLE-teks model mata uang.

Perubahan pengujian Android

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 khusus.

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 versi yang disediakan android.jar.
Untuk mempelajari lebih lanjut tentang bagaimana class berbasis JUnit diatur ke dalam library ini, serta cara mempersiapkan project aplikasi Anda guna menulis dan menjalankan pengujian, lihat Menyiapkan project untuk Android Test.

Perubahan test suite build

Metode addRequirements() dalam class TestSuiteBuilder telah dihapus, dan class TestSuiteBuilder itu sendiri sudah tidak digunakan lagi. Metode addRequirements() mengharuskan developer untuk menyediakan argumen yang bertipe hidden API, menjadikan API tidak valid.

Dekoder UTF Java

UTF-8 adalah charset default dalam Android. Rangkaian byte UTF-8 bisa di-dekode oleh konstruktor String, seperti String(byte[] bytes).
Decoder UTF-8 di Android 9 mengikuti standar Unicode 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.
• Subpart maksimal digantikan oleh U+FFFD tunggal. Misalnya, dalam rangkaian byte "41 C0 AF 41 F4 80 80 41," subpart maksimal adalah "C0," "AF," dan "F4 80 80." "F4 80 80" bisa menjadi awal subrangkaian dari "F4 80 80 80", tetapi "C0" tidak dapat menjadi subrangkaian awal dari rangkaian unit kode yang tersusun dengan baik. Dengan demikian, keluarannya seharusnya "A\ufffd\ufffdA\ufffdA."
• Untuk mendekode rangkaian UTF-8 / CESU-8 yang dimodifikasi dalam Android 9 atau yang lebih tinggi, gunakan metode DataInputStream.readUTF() atau metode JNI NewStringUTF().

Verifikasi hostname menggunakan sertifikat

RFC 2818 menjelaskan dua metode untuk mencocokkan nama domain terhadap sertifikat—menggunakan nama yang tersedia dalam ekstensi subjectAltName (SAN), atau bila tidak terdapat ekstensi SAN, kembali menggunakan commonName (CN).
Namun, kembali menggunakan CN tidak digunakan lagi dalam RFC 2818. Karena alasan ini, Android tidak lagi kembali menggunakan CN. Untuk memverifikasi hostname, server harus memberikan sertifikat dengan SAN yang sesuai. Sertifikat yang tidak berisi SAN yang sesuai dengan hostname tidak lagi dipercaya.

Pencarian alamat jaringan bisa menyebabkan pelanggaran jaringan

Pencarian alamat jaringan yang memerlukan resolusi nama bisa melibatkan I/O jaringan dan karenanya dianggap operasi pemblokiran. Operasi pemblokiran pada thread utama bisa menyebabkan jeda atau kelambanan.
Class StrictMode adalah fitur pengembangan yang membantu developer mendeteksi masalah dalam kode mereka.
Di Android 9 yang lebih tinggi, StrictMode mendeteksi pelanggaran jaringan yang disebabkan oleh pencarian alamat jaringan yang memerlukan resolusi nama.
Anda tidak boleh meluncurkan aplikasi dengan StrictMode diaktifkan. Bila melakukannya, maka aplikasi Anda bisa mengalami pengecualian, seperti NetworkOnMainThreadException ketika 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, bila sebuah soket diberi tag menggunakan metode setThreadStatsTag(), soket tersebut dihilangkan tag-nya ketika dikirim ke proses lain menggunakan binder IPC dengan container ParcelFileDescriptor.
Di Android 9 dan yang lebih tinggi, tag soket disimpan ketika dikirim ke proses lain menggunakan binder IPC. Perubahan ini bisa memengaruhi statistik traffic jaringan, misalnya, ketika menggunakan metode queryDetailsForUidTag().
Bila Anda ingin mempertahankan perilaku versi sebelumnya, yang menghilangkan tag soket yang dikirim ke proses lain, Anda bisa memanggil untagSocket() sebelum mengirim soket.

Jumlah byte tersedia yang dilaporkan dalam soket

Metode available() menunjukkan 0 ketika dipanggil setelah meminta metode shutdownInput().

Pelaporan kemampuan jaringan yang lebih detail untuk VPN

Di Android 8.1 (API level 28) dan yang lebih rendah, class NetworkCapabilities hanya melaporkan sekumpulan informasi terbatas untuk VPN, seperti TRANSPORT_VPN, tetapi mengabaikan NET_CAPABILITY_NOT_VPN. Informasi terbatas ini mempersulit penentuan apakah penggunaan VPN akan mengakibatkan beban biaya kepada pengguna aplikasi. Misalnya, memeriksa NET_CAPABILITY_NOT_METERED tidak akan memastikan apakah jaringan dasarnya diukur penggunaannya atau tidak.
Di Android 9 dan yang lebih tinggi, ketika VPN memanggil metode setUnderlyingNetworks() , sistem Android menggabungkan transpor dan kemampuan jaringan dasarnya dan menunjukkan hasilnya sebagai kemampuan jaringan efektif dari jaringan VPN.
Di Android 9 dan yang lebih tinggi, aplikasi yang sudah memeriksa NET_CAPABILITY_NOT_METERED menerima kemampuan jaringan VPN dan jaringan dasarnya.

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 pada beberapa perangkat yang tidak memiliki file-file ini sama sekali.
API publik yang bergantung pada file-file ini, TrafficStats dan NetworkStatsManager, terus berfungsi sebagaimana yang diharapkan. 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 diberlakukan

Dengan Android 9, Anda tidak bisa memulai aktivitas dari konteks nonaktivitas kecuali Anda memberikan flag intent FLAG_ACTIVITY_NEW_TASK. Bila Anda mencoba memulai aktivitas tanpa memberikan flag ini, aktivitas tidak dimulai, dan sistem mencetak pesan ke log.
Catatan: Persyaratan flag selalu merupakan perilaku yang diharapkan, dan diberlakukan pada versi yang lebih rendah daripada Android 7.0 (API level 24). Bug di Android 7.0 mencegah persyaratan flag diberlakukan.

Perubahan rotasi layar

Mulai Android 9, ada perubahan signifikan pada mode rotasi potret. Di Android 8.0 (API level 26), pengguna bisa beralih antara mode rotasi putar otomatis dan potret menggunakan setelan Display atau Quicksettings. Mode potret telah diganti namanya menjadi kunci rotasi dan aktif ketika putar otomatis dimatikan. Tidak ada perubahan pada mode putar otomatis.
Saat perangkat berada dalam mode kunci rotasi, pengguna bisa mengunci layar mereka ke rotasi apa pun yang didukung oleh Activity teratas yang terlihat. Activity tidak boleh beranggapan kalau itu akan selalu dirender dalam mode potret. Bila Activity teratas bisa dirender dalam beberapa rotasi pada mode putar otomatis, opsi yang sama harus tersedia dalam mode kunci rotasi, dengan beberapa pengecualian berdasarkan setelan screenOrientation Activity (lihat tabel di bawah ini).
Activity yang meminta orientasi tertentu (misalnya, screenOrientation=landscape) mengabaikan preferensi kunci pengguna dan berperilaku secara sama seperti di Android 8.0.
Preferensi orientasi layar bisa disetel pada tingkat Activity dalam Manifes Android, atau lewat program dengan setRequestedOrientation().
Mode kunci rotasi bekerja dengan menyetel preferensi rotasi pengguna yang digunakan WindowManager ketika menangani rotasi Activity. Preferensi rotasi pengguna mungkin saja berubah dalam kasus-kasus berikut. Perhatikan bahwa ada kecenderungan untuk kembali ke rotasi bawaan perangkat, yang biasanya potret untuk perangkat dengan faktor bentuk ponsel:

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

Tabel berikut merangkum perilaku rotasi untuk orientasi layar secara umum:

Orientasi Layar	Perilaku
unspecified, user	Dalam mode putar otomatis dan kunci rotasi, Activity bisa dirender dalam mode potret atau lanskap (dan sebaliknya). Mendukung layout potret dan lanskap.
userLandscape	Dalam mode putar otomatis dan kunci rotasi, Activity bisa dirender dalam mode lanskap atau lanskap terbalik. Mendukung hanya layout lanskap.
userPortrait	Dalam mode putar otomatis dan kunci rotasi, Activity bisa dirender dalam mode potret atau potret terbalik. Mendukung hanya layout potret.
fullUser	Dalam mode putar otomatis dan kunci rotasi, Activity bisa dirender dalam mode potret atau lanskap (dan sebaliknya). Mendukung layout potret dan lanskap. Pengguna kunci rotasi akan diberikan opsi untuk mengunci dalam posisi potret terbalik, sering kali 180º.
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 pemakaian klien HTTP Apache memengaruhi aplikasi dengan ClassLoader nonstandar

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 bisa memengaruhi aplikasi tertentu yang menggunakan struktur ClassLoader nonstandar, meskipun aplikasi tersebut tidak menargetkan Android 9 atau yang lebih tinggi.
Sebuah aplikasi bisa terpengaruh bila ia menggunakan ClassLoader nonstandar yang secara eksplisit mendelegasikan untuk ClassLoader sistem. Aplikasi-aplikasi ini harus didelegasikan ke ClassLoader aplikasi sebagai gantinya ketika mencari class di org.apache.http.*. Bila mereka mendelegasikan ke ClassLoader sistem, aplikasi akan gagal berfungsi di Android 9 atau yang lebih tinggi dengan NoClassDefFoundError, karena class tersebut tidak lagi dikenal ClassLoader sistem. Untuk mencegah masalah serupa di masa mendatang, aplikasi pada umumnya harus memuat class melalui ClassLoader aplikasi dan bukan mengakses ClassLoader sistem secara langsung.

Penghitungan kamera

Aplikasi yang berjalan di perangkat Android 9 bisa mengetahui semua kamera yang tersedia dengan memanggil getCameraIdList(). Aplikasi tidak boleh berasumsi bahwa perangkat hanya memiliki satu kamera belakang atau hanya satu kamera depan.
Misalnya, bila 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 kamera yang tersedia, memeriksa karakteristik masing-masing kamera, dan memutuskan kamera mana yang akan ditunjukkan kepada pengguna.


Source :

Perubahan perilaku: semua aplikasi