Perubahan Perilaku Android 7.0

Bersama dengan fitur dan kemampuan baru, Android 7.0 mencakup berbagai perubahan perilaku sistem dan API. Dokumen ini menyoroti beberapa perubahan penting yang harus Anda pahami dan perhitungkan di aplikasi Anda.

Jika Anda sebelumnya telah memublikasikan aplikasi untuk Android, ketahuilah bahwa aplikasi tersebut mungkin terpengaruh oleh perubahan ini pada platform.

Baterai dan Memori

Android 7.0 menyertakan perubahan perilaku sistem yang bertujuan untuk meningkatkan daya tahan baterai perangkat dan mengurangi penggunaan RAM. Perubahan ini dapat memengaruhi akses aplikasi Anda ke sumber daya sistem, beserta cara aplikasi Anda berinteraksi dengan aplikasi lain melalui intent implisit tertentu.

Istirahatkan

Diperkenalkan di Android 6.0 (API level 23), Istirahatkan meningkatkan daya tahan baterai dengan menunda aktivitas CPU dan jaringan ketika pengguna tidak mencabut perangkat, tidak bergerak, dan dengan layar dimatikan. Android 7.0 membawa lebih banyak peningkatan pada fitur Istirahatkan dengan menerapkan subset pembatasan jaringan dan CPU saat perangkat dicabut dengan layar dimatikan, namun hal itu tidak selalu diam, misalnya, ketika {i>handset<i} dibawa ke dalam saku pengguna.

Ilustrasi tentang cara Istirahatkan menerapkan pembatasan aktivitas sistem untuk meningkatkan masa pakai baterai

Gambar 1. Ilustrasi tentang cara Istirahatkan menerapkan pembatasan aktivitas sistem untuk meningkatkan masa pakai baterai.

Saat perangkat sedang menggunakan daya baterai, dan layar telah mati selama beberapa waktu waktu, perangkat memasuki Istirahatkan dan menerapkan subset pembatasan pertama: mematikan akses jaringan aplikasi, serta menunda tugas dan sinkronisasi. Jika perangkat diam selama waktu tertentu setelah memasuki Istirahatkan, sistem akan menerapkan pembatasan Istirahatkan lainnya untuk PowerManager.WakeLock, AlarmManager alarm, GPS, dan pemindaian Wi-Fi. Terlepas dari apakah beberapa atau semua pembatasan Istirahatkan diterapkan, sistem akan membangunkan perangkat untuk masa pemeliharaan singkat, selama aplikasi diizinkan akses jaringan dan dapat mengeksekusi semua tugas/sinkronisasi yang ditangguhkan.

Ilustrasi tentang cara Istirahatkan menerapkan pembatasan aktivitas sistem setelah perangkat tidak bergerak selama waktu tertentu

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

Perhatikan bahwa mengaktifkan layar atau mencolokkan perangkat akan keluar dari Istirahatkan dan menghilangkan pembatasan pemrosesan ini. Perilaku tambahan ini tidak memengaruhi rekomendasi dan praktik terbaik dalam menyesuaikan aplikasi dengan versi Istirahatkan diperkenalkan di Android 6.0 (API level 23), seperti yang dibahas dalam Mengoptimalkan untuk fitur Istirahatkan dan Aplikasi Standby. Anda masih harus mengikuti rekomendasi tersebut, seperti menggunakan Firebase Cloud Messaging (FCM) untuk mengirim dan menerima pesan, serta mulai merencanakan pembaruan 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 {i>broadcast <i}sering memulai aplikasi yang telah didaftarkan untuk mendengarkannya di latar belakang. Menghapus siaran ini bisa sangat menguntungkan perangkat performa 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 di manifes. Karena banyak aplikasi yang mendaftar untuk menerima siaran ini, satu {i>switch<i} jaringan dapat membuat mereka semua aktif dan memproses siaran di sekali.

Demikian pula, di 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 tersebut akan aktif untuk memproses siaran.

Untuk mengatasi masalah ini, Android 7.0 menerapkan hal berikut pengoptimalan:

Jika aplikasi Anda menggunakan salah satu intent ini, Anda harus menghapus dependensi pada file tersebut sesegera mungkin agar Anda dapat menargetkan perangkat Android 7.0 dengan baik. Framework Android menyediakan beberapa solusi untuk mengurangi kebutuhan siaran implisit ini. Misalnya, JobScheduler API menyediakan mekanisme yang tangguh untuk menjadwalkan operasi jaringan saat kondisi tertentu, seperti koneksi ke jaringan tidak berbayar, akan terpenuhi. Anda bahkan dapat menggunakan JobScheduler untuk merespons perubahan pada penyedia konten.

Untuk informasi selengkapnya tentang pengoptimalan latar belakang di Android 7.0 (level API 24) dan cara menyesuaikan aplikasi, lihat Latar belakang Pengoptimalan.

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 ukurannya atau eksistensinya. 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 eksposur URI file:// di luar aplikasi Anda. Jika sebuah intent berisi URI file keluar dari aplikasi Anda, aplikasi tersebut akan gagal dengan pengecualian FileUriExposedException.

Untuk berbagi file antar-aplikasi, Anda harus mengirim URI content:// dan memberikan izin akses sementara di URI. Cara termudah untuk memberikan izin ini adalah dengan menggunakan class FileProvider. Untuk informasi lebih lanjut tentang izin akses dan berbagi file, lihat Berbagi File.

Peningkatan Aksesibilitas

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

Zoom Layar

Android 7.0 memungkinkan pengguna menyetel Ukuran tampilan yang akan memperbesar atau mengecilkan semua elemen pada layar, sehingga meningkatkan aksesibilitas perangkat bagi pengguna dengan gangguan penglihatan. Pengguna tidak dapat memperbesar layar melewati layar minimum lebar sw320dp, yang merupakan lebar Nexus 4, yaitu ponsel ukuran sedang pada umumnya.

Layar yang menunjukkan ukuran tampilan perangkat yang menjalankan image sistem Android 7.0 yang tidak diperbesar
Layar menunjukkan efek peningkatan ukuran tampilan perangkat yang menjalankan image sistem Android 7.0

Gambar 3. Layar di sebelah kanan menampilkan efek meningkatkan ukuran tampilan perangkat yang menjalankan image sistem Android 7.0.

Bila kepadatan perangkat berubah, sistem akan memberi tahu aplikasi yang berjalan di cara berikut:

  • Jika aplikasi menargetkan API level 23 atau yang lebih rendah, sistem akan secara otomatis menghentikan semua proses latar belakangnya. Ini berarti bahwa jika pengguna beralih dari aplikasi tersebut untuk membuka layar Settings dan mengubah Setelan Ukuran tampilan, sistem akan menghentikan aplikasi dalam seperti pada situasi dengan memori rendah. Jika aplikasi memiliki latar depan proses, sistem memberi tahu proses tersebut tentang perubahan konfigurasi sebagai dijelaskan dalam Menangani Perubahan Runtime, sama seperti orientasi perangkat telah berubah.
  • Jika aplikasi menargetkan Android 7.0, semua prosesnya (latar depan dan latar belakang) akan diberi tahu tentang perubahan konfigurasi sebagai dijelaskan dalam Penanganan Perubahan Runtime.

Sebagian besar aplikasi tidak perlu melakukan perubahan apa pun 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 performanya memadai.
  • Saat konfigurasi perangkat berubah, update semua konfigurasi yang bergantung pada kepadatan informasi yang di-cache, seperti bitmap yang di-cache atau resource yang dimuat dari jaringan. Periksa perubahan konfigurasi saat aplikasi melanjutkan dari periode dijeda status.

    Catatan: Jika Anda meng-cache data yang bergantung pada konfigurasi, sebaiknya sertakan metadata yang relevan seperti layar yang sesuai atau kepadatan piksel untuk data tersebut. Menyimpan {i>metadata<i} ini memungkinkan Anda untuk memutuskan apakah Anda perlu me-refresh data yang di-cache setelah konfigurasi berubah.

  • Hindari menentukan dimensi dengan satuan px, karena satuan px tidak diskalakan dengan kepadatan layar. Sebagai gantinya, tentukan dimensi dengan filter independen kepadatan satuan piksel (dp).

Vision Settings di Setup Wizard

Android 7.0 menyertakan Vision Settings di layar Sambutan, yang memungkinkan pengguna siapkan setelan aksesibilitas berikut di perangkat baru: Gestur pembesaran, Ukuran font, Ukuran tampilan dan TalkBack. Perubahan ini meningkatkan visibilitas bug yang terkait dengan setelan layar yang berbeda. Kepada menilai dampak fitur ini, Anda harus menguji aplikasi dengan mengaktifkan setelan. Anda dapat menemukan setelan pada Setelan > Aksesibilitas.

Penautan Aplikasi NDK ke Pustaka Platform

Mulai Android 7.0, sistem mencegah aplikasi menautkan secara dinamis terhadap library non-NDK, yang dapat menyebabkan aplikasi Anda error. Perubahan pada bertujuan untuk menciptakan pengalaman aplikasi yang konsisten di seluruh update platform dan perangkat yang berbeda. Meskipun kode Anda mungkin tidak tertaut ke perpustakaan pribadi, ada kemungkinan bahwa perpustakaan statis pihak ketiga di bisa melakukannya. Oleh karena itu, semua developer harus memeriksa untuk memastikan bahwa aplikasi mereka tidak error pada perangkat yang menjalankan Android 7.0. Jika aplikasi Anda menggunakan kode native, Anda hanya boleh menggunakan API NDK publik.

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

  • Aplikasi Anda mengakses langsung pustaka platform privat. Sebaiknya update aplikasi Anda menyertakan salinan library tersebut sendiri atau menggunakan API NDK publik.
  • Aplikasi Anda menggunakan library pihak ketiga yang mengakses platform pribadi library. Meskipun Anda yakin aplikasi tidak mengakses library pribadi secara langsung, Anda masih harus menguji aplikasi untuk skenario ini.
  • Aplikasi Anda mereferensikan pustaka yang tidak disertakan dalam APK-nya. Sebagai contoh ini, ini bisa terjadi jika Anda mencoba menggunakan salinan OpenSSL milik Anda tetapi lupa memaketkannya dengan APK aplikasi Anda. Aplikasi dapat berjalan normal pada versi platform Android yang menyertakan libcrypto.so. Namun, aplikasi dapat mengalami error pada versi Android berikutnya yang tidak menyertakan library ini (seperti, Android 6.0 dan yang lebih baru). Untuk memperbaikinya, pastikan Anda memaketkan semua library non-NDK dengan APK Anda.

Aplikasi tidak boleh menggunakan library native yang tidak disertakan dalam NDK karena perubahan atau penghapusan antara versi Android yang berbeda. Tujuan beralih dari OpenSSL ke BoringSSL adalah contoh dari perubahan tersebut. Selain itu, karena tidak ada persyaratan kompatibilitas untuk library platform yang tidak termasuk dalam NDK, perangkat yang berbeda mungkin menawarkan level kompatibilitas mundur.

Untuk mengurangi dampak pembatasan ini terhadap merilis aplikasi, sekumpulan library yang melihat penggunaan secara signifikan—seperti libandroid_runtime.so, libcutils.so, libcrypto.so, dan libssl.so—untuk sementara dapat diakses di Android 7.0 (API level 24) untuk aplikasi yang menargetkan API level 23 atau 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 Anda melihat Anda harus mengupdate aplikasi agar menyertakan salinannya sendiri library atau hanya menggunakan NDK API publik. Rilis Android mendatang dapat membatasi penggunaan library pribadi sama sekali dan menyebabkan aplikasi Anda mengalami error.

Semua aplikasi menghasilkan kesalahan runtime ketika mereka memanggil API yang bukan publik maupun dapat diakses sementara. Hasilnya, System.loadLibrary dan dlopen(3) ditampilkan NULL, dan dapat menyebabkan aplikasi error. Anda harus meninjau kode aplikasi untuk menghapus penggunaan API platform pribadi dan menguji aplikasi Anda secara menyeluruh menggunakan perangkat atau emulator yang menjalankan Android 7.0 (API level 24). Jika Anda tidak yakin apakah aplikasi menggunakan library pribadi atau tidak, Anda dapat memeriksa logcat untuk mengidentifikasi error runtime.

Tabel berikut menjelaskan perilaku yang akan Anda lihat dari bergantung pada penggunaan library native pribadi dan API targetnya level (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 membuat peringatan atau kesalahan runtime. Misalnya, jika aplikasi Anda menargetkan API level 23 atau dan mencoba mengakses pustaka pribadi di perangkat yang menjalankan Android 7.0, Anda mungkin melihat peringatan yang serupa dengan berikut ini: 

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 mencoba mengakses API platform pribadi, tetapi tidak akan menyebabkan aplikasi error. Jika aplikasi menargetkan API level 24 atau yang lebih tinggi, namun, logcat menghasilkan error runtime dan aplikasi Anda mungkin 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 mungkin juga melihat output logcat ini jika aplikasi Anda menggunakan library pihak ketiga yang secara dinamis tertaut ke API platform pribadi. Alat readelf di Android 7.0DK memungkinkan Anda membuat daftar semua link bersama yang ditautkan secara dinamis library file .so tertentu dengan menjalankan perintah berikut: 

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

Mengupdate aplikasi Anda

Berikut adalah beberapa langkah yang dapat Anda ambil untuk memastikan aplikasi Anda tidak error saat update platform mendatang:

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

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

  • Gunakan versi lokal simbol SSL_ctrl dari libcrypto.so. Misalnya, Anda harus menautkan libcyrpto.a secara statis di file .so Anda, atau sertakan versi libcrypto.so yang ditautkan secara dinamis dari BoringSSL/OpenSSL dan kemas dalam APK.

Android for Work

Android 7.0 berisi perubahan untuk aplikasi yang menargetkan Android for Work, termasuk perubahan pada penginstalan sertifikat, reset sandi, pengguna sekunder pengelolaan, dan akses ke ID perangkat. Jika Anda membangun aplikasi untuk Android for Work, Anda harus meninjau perubahan ini dan memodifikasi aplikasi Anda.

  • Anda harus menginstal penginstal sertifikat yang didelegasikan sebelum DPC dapat menetapkan anotasi. Untuk aplikasi pemilik profil dan pemilik perangkat yang menargetkan Android 7.0 (API level 24), Anda harus menginstal penginstal sertifikat yang didelegasikan sebelum kebijakan perangkat panggilan pengontrol (DPC) DevicePolicyManager.setCertInstallerPackage(). Jika pemasang belum diinstal, sistem akan menampilkan IllegalArgumentException.
  • Pembatasan sandi reset untuk admin perangkat sekarang diterapkan ke profil pemilik situs. Admin perangkat tidak dapat lagi menggunakan DevicePolicyManager.resetPassword() untuk menghapus sandi atau mengubah yang sudah ditetapkan. Admin perangkat masih dapat menyetel sandi, tetapi hanya saat perangkat belum memiliki sandi, PIN, atau pola.
  • Pemilik perangkat dan profil dapat mengelola akun meskipun pembatasan atur. Pemilik perangkat dan pemilik profil dapat memanggil Account Management API meskipun pembatasan pengguna DISALLOW_MODIFY_ACCOUNTS diterapkan.
  • Pemilik perangkat bisa mengelola pengguna tambahan lebih mudah. Jika perangkat sedang berjalan dalam mode pemilik perangkat, pembatasan DISALLOW_ADD_USER akan otomatis diatur. Tindakan ini mencegah pengguna membuat akun sekunder yang tidak dikelola pelanggan. Selain itu, CreateUser() dan Metode createAndInitializeUser() tidak digunakan lagi; baru Metode DevicePolicyManager.createAndManageUser() menggantikannya.
  • Pemilik perangkat bisa mengakses identifier perangkat. Pemilik perangkat dapat mengakses Alamat MAC Wi-Fi perangkat, menggunakan DevicePolicyManager.getWifiMacAddress(). Jika Wi-Fi tidak pernah diaktifkan pada perangkat, metode ini akan menampilkan nilai null.
  • Setelan Mode Kerja mengontrol akses ke aplikasi kerja. Saat mode kerja nonaktif peluncur sistem akan menunjukkan bahwa aplikasi kerja tidak tersedia dengan membuat warnanya menjadi abu-abu. Mengaktifkan mode kerja lagi akan memulihkan perilaku normal.
  • Saat menginstal file PKCS #12 yang berisi rantai sertifikat klien dan kunci pribadi yang sesuai dari Settings UI, sertifikat CA di rantai tidak lagi diinstal ke penyimpanan kredensial tepercaya. Hal ini dapat tidak memengaruhi hasil KeyChain.getCertificateChain() saat aplikasi mencoba mengambil klien rantai sertifikat di lain waktu. Jika diperlukan, Sertifikat CA harus diinstal ke penyimpanan kredensial tepercaya melalui Settings UI secara terpisah, dengan Format yang dikodekan DER dengan ekstensi file .crt atau .cer.
  • Mulai Android 7.0, pendaftaran dan penyimpanan sidik jari dikelola dengan ukuran unit maksimum 1 MB per pengguna. Jika Klien Kebijakan Perangkat (DPC) pemilik profil menargetkan level API 23 (atau yang lebih rendah) di perangkat yang menjalankan Android 7.0 (level API 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 tinggi, pengguna dapat menetapkan sidik jari khusus untuk profil kerja dengan membuka Setelan > Keamanan > Keamanan profil kerja.
  • Status enkripsi baru ENCRYPTION_STATUS_ACTIVE_PER_USER adalah dikembalikan oleh DevicePolicyManager.getStorageEncryptionStatus(), menjadi menunjukkan bahwa enkripsi itu aktif dan kunci enkripsi terkait dengan . Status baru hanya dikembalikan jika DPC menargetkan API Level 24 dan yang lebih tinggi. Untuk aplikasi yang menargetkan API level sebelumnya, ENCRYPTION_STATUS_ACTIVE ditampilkan, meskipun kunci enkripsi spesifik untuk pengguna atau profil tersebut.
  • Di Android 7.0, beberapa metode yang biasanya akan memengaruhi seluruh perangkat berfungsi secara berbeda jika perangkat telah menginstal profil kerja dengan tantangan kerja terpisah. Alih-alih memengaruhi seluruh perangkat, perubahan ini metode hanya berlaku untuk profil kerja. (Daftar lengkap metode tersebut adalah dalam dokumentasi DevicePolicyManager.getParentProfileInstance().) Misalnya, DevicePolicyManager.lockNow() hanya mengunci profil kerja, bukan mengunci seluruh perangkat. Untuk setiap metode ini, Anda bisa mendapatkan dengan memanggil metode pada instance induk DevicePolicyManager; Anda bisa mendapatkan orang tua ini dengan memanggil DevicePolicyManager.getParentProfileInstance(). Misalnya, jika Anda memanggil lockNow() instance induk , seluruh perangkat dikunci.

Retensi Anotasi

Android 7.0 memperbaiki bug yang membuat visibilitas anotasi menjadi terabaikan. Masalah ini mengaktifkan runtime untuk mengakses anotasi yang seharusnya tidak kemampuan Anda. Anotasi ini termasuk:

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

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

Perubahan Konfigurasi Default TLS/SSL

Android 7.0 melakukan perubahan berikut pada konfigurasi TLS/SSL default digunakan oleh aplikasi untuk HTTPS dan traffic TLS/SSL lainnya:

  • Cipher suite RC4 kini dinonaktifkan.
  • Paket penyandian CHACHA20-POLY1305 kini diaktifkan.

Menonaktifkan RC4 secara default dapat menyebabkan kerusakan di HTTPS atau TLS/SSL konektivitas ketika server tidak menegosiasikan rangkaian penyandian modern. Perbaikan yang diutamakan adalah meningkatkan konfigurasi server untuk mengaktifkan serta rangkaian penyandian dan protokol yang lebih modern. Idealnya, TLSv1.2 dan AES-GCM harus diaktifkan, dan paket penyandian Forward Secrecy (ECDHE) harus diaktifkan dan disukai.

Alternatifnya adalah dengan memodifikasi aplikasi agar menggunakan SSLSocketFactory kustom untuk berkomunikasi dengan server. Tujuan factory harus didesain untuk membuat SSLSocket yang memiliki beberapa rangkaian penyandian yang dibutuhkan oleh server diaktifkan, selain rangkaian penyandian {i>default<i}.

Catatan: Perubahan ini tidak ada kaitannya dengan WebView.

Aplikasi yang menargetkan Android 7.0

Perubahan perilaku ini berlaku khusus bagi aplikasi yang menargetkan Android 7.0 (level API 24) atau yang lebih tinggi. Aplikasi yang dikompilasi untuk Android 7.0, atau menyetel targetSdkVersion ke Android 7.0 atau yang lebih tinggi harus memodifikasi aplikasi mereka untuk mendukung perilaku ini dengan benar, jika memungkinkan pada aplikasi.

Perubahan Serialisasi

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

Class yang mengimplementasikan Serializable dan tidak menentukan kolom serialVersionUID eksplisit dapat melihat perubahan pada serialVersionUID {i>default<i} mereka, yang akan menyebabkan pengecualian yang akan ditampilkan saat mencoba melakukan deserialisasi instance class yang diserialisasi pada versi sebelumnya atau diserialisasi oleh aplikasi yang menargetkan versi . Pesan error akan terlihat seperti ini: 

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

Perbaikan masalah ini memerlukan penambahan kolom serialVersionUID ke semua class yang terpengaruh dengan nilai stream classdesc serialVersionUID dari pesan error, mis. 1234 inci dalam kasus ini. Perubahan itu mematuhi semua rekomendasi praktik yang baik untuk menulis kode serialisasi dan akan berfungsi di semua versi Android.

{i>Bug<i} spesifik yang diperbaiki terkait dengan keberadaan listrik statis metode penginisialisasi, yaitu <clinit>. Menurut menentukan ada tidaknya metode penginisialisasi statis dalam akan memengaruhi serialVersionUID default yang dihitung untuk class tersebut. Sebelum perbaikan bug, penghitungan juga akan memeriksa kelas super untuk penginisialisasi statis jika class tidak memilikinya.

Untuk memperjelas, perubahan ini tidak memengaruhi aplikasi yang menargetkan API level 23 atau class yang lebih rendah yang memiliki kolom atau class serialVersionUID yang memiliki metode penginisialisasi statis.

Poin Penting Lainnya

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

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

    Aplikasi yang menargetkan Android 7.0 (API level 24) dan yang lebih tinggi tidak otomatis dihentikan saat terjadi perubahan kepadatan; namun, mereka mungkin masih merespons buruk terhadap perubahan konfigurasi.

  • Aplikasi pada Android 7.0 harus mampu menangani perubahan konfigurasi dengan baik, dan tidak akan error pada start berikutnya. Anda dapat memverifikasi perilaku aplikasi dengan mengubah ukuran font (Setelan > Tampilan > Ukuran font), lalu memulihkan aplikasi dari Recents.
  • Karena adanya bug pada 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. Umumnya, melakukan operasi jaringan pada thread utama adalah ide yang buruk karena operasi ini biasanya memiliki latensi tinggi yang menyebabkan ANR dan jank.
  • Kelompok metode Debug.startMethodTracing() sekarang ditetapkan secara default ke menyimpan {i>output<i} di direktori khusus paket Anda di penyimpanan bersama, bukan di tingkat teratas di 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 Binder transaksi, dan sistem sekarang menampilkan kembali TransactionTooLargeExceptions sebagai RuntimeExceptions, bukan secara otomatis mencatat atau menyembunyikannya. paket Premium AI Contoh umumnya adalah menyimpan terlalu banyak data di Activity.onSaveInstanceState(), yang menyebabkan ActivityThread.StopInfo menampilkan RuntimeException jika aplikasi Anda menargetkan Android 7.0.
  • Jika aplikasi memposting tugas Runnable ke View, dan View tidak terpasang ke jendela, maka sistem mengantrekan tugas Runnable dengan View; tugas Runnable tidak akan dijalankan sampai View dilampirkan ke jendela. Perilaku ini memperbaiki bug berikut:
    • Jika aplikasi memposting ke View dari thread selain yang dimaksud UI thread jendela, Runnable dapat berjalan di thread yang salah akibatnya.
    • Jika tugas Runnable diposting dari rangkaian pesan selain thread looper, aplikasi dapat mengekspos tugas Runnable.
  • Jika aplikasi pada Android 7.0 dengan DELETE_PACKAGES izin akses mencoba menghapus sebuah paket, tetapi aplikasi lain telah menginstal paket itu, sistem memerlukan konfirmasi pengguna. Dalam skenario ini, aplikasi harus memperkirakan STATUS_PENDING_USER_ACTION sebagai status pengembalian saat mereka memanggil PackageInstaller.uninstall().
  • Penyedia JCA bernama Crypto tidak digunakan lagi, karena hanya SHA1PRNG, secara kriptografis lemah. Aplikasi tidak dapat digunakan lagi SHA1PRNG untuk (secara tidak aman) memperoleh kunci, karena penyedia ini tidak lagi yang tersedia. Untuk informasi selengkapnya, lihat blog posting Security "Crypto" penyedia tidak digunakan lagi di Android T.