Perubahan Perilaku Android 7.0

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

Jika Anda sebelumnya telah mempublikasikan 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 daya tahan baterai perangkat dan mengurangi penggunaan RAM. Perubahan ini bisa memengaruhi akses aplikasi Anda ke sumber daya sistem, termasuk cara aplikasi Anda berinteraksi dengan aplikasi lain melalui maksud implisit tertentu.

Istirahatkan

Diperkenalkan dalam Android 6.0 (API level 23), Istirahatkan meningkatkan daya tahan baterai dengan menangguhkan aktivitas CPU dan jaringan bila pengguna tidak mencabut perangkat, tidak bergerak, dan layar dinonaktifkan. Android 7.0 menyempurnakan lebih jauh Istirahatkan dengan menerapkan subset CPU dan pembatasan jaringan bila perangkat dicabut dan layar dinonaktifkan, namun tidak harus diam, misalnya, bila handset dibawa bepergian di saku pengguna.

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

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

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

Perhatikan, mengaktifkan layar atau mencolokkan steker perangkat akan keluar dari Istirahatkan dan membuang pembatasan pemrosesan ini. Perilaku tambahan ini tidak memengaruhi saran dan praktik terbaik dalam menyesuaikan aplikasi Anda dengan versi Istirahatkan sebelumnya yang diperkenalkan dalam Android 6.0 (API level 23), seperti yang dibahas di Mengoptimalkan untuk Istirahatkan dan Aplikasi Siaga. Anda tetap harus mengikuti saran itu, seperti menggunakan Google Cloud Messaging (GCM) untuk mengirim dan menerima pesan, serta mulai merencanakan pembaruan guna mengakomodasi perilaku Istirahatkan tambahan.

Project Svelte: Optimalisasi Latar Belakang

Android 7.0 membuang tiga siaran implisit untuk membantu mengoptimalkan penggunaan memori dan konsumsi daya. Perubahan ini penting karena siaran implisit sering memulai aplikasi yang telah didaftarkan untuk mendengarkannya di latar belakang. Membuang siaran ini bisa sangat menguntungkan kinerja perangkat dan pengalaman pengguna.

Perangkat seluler sering kali mengalami perubahan konektivitas, seperti saat berpindah antara Wi-Fi dan data seluler. Saat ini, aplikasi bisa memantau perubahan dalam konektivitas dengan mendaftarkan suatu penerima untuk siaran implisit CONNECTIVITY_ACTION dalam manifes mereka. Karena banyak aplikasi yang didaftarkan untuk menerima siaran ini, switch jaringan tunggal bisa menyebabkan semuanya aktif dan memproses siaran tersebut secara bersamaan.

Demikian pula, dalam Android versi sebelumnya, aplikasi bisa mendaftar untuk menerima siaran implisit ACTION_NEW_PICTURE dan ACTION_NEW_VIDEO dari aplikasi lain, seperti Kamera. Bila pengguna mengambil gambar dengan aplikasi Kamera, semua aplikasi ini akan aktif untuk memproses siaran.

Untuk meminimalkan masalah ini, Android 7.0 menerapkan optimalisasi berikut:

  • Aplikasi yang menargetkan Android 7.0 tidak menerima siaran CONNECTIVITY_ACTION, sekalipun memiliki entri manifes untuk meminta notifikasi mengenai kejadian ini. Aplikasi yang berjalan tetap bisa mendengarkan CONNECTIVITY_CHANGE pada thread utama jika mereka meminta notifikasi dengan BroadcastReceiver.
  • Aplikasi tidak bisa mengirim atau menerima siaran ACTION_NEW_PICTURE atau ACTION_NEW_VIDEO. Optimalisasi ini memengaruhi semua aplikasi, bukan hanya aplikasi yang menargetkan Android 7.0.

Jika aplikasi menggunakan maksud ini, Anda harus membuang dependensi padanya secepat mungkin agar bisa menargetkan perangkat Android 7.0 dengan benar. Kerangka kerja Android menyediakan sejumlah solusi untuk mengurangi kebutuhan akan siaran implisit ini. Misalnya, JobScheduler API menyediakan mekanisme yang tangguh untuk menjadwalkan operasi jaringan bila ketentuan yang ditetapkan, seperti koneksi ke jaringan yang berbiaya tetap, terpenuhi. Anda bahkan bisa menggunakan JobScheduler untuk bereaksi terhadap perubahan pada penyedia materi.

Untuk informasi selengkapnya tentang optimalisasi latar belakang di N dan cara menyesuaikan aplikasi Anda, lihat Optimalisasi Latar Belakang.

Perubahan Izin

Android 7.0 menyertakan perubahan pada izin yang bisa memengaruhi aplikasi Anda.

Perubahan izin sistem file

Guna meningkatkan keamanan file privat, direktori privat aplikasi yang menargetkan Android 7.0 atau yang lebih tinggi memiliki akses terbatas (0700). Setelan ini mencegah kebocoran metadata file privat, seperti ukuran atau eksistensinya. Perubahan izin ini memiliki beberapa efek samping:

Berbagi File Antar Aplikasi

Untuk aplikasi yang menargetkan Android 7.0, kerangka kerja Android menerapkan kebijakan StrictMode API yang melarang mengekspos URI file:// di luar aplikasi Anda. Jika sebuah maksud berisi URI file meninggalkan aplikasi Anda, aplikasi tersebut 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 kelas FileProvider. Untuk informasi selengkapnya mengenai izin dan berbagi file, lihat Berbagi File.

Peningkatan Aksesibilitas

Android 7.0 menyertakan perubahan yang bertujuan meningkatkan kegunaan platform untuk pengguna dengan penglihatan yang rendah atau lemah. Perubahan ini umumnya tidak memerlukan perubahan kode dalam aplikasi, akan tetapi Anda harus memeriksa fitur ini dan mengujinya dengan aplikasi untuk menilai kemungkinan dampaknya terhadap pengalaman pengguna.

Zoom Layar

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

Gambar 3. Layar di sebelah kanan menampilkan efek penambahan Display size perangkat yang menjalankan citra sistem Android 7.0.

Bila 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 belakang. Artinya, jika pengguna beralih dari aplikasi tersebut untuk membuka layar Settings dan mengubah setelan Display size, maka sistem akan mematikan aplikasi tersebut dengan cara yang sama dengan situasi dengan memori minim. Jika aplikasi memiliki beberapa proses latar depan, sistem akan memberi tahu proses tersebut mengenai perubahan konfigurasi seperti yang dijelaskan dalam Menangani Perubahan Waktu Proses, seolah-olah orientasi perangkat telah berubah.
  • Jika sebuah aplikasi menargetkan Android 7.0, semua prosesnya (latar depan dan latar belakang) akan diberi tahu mengenai perubahan konfigurasi seperti yang dijelaskan dalam Menangani Perubahan Waktu Proses.

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 aplikasinya berjalan dengan semestinya.
  • Bila konfigurasi perangkat berubah, perbarui informasi cache yang bergantung pada kepadatan, seperti bitmap di cache atau sumber daya yang dimuat dari jaringan. Periksa perubahan konfigurasi bila aplikasi melanjutkan dari status dihentikan sementara.

    Catatan: 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 untuk memutuskan apakah perlu segarkan 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, di mana pengguna bisa mempersiapkan setelan aksesibilitas berikut pada perangkat baru: Magnification gesture, Font size, Display size dan TalkBack. Perubahan ini meningkatkan visibilitas bug terkait dengan setelan layar yang berbeda. Untuk mengurangi dampak fitur ini, Anda harus menguji aplikasi dengan setelan ini diaktifkan. Anda bisa menemukannya pada Settings > Accessibility.

Penautan Aplikasi NDK ke Pustaka Platform

Mulai Android 7.0, sistem mencegah aplikasi menautkan secara dinamis ke pustaka non-NDK, sehingga dapat menyebabkan aplikasi Anda mogok. Perubahan dalam perilaku ini bertujuan untuk menciptakan pengalaman aplikasi yang konsisten di semua pembaruan platform dan perangkat yang berbeda. Walaupun kode Anda mungkin tidak menautkan ke pustaka privat, mungkin saja pustaka statis pihak ketiga di aplikasi Anda bisa melakukannya. Karena itu, semua developer harus memeriksa untuk memastikan bahwa aplikasi mereka tidak mogok pada perangkat yang menjalankan Android 7.0. Jika aplikasi Anda menggunakan kode asli, Anda hanya boleh menggunakan NDK API publik.

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

  • Aplikasi Anda mengakses langsung pustaka platform privat. Anda harus memperbarui aplikasi agar menyertakan salinan pustakanya sendiri atau menggunakan NDK API publik.
  • Aplikasi Anda menggunakan pustaka pihak ketiga yang mengakses pustaka platform privat. Sekalipun yakin aplikasi Anda tidak mengakses pustaka privat 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 namun lupa membundelnya dengan APK aplikasi Anda. Aplikasi mungkin berjalan normal pada versi platform Android yang menyertakan libcrypto.so. Akan tetapi, aplikasi bisa mogok pada versi Android mendatang yang tidak menyertakan pustaka ini (misalnya, Android 6.0 dan yang lebih baru). Untuk memperbaikinya, pastikan Anda membundel pustaka non-NDK bersama APK Anda.

Aplikasi seharusnya tidak menggunakan pustaka asli yang tidak disertakan dalam NDK karena dapat berubah atau dihapus di antara versi-versi Android yang berbeda. Peralihan dari OpenSSL ke BoringSSL merupakan satu contoh dari perubahan semacam ini. Selain itu, karena tidak ada persyaratan kompatibilitas untuk pustaka platform yang tidak disertakan dalam NDK, perangkat yang berbeda mungkin menawarkan tingkat kompatibilitas yang berbeda pula.

Untuk mengurangi dampak pembatasan ini atas aplikasi yang dirilis saat ini, seperangkat pustaka yang melihat penggunaan signifikan—misalnya libandroid_runtime.so, libcutils.so, libcrypto.so, dan libssl.so—untuk sementara dapat diakses di N bagi aplikasi yang menargetkan API level 23 atau yang lebih rendah. Jika aplikasi Anda memuat salah satu pustaka ini, logcat akan menghasilkan peringatan dan toast akan muncul pada perangkat target untuk memberi tahu Anda. Jika melihat peringatan ini, Anda harus memperbarui aplikasi agar menyertakan salinan pustakanya sendiri atau hanya menggunakan NDK API publik. Rilis platform Android yang akan datang mungkin akan membatasi penggunaan pustaka privat bersama-sama dan menyebabkan aplikasi Anda mogok.

Semua aplikasi menghasilkan kesalahan waktu proses bila memanggil API yang bukan publik atau bisa diakses untuk sementara. Akibatnya System.loadLibrary dan dlopen(3) keduanya mengembalikan NULL, dan mungkin menyebabkan aplikasi Anda mogok. Anda harus memeriksa kode aplikasi untuk membuang penggunaan API platform privat dan secara saksama menguji aplikasi menggunakan perangkat pratinjau atau emulator. Jika tidak yakin apakah aplikasi menggunakan pustaka privat, Anda bisa memeriksa logcat untuk mengidentifikasi kesalahan waktu proses.

Tabel berikut menjelaskan perilaku yang seharusnya Anda lihat dari aplikasi, bergantung pada penggunaannya atas pustaka asli privat dan target API level (android:targetSdkVersion).

Pustaka Target API level Akses waktu proses lewat linker dinamis Perilaku N Developer Preview Perilaku Rilis N Final Perilaku platform Android mendatang
Publik NDK Apa saja Dapat diakses Bekerja sesuai harapan 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 dan pesan pada perangkat target. 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 Kesalahan waktu proses
Privat (lainnya) Apa saja Dibatasi Kesalahan waktu proses Kesalahan waktu proses Kesalahan waktu proses

Periksa apakah aplikasi Anda menggunakan pustaka privat

Untuk membantu Anda mengidentifikasi masalah saat memuat pustaka privat, logcat mungkin menghasilkan peringatan atau kesalahan waktu proses. Misalnya, jika aplikasi Anda menargetkan API level 23 atau yang lebih rendah, dan mencoba mengakses pustaka privat pada perangkat yang menjalankan Android 7.0, Anda mungkin akan 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 sedang mencoba mengakses API platform privat, namun tidak akan menyebabkan aplikasi Anda mogok. Jika aplikasi menargetkan API level 24 atau yang lebih tinggi, bagaimanapun juga, logcat akan menghasilkan kesalahan waktu proses berikut ini dan aplikasi Anda mungkin akan mogok: 

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 keluaran logcat ini juga aplikasi Anda menggunakan pustaka pihak ketiga yang secara dinamis menautkan ke API platform privat. Alat bantu readelf di Android 7.0 DK memungkinkan Anda membuat daftar semua pustaka bersama yang ditautkan secara dinamis atas file .so yang diberikan dengan menjalankan perintah berikut: 

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

Perbarui aplikasi Anda

Inilah beberapa langkah yang bisa Anda ambil untuk memperbaiki tipe kesalahan ini dan memastikan aplikasi Anda tidak mogok pada pembaruan platform di masa mendatang:

  • Jika aplikasi Anda menggunakan pustaka platform privat, Anda harus memperbaruinya agar menyertakan salinan pustakanya sendiri atau menggunakan NDK API publik.
  • Jika aplikasi Anda menggunakan pustaka pihak ketiga yang mengakses simbol privat, hubungi penulis pustaka tersebut untuk memperbarui pustaka.
  • 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 sebagai ganti simbol privat property_get dari libcutils.so. Caranya, gunakan __system_property_get dengan menyertakan yang berikut: 
    #include <sys/system_properties.h>

    Catatan: Ketersediaan dan isi properti sistem belum diuji melalui CTS. Perbaikan yang lebih bagus adalah menghindari penggunaan properti ini bersama-sama.

  • Gunakan versi lokal dari simbol SSL_ctrl dari libcrypto.so. Misalnya, Anda harus menautkan libcyrpto.a secara statistik 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 pemasangan sertifikat, penyetelan ulang sandi, manajemen pengguna tambahan, dan akses ke identifier perangkat. Jika membangun aplikasi untuk lingkungan Android for Work, Anda harus meninjau perubahan ini dan memodifikasi aplikasi sebagaimana mestinya.

  • Anda harus memasang pemasang sertifikat yang didelegasikan sebelum DPC bisa menyetelnya. Untuk aplikasi pemilik profil dan pemilik perangkat yang menargetkan N SDK, Anda harus memasang pemasang sertifikat yang didelegasikan sebelum Pengontrol Kebijakan Perangkat (Device Policy Controller/DPC) memanggil DevicePolicyManager.setCertInstallerPackage(). Jika pemasang belum dipasang, sistem akan melontarkan IllegalArgumentException.
  • Pembatasan sandi penyetelan ulang untuk administrator perangkat sekarang diterapkan ke pemilik profil. Administrator perangkat tidak bisa lagi menggunakan DevicePolicyManager.resetPassword() untuk menghapus sandi atau mengubah sandi yang sudah disetel. Administrator perangkat tetap bisa menyetel sandi, namun hanya bila perangkat belum memiliki sandi, PIN, atau pola.
  • Pemilik profil dan perangkat bisa mengelola akun meskipun pembatasan telah disetel. Pemilik perangkat dan pemilik profil bisa memanggil Account Management API sekalipun pembatasan pengguna DISALLOW_MODIFY_ACCOUNTS diberlakukan.
  • Pemilik perangkat bisa mengelola pengguna tambahan lebih mudah. Bila perangkat berjalan dalam mode pemilik perangkat, maka pembatasan DISALLOW_ADD_USER secara otomatis akan disetel. Ini akan mencegah pengguna membuat pengguna tambahan yang tidak terkelola. Selain itu, metode CreateUser() dan createAndInitializeUser() tidak digunakan lagi; metode DevicePolicyManager.createAndManageUser() telah menggantikannya.
  • Pemilik perangkat bisa mengakses identifier perangkat. Pemilik perangkat bisa mengakses alamat MAC Wi-Fi perangkat, menggunakan DevicePolicyManagewr.getWifiMacAddress(). Jika Wi-Fi belum pernah diaktifkan pada perangkat tersebut, metode ini akan mengembalikan nilai null.
  • Setelan Mode Kerja mengontrol akses ke aplikasi kerja. Bila 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 memasang file PKCS #12 berisi rantai sertifikat klien dan kunci privat yang bersangkutan dari Settings UI, sertifikat CA di rantai tersebut tidak lagi dipasang ke storage kredensial tepercaya. Hal ini tidak memengaruhi hasil KeyChain.getCertificateChain() bila aplikasi berupaya mengambil rantai sertifikat klien belakangan. Jika diperlukan, sertifikat CA harus dipasang ke storage kredensial tepercaya lewat Settings UI secara terpisah, dengan format yang dikodekan dengan DER menggunakan ekstensi file .crt atau .cer.
  • Mulai Android 7.0, pendaftaran dan storage sidik jari dikelola per pengguna. Jika Klien Kebijakan Perangkat (Device Policy Client/DPC) pemilik profil menargetkan pre-N pada perangkat N, pengguna tetap bisa menyetel sidik jari di perangkat, namun aplikasi kerja tidak bisa mengakses sidik jari perangkat. Bila DPC menargetkan N dan versi yang lebih tinggi, pengguna bisa menyetel sidik jari secara spesifik untuk profil kerja dengan masuk ke Settings > Security > Work profile security.
  • Status enkripsi baru ENCRYPTION_STATUS_ACTIVE_PER_USER dikembalikan oleh DevicePolicyManager.getStorageEncryptionStatus(), untuk menunjukkan bahwa enkripsi sedang aktif dan kunci enkripsi dikaitkan ke pengguna. Status baru hanya dikembalikan jika DPC menargetkan API Level 24 dan yang lebih tinggi. Untuk aplikasi yang menargetkan API level sebelumnya, maka akan dikembalikan ENCRYPTION_STATUS_ACTIVE, sekalipun kunci enkripsi spesifik untuk pengguna atau profil tersebut.
  • Di Android 7.0, sejumlah metode yang biasanya akan memengaruhi keseluruhan perangkat ternyata berbeda perilakunya jika perangkat telah dipasangi profil kerja dengan pertanyaan kerja terpisah. Alih-alih memengaruhi keseluruhan perangkat, metode ini hanya berlaku pada profil kerja. (Daftar lengkap metode demikian ada dalam dokumentasi DevicePolicyManager.getParentProfileInstance().) Misalnya, DevicePolicyManager.lockNow() akan mengunci profil kerja saja, sebagai ganti mengunci keseluruhan perangkat. Untuk setiap metode ini, Anda bisa mendapatkan perilaku yang lama dengan memanggil metode pada instance induk DevicePolicyManager; Anda bisa mendapatkan induknya dengan memanggil DevicePolicyManager.getParentProfileInstance(). Jadi misalnya, jika Anda memanggil metode lockNow() instance induk, keseluruhan perangkat akan dikunci.

Untuk informasi selengkapnya tentang perubahan pada Android for Work di Android 7.0, lihat Pembaruan Android for Work.

Retensi Anotasi

Android 7.0 memperbaiki bug yang membuat visibilitas anotasi menjadi terabaikan. Masalah membuat waktu proses bisa mengakses anotasi yang seharusnya tidak bisa dilakukannya. Anotasi ini termasuk:

  • VISIBILITY_BUILD: Dimaksudkan agar hanya bisa terlihat pada waktu pembangunan.
  • VISIBILITY_SYSTEM: Dimaksud agar bisa terlihat pada waktu proses, namun hanya pada sistem yang mendasarinya.

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

Poin Penting Lainnya

  • Bila aplikasi berjalan pada Android 7.0, namun menargetkan API level yang lebih rendah, dan pengguna mengubah ukuran tampilan, proses aplikasi akan dimatikan. Aplikasi harus dapat menangani skenario ini dengan lancar. Jika tidak, maka aplikasi akan mogok bila pengguna memulihkannya dari Recents.

    Anda harus menguji aplikasi untuk memastikan bahwa perilaku ini tidak terjadi. Anda bisa melakukannya dengan menyebabkan mogok yang identik saat mematikan aplikasi secara manual lewat DDMS.

    Aplikasi yang menargetkan N dan yang di atasnya tidak secara 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 mogok saat dimulai selanjutnya. Anda bisa memverifikasi perilaku aplikasi dengan mengubah ukuran font (Setting > Display > Font size), kemudian memulihkan aplikasi dari Recents.
  • Dikarenakan adanya bug di Android versi 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 melontarkan android.os.NetworkOnMainThreadException. Secara umum, melakukan operasi jaringan di thread utama tidak baik karena operasi ini biasanya memiliki latensi tinggi yang menyebabkan ANR dan jank.
  • Kelompok metode Debug.startMethodTracing() kini menjadi default untuk keluaran storage di direktori paket tertentu pada penyimpanan bersama, sebagai ganti di level teratas kartu SD. Berarti aplikasi tidak perlu lagi meminta izin WRITE_EXTERNAL_STORAGE untuk menggunakan API ini.
  • Banyak platform API yang kini mulai memeriksa payload besar yang dikirim ke seluruh transaksi Binder, dan sistem kini melontarkan kembali TransactionTooLargeExceptions sebagai RuntimeExceptions, sebagai ganti pembuatan log secara diam-diam atau menyembunyikannya. Satu contoh umum adalah menyimpan terlalu banyak data di Activity.onSaveInstanceState(), yang menyebabkan ActivityThread.StopInfo melontarkan RuntimeException bila aplikasi Anda menargetkan Android 7.0.
  • Jika sebuah aplikasi mengeposkan 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:
    • Jika sebuah aplikasi mengeposkan ke View dari thread selain thread UI jendela yang dimaksud, maka Runnable mungkin akan menjalankan thread yang salah.
    • Jika tugas Runnable diposkan dari thread selain looper-thread, aplikasi bisa mengekspos tugas Runnable.
  • Jika sebuah aplikasi di Android 7.0 dengan izin DELETE_PACKAGES mencoba menghapus sebuah paket, namun sebuah aplikasi berbeda telah memasang paket itu, sistem akan memerlukan konfirmasi pengguna. Dalam skenario ini, aplikasi harus mengharapkan STATUS_PENDING_USER_ACTION sebagai status kembalian bila memanggil PackageInstaller.uninstall().
  • Penyedia JCA yang memanggil Crypto kini tidak digunakan lagi, karena ini hanya algoritme, SHA1PRNG, secara kritografik adalah lemah. Aplikasi tidak bisa lagi menggunakan SHA1PRNG untuk (secara tidak aman) memperoleh kunci, karena penyedia ini tidak lagi tersedia. Untuk informasi selengkapnya, lihat entri blog Security "Crypto" provider deprecated in Android N.