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 mendengarkanCONNECTIVITY_CHANGE
pada thread utama jika mereka meminta notifikasi denganBroadcastReceiver
. - Aplikasi tidak bisa mengirim atau menerima siaran
ACTION_NEW_PICTURE
atauACTION_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:
-
Izin file privat tidak boleh dianggap remeh oleh pemilik, dan usaha untuk melakukannya menggunakan
MODE_WORLD_READABLE
dan/atauMODE_WORLD_WRITEABLE
, akan memicu sebuahSecurityException
.Catatan: Seperti sebelumnya, pembatasan ini tidak sepenuhnya diterapkan. Aplikasi mungkin masih memodifikasi izin ke direktori privat mereka menggunakan API asli atau
File
API. Akan tetapi, kami sangat tidak menyarankan Anda meremehkan izin direktori privat. -
Meneruskan URI
file://
di luar domain paket dapat meninggalkan penerima dengan jalur yang tidak bisa di akses. Karena itu, upaya untuk meneruskan URIfile://
akan memicuFileUriExposedException
. Cara yang disarankan untuk berbagi materi file privat adalah menggunakanFileProvider
. -
DownloadManager
tidak bisa lagi berbagi file yang tersimpan secara privat berdasarkan nama file. Aplikasi lawas dapat mengakibatkan jalur yang tidak dapat diakses saat mengaksesCOLUMN_LOCAL_FILENAME
. Aplikasi yang menargetkan Android 7.0 atau yang lebih tinggi akan memicuSecurityException
saat berupaya mengaksesCOLUMN_LOCAL_FILENAME
. Aplikasi lawas yang menyetel lokasi unduhan ke lokasi publik dengan menggunakanDownloadManager.Request.setDestinationInExternalFilesDir()
atauDownloadManager.Request.setDestinationInExternalPublicDir()
tetap bisa mengakses jalur tersebut diCOLUMN_LOCAL_FILENAME
, akan tetapi, metode ini sangat tidak disarankan. Cara yang disukai untuk mengakses file yang diekspos olehDownloadManager
adalah menggunakanContentResolver.openFileDescriptor()
.
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
dangetJNIEnv
darilibandroid_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 privatproperty_get
darilibcutils.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
darilibcrypto.so
. Misalnya, Anda harus menautkanlibcyrpto.a
secara statistik dalam 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 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 melontarkanIllegalArgumentException
. - 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, metodeCreateUser()
dancreateAndInitializeUser()
tidak digunakan lagi; metodeDevicePolicyManager.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 nilainull
. - 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 olehDevicePolicyManager.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 dikembalikanENCRYPTION_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 indukDevicePolicyManager
; Anda bisa mendapatkan induknya dengan memanggilDevicePolicyManager.getParentProfileInstance()
. Jadi misalnya, jika Anda memanggil metodelockNow()
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 izinWRITE_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 kembaliTransactionTooLargeExceptions
sebagaiRuntimeExceptions
, sebagai ganti pembuatan log secara diam-diam atau menyembunyikannya. Satu contoh umum adalah menyimpan terlalu banyak data diActivity.onSaveInstanceState()
, yang menyebabkanActivityThread.StopInfo
melontarkanRuntimeException
bila aplikasi Anda menargetkan Android 7.0. -
Jika sebuah aplikasi mengeposkan tugas
Runnable
keView
, danView
tidak terpasang ke jendela, sistem akan mengantrekan tugasRunnable
denganView
; tugasRunnable
tidak akan dieksekusi hinggaView
terpasang ke jendela. Perilaku ini memperbaiki bug berikut: -
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 mengharapkanSTATUS_PENDING_USER_ACTION
sebagai status kembalian bila memanggilPackageInstaller.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.