Halaman ini diterjemahkan oleh Cloud Translation API.

Perubahan Perilaku Android 5.0

API Level: 21

Bersama dengan fitur dan kemampuan baru, Android 5.0 menyertakan berbagai perubahan sistem dan perubahan perilaku API. Dokumen ini menyoroti beberapa perubahan utama yang harus Anda pahami dan pertimbangkan dalam aplikasi Anda.

Jika sebelumnya Anda telah memublikasikan aplikasi untuk Android, perhatikan bahwa aplikasi Anda mungkin akan terpengaruh oleh perubahan ini di Android 5.0.

Untuk melihat fitur platform baru secara umum, lihat sorotan Android Lollipop.

Video

Dev Byte: Yang Baru di Android 5.0

Byte Dev: Notifikasi

Android Runtime (ART)

Di Android 5,0 waktu proses ART menggantikan Dalvik sebagai default platform. Runtime ART diperkenalkan di Android 4.4 secara eksperimental.

Untuk ringkasan fitur baru ART, lihat Memperkenalkan ART. Beberapa fitur baru utama adalah:

Kompilasi mendahului-waktu (Ahead-of-Time/AOT)
Pengumpulan sampah (Garbage Collection/GC) yang ditingkatkan
Dukungan debug yang ditingkatkan

Sebagian besar aplikasi Android akan berfungsi begitu saja tanpa ada perubahan pada ART. Namun, beberapa teknik yang berfungsi di Dalvik tidak berfungsi di ART. Untuk informasi tentang masalah yang paling penting, lihat Memverifikasi Perilaku Aplikasi di Android Runtime (ART). Berikan perhatian khusus jika:

Aplikasi Anda menggunakan Antarmuka Bawaan Java (Java Native Interface/JNI) untuk menjalankan kode C/C++.
Anda menggunakan alat pengembangan yang menghasilkan kode non-standar (seperti beberapa obfuscator).
Anda menggunakan teknik yang tidak kompatibel dengan pengumpulan sampah yang dikompresi.

Notifikasi

Pastikan notifikasi Anda memperhitungkan perubahan Android 5.0 ini. Untuk mempelajari lebih lanjut cara mendesain notifikasi untuk Android 5.0 dan yang lebih baru, lihat panduan desain notifikasi.

Gaya desain material

Notifikasi digambar dengan teks gelap di atas latar belakang putih (atau sangat terang) agar cocok dengan widget desain material baru. Pastikan semua notifikasi Anda terlihat benar dengan skema warna baru. Jika notifikasi Anda terlihat salah, perbaiki:

Gunakan setColor() untuk menetapkan warna aksen dalam lingkaran di belakang gambar ikon Anda.
Perbarui atau buang aset yang melibatkan warna. Sistem mengabaikan semua saluran non-alpha di ikon tindakan dan di ikon notifikasi utama. Anda harus mengasumsikan bahwa ikon ini hanya akan berupa alfa. Sistem menggambar ikon notifikasi dalam warna putih dan ikon tindakan dalam warna abu-abu gelap.

Suara dan getaran

Jika saat ini Anda menambahkan suara dan getaran ke notifikasi dengan menggunakan class Ringtone, MediaPlayer, atau Vibrator, hapus kode ini agar sistem dapat menampilkan notifikasi dengan benar dalam mode prioritas. Sebagai gantinya, gunakan metode Notification.Builder untuk menambahkan suara dan getaran.

Menetapkan perangkat ke RINGER_MODE_SILENT akan menyebabkan perangkat memasuki mode prioritas baru. Perangkat akan keluar dari mode prioritas jika Anda menetapkannya ke RINGER_MODE_NORMAL atau RINGER_MODE_VIBRATE.

Sebelumnya, Android menggunakan STREAM_MUSIC sebagai streaming master untuk mengontrol volume di perangkat tablet. Di Android 5.0, streaming volume master untuk perangkat ponsel dan tablet kini disatukan, dan dikontrol oleh STREAM_RING atau STREAM_NOTIFICATION.

Visibilitas layar kunci

Secara default, notifikasi kini muncul di layar kunci pengguna di Android 5.0. Pengguna dapat memilih untuk melindungi informasi sensitif agar tidak terekspos. Dalam hal ini, sistem akan otomatis menyamarkan teks yang ditampilkan oleh notifikasi. Untuk menyesuaikan notifikasi yang disamarkan ini, gunakan setPublicVersion().

Jika notifikasi tidak berisi informasi pribadi, atau jika Anda ingin mengizinkan kontrol pemutaran media pada notifikasi, panggil metode setVisibility() dan tetapkan tingkat visibilitas notifikasi ke VISIBILITY_PUBLIC.

Pemutaran media

Jika Anda menerapkan notifikasi yang menampilkan status pemutaran media atau kontrol transpor, sebaiknya gunakan template Notification.MediaStyle baru, bukan objek RemoteViews.RemoteView kustom. Apa pun pendekatan yang Anda pilih, pastikan untuk menetapkan visibilitas notifikasi ke VISIBILITY_PUBLIC sehingga kontrol Anda dapat diakses dari layar kunci. Perhatikan bahwa mulai Android 5.0, sistem tidak lagi menampilkan objek RemoteControlClient di layar kunci. Untuk informasi selengkapnya, lihat Jika aplikasi Anda menggunakan RemoteControlClient.

Notifikasi pendahuluan

Notifikasi kini dapat muncul di jendela mengambang kecil (juga disebut notifikasi pemberitahuan) saat perangkat aktif (yaitu, perangkat tidak terkunci dan layarnya aktif). Notifikasi ini muncul mirip dengan bentuk ringkas notifikasi Anda, kecuali bahwa notifikasi pendahuluan juga menampilkan tombol tindakan. Pengguna dapat menindaklanjuti atau menutup notifikasi pemberitahuan tanpa keluar dari aplikasi saat ini.

Contoh-contoh kondisi yang dapat memicu notifikasi pendahuluan antara lain:

Aktivitas pengguna dalam mode layar penuh (aplikasi menggunakan fullScreenIntent)
Notifikasi memiliki prioritas tinggi dan menggunakan nada dering atau getaran

Jika aplikasi Anda menerapkan notifikasi dalam salah satu skenario tersebut, pastikan notifikasi peringatan dini ditampilkan dengan benar.

Kontrol Media dan RemoteControlClient

Class RemoteControlClient kini tidak digunakan lagi. Beralihlah ke MediaSession API baru sesegera mungkin.

Layar kunci di Android 5.0 tidak menampilkan kontrol transpor untuk MediaSession atau RemoteControlClient Anda. Sebagai gantinya, aplikasi Anda dapat menyediakan kontrol pemutaran media dari layar kunci melalui notifikasi. Hal ini memberi aplikasi Anda lebih banyak kontrol atas presentasi tombol media, sekaligus memberikan pengalaman yang konsisten bagi pengguna di seluruh perangkat yang terkunci dan terbuka kuncinya.

Android 5.0 memperkenalkan template Notification.MediaStyle baru untuk tujuan ini. Notification.MediaStyle mengonversi tindakan notifikasi yang Anda tambahkan dengan Notification.Builder.addAction() menjadi tombol ringkas yang disematkan dalam notifikasi pemutaran media aplikasi Anda. Teruskan token sesi Anda ke metode setSession() untuk memberi tahu sistem bahwa notifikasi ini mengontrol sesi media yang sedang berlangsung.

Pastikan untuk menetapkan visibilitas notifikasi ke VISIBILITY_PUBLIC untuk menandai notifikasi sebagai aman untuk ditampilkan di layar kunci apa pun (aman atau tidak). Untuk informasi selengkapnya, lihat Notifikasi layar kunci.

Untuk menampilkan kontrol pemutaran media jika aplikasi Anda berjalan di platform TV atau Wear Android, terapkan class MediaSession. Anda juga harus menerapkan MediaSession jika aplikasi Anda perlu menerima peristiwa tombol media di perangkat Android.

getRecentTasks()

Dengan diperkenalkannya fitur tugas dokumen dan aktivitas serentak baru di Android 5.0 (lihat Dokumen dan aktivitas serentak di layar terbaru di bawah), metode ActivityManager.getRecentTasks() kini tidak digunakan lagi untuk meningkatkan privasi pengguna. Untuk kompatibilitas mundur, metode ini masih menampilkan sebagian kecil datanya, termasuk tugas aplikasi panggilan itu sendiri dan mungkin beberapa tugas non-sensitif lainnya (seperti Beranda). Jika aplikasi Anda menggunakan metode ini untuk mengambil tugasnya sendiri, gunakan getAppTasks() untuk mengambil informasi tersebut.

Dukungan 64-Bit di Android NDK

Android 5.0 memperkenalkan dukungan untuk sistem 64-bit. Peningkatan 64-bit meningkatkan ruang alamat dan meningkatkan performa, sekaligus tetap mendukung aplikasi 32-bit yang ada sepenuhnya. Dukungan 64-bit juga meningkatkan performa OpenSSL untuk kriptografi. Selain itu, rilis ini memperkenalkan API NDK media native baru, serta dukungan OpenGL ES (GLES) 3.1 native.

Untuk menggunakan dukungan 64-bit yang disediakan di Android 5.0, download dan instal NDK Revisi 10c dari halaman Android NDK. Lihat catatan rilis Revisi 10c untuk mengetahui informasi selengkapnya tentang perubahan penting dan perbaikan bug pada NDK.

Mengikat ke Layanan

Metode Context.bindService() kini memerlukan Intent eksplisit, dan menampilkan pengecualian jika diberi intent implisit. Untuk memastikan aplikasi Anda aman, gunakan intent eksplisit saat memulai atau mengikat Service, dan jangan deklarasikan filter intent untuk layanan.

WebView

Android 5.0 mengubah perilaku default aplikasi Anda.

Jika aplikasi Anda menargetkan API level 21 atau yang lebih tinggi:
- Sistem memblokir konten campuran dan cookie pihak ketiga secara default. Untuk mengizinkan konten campuran dan cookie pihak ketiga, gunakan metode setMixedContentMode() dan setAcceptThirdPartyCookies().
- Sistem kini memilih bagian dokumen HTML untuk digambar secara cerdas. Perilaku default baru ini membantu mengurangi footprint memori dan meningkatkan performa. Jika Anda ingin merender seluruh dokumen sekaligus, nonaktifkan pengoptimalan ini dengan memanggil enableSlowWholeDocumentDraw().
Jika aplikasi Anda menargetkan API level yang lebih rendah dari 21: Sistem mengizinkan konten campuran dan cookie pihak ketiga, serta selalu merender seluruh dokumen sekaligus.

Syarat Keunikan untuk Izin Khusus

Seperti yang didokumentasikan dalam ringkasan Izin, aplikasi Android dapat menentukan izin kustom sebagai cara untuk mengelola akses ke komponen dengan cara eksklusif, tanpa menggunakan izin sistem yang telah ditentukan sebelumnya di platform. Aplikasi menentukan izin kustom dalam elemen <permission> yang dideklarasikan dalam file manifesnya.

Ada sejumlah kecil skenario saat menentukan izin kustom adalah pendekatan yang sah dan aman. Namun, membuat izin kustom terkadang tidak perlu dan bahkan dapat menimbulkan potensi risiko pada aplikasi, bergantung pada tingkat perlindungan yang ditetapkan ke izin.

Android 5.0 menyertakan perubahan perilaku untuk memastikan bahwa hanya satu aplikasi yang dapat menentukan izin kustom tertentu, kecuali jika ditandatangani dengan kunci yang sama dengan aplikasi lain yang menentukan izin.

Aplikasi menggunakan izin khusus duplikat

Setiap aplikasi dapat menentukan izin kustom yang diinginkan, sehingga beberapa aplikasi mungkin menentukan izin kustom yang sama. Misalnya, jika dua aplikasi menawarkan kemampuan yang serupa, aplikasi tersebut mungkin memperoleh nama logis yang sama untuk izin kustomnya. Aplikasi juga dapat menggabungkan library publik umum atau contoh kode yang menyertakan definisi izin kustom yang sama.

Di Android 4.4 dan yang lebih lama, pengguna dapat menginstal beberapa aplikasi tersebut di perangkat tertentu, meskipun sistem menetapkan tingkat perlindungan yang ditentukan oleh aplikasi yang diinstal pertama kali.

Mulai Android 5.0, sistem menerapkan pembatasan keunikan pada izin kustom baru untuk aplikasi yang ditandatangani dengan kunci yang berbeda. Sekarang hanya satu aplikasi di perangkat yang dapat menentukan izin kustom tertentu (sebagaimana ditentukan oleh namanya), kecuali aplikasi lain yang menentukan izin ditandatangani dengan kunci yang sama. Jika pengguna mencoba menginstal aplikasi dengan izin kustom duplikat dan tidak ditandatangani dengan kunci yang sama seperti aplikasi resident yang menentukan izin, sistem akan memblokir penginstalan.

Pertimbangan untuk aplikasi Anda

Di Android 5.0 dan yang lebih baru, aplikasi dapat terus menentukan izin kustomnya sendiri seperti sebelumnya dan meminta izin kustom dari aplikasi lain melalui mekanisme <uses-permission>. Namun, dengan persyaratan baru yang diperkenalkan di Android 5.0, Anda harus menilai dengan cermat kemungkinan dampaknya pada aplikasi Anda.

Inilah beberapa hal yang harus dipertimbangkan:

Apakah aplikasi Anda mendeklarasikan elemen <permission> dalam manifesnya? Jika ya, apakah izin tersebut benar-benar diperlukan untuk fungsi aplikasi atau layanan Anda yang tepat? Atau, apakah Anda dapat menggunakan izin default sistem?
Jika Anda memiliki elemen <permission> di aplikasi, apakah Anda tahu asal elemen tersebut?
Apakah Anda benar-benar ingin aplikasi lain meminta izin kustom Anda melalui <uses-permission>?
Apakah Anda menggunakan boilerplate atau kode contoh di aplikasi yang menyertakan elemen <permission>? Apakah elemen izin tersebut benar-benar diperlukan?
Apakah izin kustom Anda menggunakan nama yang sederhana atau berdasarkan istilah umum yang mungkin digunakan aplikasi lain?

Pemasangan baru dan pembaruan

Seperti yang disebutkan di atas, untuk penginstalan dan update baru aplikasi Anda di perangkat yang menjalankan Android 4.4 atau yang lebih lama tidak akan terpengaruh dan tidak ada perubahan perilaku. Untuk penginstalan dan update baru di perangkat yang menjalankan Android 5.0 atau yang lebih baru, sistem mencegah penginstalan aplikasi Anda jika menentukan izin kustom yang sudah ditentukan oleh aplikasi resident yang ada.

Pemasangan yang ada dengan pemutakhiran sistem Android 5.0

Jika aplikasi Anda menggunakan izin kustom dan didistribusikan serta diinstal secara luas, ada kemungkinan aplikasi akan terpengaruh saat pengguna menerima update perangkat mereka ke Android 5.0. Setelah update sistem diinstal, sistem akan memvalidasi ulang aplikasi yang diinstal, termasuk pemeriksaan izin kustomnya. Jika aplikasi Anda menentukan izin kustom yang sudah ditentukan oleh aplikasi lain yang telah divalidasi, dan aplikasi Anda tidak ditandatangani dengan kunci yang sama seperti aplikasi lain, sistem tidak menginstal ulang aplikasi Anda.

Rekomendasi

Di perangkat yang menjalankan Android 5.0 atau yang lebih baru, sebaiknya periksa aplikasi Anda segera, lakukan penyesuaian yang diperlukan, dan publikasikan versi yang diupdate sesegera mungkin kepada pengguna.

Jika Anda menggunakan izin kustom di aplikasi, pertimbangkan asal izin tersebut dan apakah Anda benar-benar memerlukannya. Hapus semua elemen <permission> dari aplikasi Anda, kecuali jika Anda yakin bahwa elemen tersebut diperlukan agar aplikasi berfungsi dengan baik.
Pertimbangkan untuk mengganti izin kustom Anda dengan izin default sistem jika memungkinkan.
Jika aplikasi Anda memerlukan izin kustom, ganti nama izin kustom agar unik untuk aplikasi Anda, seperti dengan menambahkannya ke nama paket lengkap aplikasi Anda.
Jika Anda memiliki rangkaian aplikasi yang ditandatangani dengan kunci yang berbeda dan aplikasi mengakses komponen bersama melalui izin kustom, pastikan izin kustom hanya ditentukan sekali, di komponen bersama. Aplikasi yang menggunakan komponen bersama tidak boleh menentukan izin kustomnya sendiri, tetapi harus meminta akses melalui mekanisme <uses-permission>.
Jika Anda memiliki rangkaian aplikasi yang ditandatangani dengan kunci yang sama, setiap aplikasi dapat menentukan izin kustom yang sama sesuai kebutuhan — sistem memungkinkan aplikasi diinstal dengan cara biasa.

Perubahan Konfigurasi Default TLS/SSL

Android 5.0 memperkenalkan perubahan konfigurasi TLS/SSL default yang digunakan oleh aplikasi untuk HTTPS dan traffic TLS/SSL lainnya:

Protokol TLSv1.2 dan TLSv1.1 kini diaktifkan,
Paket penyandian AES-GCM (AEAD) kini diaktifkan,
Paket penyandian MD5, 3DES, ekspor, dan ECDH kunci statis kini dinonaktifkan,
Paket penyandian Forward Secrecy (ECDHE dan DHE) lebih diutamakan.

Perubahan ini dapat menyebabkan kerusakan pada konektivitas HTTPS atau TLS/SSL dalam beberapa kasus yang tercantum di bawah.

Perhatikan bahwa ProviderInstaller keamanan dari layanan Google Play sudah menawarkan perubahan ini di seluruh versi platform Android hingga Android 2.3.

Server tidak mendukung paket penyandian apa pun yang diaktifkan

Misalnya, server hanya mendukung paket penyandian 3DES atau MD5. Perbaikan yang lebih disukai adalah meningkatkan konfigurasi server untuk mengaktifkan cipher suite dan protokol yang lebih kuat dan lebih modern. Idealnya, TLSv1.2 dan AES-GCM harus diaktifkan, dan cipher suite Forward Secrecy (ECDHE, DHE) harus diaktifkan dan lebih disukai.

Alternatifnya adalah mengubah aplikasi untuk menggunakan SSLSocketFactory kustom guna berkomunikasi dengan server. Factory harus dirancang untuk membuat instance SSLSocket yang memiliki beberapa cipher suite yang diperlukan oleh server yang diaktifkan selain cipher suite default.

Aplikasi membuat asumsi salah tentang paket penyandian yang digunakan untuk menghubungkan ke server

Misalnya, beberapa aplikasi berisi X509TrustManager kustom yang rusak karena mengharapkan parameter authType berupa RSA, tetapi menemukan ECDHE_RSA atau DHE_RSA.

Server tidak toleran pada TLSv1.1, TLSv1.2 atau ekstensi TLS baru

Misalnya, TLS/SSL handshake dengan server salah ditolak atau terhenti. Perbaikan yang direkomendasikan adalah mengupgrade server agar mematuhi protokol TLS/SSL. Tindakan ini akan membuat server berhasil menegosiasikan protokol yang lebih baru ini atau menegosiasikan TLSv1 atau protokol yang lebih lama dan mengabaikan ekstensi TLS yang tidak dipahami. Dalam beberapa kasus, menonaktifkan TLSv1.1 dan TLSv1.2 di server dapat berfungsi sebagai tindakan sementara hingga software server diupgrade.

Alternatifnya adalah mengubah aplikasi untuk menggunakan SSLSocketFactory kustom guna berkomunikasi dengan server. Factory harus dirancang untuk membuat instance SSLSocket dengan hanya mengaktifkan protokol yang didukung dengan benar oleh server.

Dukungan untuk Profil Terkelola

Administrator perangkat dapat menambahkan profil terkelola ke perangkat. Profil ini dimiliki oleh administrator, sehingga memberi administrator kontrol atas profil terkelola, sementara profil pribadi pengguna, dan ruang penyimpanannya, tetap berada di bawah kontrol pengguna. Perubahan ini dapat memengaruhi perilaku aplikasi yang ada dengan cara berikut.

Menangani maksud

Administrator perangkat dapat membatasi akses ke aplikasi sistem dari profil terkelola. Dalam hal ini, jika aplikasi memicu intent dari profil terkelola yang biasanya ditangani oleh aplikasi tersebut, dan tidak ada pengendali yang sesuai untuk intent di profil terkelola, intent akan menyebabkan pengecualian. Misalnya, administrator perangkat dapat membatasi aplikasi di profil terkelola agar tidak mengakses aplikasi kamera sistem. Jika aplikasi Anda berjalan di profil terkelola dan memanggil startActivityForResult() untuk MediaStore.ACTION_IMAGE_CAPTURE, dan tidak ada aplikasi di profil terkelola yang dapat menangani intent, hal ini akan menghasilkan ActivityNotFoundException.

Anda dapat mencegahnya dengan memeriksa adanya setidaknya satu pengendali untuk intent apa pun sebelum mengaktifkannya. Untuk memeriksa pengendali yang valid, panggil Intent.resolveActivity(). Anda dapat melihat contohnya di Mengambil Foto dengan Mudah: Mengambil Foto dengan Aplikasi Kamera.

Berbagi file di semua profil

Setiap profil memiliki penyimpanan file-nya sendiri. Karena URI file merujuk ke lokasi tertentu dalam penyimpanan file, ini berarti URI file yang valid di satu profil tidak valid di profil lainnya. Hal ini biasanya tidak menjadi masalah bagi aplikasi, yang biasanya hanya mengakses file yang dibuatnya. Namun, jika aplikasi melampirkan file ke intent, tidak aman untuk melampirkan URI file, karena dalam beberapa keadaan, intent mungkin ditangani di profil lain. Misalnya, administrator perangkat mungkin menentukan bahwa peristiwa pengambilan gambar harus ditangani oleh aplikasi kamera di profil pribadi. Jika intent diaktifkan oleh aplikasi di profil terkelola, kamera harus dapat menulis gambar ke lokasi tempat aplikasi profil terkelola dapat membacanya.

Untuk keamanan, saat Anda perlu melampirkan file ke intent yang mungkin melintas dari satu profil ke profil lainnya, Anda harus membuat dan menggunakan URI konten untuk file tersebut. Untuk informasi selengkapnya tentang berbagi file dengan URI konten, lihat Berbagi File. Misalnya, administrator perangkat mungkin mengizinkan ACTION_IMAGE_CAPTURE ditangani oleh kamera di profil pribadi. EXTRA_OUTPUT intent pengaktifan harus berisi URI konten yang menentukan tempat foto harus disimpan. Aplikasi kamera dapat menulis gambar ke lokasi yang ditentukan oleh URI tersebut, dan aplikasi yang mengaktifkan intent akan dapat membaca file tersebut, meskipun aplikasi berada di profil lain.

Android 5.0 menghapus dukungan untuk widget layar kunci; Android 5.0 terus mendukung widget di layar utama.