Bersama fitur dan kemampuan baru, Android 7.0 menyertakan berbagai perubahan sistem dan perubahan perilaku API. Dokumen ini menyoroti beberapa perubahan utama yang harus Anda pahami dan perhitungkan dalam aplikasi Anda.
Jika sebelumnya Anda telah memublikasikan aplikasi untuk Android, ketahuilah bahwa aplikasi Anda mungkin terpengaruh oleh perubahan dalam platform ini.
Baterai dan Memori
Android 7.0 menyertakan perubahan perilaku sistem yang bertujuan untuk meningkatkan masa pakai baterai perangkat dan mengurangi penggunaan RAM. Perubahan ini dapat memengaruhi akses aplikasi Anda ke resource sistem, beserta cara aplikasi Anda berinteraksi dengan aplikasi lain melalui intent implisit tertentu.
Istirahatkan
Diperkenalkan di Android 6.0 (API level 23), fitur Istirahatkan meningkatkan masa pakai baterai dengan menangguhkan aktivitas CPU dan jaringan saat pengguna membiarkan perangkat tidak dicolokkan, tidak bergerak, dan dengan layar dinonaktifkan. Android 7.0 menghadirkan peningkatan lebih lanjut pada Istirahatkan dengan menerapkan pembatasan CPU dan jaringan saat perangkat tidak dicolokkan ke sumber listrik dengan layar dimatikan, tetapi tidak selalu diam, misalnya, saat ponsel berada dalam saku.
![Ilustrasi tentang cara Istirahatkan menerapkan pembatasan
aktivitas sistem level pertama untuk meningkatkan masa pakai baterai](https://developer.android.com/static/images/android-7.0/doze-diagram-1.png?authuser=9&hl=id)
Gambar 1. Ilustrasi tentang cara Istirahatkan menerapkan pembatasan aktivitas sistem tingkat pertama untuk meningkatkan masa pakai baterai.
Jika perangkat menggunakan daya baterai, dan layar telah nonaktif selama waktu
tertentu, perangkat akan memasuki mode Istirahatkan dan menerapkan subset pembatasan pertama: Perangkat
akan menutup akses jaringan aplikasi, serta menunda tugas dan sinkronisasi. Jika perangkat
diam selama waktu tertentu setelah memasuki mode Istirahatkan, sistem akan menerapkan
pembatasan Istirahatkan lainnya terhadap alarm PowerManager.WakeLock
,
AlarmManager
, GPS, dan pemindaian Wi-Fi. Terlepas dari
apakah sebagian atau semua pembatasan Istirahatkan diterapkan, sistem akan membangunkan
perangkat selama masa pemeliharaan singkat, saat aplikasi diizinkan
mengakses jaringan dan dapat menjalankan semua tugas/sinkronisasi yang ditangguhkan.
![Ilustrasi tentang cara Istirahatkan menerapkan pembatasan aktivitas sistem
level kedua setelah perangkat diam selama jangka waktu tertentu](https://developer.android.com/static/images/android-7.0/doze-diagram-2.png?authuser=9&hl=id)
Gambar 2. Ilustrasi tentang cara Istirahatkan menerapkan pembatasan aktivitas sistem level kedua setelah perangkat diam selama jangka waktu tertentu.
Perhatikan bahwa mengaktifkan layar atau mencolokkan perangkat akan keluar dari mode Istirahatkan dan menghapus batasan pemrosesan ini. Perilaku tambahan ini tidak memengaruhi rekomendasi dan praktik terbaik dalam menyesuaikan aplikasi Anda dengan versi Istirahatkan sebelumnya yang diperkenalkan di Android 6.0 (API level 23), seperti yang dibahas dalam Mengoptimalkan mode Istirahatkan dan Aplikasi Standby. Anda tetap harus mengikuti rekomendasi tersebut, seperti menggunakan Firebase Cloud Messaging (FCM) untuk mengirim dan menerima pesan, serta mulai merencanakan update untuk mengakomodasi perilaku Istirahatkan tambahan.
Project Svelte: Optimisasi Latar Belakang
Android 7.0 menghapus tiga siaran implisit untuk membantu mengoptimalkan penggunaan memori dan konsumsi daya. Perubahan ini diperlukan karena siaran implisit sering memulai aplikasi yang telah didaftarkan untuk memprosesnya di latar belakang. Menghapus siaran ini dapat sangat menguntungkan performa perangkat dan pengalaman pengguna.
Perangkat seluler sering mengalami perubahan konektivitas, seperti saat berpindah
antara Wi-Fi dan data seluler. Saat ini, aplikasi dapat memantau perubahan
konektivitas dengan mendaftarkan penerima untuk siaran CONNECTIVITY_ACTION
implisit dalam
manifesnya. Karena banyak aplikasi yang mendaftar untuk menerima siaran ini, satu
switch jaringan dapat menyebabkan semuanya aktif dan memproses siaran
secara bersamaan.
Demikian pula, pada versi Android sebelumnya, aplikasi dapat mendaftar untuk menerima siaran ACTION_NEW_PICTURE
dan ACTION_NEW_VIDEO
implisit dari aplikasi lain, seperti
Kamera. Saat pengguna mengambil gambar dengan aplikasi Kamera, aplikasi ini akan aktif
untuk memproses siaran.
Untuk mengatasi masalah ini, Android 7.0 menerapkan pengoptimalan berikut:
- Aplikasi yang menargetkan Android 7.0 (API level 24) dan yang lebih tinggi tidak menerima
siaran
CONNECTIVITY_ACTION
jika aplikasi tersebut mendeklarasikan penerima siarannya di manifes. Aplikasi akan tetap menerima siaranCONNECTIVITY_ACTION
jika mendaftarkanBroadcastReceiver
denganContext.registerReceiver()
dan konteks tersebut masih valid. - Sistem tidak lagi mengirim siaran
ACTION_NEW_PICTURE
atauACTION_NEW_VIDEO
. Pengoptimalan ini memengaruhi semua aplikasi, tidak hanya aplikasi yang menargetkan Android 7.0.
Jika aplikasi Anda menggunakan salah satu intent ini, Anda harus menghapus dependensi
pada intent tersebut sesegera mungkin agar dapat menargetkan perangkat Android 7.0 dengan benar.
Framework Android menyediakan beberapa solusi untuk mengurangi kebutuhan akan
siaran implisit ini. Misalnya, JobScheduler
API menyediakan mekanisme yang andal untuk menjadwalkan
operasi jaringan jika kondisi tertentu terpenuhi, misalnya koneksi ke
jaringan tidak berbayar. Anda bahkan dapat menggunakan JobScheduler
untuk bereaksi terhadap perubahan pada penyedia konten.
Untuk mengetahui informasi selengkapnya tentang pengoptimalan latar belakang di Android 7.0 (API level 24) dan cara menyesuaikan aplikasi Anda, lihat Pengoptimalan Latar Belakang.
Perubahan Izin
Android 7.0 menyertakan perubahan pada izin yang bisa memengaruhi aplikasi Anda.
Perubahan izin sistem file
Untuk meningkatkan keamanan file pribadi, direktori pribadi
aplikasi yang menargetkan Android 7.0 atau yang lebih tinggi memiliki akses terbatas (0700
).
Setelan ini mencegah kebocoran metadata file pribadi, seperti ukuran
atau keberadaannya. Perubahan izin ini memiliki beberapa efek samping:
-
Izin file pribadi tidak akan lagi ditentukan oleh pemiliknya, dan upaya untuk melakukannya menggunakan
MODE_WORLD_READABLE
dan/atauMODE_WORLD_WRITEABLE
akan memicuSecurityException
.Catatan: Pembatasan ini tidak sepenuhnya diterapkan. Aplikasi mungkin masih mengubah izin ke direktori pribadinya menggunakan API native atau
File
API. Namun, kami sangat tidak menyarankan Anda meremehkan izin direktori pribadi. -
Meneruskan URI
file://
di luar domain paket dapat meninggalkan penerima dengan jalur yang tidak dapat diakses. Oleh karena itu, upaya untuk meneruskan URIfile://
akan memicuFileUriExposedException
. Cara yang direkomendasikan untuk membagikan konten file pribadi adalah menggunakanFileProvider
. -
DownloadManager
tidak dapat lagi berbagi file yang disimpan secara pribadi berdasarkan nama file. Aplikasi lama mungkin akan memiliki jalur yang tidak dapat diakses saat mengaksesCOLUMN_LOCAL_FILENAME
. Aplikasi yang menargetkan Android 7.0 atau yang lebih tinggi akan memicuSecurityException
saat mencoba mengaksesCOLUMN_LOCAL_FILENAME
. Aplikasi lama yang menetapkan lokasi download ke lokasi publik menggunakanDownloadManager.Request.setDestinationInExternalFilesDir()
atauDownloadManager.Request.setDestinationInExternalPublicDir()
masih dapat mengakses jalur tersebut diCOLUMN_LOCAL_FILENAME
, tetapi metode ini sangat tidak dianjurkan. Cara yang lebih disukai untuk mengakses file yang diekspos olehDownloadManager
adalah menggunakanContentResolver.openFileDescriptor()
.
Berbagi File Antar Aplikasi
Untuk aplikasi yang menargetkan Android 7.0, framework Android menerapkan
kebijakan API StrictMode
yang melarang mengekspos URI file://
di luar aplikasi Anda. Jika intent yang berisi URI file keluar dari aplikasi, aplikasi akan gagal
dengan pengecualian FileUriExposedException
.
Untuk berbagi file antar-aplikasi, Anda harus mengirim URI content://
dan memberikan izin akses sementara pada URI. Cara termudah untuk memberikan izin ini adalah dengan
menggunakan class FileProvider
. Untuk informasi selengkapnya
tentang izin dan berbagi file,
lihat Berbagi File.
Peningkatan Aksesibilitas
Android 7.0 menyertakan perubahan yang dimaksudkan untuk meningkatkan kegunaan platform bagi pengguna dengan gangguan penglihatan atau yang rendah. Perubahan ini umumnya tidak memerlukan perubahan kode pada aplikasi Anda, tetapi Anda harus meninjau fitur ini dan mengujinya dengan aplikasi untuk menilai potensi dampaknya terhadap pengalaman pengguna.
Zoom Layar
Android 7.0 memungkinkan pengguna menyetel Display size yang akan memperbesar atau memperkecil semua elemen pada layar, sehingga meningkatkan aksesibilitas perangkat bagi pengguna yang mengalami gangguan penglihatan. Pengguna tidak dapat memperbesar layar melewati lebar layar minimum sw320dp, yang merupakan lebar Nexus 4, yakni ponsel ukuran sedang pada umumnya.
![Layar menunjukkan ukuran tampilan perangkat yang tidak diperbesar yang menjalankan image sistem Android 7.0](https://developer.android.com/static/images/android-7.0/screen-zoom-1.png?authuser=9&hl=id)
![Layar yang menunjukkan efek penambahan ukuran tampilan perangkat yang menjalankan image sistem Android 7.0](https://developer.android.com/static/images/android-7.0/screen-zoom-2.png?authuser=9&hl=id)
Gambar 3. Layar di sebelah kanan menampilkan efek meningkatkan Ukuran tampilan perangkat yang menjalankan image sistem Android 7.0.
Saat kepadatan perangkat berubah, sistem akan memberi tahu aplikasi yang sedang berjalan dengan cara berikut:
- Jika aplikasi menargetkan API level 23 atau yang lebih rendah, sistem akan secara otomatis menghentikan semua proses latar belakangnya. Artinya, jika pengguna beralih dari aplikasi tersebut untuk membuka layar Settings dan mengubah setelan Display size, sistem akan menghentikan aplikasi dengan cara yang sama seperti dalam situasi memori rendah. Jika aplikasi memiliki proses latar depan, sistem akan memberi tahu proses tersebut tentang perubahan konfigurasi seperti yang dijelaskan dalam Menangani Perubahan Runtime, seolah-olah orientasi perangkat telah berubah.
- Jika aplikasi menargetkan Android 7.0, semua prosesnya (latar depan dan latar belakang) akan diberi tahu tentang perubahan konfigurasi seperti yang dijelaskan dalam Menangani Perubahan Runtime.
Sebagian besar aplikasi tidak perlu melakukan perubahan untuk mendukung fitur ini, asalkan aplikasi tersebut mengikuti praktik terbaik Android. Hal-hal tertentu yang harus diperiksa:
- Uji aplikasi Anda di perangkat dengan lebar layar
sw320dp
dan pastikan aplikasi berjalan dengan memadai. - Saat konfigurasi perangkat berubah, perbarui informasi cache yang bergantung
pada kepadatan, seperti bitmap yang di-cache atau resource yang dimuat dari
jaringan. Periksa perubahan konfigurasi saat aplikasi melanjutkan dari status dijeda.
Catatan: Jika Anda meng-cache data yang bergantung pada konfigurasi, sebaiknya sertakan metadata yang relevan seperti ukuran layar atau kepadatan piksel yang sesuai untuk data tersebut. Dengan menyimpan metadata ini, Anda dapat memutuskan apakah Anda perlu me-refresh data yang di-cache setelah perubahan konfigurasi.
- Hindari menentukan dimensi dengan satuan px, karena satuan ini tidak diskalakan dengan
kepadatan layar. Sebagai gantinya, tentukan dimensi dengan satuan piksel
kepadatan mandiri (
dp
).
Vision Settings di Setup Wizard
Android 7.0 menyertakan Setelan Vision pada layar Selamat Datang, tempat pengguna dapat menyiapkan setelan aksesibilitas berikut di perangkat baru: Gestur pembesaran, Ukuran font, Ukuran tampilan, dan TalkBack. Perubahan ini meningkatkan visibilitas bug terkait setelan layar yang berbeda-beda. Untuk menilai dampak fitur ini, Anda harus menguji aplikasi dengan mengaktifkan setelan ini. Anda dapat menemukan setelan ini di bagian Setelan > Aksesibilitas.
Penautan Aplikasi NDK ke Pustaka Platform
Mulai Android 7.0, sistem mencegah aplikasi menautkan secara dinamis ke library non-NDK, yang dapat menyebabkan aplikasi Anda error. Perubahan perilaku ini bertujuan untuk menciptakan pengalaman aplikasi yang konsisten di seluruh update platform dan perangkat yang berbeda. Meskipun kode Anda mungkin tidak ditautkan ke library pribadi, mungkin saja library statis pihak ketiga di aplikasi Anda dapat melakukannya. Oleh karena itu, semua developer harus memeriksa untuk memastikan bahwa aplikasi mereka tidak error di perangkat yang menjalankan Android 7.0. Jika aplikasi Anda menggunakan kode native, sebaiknya hanya gunakan API NDK publik.
Ada tiga cara yang dapat digunakan aplikasi Anda untuk mencoba mengakses API platform pribadi:
- Aplikasi Anda mengakses langsung pustaka platform privat. Anda harus mengupdate aplikasi untuk menyertakan salinan library-nya sendiri atau menggunakan NDK API publik.
- Aplikasi Anda menggunakan library pihak ketiga yang mengakses library platform pribadi. Meskipun Anda yakin aplikasi tidak mengakses library pribadi secara langsung, Anda tetap harus menguji aplikasi untuk skenario ini.
- Aplikasi Anda mereferensikan pustaka yang tidak disertakan dalam APK-nya. Misalnya,
hal ini bisa terjadi jika Anda mencoba menggunakan salinan OpenSSL Anda sendiri, tetapi
lupa memaketkannya dengan APK aplikasi. Aplikasi dapat berjalan normal di versi
platform Android yang menyertakan
libcrypto.so
. Namun, aplikasi dapat mengalami error pada versi Android lebih baru yang tidak menyertakan library ini (seperti Android 6.0 dan yang lebih baru). Untuk memperbaikinya, pastikan Anda memaketkan semua library non-NDK dengan APK.
Aplikasi tidak boleh menggunakan library native yang tidak disertakan dalam NDK karena dapat berubah atau dihapus antara versi Android yang berbeda. Peralihan dari OpenSSL ke BoringSSL adalah contoh dari perubahan tersebut. Selain itu, karena tidak ada persyaratan kompatibilitas untuk library platform yang tidak disertakan dalam NDK, perangkat yang berbeda mungkin menawarkan tingkat kompatibilitas yang berbeda.
Untuk mengurangi dampak pembatasan ini terhadap aplikasi yang
dirilis saat ini, sekumpulan library yang mengalami penggunaan signifikan—seperti
libandroid_runtime.so
, libcutils.so
,
libcrypto.so
, dan libssl.so
—dapat diakses
sementara di Android 7.0 (API level 24) untuk aplikasi yang menargetkan API level 23 atau
yang lebih rendah. Jika aplikasi Anda memuat salah satu library ini, logcat akan menghasilkan peringatan
dan toast akan muncul pada perangkat target untuk memberi tahu Anda. Jika melihat peringatan ini, Anda harus mengupdate aplikasi agar menyertakan salinan library-nya sendiri atau hanya menggunakan NDK API publik. Rilis platform Android mendatang mungkin akan membatasi penggunaan library pribadi sepenuhnya dan menyebabkan aplikasi Anda error.
Semua aplikasi menghasilkan error runtime saat memanggil API yang bukan
publik atau dapat diakses untuk sementara. Hasilnya adalah
System.loadLibrary
dan dlopen(3)
menampilkan
NULL
, dan dapat menyebabkan aplikasi Anda error. Anda harus meninjau
kode aplikasi untuk menghapus penggunaan API platform pribadi dan menguji aplikasi secara menyeluruh
menggunakan perangkat atau emulator yang menjalankan Android 7.0 (level API 24). Jika tidak yakin apakah aplikasi Anda menggunakan library pribadi atau tidak, Anda dapat memeriksa logcat untuk mengidentifikasi error runtime.
Tabel berikut menjelaskan perilaku yang akan Anda lihat dari
aplikasi, bergantung pada penggunaan library native pribadi dan level API
targetnya (android:targetSdkVersion
).
Library | Tingkat API target | Akses waktu proses lewat linker dinamis | Perilaku Android 7.0 (level API 24) | Perilaku platform Android mendatang |
---|---|---|---|---|
Publik NDK | Ada | Mudah diakses | Bekerja sesuai harapan | Bekerja sesuai harapan |
Privat (pustaka privat yang dapat diakses sementara) | 23 atau yang lebih rendah | Untuk sementara dapat diakses | Bekerja sesuai harapan, namun Anda menerima peringatan logcat. | Kesalahan waktu proses |
Privat (pustaka privat yang dapat diakses sementara) | 24 atau yang lebih tinggi | Dibatasi | Kesalahan waktu proses | Kesalahan waktu proses |
Privat (lainnya) | Ada | Dibatasi | Kesalahan waktu proses | Kesalahan waktu proses |
Periksa apakah aplikasi Anda menggunakan pustaka privat
Untuk membantu Anda mengidentifikasi masalah saat memuat library pribadi, logcat dapat menghasilkan peringatan atau error runtime. Misalnya, jika aplikasi Anda menargetkan API level 23 atau yang lebih rendah, dan mencoba mengakses library pribadi di perangkat yang menjalankan Android 7.0, Anda mungkin melihat peringatan seperti berikut:
03-21 17:07:51.502 31234 31234 W linker : library "libandroid_runtime.so" ("/system/lib/libandroid_runtime.so") needed or dlopened by "/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible for the namespace "classloader-namespace" - the access is temporarily granted as a workaround for http://b/26394120
Peringatan logcat ini memberi tahu Anda library mana yang mencoba mengakses API platform pribadi, tetapi tidak akan menyebabkan aplikasi error. Namun, jika aplikasi menargetkan API level 24 atau yang lebih tinggi, logcat akan menghasilkan error runtime berikut dan aplikasi Anda mungkin akan error:
java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so" ("/system/lib/libcutils.so") needed or dlopened by "/system/lib/libnativeloader.so" is not accessible for the namespace "classloader-namespace" at java.lang.Runtime.loadLibrary0(Runtime.java:977) at java.lang.System.loadLibrary(System.java:1602)
Anda juga mungkin melihat output logcat ini jika aplikasi menggunakan library pihak ketiga yang secara dinamis menautkan ke API platform pribadi. Alat readelf di Android 7.0DK memungkinkan Anda membuat daftar semua library bersama yang tertaut secara dinamis dari file .so
tertentu dengan menjalankan perintah berikut:
aarch64-linux-android-readelf -dW libMyLibrary.so
Update aplikasi Anda
Berikut adalah beberapa langkah yang dapat Anda lakukan untuk memperbaiki jenis error ini dan memastikan aplikasi tidak error pada update platform mendatang:
- Jika aplikasi Anda menggunakan library platform pribadi, Anda harus mengupdatenya agar menyertakan salinan library-nya sendiri atau menggunakan NDK API publik.
- Jika aplikasi Anda menggunakan library pihak ketiga yang mengakses simbol pribadi, hubungi penulis library untuk mengupdate library.
- Pastikan Anda mengemas semua pustaka non-NDK bersama APK.
- Gunakan fungsi JNI standar, bukan
getJavaVM
dangetJNIEnv
darilibandroid_runtime.so
:AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h> AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or JavaVM::AttachCurrentThread from <jni.h>.
- Gunakan
__system_property_get
, bukan simbolproperty_get
pribadi darilibcutils.so
. Untuk melakukannya, gunakan__system_property_get
dengan yang berikut ini:#include <sys/system_properties.h>
Catatan: Ketersediaan dan isi properti sistem tidak diuji melalui CTS. Perbaikan yang lebih baik adalah menghindari penggunaan properti ini sepenuhnya.
- Gunakan versi lokal simbol
SSL_ctrl
darilibcrypto.so
. Misalnya, Anda harus menautkanlibcyrpto.a
secara statis di file.so
, atau menyertakan versilibcrypto.so
yang ditautkan secara dinamis dari BoringSSL/OpenSSL dan memaketkannya dalam APK.
Android for Work
Android 7.0 berisi perubahan untuk aplikasi yang menargetkan Android for Work, termasuk perubahan pada penginstalan sertifikat, reset sandi, pengelolaan pengguna sekunder, dan akses ke ID perangkat. Jika membangun aplikasi untuk lingkungan Android for Work, Anda harus meninjau perubahan ini dan memodifikasi aplikasi sebagaimana mestinya.
- Anda harus menginstal penginstal sertifikat yang didelegasikan sebelum DPC dapat
menyetelnya. Untuk profil dan aplikasi pemilik perangkat yang menargetkan Android 7.0 (API level 24),
Anda harus menginstal penginstal sertifikat yang didelegasikan sebelum pengontrol kebijakan
perangkat (DPC) memanggil
DevicePolicyManager.setCertInstallerPackage()
. Jika penginstal belum diinstal, sistem akan menampilkanIllegalArgumentException
. - Pembatasan sandi reset untuk admin perangkat kini diterapkan ke pemilik
profil. Admin perangkat tidak dapat lagi menggunakan
DevicePolicyManager.resetPassword()
untuk menghapus sandi atau mengubah sandi yang sudah ditetapkan. Admin perangkat tetap dapat menyetel sandi, namun hanya jika perangkat belum memiliki sandi, PIN, atau pola. - Pemilik perangkat dan profil dapat mengelola akun meskipun pembatasan
ditetapkan. Pemilik perangkat dan pemilik profil dapat memanggil Account Management API meskipun pembatasan pengguna
DISALLOW_MODIFY_ACCOUNTS
diberlakukan. - Pemilik perangkat bisa mengelola pengguna tambahan lebih mudah. Jika perangkat berjalan dalam mode pemilik perangkat, batasan
DISALLOW_ADD_USER
akan otomatis disetel. Tindakan ini mencegah pengguna membuat pengguna sekunder yang tidak dikelola. Selain itu, metodeCreateUser()
dancreateAndInitializeUser()
tidak digunakan lagi; metodeDevicePolicyManager.createAndManageUser()
baru menggantikannya. - Pemilik perangkat bisa mengakses identifier perangkat. Pemilik perangkat dapat mengakses
alamat MAC Wi-Fi perangkat, menggunakan
DevicePolicyManager.getWifiMacAddress()
. Jika Wi-Fi belum pernah diaktifkan di perangkat tersebut, metode ini akan menampilkan nilainull
. - Setelan Mode Kerja mengontrol akses ke aplikasi kerja. Jika mode kerja tidak aktif, peluncur sistem akan menunjukkan aplikasi kerja tidak tersedia dengan membuat warnanya jadi abu-abu. Mengaktifkan kembali mode kerja akan memulihkan perilaku normal.
- Saat menginstal file PKCS #12 yang berisi rantai sertifikat klien dan
kunci pribadi yang terkait dari Settings UI, sertifikat CA dalam
rantai tersebut tidak lagi diinstal ke penyimpanan kredensial tepercaya. Hal ini
tidak memengaruhi hasil
KeyChain.getCertificateChain()
jika aplikasi mencoba mengambil rantai sertifikat klien nanti. Jika diperlukan, sertifikat CA harus diinstal ke penyimpanan kredensial tepercaya melalui UI Setelan secara terpisah, dengan format yang dienkode DER menggunakan ekstensi file .crt atau .cer. - Mulai Android 7.0, pendaftaran dan penyimpanan sidik jari dikelola per pengguna. Jika Device Policy Client (DPC) pemilik profil menargetkan API level 23 (atau yang lebih rendah) di perangkat yang menjalankan Android 7.0 (API level 24), pengguna tetap dapat menyetel sidik jari di perangkat, tetapi aplikasi kerja tidak dapat mengakses sidik jari perangkat. Jika DPC menargetkan API level 24 dan yang lebih baru, pengguna dapat menyetel sidik jari secara khusus untuk profil kerja dengan membuka Settings > Security > Work profile security.
- Status enkripsi baru
ENCRYPTION_STATUS_ACTIVE_PER_USER
ditampilkan olehDevicePolicyManager.getStorageEncryptionStatus()
, untuk menunjukkan bahwa enkripsi aktif dan kunci enkripsi terkait dengan pengguna. Status baru hanya dikembalikan jika DPC menargetkan API Level 24 dan yang lebih tinggi. Untuk aplikasi yang menargetkan API level sebelumnya,ENCRYPTION_STATUS_ACTIVE
akan ditampilkan, meskipun kunci enkripsi ini khusus untuk pengguna atau profil. - Di Android 7.0, beberapa metode yang biasanya akan memengaruhi seluruh
perangkat akan berperilaku berbeda jika perangkat menginstal profil kerja dengan
tantangan kerja terpisah. Tidak memengaruhi seluruh perangkat, metode
ini hanya berlaku untuk profil kerja. (Daftar lengkap metode tersebut ada dalam dokumentasi
DevicePolicyManager.getParentProfileInstance()
.) Misalnya,DevicePolicyManager.lockNow()
hanya mengunci profil kerja, bukan mengunci seluruh perangkat. Untuk setiap metode ini, Anda bisa memperoleh perilaku lama dengan memanggil metode pada instance indukDevicePolicyManager
; Anda bisa mendapatkan induk ini dengan memanggilDevicePolicyManager.getParentProfileInstance()
. Jadi, misalnya, jika Anda memanggil metodelockNow()
instance induk, seluruh perangkat akan dikunci.
Retensi Anotasi
Android 7.0 memperbaiki bug yang membuat visibilitas anotasi menjadi terabaikan. Masalah ini memungkinkan runtime mengakses anotasi yang seharusnya tidak dapat dilakukannya. Anotasi ini termasuk:
VISIBILITY_BUILD
: Dimaksudkan agar hanya terlihat pada waktu build.VISIBILITY_SYSTEM
: Dimaksudkan agar terlihat saat runtime, tetapi hanya pada sistem yang mendasarinya.
Jika aplikasi Anda mengandalkan perilaku ini, tambahkan kebijakan retensi ke anotasi yang harus
tersedia selama runtime. Anda melakukannya menggunakan @Retention(RetentionPolicy.RUNTIME)
.
Perubahan Konfigurasi Default TLS/SSL
Android 7.0 melakukan perubahan berikut pada konfigurasi TLS/SSL default yang digunakan oleh aplikasi untuk HTTPS dan traffic TLS/SSL lainnya:
- Cipher suite RC4 kini dinonaktifkan.
- Cipher suite CHACHA20-POLY1305 kini diaktifkan.
RC4 yang dinonaktifkan secara default dapat menyebabkan kerusakan dalam konektivitas HTTPS atau TLS/SSL jika server tidak menegosiasikan cipher suite modern. Perbaikan yang diutamakan adalah meningkatkan konfigurasi server untuk memungkinkan cipher suite dan protokol yang lebih kuat dan lebih modern. Idealnya, TLSv1.2 dan AES-GCM harus diaktifkan, sedangkan cipher suite Forward Secrecy (ECDHE) harus diaktifkan dan diprioritaskan.
Alternatifnya, Anda dapat memodifikasi aplikasi agar menggunakan SSLSocketFactory
kustom untuk berkomunikasi dengan server. Factory harus didesain untuk membuat instance SSLSocket
yang memiliki beberapa cipher suite yang diperlukan oleh server yang diaktifkan selain cipher suite default.
Catatan: Perubahan ini tidak berkaitan dengan WebView
.
Aplikasi yang menargetkan Android 7.0
Perubahan perilaku ini berlaku secara eksklusif pada aplikasi yang menargetkan
Android 7.0 (API level 24) atau yang lebih tinggi. Aplikasi yang dikompilasi untuk Android 7.0,
atau menetapkan targetSdkVersion
ke Android 7.0 atau yang lebih tinggi, harus memodifikasi
aplikasinya untuk mendukung perilaku ini dengan benar, jika memungkinkan bagi aplikasi tersebut.
Perubahan Serialisasi
Android 7.0 (API level 24) memperbaiki bug dalam penghitungan serialVersionUID default yang tidak sesuai dengan spesifikasi.
Class yang mengimplementasikan Serializable
dan tidak menentukan kolom serialVersionUID
eksplisit dapat
melihat perubahan dalam serialVersionUID default-nya yang akan menyebabkan pengecualian
ditampilkan saat mencoba melakukan deserialisasi instance class yang
diserialisasi pada versi sebelumnya atau diserialisasi oleh aplikasi yang menargetkan versi
sebelumnya. Pesan error akan terlihat seperti ini:
local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567
Untuk memperbaiki masalah ini, Anda harus menambahkan kolom serialVersionUID
ke
class yang terpengaruh dengan nilai stream classdesc
serialVersionUID
dari pesan error, misalnya 1234
dalam
kasus ini. Perubahan tersebut mematuhi semua rekomendasi praktik yang baik untuk
menulis kode serialisasi dan akan berfungsi pada semua versi Android.
Bug spesifik yang diperbaiki terkait dengan keberadaan metode
penginisialisasi statis, yaitu <clinit>
. Menurut spesifikasi, ada atau tidaknya metode penginisialisasi statis di class akan memengaruhi serialVersionUID default yang dihitung untuk class tersebut.
Sebelum perbaikan bug, kalkulasi juga akan memeriksa class super untuk penginisialisasi statis jika class tidak memilikinya.
Untuk memperjelas, perubahan ini tidak memengaruhi aplikasi yang menargetkan API level 23 atau
lebih rendah, yaitu class yang memiliki kolom atau class serialVersionUID
yang memiliki metode penginisialisasi statis.
Poin Penting Lainnya
- Saat aplikasi berjalan pada Android 7.0, tetapi menargetkan level API yang lebih rendah,
dan pengguna mengubah ukuran tampilan, proses aplikasi akan dihentikan. Aplikasi
harus dapat menangani skenario ini dengan baik. Jika tidak, maka akan error
saat pengguna memulihkannya dari Recents.
Anda harus menguji aplikasi untuk memastikan perilaku ini tidak terjadi. Anda dapat melakukannya dengan menyebabkan error yang sama saat menghentikan aplikasi secara manual melalui DDMS.
Aplikasi yang menargetkan Android 7.0 (API level 24) dan yang lebih baru tidak secara otomatis dimatikan saat perubahan kepadatan; namun, aplikasi mungkin masih merespons perubahan konfigurasi dengan buruk.
- Aplikasi di Android 7.0 harus dapat menangani perubahan konfigurasi dengan lancar, dan tidak boleh error pada pemulaian berikutnya. Anda dapat memverifikasi perilaku aplikasi dengan mengubah ukuran font (Setting > Display > Font size), lalu memulihkan aplikasi dari Recents.
-
Karena adanya bug di versi Android sebelumnya, sistem tidak menandai penulisan
ke soket TCP di thread utama sebagai pelanggaran mode ketat. Android 7.0 telah memperbaiki bug ini.
Aplikasi yang menunjukkan perilaku ini sekarang akan menampilkan
android.os.NetworkOnMainThreadException
. Secara umum, menjalankan operasi jaringan di thread utama merupakan ide buruk karena operasi ini biasanya memiliki latensi tinggi yang menyebabkan ANR dan jank. -
Kumpulan metode
Debug.startMethodTracing()
kini ditetapkan secara default ke output penyimpanan di direktori khusus paket Anda di penyimpanan bersama, bukan di level teratas kartu SD. Artinya, aplikasi tidak perlu lagi meminta izinWRITE_EXTERNAL_STORAGE
untuk menggunakan API ini. -
Banyak API platform kini mulai memeriksa payload besar yang dikirim
ke seluruh transaksi
Binder
, dan sistem kini menampilkan kembaliTransactionTooLargeExceptions
sebagaiRuntimeExceptions
, bukan melakukan logging secara diam-diam atau menyembunyikannya. Salah satu contoh umum adalah menyimpan terlalu banyak data diActivity.onSaveInstanceState()
, yang menyebabkanActivityThread.StopInfo
menampilkanRuntimeException
saat aplikasi menargetkan Android 7.0. -
Jika aplikasi memposting tugas
Runnable
keView
, danView
tidak terpasang ke jendela, sistem akan mengantrekan tugasRunnable
denganView
; tugasRunnable
tidak akan dijalankan hinggaView
terpasang ke jendela. Perilaku ini memperbaiki bug berikut: -
Jika aplikasi di Android 7.0 dengan
izin
DELETE_PACKAGES
mencoba menghapus paket, namun aplikasi lain telah menginstal paket tersebut, sistem akan memerlukan konfirmasi pengguna. Dalam skenario ini, aplikasi harus mengharapkanSTATUS_PENDING_USER_ACTION
sebagai status pengembalian saat memanggilPackageInstaller.uninstall()
. - Penyedia JCA yang disebut Crypto tidak digunakan lagi, karena satu-satunya algoritmenya, SHA1PRNG, lemah secara kriptografis. Aplikasi tidak dapat lagi menggunakan SHA1PRNG untuk (secara tidak aman) memperoleh kunci, karena penyedia ini tidak lagi tersedia. Untuk mengetahui informasi selengkapnya, lihat postingan blog Penyedia keamanan "Crypto" yang tidak digunakan lagi di Android N.