Perubahan Perilaku Android 5.0

API Level: 21

Bersama 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 perhitungkan dalam aplikasi Anda.

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

Untuk mendapatkan gambaran lengkap tentang fitur platform baru, lihat Sorotan Android Lollipop.

Video

Dev Byte: Yang Baru di Android 5.0

Dev Byte: 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 pada 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 (misalnya beberapa obfuscator).
  • Anda menggunakan teknik yang tidak kompatibel dengan pemadatan pembersihan sampah memori.

Notifikasi

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

Gaya desain material

Notifikasi digambar dengan teks gelap di atas latar belakang putih (atau sangat terang) agar sesuai 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.
  • Perbarui atau buang aset yang melibatkan warna. Sistem mengabaikan semua saluran non-alfa dalam ikon tindakan dan di ikon notifikasi utama. Anda harus berasumsi bahwa ikon ini hanya akan berfungsi sebagai alfa. Sistem menggambar ikon notifikasi dengan warna putih dan ikon tindakan dalam warna abu-abu tua.

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.

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

Sebelumnya, Android menggunakan STREAM_MUSIC sebagai streaming master untuk mengontrol volume di perangkat tablet. Pada Android 5.0, aliran volume master untuk perangkat ponsel dan tablet kini terpadu, 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, dan jika sistemnya 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 transmisi, pertimbangkan untuk menggunakan template Notification.MediaStyle baru, bukan objek RemoteViews.RemoteView kustom. Apa pun pendekatan yang Anda pilih, pastikan untuk menyetel visibilitas notifikasi ke VISIBILITY_PUBLIC agar kontrol dapat diakses dari layar kunci. Perhatikan bahwa mulai Android 5.0, sistem tidak lagi menampilkan objek RemoteControlClient di layar kunci. Untuk mengetahui informasi selengkapnya, lihat Jika aplikasi Anda menggunakan RemoteControlClient.

Notifikasi pendahuluan

Notifikasi kini dapat muncul di jendela mengambang kecil (juga disebut notifikasi pendahuluan) saat perangkat aktif (yaitu, perangkat tidak terkunci dan layarnya aktif). Notifikasi ini terlihat mirip dengan bentuk ringkas notifikasi Anda, hanya saja notifikasi pendahuluan juga menampilkan tombol tindakan. Pengguna dapat menindaklanjuti atau menutup notifikasi peringatan dini 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 mengimplementasikan notifikasi dalam salah satu skenario tersebut, pastikan notifikasi pendahuluan 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 transport untuk MediaSession atau RemoteControlClient. Sebagai gantinya, aplikasi Anda dapat menyediakan kontrol pemutaran media dari layar kunci melalui notifikasi. Hal ini memberi aplikasi Anda kontrol yang lebih besar atas penyajian tombol media, sekaligus memberikan pengalaman yang konsisten bagi pengguna di seluruh perangkat yang terkunci dan tidak terkunci.

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 menyetel visibilitas notifikasi ke VISIBILITY_PUBLIC guna 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 Android TV atau Wear, implementasikan class MediaSession. Anda juga harus mengimplementasikan MediaSession jika aplikasi perlu menerima peristiwa tombol media di perangkat Android.

getRecentTasks()

Dengan diperkenalkannya fitur dokumen dan tugas aktivitas serentak yang baru di Android 5.0 (lihat Dokumen dan aktivitas serentak pada 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 pemanggil itu sendiri dan mungkin beberapa tugas tidak 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 ini menambah ruang alamat dan meningkatkan performa, sekaligus tetap mendukung sepenuhnya aplikasi 32-bit yang sudah ada. 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() sekarang 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 mendeklarasikan 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 akan memblokir konten campuran dan cookie pihak ketiga secara default. Untuk mengizinkan konten campuran dan cookie pihak ketiga, gunakan metode setMixedContentMode() dan setAcceptThirdPartyCookies() masing-masing.
    • Kini, sistem secara cerdas memilih bagian dari dokumen HTML yang akan digambar. Perilaku default baru ini membantu mengurangi jejak memori dan meningkatkan performa. Jika Anda ingin merender seluruh dokumen sekaligus, nonaktifkan pengoptimalan ini dengan memanggil enableSlowWholeDocumentDraw().
  • Jika aplikasi Anda menargetkan API level di bawah 21: Sistem akan 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 mendefinisikan izin kustom sebagai cara mengelola akses ke komponen dengan cara yang eksklusif, tanpa menggunakan izin sistem yang telah ditentukan sebelumnya oleh platform. Aplikasi menentukan izin kustom dalam elemen <permission> yang dideklarasikan dalam file manifesnya.

Ada sejumlah kecil skenario ketika menetapkan izin kustom sebagai pendekatan yang sah dan aman. Namun, membuat izin kustom terkadang tidak diperlukan dan bahkan dapat menimbulkan potensi risiko pada aplikasi, bergantung pada tingkat perlindungan yang ditetapkan pada izin tersebut.

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

Aplikasi menggunakan izin khusus duplikat

Aplikasi apa pun dapat menentukan izin kustom yang diinginkan, sehingga bisa saja beberapa aplikasi menetapkan izin kustom yang sama. Misalnya, jika dua aplikasi menawarkan kemampuan yang serupa, aplikasi tersebut dapat memperoleh nama logis yang sama untuk izin kustomnya. Aplikasi juga dapat menyertakan library publik umum atau contoh kode yang dengan sendirinya menyertakan definisi izin kustom yang sama.

Pada Android 4.4 dan yang lebih lama, pengguna dapat menginstal beberapa aplikasi seperti itu di perangkat tertentu, meskipun sistem telah menetapkan tingkat perlindungan yang ditentukan oleh aplikasi yang diinstal pertama.

Mulai Android 5.0, sistem memberlakukan batasan keunikan baru pada izin khusus untuk aplikasi yang ditandatangani dengan kunci berbeda. Kini, hanya satu aplikasi di perangkat yang dapat menetapkan izin kustom tertentu (sebagaimana ditentukan oleh namanya), kecuali aplikasi lain yang menentukan izin tersebut ditandatangani dengan kunci yang sama. Jika pengguna mencoba menginstal aplikasi dengan izin kustom duplikat dan tidak ditandatangani dengan kunci yang sama dengan aplikasi penduduk yang menentukan izin tersebut, 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 terhadap aplikasi.

Inilah beberapa hal yang harus dipertimbangkan:

  • Apakah aplikasi Anda mendeklarasikan elemen <permission> dalam manifesnya? Jika ya, apakah elemen-elemen tersebut benar-benar diperlukan untuk menjalankan fungsi aplikasi atau layanan Anda secara tepat? Atau, dapatkah Anda menggunakan izin default sistem?
  • Jika Anda memiliki elemen <permission> di aplikasi, tahukah Anda dari mana elemen tersebut berasal?
  • Apakah Anda benar-benar ingin aplikasi lain meminta izin kustom Anda melalui <uses-permission>?
  • Apakah Anda menggunakan boilerplate atau kode contoh dalam aplikasi yang menyertakan elemen <permission>? Apakah elemen izin tersebut benar-benar diperlukan?
  • Apakah izin kustom Anda menggunakan nama yang sederhana atau yang didasarkan pada istilah umum yang mungkin digunakan oleh aplikasi lain?

Pemasangan baru dan pembaruan

Seperti yang disebutkan di atas, untuk penginstalan baru dan update aplikasi Anda di perangkat yang menjalankan Android 4.4 atau sebelumnya tidak akan terpengaruh dan tidak ada perubahan perilaku. Untuk penginstalan baru dan update di perangkat yang menjalankan Android 5.0 atau yang lebih baru, sistem akan mencegah penginstalan aplikasi Anda jika menentukan izin kustom yang sudah ditetapkan oleh aplikasi penghuni yang sudah 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 tersebut akan terpengaruh saat pengguna menerima update perangkat mereka ke Android 5.0. Setelah update sistem diinstal, sistem akan memvalidasi ulang aplikasi terinstal, termasuk memeriksa izin kustomnya. Jika aplikasi Anda menetapkan izin kustom yang sudah ditetapkan oleh aplikasi lain yang telah divalidasi, dan aplikasi Anda tidak ditandatangani dengan kunci yang sama seperti aplikasi lain, sistem tidak akan menginstal ulang aplikasi Anda.

Konten

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

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

Perubahan Konfigurasi Default TLS/SSL

Android 5.0 memperkenalkan perubahan pada 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 sejumlah kecil kasus yang tercantum di bawah ini.

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

Server tidak mendukung paket penyandian apa pun yang diaktifkan

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

Alternatifnya, Anda dapat memodifikasi aplikasi agar menggunakan SSLSocketFactory kustom untuk berkomunikasi dengan server. Pabrik harus didesain untuk membuat instance SSLSocket dengan beberapa cipher suite yang diperlukan oleh server 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, handshake TLS/SSL dengan server ditolak secara keliru atau macet. Perbaikan yang disarankan adalah mengupgrade server agar mematuhi protokol TLS/SSL. Hal ini akan membuat server berhasil menegosiasikan protokol yang lebih baru ini atau menegosiasikan TLSv1 atau protokol yang lebih lama serta mengabaikan ekstensi TLS yang tidak dipahaminya. Dalam beberapa kasus, menonaktifkan TLSv1.1 dan TLSv1.2 di server dapat berfungsi sebagai tindakan sementara hingga software server diupgrade.

Alternatifnya, Anda dapat memodifikasi aplikasi agar menggunakan SSLSocketFactory kustom untuk berkomunikasi dengan server. Factory harus didesain untuk membuat instance SSLSocket hanya dengan protokol yang diaktifkan 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 sekaligus membiarkan profil pribadi pengguna, dan ruang penyimpanannya, 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 mengaktifkan intent dari profil terkelola yang biasanya akan ditangani oleh aplikasi tersebut, dan tidak ada pengendali yang sesuai untuk intent di profil terkelola, intent tersebut akan menyebabkan pengecualian. Misalnya, administrator perangkat dapat membatasi aplikasi pada 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 mencegah hal ini dengan memeriksa bahwa setidaknya ada satu pengendali untuk setiap intent sebelum mengaktifkannya. Untuk memeriksa pengendali yang valid, panggil Intent.resolveActivity(). Anda dapat melihat contohnya yang dilakukan di Mengambil Foto Cukup: 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, URI file yang valid di satu profil tidak valid di profil lainnya. Biasanya ini bukan 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 situasi, intent mungkin ditangani di profil lainnya. Misalnya, administrator perangkat dapat menetapkan bahwa peristiwa pengambilan gambar harus ditangani oleh aplikasi kamera pada profil pribadi. Jika intent diaktifkan oleh aplikasi di profil terkelola, kamera harus dapat menulis gambar ke lokasi tempat aplikasi profil terkelola dapat membacanya.

Agar aman, jika perlu melampirkan file ke intent yang mungkin berasal 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 dapat 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.

Dukungan widget layar kunci telah dibuang

Android 5.0 menghapus dukungan untuk widget layar kunci, tetapi tetap mendukung widget di layar utama.