Perubahan Perilaku Android 7.0

Bersama fitur dan kemampuan baru, Android 7.0 menyertakan berbagai macam perubahan sistem dan perilaku API. Dokumen ini menyoroti beberapa perubahan utama yang harus dipahami dan diperhitungkan dalam aplikasi Anda.

Jika Anda sebelumnya telah memublikasikan aplikasi untuk Android, ketahuilah bahwa aplikasi Anda mungkin akan 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 daya tahan baterai dengan menangguhkan aktivitas CPU dan jaringan saat pengguna tidak mencabut perangkat, tidak bergerak, dan layar dinonaktifkan. Android 7.0 lebih menyempurnakan fitur Istirahatkan dengan menerapkan subset CPU dan pembatasan jaringan saat perangkat dicabut dan layar dinonaktifkan, tetapi tidak harus diam, misalnya, saat handset dibawa bepergian di saku pengguna.

Ilustrasi tentang cara Istirahatkan menerapkan pembatasan aktivitas sistem level pertama untuk meningkatkan daya tahan baterai

Gambar 1. Ilustrasi tentang cara Istirahatkan menerapkan pembatasan aktivitas sistem level pertama untuk meningkatkan daya tahan baterai.

Saat perangkat menggunakan daya baterai, dan layar telah nonaktif selama jangka waktu tertentu, perangkat akan memasuki mode Istirahatkan dan menerapkan subset pembatasan pertama: Perangkat akan menutup akses jaringan aplikasi, serta menangguhkan tugas dan sinkronisasi. Jika perangkat diam selama jangka waktu tertentu setelah memasuki mode Istirahatkan, sistem akan menerapkan pembatasan Istirahatkan selebihnya ke PowerManager.WakeLock, alarm AlarmManager, GPS, dan pemindaian Wi-Fi. Terlepas dari apakah sebagian atau semua pembatasan Istirahatkan diterapkan, sistem akan membangunkan perangkat selama jeda pemeliharaan singkat, dan selama itu aplikasi diizinkan mengakses jaringan dan dapat mengeksekusi semua tugas/sinkronisasi yang telah ditangguhkan.

Ilustrasi tentang cara Istirahatkan menerapkan pembatasan aktivitas sistem level kedua setelah perangkat diam selama jangka waktu tertentu

Gambar 2. Ilustrasi tentang cara Istirahatkan menerapkan pembatasan aktivitas sistem level kedua setelah perangkat diam selama jangka waktu tertentu.

Perhatikan, mengaktifkan layar atau mencolokkan perangkat akan keluar dari mode Istirahatkan dan menghilangkan pembatasan 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 untuk 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 Doze 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. Membuang siaran ini bisa sangat menguntungkan kinerja 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 dalam konektivitas dengan mendaftarkan penerima untuk siaran CONNECTIVITY_ACTION implisit dalam manifesnya. Karena banyak aplikasi yang didaftarkan untuk menerima siaran ini, satu tombol jaringan dapat menyebabkan semuanya aktif dan memproses siaran tersebut secara bersamaan.

Demikian pula, dalam Android versi 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, semua aplikasi ini akan aktif untuk memproses siaran.

Untuk meminimalkan masalah ini, Android 7.0 menerapkan optimalisasi berikut:

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, seperti koneksi ke jaringan tidak berbayar. Anda bahkan dapat menggunakan JobScheduler untuk bereaksi terhadap perubahan pada penyedia konten.

Untuk 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:

Berbagi File Antar Aplikasi

Untuk aplikasi yang menargetkan Android 7.0, framework Android menerapkan kebijakan StrictMode API yang melarang mengekspos URI file:// di luar aplikasi Anda. Jika intent yang berisi URI file keluar dari aplikasi Anda, 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 mengenai izin dan berbagi file, lihat Berbagi File.

Peningkatan Aksesibilitas

Android 7.0 menyertakan perubahan yang bertujuan untuk meningkatkan kegunaan platform bagi pengguna dengan gangguan penglihatan atau rendah. Perubahan ini umumnya tidak memerlukan perubahan kode di aplikasi Anda, tetapi Anda harus meninjau fitur ini dan mengujinya dengan aplikasi Anda untuk menilai potensi dampaknya terhadap pengalaman pengguna.

Zoom Layar

Android 7.0 memungkinkan pengguna menyetel Ukuran tampilan yang memperbesar atau memperkecil semua elemen pada layar, sehingga meningkatkan aksesibilitas perangkat bagi pengguna yang kurang melihat. Pengguna tidak dapat memperbesar layar melebihi lebar layar minimum sw320dp, yang merupakan lebar Nexus 4, ponsel ukuran sedang pada umumnya.

Layar yang menampilkan ukuran tampilan perangkat yang tidak diperbesar yang menjalankan image sistem Android 7.0
Layar yang menampilkan efek penambahan ukuran layar perangkat yang menjalankan image sistem Android 7.0

Gambar 3. Layar di sebelah kanan menampilkan efek penambahan Display size 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 secara otomatis akan mematikan semua proses latar belakangnya. Artinya, jika pengguna beralih dari aplikasi tersebut untuk membuka layar Settings dan mengubah setelan Display size, sistem akan mematikan aplikasi dengan cara yang sama seperti saat memori tinggal sedikit. 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 mengenai perubahan konfigurasi seperti 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 pada perangkat dengan lebar layar sw320dp dan pastikan aplikasi berjalan dengan semestinya.
  • Ketika 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, ada baiknya untuk menyertakan metadata yang relevan seperti ukuran layar atau kepadatan piksel yang sesuai untuk data tersebut. Menyimpan metadata ini memungkinkan Anda memutuskan apakah perlu memuat ulang data cache setelah perubahan konfigurasi.

  • Hindari menetapkan dimensi dengan satuan px, karena satuan ini tidak diskalakan dengan kepadatan layar. Sebagai gantinya, tetapkan dimensi dengan satuan piksel yang tidak bergantung kepadatan (dp).

Vision Settings di Setup Wizard

Android 7.0 menyertakan Vision Settings di layar Sambutan, tempat pengguna dapat menyiapkan setelan aksesibilitas berikut di perangkat baru: Gerakan untuk memperbesar, Ukuran font, Ukuran layar, dan TalkBack. Perubahan ini meningkatkan visibilitas bug terkait dengan setelan layar yang berbeda. 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, sehingga dapat menyebabkan aplikasi Anda mogok. Perubahan perilaku ini bertujuan untuk menciptakan pengalaman aplikasi yang konsisten di seluruh update platform dan perangkat yang berbeda. Meskipun kode Anda mungkin tidak menautkan ke library pribadi, mungkin saja library statis pihak ketiga di aplikasi Anda bisa melakukannya. Oleh karena itu, semua developer harus memeriksa untuk memastikan bahwa aplikasi mereka tidak mengalami error di perangkat yang menjalankan Android 7.0. Jika aplikasi Anda menggunakan kode native, Anda hanya boleh menggunakan NDK API publik.

Ada tiga cara yang mungkin digunakan aplikasi Anda untuk mencoba mengakses API platform privat:

  • Aplikasi Anda mengakses langsung pustaka platform privat. Anda harus mengupdate aplikasi agar menyertakan salinan library tersebut sendiri atau menggunakan API NDK 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 sendiri, tetapi lupa membundelnya dengan APK aplikasi Anda. Aplikasi dapat berjalan seperti biasa pada 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 membundel semua library non-NDK dengan APK Anda.

Aplikasi tidak boleh menggunakan library native yang tidak disertakan dalam NDK karena library tersebut dapat berubah atau dihapus di antara versi-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 pula.

Untuk mengurangi dampak pembatasan ini pada aplikasi yang baru dirilis, sekumpulan library yang memperlihatkan 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 di perangkat target untuk memberi tahu Anda. Jika melihat peringatan ini, Anda harus mengupdate aplikasi agar menyertakan salinan pustakanya sendiri atau hanya menggunakan NDK API publik. Rilis platform Android mendatang mungkin akan membatasi penggunaan library pribadi secara keseluruhan dan menyebabkan aplikasi Anda mogok.

Semua aplikasi menghasilkan error runtime saat memanggil API yang tidak bersifat publik atau tidak dapat diakses untuk sementara. Akibatnya, System.loadLibrary dan dlopen(3) akan 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 (API level 24). Jika tidak yakin apakah aplikasi menggunakan library pribadi, Anda dapat memeriksa logcat untuk mengidentifikasi error runtime.

Tabel berikut menjelaskan perilaku yang seharusnya Anda lihat dari aplikasi, bergantung pada penggunaannya atas library native pribadi dan level API targetnya (android:targetSdkVersion).

Library Tingkat API target Akses waktu proses lewat linker dinamis Perilaku Android 7.0 (API level 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 mungkin 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 akan 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 pustaka mana yang sedang mencoba mengakses API platform pribadi, tetapi tidak akan menyebabkan aplikasi Anda mogok. Namun, jika aplikasi menargetkan API level 24 atau yang lebih tinggi, logcat akan menghasilkan error runtime berikut dan aplikasi Anda dapat mengalami 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 akan melihat output logcat ini jika aplikasi Anda menggunakan library pihak ketiga yang secara dinamis menautkan ke API platform privat. Alat readelf di Android 7.0DK memungkinkan Anda membuat daftar semua library bersama yang ditautkan secara dinamis dari file .so tertentu dengan menjalankan perintah berikut: 

aarch64-linux-android-readelf -dW libMyLibrary.so

Mengupdate aplikasi Anda

Berikut beberapa langkah yang dapat Anda lakukan untuk memperbaiki jenis error ini dan memastikan aplikasi Anda tidak error pada update platform mendatang:

  • Jika aplikasi Anda menggunakan library platform pribadi, Anda harus mengupdatenya untuk menyertakan salinan library-nya sendiri atau menggunakan NDK API publik.
  • Jika aplikasi Anda menggunakan library pihak ketiga yang mengakses simbol pribadi, hubungi pembuat library untuk mengupdate library.
  • Pastikan Anda mengemas semua pustaka non-NDK bersama APK.
  • Gunakan fungsi JNI standar sebagai ganti getJavaVM dan getJNIEnv dari libandroid_runtime.so: 
    AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from <jni.h>.
  • Gunakan __system_property_get, bukan simbol property_get pribadi dari libcutils.so. Untuk melakukannya, gunakan __system_property_get dengan menyertakan yang berikut: 
    #include <sys/system_properties.h>

    Catatan: Ketersediaan dan isi properti sistem tidak diuji melalui CTS. Perbaikan yang lebih baik adalah menghindari penggunaan properti ini secara keseluruhan.

  • Gunakan versi lokal simbol SSL_ctrl dari libcrypto.so. Misalnya, Anda harus menautkan libcyrpto.a secara statis dalam file .so, atau menyertakan versi libcrypto.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, manajemen pengguna tambahan, dan akses ke ID perangkat. Jika Anda mem-build 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 menetapkannya. Untuk aplikasi pemilik profil dan pemilik perangkat yang menargetkan Android 7.0 (API level 24), Anda harus menginstal pemasang sertifikat yang didelegasikan sebelum pengontrol kebijakan perangkat (DPC) memanggil DevicePolicyManager.setCertInstallerPackage(). Jika penginstal belum diinstal, sistem akan menampilkan IllegalArgumentException.
  • Pembatasan sandi penyetelan ulang untuk admin perangkat sekarang diterapkan kepada pemilik profil. Admin perangkat tidak dapat lagi menggunakan DevicePolicyManager.resetPassword() untuk menghapus sandi atau mengubah sandi yang sudah ditetapkan. Admin perangkat masih dapat menyetel sandi, tetapi hanya jika perangkat belum memiliki sandi, PIN, atau pola.
  • Pemilik perangkat dan profil dapat mengelola akun meskipun pembatasan telah 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. Saat perangkat berjalan dalam mode pemilik perangkat, pembatasan DISALLOW_ADD_USER akan otomatis ditetapkan. Tindakan ini mencegah pengguna membuat pengguna tambahan yang tidak terkelola. Selain itu, metode CreateUser() dan createAndInitializeUser() tidak digunakan lagi; metode DevicePolicyManager.createAndManageUser() yang baru akan 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 pada perangkat, metode ini akan menampilkan nilai null.
  • Setelan Mode Kerja mengontrol akses ke aplikasi kerja. Jika mode kerja nonaktif, peluncur sistem akan menunjukkan bahwa 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 sesuai dari UI Setelan, sertifikat CA di rantai tersebut tidak lagi diinstal ke penyimpanan kredensial tepercaya. Hal ini tidak memengaruhi hasil KeyChain.getCertificateChain() saat aplikasi mencoba mengambil rantai sertifikat klien nanti. Jika diperlukan, sertifikat CA harus diinstal ke penyimpanan kredensial tepercaya melalui UI Setelan secara terpisah, dengan format berenkode DER menggunakan ekstensi file .crt atau .cer.
  • Mulai Android 7.0, pendaftaran dan penyimpanan sidik jari dikelola per pengguna. Jika Klien Kebijakan Perangkat (DPC) pemilik profil menargetkan API level 23 (atau lebih rendah) di perangkat yang menjalankan Android 7.0 (API level 24), pengguna masih 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 menetapkan sidik jari secara khusus untuk profil kerja dengan membuka Setelan > Keamanan > Keamanan profil kerja.
  • Status enkripsi baru ENCRYPTION_STATUS_ACTIVE_PER_USER ditampilkan oleh DevicePolicyManager.getStorageEncryptionStatus(), untuk menunjukkan bahwa enkripsi sedang aktif dan kunci enkripsi dikaitkan 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 spesifik untuk pengguna atau profil tersebut.
  • Di Android 7.0, beberapa metode yang biasanya akan memengaruhi seluruh perangkat berperilaku berbeda jika perangkat memiliki profil kerja yang diinstal dengan tantangan kerja terpisah. Daripada 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 mendapatkan perilaku lama dengan memanggil metode pada instance induk DevicePolicyManager; Anda bisa mendapatkan induk ini dengan memanggil DevicePolicyManager.getParentProfileInstance(). Jadi, misalnya, jika Anda memanggil metode lockNow() 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 dilakukan. Anotasi ini termasuk:

  • VISIBILITY_BUILD: Dimaksudkan agar hanya bisa terlihat pada waktu build.
  • VISIBILITY_SYSTEM: Dimaksudkan agar terlihat pada runtime, tetapi hanya pada sistem yang mendasarinya.

Jika aplikasi Anda mengandalkan perilaku ini, tambahkan kebijakan retensi untuk anotasi yang harus tersedia di waktu proses. Anda melakukannya dengan menggunakan @Retention(RetentionPolicy.RUNTIME).

Perubahan Konfigurasi Default TLS/SSL

Android 7.0 membuat 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 pada konektivitas HTTPS atau TLS/SSL saat server tidak menegosiasikan cipher suite modern. Perbaikan yang direkomendasikan adalah meningkatkan konfigurasi server untuk memungkinkan protokol dan cipher suite yang lebih kuat dan lebih modern. Idealnya, TLSv1.2 dan AES-GCM harus diaktifkan, dan paket penyandian Forward Secrecy (ECDHE) harus diaktifkan dan diutamakan.

Alternatifnya adalah memodifikasi aplikasi agar menggunakan SSLSocketFactory kustom untuk berkomunikasi dengan server. Pabrik harus didesain untuk membuat instance SSLSocket yang memiliki beberapa cipher suite yang diperlukan oleh server yang telah diaktifkan selain cipher suite default.

Catatan: Perubahan ini tidak ada kaitannya 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 baru. 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 berlaku untuk aplikasi.

Perubahan Serialisasi

Android 7.0 (API level 24) memperbaiki bug dalam penghitungan serialVersionUID default yang tidak cocok dengan spesifikasi.

Class yang mengimplementasikan Serializable dan tidak menentukan kolom serialVersionUID eksplisit dapat melihat perubahan pada serialVersionUID default yang akan menyebabkan pengecualian ditampilkan saat mencoba mendeserialisasi 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 terbaik untuk menulis kode serialisasi dan akan berfungsi di semua versi Android.

Bug tertentu yang diperbaiki terkait dengan keberadaan metode penginisialisasi statis, yaitu <clinit>. Menurut spesifikasi, keberadaan atau tidak adanya metode penginisialisasi statis di class akan memengaruhi serialVersionUID default yang dihitung untuk class tersebut. Sebelum perbaikan bug, penghitungan 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 yang lebih rendah, class yang memiliki kolom serialVersionUID, atau class yang memiliki metode penginisialisasi statis.

Poin Penting Lainnya

  • Saat aplikasi berjalan di Android 7.0, tetapi menargetkan API level yang lebih rendah, dan pengguna mengubah ukuran tampilan, proses aplikasi akan dihentikan. Aplikasi harus dapat menangani skenario ini dengan baik. Jika tidak, error akan error saat pengguna memulihkannya dari Recents.

    Anda harus menguji aplikasi untuk memastikan perilaku ini tidak terjadi. Anda dapat melakukannya dengan menyebabkan error yang identik saat menghentikan aplikasi secara manual melalui DDMS.

    Aplikasi yang menargetkan Android 7.0 (API level 24) dan yang lebih tinggi tidak otomatis dimatikan saat perubahan kepadatan; akan tetapi, aplikasi tersebut mungkin tetap merespons perubahan konfigurasi dengan buruk.

  • Aplikasi pada Android 7.0 harus mampu menangani perubahan konfigurasi dengan lancar, dan tidak boleh mengalami error saat dimulai kembali. 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 menampilkan android.os.NetworkOnMainThreadException. Secara umum, menjalankan operasi jaringan di thread utama adalah ide yang buruk karena operasi ini biasanya memiliki latensi tinggi yang menyebabkan ANR dan jank.
  • Kelompok metode Debug.startMethodTracing() kini secara default menyimpan output di direktori khusus paket Anda di penyimpanan bersama, bukan di level teratas kartu SD. Artinya, aplikasi tidak perlu lagi meminta izin WRITE_EXTERNAL_STORAGE untuk menggunakan API ini.
  • Banyak API platform yang kini mulai memeriksa payload besar yang dikirim di seluruh transaksi Binder, dan sistem kini menampilkan kembali TransactionTooLargeExceptions sebagai RuntimeExceptions, bukan mencatat atau menyembunyikannya secara otomatis ke dalam log. Satu contoh umum adalah menyimpan terlalu banyak data di Activity.onSaveInstanceState(), yang menyebabkan ActivityThread.StopInfo menampilkan RuntimeException saat aplikasi Anda menargetkan Android 7.0.
  • Jika aplikasi memposting tugas Runnable ke View, dan View tidak terpasang ke jendela, sistem akan mengantrekan tugas Runnable dengan View; tugas Runnable tidak akan dieksekusi hingga View terpasang ke jendela. Perilaku ini memperbaiki bug berikut:
    • Akibatnya, jika aplikasi memposting ke View dari thread selain UI thread jendela yang dimaksud, maka Runnable dapat berjalan di thread yang salah.
    • Jika tugas Runnable diposting dari thread selain thread looper, aplikasi dapat mengekspos tugas Runnable.
  • Jika aplikasi di Android 7.0 dengan izin DELETE_PACKAGES mencoba menghapus paket, tetapi aplikasi lain telah menginstal paket tersebut, sistem akan memerlukan konfirmasi pengguna. Dalam skenario ini, aplikasi harus mengharapkan STATUS_PENDING_USER_ACTION sebagai status kembalian saat memanggil PackageInstaller.uninstall().
  • Penyedia JCA yang disebut Crypto tidak digunakan lagi, karena algoritmenya yang satu-satunya, SHA1PRNG, secara kriptografis lemah. 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 "Crypto" keamanan tidak digunakan lagi di Android N.