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:
- Untuk membaca angka dari tindakan
intent
PHONE_STATE
, Anda memerlukan izinREAD_CALL_LOG
dan izinREAD_PHONE_STATE
. - Untuk membaca nomor dari
onCallStateChanged()
, Anda hanya memerlukan izinREAD_CALL_LOG
. Anda tidak memerlukan izinREAD_PHONE_STATE
.
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:
- Metode
getScanResults()
dangetConnectionInfo()
dariWifiManager
. - Metode
discoverServices()
danaddServiceRequest()
dariWifiP2pManager
. - 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 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:
- Jika instance
SSLSocket
gagal terhubung saat sedang dibuat, sistem akan menampilkanIOException
, bukanNullPointerException
. - Class
SSLEngine
menangani dengan baik setiap pemberitahuanclose_notify
yang terjadi.
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.
- Memformat
- 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 stringUTC
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.
- Seperti halnya
- Asia/Hanoi bukan lagi zona yang diakui. Karena alasan ini,
java.util.TimeZones.getAvailableIds()
tidak menampilkan nilai ini, danjava.util.TimeZone.getTimeZone()
tidak mengenalinya. Perilaku ini konsisten dengan perilakuandroid.icu
yang sudah ada.
- Platform menangani GMT dan UTC dengan lebih baik; UTC tidak lagi sama dengan
GMT.
- Metode
android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String)
dapat menampilkanParseException
bahkan saat mengurai teks mata uang yang sah. Hindari masalah ini dengan menggunakanNumberFormat.parseCurrency
, tersedia sejak Android 7.0 (level API 24), untuk teks mata uang gayaPLURALCURRENCYSTYLE
.
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 JNINewStringUTF()
.
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.