Perubahan Perilaku Android 5.0

Level API: 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 dipahami dan diperhitungkan dalam aplikasi Anda.

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

Untuk gambaran mendetail tentang fitur platform baru, lihat highlight 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 pada 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 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 yang lebih baru, 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 di ikon tindakan dan di ikon notifikasi utama. Anda harus mengasumsikan bahwa ikon ini hanya untuk 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. Di Android 5.0, aliran volume master untuk perangkat ponsel serta tablet kini digabungkan, 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 sistem ini 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 transport, 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 sehingga kontrol Anda 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 peringatan dini) saat perangkat aktif (artinya, perangkat tidak terkunci dan layarnya aktif). Notifikasi ini tampak mirip dengan bentuk ringkas notifikasi Anda, hanya saja notifikasi peringatan dini 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 menerapkan 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 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 semua 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 di 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 Anda menyetel visibilitas notifikasi ke VISIBILITY_PUBLIC untuk menandai notifikasi sebagai aman untuk ditampilkan di layar kunci mana pun (aman atau sebaliknya). Untuk informasi selengkapnya, lihat Notifikasi layar kunci.

Untuk menampilkan kontrol pemutaran media jika aplikasi Anda berjalan di platform TV atau Wear Android, 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 di layar terbaru di bawah), metode ActivityManager.getRecentTasks() kini tidak digunakan lagi untuk meningkatkan privasi pengguna. Untuk kompatibilitas mundur, metode ini tetap menampilkan subset kecil datanya, termasuk tugas aplikasi panggilan 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. Penyempurnaan 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 NDK API 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 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 masing-masing metode setMixedContentMode() dan setAcceptThirdPartyCookies().
    • 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 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 sarana untuk mengelola akses ke komponen dengan cara yang eksklusif, tanpa menggunakan izin sistem yang telah ditetapkan sebelumnya oleh platform. Aplikasi menentukan izin kustom dalam elemen <permission> yang dideklarasikan dalam file manifesnya.

Ada sejumlah kecil skenario ketika menetapkan izin kustom merupakan 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 untuk 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 menentukan izin tersebut.

Aplikasi menggunakan izin khusus duplikat

Aplikasi apa pun dapat menentukan izin kustom yang diinginkannya, sehingga mungkin saja terjadi beberapa aplikasi mungkin 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 sendiri menyertakan definisi izin kustom yang sama.

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

Mulai dari Android 5.0, sistem menerapkan batasan keunikan yang baru pada izin khusus untuk aplikasi yang ditandatangani dengan kunci yang berbeda. Kini hanya satu aplikasi di perangkat yang dapat menentukan izin kustom tertentu (sebagaimana ditentukan oleh namanya), kecuali jika 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 seperti aplikasi penghuni 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 dampak pada aplikasi Anda.

Inilah beberapa hal yang harus dipertimbangkan:

  • Apakah aplikasi Anda mendeklarasikan elemen <permission> dalam manifesnya? Jika ya, apakah itu benar-benar diperlukan untuk fungsi aplikasi atau layanan yang tepat? Atau dapatkah Anda menggunakan izin default sistem?
  • Jika memiliki elemen <permission> di aplikasi, apakah Anda tahu dari mana elemen tersebut berasal?
  • Apakah Anda benar-benar bermaksud agar 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 berdasarkan 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 yang lebih lama, 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 jika menentukan izin kustom yang sudah ditetapkan oleh aplikasi penghuni yang ada.

Pemasangan yang ada dengan pemutakhiran sistem Android 5.0

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

Konten

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

  • 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 Anda dengan izin default sistem jika memungkinkan.
  • Jika aplikasi Anda memerlukan izin kustom, ganti nama izin kustom agar unik untuk aplikasi Anda, misalnya dengan menambahkannya ke nama paket lengkap aplikasi Anda.
  • Jika Anda memiliki serangkaian aplikasi yang ditandatangani dengan kunci berbeda dan aplikasi mengakses komponen bersama melalui izin kustom, pastikan izin kustom hanya ditetapkan sekali, dalam komponen bersama. Aplikasi yang menggunakan komponen bersama tidak boleh menetapkan izin kustom itu sendiri, tetapi harus meminta akses melalui mekanisme <uses-permission>.
  • Jika Anda memiliki serangkaian 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 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.

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 diutamakan 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 diutamakan.

Alternatifnya adalah memodifikasi aplikasi agar menggunakan SSLSocketFactory kustom untuk berkomunikasi dengan server. Selain cipher suite default, factory harus didesain untuk membuat instance SSLSocket, yang memiliki beberapa cipher suite yang diperlukan oleh server.

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 protokol TLSv1 atau 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 adalah 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, yang memberi administrator kontrol atas profil terkelola tersebut, sekaligus tetap mempertahankan 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 pada profil terkelola, intent tersebut 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 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 Simply: 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, artinya URI file yang valid di satu profil tidak akan valid di profil lainnya. Biasanya ini bukan masalah untuk aplikasi, yang biasanya hanya mengakses file yang dibuatnya. Namun, jika aplikasi melampirkan file ke suatu intent, tidak aman untuk melampirkan URI file, karena dalam beberapa situasi, intent mungkin ditangani pada profil lainnya. Misalnya, administrator perangkat mungkin menetapkan bahwa peristiwa pengambilan gambar harus ditangani oleh aplikasi kamera pada profil pribadi. Jika intent diaktifkan oleh aplikasi pada 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 muncul 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 dan tetap mendukung widget di layar utama.