Google berkomitmen untuk mendorong terwujudnya keadilan rasial bagi komunitas Kulit Hitam. Lihat caranya.

Perubahan Perilaku Android 5.0

Video

Dev Byte: Yang baru di Android 5.0

Video

Dev Byte: Notifikasi

API Level: 21

Bersama fitur dan kemampuan baru, Android 5.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 dipengaruhi oleh perubahan ini dalam Android 5.0.

Untuk mendapatkan gambaran tingkat tinggi pada fitur platform baru, lihat Fitur Unggulan Android Lollipop.

Android Runtime (ART)

Di Android 5,0 waktu proses ART menggantikan Dalvik sebagai default platform. Waktu proses ART diperkenalkan dalam 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. Akan tetapi, beberapa teknik yang berfungsi di Dalvik tidak berfungsi di ART. Untuk informasi tentang masalah paling penting, lihat Memverifikasi Perilaku Aplikasi pada Android Runtime (ART). Berikan perhatian khusus jika:

  • Aplikasi Anda menggunakan Antarmuka Asli Java (Java Native Interface/JNI) untuk menjalankan kode C/C++.
  • Anda menggunakan alat development yang menghasilkan kode non-standar (misalnya beberapa obfuscator).
  • Anda menggunakan teknik yang tidak kompatibel dengan pemadatan pengumpulan sampah.

Notifikasi

Pastikan notifikasi Anda memperhitungkan perubahan Android 5.0 ini. Untuk mengetahui selengkapnya tentang mendesain notifikasi untuk Android 5.0 dan yang lebih tinggi, 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. Perbaiki jika notifikasi Anda terlihat salah:

  • Gunakan setColor() untuk menyetel 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 dalam ikon notifikasi utama. Anda harus beranggapan bahwa ikon-ikon ini akan berupa alfa-saja. Sistem akan menggambar ikon notifikasi dengan warna putih dan ikon tindakan dalam warna abu-abu tua.

Suara dan getaran

Jika Anda saat ini menambahkan suara dan getaran ke notifikasi dengan menggunakan kelas-kelas Ringtone, MediaPlayer, atau Vibrator, buang kode ini agar sistem bisa memberikan 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 masuk ke mode prioritas baru. Perangkat membiarkan mode prioritas jika Anda menyetelnya ke RINGER_MODE_NORMAL atau RINGER_MODE_VIBRATE.

Sebelumnya, Android menggunakan STREAM_MUSIC sebagai aliran master untuk mengontrol volume pada perangkat tablet. Di Android 5.0, aliran volume master baik untuk ponsel maupun perangkat tablet kini disatukan, dan dikontrol melalui STREAM_RING atau STREAM_NOTIFICATION.

Visibilitas layar kunci

Secara default, notifikasi kini muncul di layar kunci pengguna di Android 5.0. Pengguna bisa memilih untuk melindungi informasi sensitif agar tidak diekspos, dalam hal ini sistem secara otomatis akan menyunting teks yang ditampilkan oleh notifikasi. Untuk menyesuaikan notifikasi yang telah diedit ini, gunakan setPublicVersion().

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

Pemutaran media

Jika Anda sedang mengimplementasikan notifikasi yang memberikan status pemutaran media atau kontrol transpor, pertimbangkan untuk menggunakan template baru Notification.MediaStyle sebagai ganti objek khusus RemoteViews.RemoteView. Pendekatan apa pun yang Anda pilih, pastikan menyetel visibilitas notifikasi VISIBILITY_PUBLIC agar kontrol Anda bisa diakses dari layar kunci. Perhatikan, mulai Android 5.0, sistem tidak lagi menampilkan objek RemoteControlClient pada layar kunci. Untuk informasi selengkapnya, lihat Jika aplikasi Anda menggunakan RemoteControlClient.

Notifikasi pendahuluan

Notifikasi bisa muncul dalam jendela kecil mengambang (yang disebut juga dengan notifikasi pendahuluan) saat perangkat aktif (yakni, perangkat dibuka kuncinya dan layarnya menyala). Notifikasi ini tampak mirip dengan bentuk ringkas notifikasi Anda, hanya saja notifikasi pendahuluan juga menampilkan tombol tindakan. Pengguna bisa menindaklanjuti atau menutup notifikasi pendahuluan tanpa meninggalkan aplikasi saat ini.

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

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

Jika aplikasi Anda mengimplementasikan notifikasi pada skenario itu, pastikan notifikasi pendahuluan ditampilkan dengan benar.

Kontrol Media dan RemoteControlClient

Kelas RemoteControlClient sekarang tidak digunakan lagi. Beralihlah ke MediaSession API baru secepatnya.

Layar kunci di Android 5.0 tidak menampilkan kontrol transpor untuk MediaSession atau RemoteControlClient. Sebagai gantinya, aplikasi Anda bisa menyediakan kontrol pemutaran media dari layar kunci melalui notifikasi. Ini memberi kontrol lebih banyak pada aplikasi Anda melalui penyajian tombol media, sekaligus menyediakan pengalaman yang konsisten bagi pengguna di semua perangkat yang terkunci maupun terbuka.

Android 5.0 memperkenalkan template baru Notification.MediaStyle untuk keperluan ini. Notification.MediaStyle mengonversi tindakan notifikasi yang Anda tambahkan dengan Notification.Builder.addAction() menjadi tombol-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 menyetel visibilitas notifikasi ke VISIBILITY_PUBLIC untuk menandai notifikasi sebagai aman untuk ditampilkan pada layar kunci (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 kelas MediaSession. Anda juga harus mengimplementasikan MediaSession jika aplikasi perlu menerima kejadian tombol media pada perangkat Android.

getRecentTasks()

Dengan diperkenalkannya fitur baru Beberapa dokumen dan tugas aktivitas sekaligus di Android 5.0 (lihat Beberapa dokumen dan aktivitas sekaligus di layar terbaru di bawah ini), metode ActivityManager.getRecentTasks() sekarang tidak digunakan lagi untuk memperbaiki privasi pengguna. Untuk kompatibilitas mundur, metode ini tetap mengembalikan subset kecil datanya, termasuk tugas aplikasi pemanggil sendiri dan mungkin beberapa tugas non-sensitif lainnya (misalnya Beranda). Jika aplikasi Anda menggunakan metode ini untuk mengambil tugasnya sendiri, gunakan getAppTasks() sebagai ganti mengambil informasi itu.

Dukungan 64-Bit di Android NDK

Android 5.0 memperkenalkan dukungan untuk sistem 64-bit. Penyempurnaan 64-bit menambah ruang alamat dan meningkatkan kinerja, sekaligus tetap mendukung penuh aplikasi 32-bit yang ada. Dukungan 64-bit juga meningkatkan kinerja OpenSSL untuk kriptografi. Sebagai tambahan, rilis ini memperkenalkan NDK API media asli baru, serta dukungan OpenGL ES (GLES) 3.1 asli.

Untuk menggunakan dukungan 64-bit yang disediakan di Android 5.0, unduh dan pasang NDK Revision 10c dari laman Android NDK. Lihat catatan rilis Revision 10c untuk informasi selengkapnya tentang perubahan penting dan perbaikan bug pada NDK.

Mengikat ke Layanan

Metode Context.bindService() sekarang memerlukan Intent eksplisit, dan melontarkan pengecualian jika diberikan maksud implisit. Untuk memastikan aplikasi Anda aman, gunakan maksud eksplisit saat memulai atau mengikat Service, dan jangan deklarasikan filter maksud untuk layanan.

WebView

Android 5.0 mengubah perilaku default aplikasi Anda.

  • Jika aplikasi Anda menargetkan API level 21 atau yang lebih tinggi:
    • Sistem memblokir materi campuran dan cookie pihak ketiga secara default. Untuk mengizinkan materi campuran dan cookie pihak ketiga, masing-masing gunakan metode setMixedContentMode() dan setAcceptThirdPartyCookies().
    • Sekarang sistem secara cerdas memilih bagian dari dokumen HTML yang akan digambar. Perilaku default yang baru ini membantu mengurangi footprint memori dan menambah kinerja. Jika Anda ingin me-render keseluruhan dokumen sekaligus, nonaktifkan optimalisasi ini dengan memanggil enableSlowWholeDocumentDraw().
  • Jika aplikasi Anda menargetkan API level yang lebih rendah dari 21: Sistem memungkinkan materi campuran dan cookie pihak ketiga, dan selalu me-render keseluruhan dokumen sekaligus.

Syarat Keunikan untuk Izin Khusus

Seperti yang didokumentasikan dalam ringkasan Izin, aplikasi Android bisa mendefinisikan izin khusus sebagai sarana mengelola akses ke berbagai komponen dengan cara yang semestinya, tanpa menggunakan izin sistem yang telah didefinisikan sebelumnya oleh platform. Aplikasi mendefinisikan izin khusus dalam elemen <permission> yang dideklarasikan dalam file manifesnya.

Ada sejumlah kecil skenario di mana mendefinisikan izin khusus menjadi pendekatan yang wajar dan aman. Akan tetapi, membuat izin khusus kadang-kadang tidak diperlukan dan bahkan bisa menimbulkan kemungkinan risiko pada aplikasi, bergantung pada tingkat perlindungan yang diberikan pada izin tersebut.

Android 5.0 menyertakan perubahan perilaku untuk memastikan hanya satu aplikasi yang bisa mendefinisikan izin khusus yang diberikan, kecuali jika ditandatangani dengan kunci yang sama seperti aplikasi lain yang mendefinisikan izin.

Aplikasi menggunakan izin khusus duplikat

Aplikasi apa saja bisa mendefinisikan izin khusus yang diinginkannya, jadi bisa saja terjadi beberapa aplikasi mendefinisikan izin khusus yang sama. Misalnya, jika dua aplikasi menawarkan kemampuan serupa, keduanya dapat memperoleh nama logis yang sama untuk izin khusus tersebut. Aplikasi juga dapat menyertakan pustaka publik yang umum atau contoh kode yang dengan sendirinya menyertakan definisi izin khusus yang sama.

Di Android 4.4 dan sebelumnya, pengguna dapat memasang banyak aplikasi seperti itu sekaligus pada perangkat dimaksud, walaupun sistem telah memberikan tingkat perlindungan yang ditetapkan melalui aplikasi yang dipasang pertama.

Mulai Android 5.0, sistem memberlakukan pembatasan keunikan baru pada izin khusus bagi aplikasi yang ditandatangani dengan kunci berbeda. Kini hanya satu aplikasi di perangkat yang bisa mendefinisikan izin khusus tersebut (sebagaimana diketahui melalui namanya), kecuali jika aplikasi lain yang mendefinisikan izin ditandatangani dengan kunci yang sama. Jika pengguna mencoba memasang aplikasi dengan izin khusus duplikat dan tidak ditandatangani dengan kunci yang sama seperti aplikasi residen yang mendefinisikan izin, sistem akan memblokir pemasangan tersebut.

Pertimbangan untuk aplikasi Anda

Di Android 5.0 dan yang lebih baru, aplikasi bisa melanjutkan mendefinisikan izin khususnya sendiri seperti sebelumnya dan meminta izin khusus dari aplikasi lain melalui mekanisme <uses-permission>. Akan tetapi, dengan diperkenalkannya persyaratan baru dalam Android 5.0, Anda harus hati-hati menilai kemungkinan dampaknya pada aplikasi Anda.

Inilah beberapa hal yang harus dipertimbangkan:

  • Apakah aplikasi Anda mendeklarasikan elemen <permission> dalam manifesnya? Jika ya, apakah itu benar-benar diperlukan agar aplikasi atau layanan Anda bisa berfungsi dengan semestinya? Atau, bisakah Anda menggunakan izin default sistem sebagai gantinya?
  • Jika memiliki elemen <permission> dalam aplikasi, apakah Anda tahu dari mana asalnya?
  • Apakah Anda memang ingin aplikasi lain meminta izin khusus melalui <uses-permission>?
  • Apakah Anda menggunakan boilerplate atau kode contoh dalam aplikasi yang berisi elemen <permission>? Apakah elemen izin itu benar-benar diperlukan?
  • Apakah izin khusus Anda menggunakan nama yang sederhana atau berdasarkan istilah umum yang mungkin digunakan bersama oleh aplikasi lain?

Pemasangan baru dan pembaruan

Seperti disebutkan di atas, untuk pemasangan baru dan pembaruan aplikasi Anda di perangkat yang menjalankan Android 4.4 atau sebelumnya tidak terpengaruh dan tidak ada perubahan perilaku. Untuk pemasangan baru dan pembaruan pada perangkat yang menjalankan Android 5.0 atau yang lebih baru, sistem akan mencegah pemasangan aplikasi jika mendefinisikan izin khusus yang didefinisikan oleh aplikasi residen yang sudah ada.

Pemasangan yang ada dengan pemutakhiran sistem Android 5.0

Jika aplikasi Anda menggunakan izin khusus dan secara luas didistribusikan serta dipasang, ada kemungkinan ia akan terpengaruh bila pengguna menerima pembaruan perangkat mereka ke Android 5.0. Setelah pemutakhiran sistem dipasang, sistem akan memvalidasi kembali aplikasi yang telah dipasang, termasuk pemeriksaan izin khususnya. Jika aplikasi Anda mendefinisikan izin khusus yang didefinisikan oleh aplikasi lain yang sudah divalidasi, dan aplikasi Anda tidak ditandatangani dengan kunci yang sama seperti aplikasi lain, sistem tidak akan memasang ulang aplikasi Anda.

Saran

Pada perangkat yang menjalankan Android 5.0 atau yang lebih baru, kami menyarankan agar Anda segera memeriksa aplikasi, membuat penyesuaian yang diperlukan, dan secepatnya mempublikasikan versi yang telah diperbarui kepada pengguna.

  • Jika Anda menggunakan izin khusus di aplikasi, pertimbangkan asalnya dan apakah Anda benar-benar memerlukannya. Buang semua elemen <permission> dari aplikasi, kecuali jika Anda sudah pasti memerlukannya agar aplikasi bisa berfungsi dengan benar.
  • Pertimbangkan untuk mengganti izin khusus dengan izin default sistem bila memungkinkan.
  • Jika aplikasi Anda memerlukan izin khusus, ganti nama izin khusus agar unik untuk aplikasi, misalnya menambahkannya ke nama paket lengkap aplikasi.
  • Jika Anda memiliki paket aplikasi yang ditandatangani dengan kunci berbeda dan aplikasi tersebut mengakses komponen bersama dengan menggunakan izin khusus, pastikan izin khusus hanya didefinisikan sekali, di komponen bersama. Aplikasi yang menggunakan komponen bersama tidak boleh mendefinisikan izin khususnya sendiri, melainkan harus meminta akses melalui mekanisme <uses-permission>.
  • Jika Anda memiliki paket aplikasi yang ditandatangani dengan kunci yang sama, setiap aplikasi bisa mendefinisikan izin khusus yang sama sebagaimana diperlukan — sistem memungkinkan aplikasi dipasang dengan cara biasanya.

Perubahan Konfigurasi Default TLS/SSL

Android 5.0 memperkenalkan perubahan pada konfigurasi default TLS/SSL yang digunakan oleh aplikasi untuk HTTPS dan lalu lintas 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.

Semua perubahan ini dapat menimbulkan kerusakan di konektivitas HTTPS atau TLS/SSL dalam sejumlah kecil kasus yang dicantumkan di bawah ini.

Perhatikan, ProviderInstaller keamanan dari Google Play Services sudah menawarkan perubahan ini di semua 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 memperbaiki konfigurasi server untuk memungkinkan protokol dan paket penyandian yang lebih kuat dan lebih modern. Idealnya, TLSv1.2 dan AES-GCM harus diaktifkan, dan paket penyandian Forward Secrecy (ECDHE, DHE) harus diaktifkan dan diutamakan.

Alternatifnya adalah memodifikasi aplikasi agar menggunakan SSLSocketFactory khusus untuk berkomunikasi dengan server. Pabrik harus didesain untuk membuat instance SSLSocket yang memiliki beberapa paket penyandian yang diperlukan oleh server yang telah diaktifkan selain paket penyandian default.

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

Misalnya, beberapa aplikasi berisi X509TrustManager khusus yang rusak karena mengharapkan parameter authType berupa RSA namun yang didapatnya adalah 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 salah atau macet. Perbaikan yang diutamakan adalah meningkatkan versi server agar sesuai dengan protokol TLS/SSL. Ini akan membuat server berhasil menegosiasikan protokol baru ini atau menegosiasikan TLSv1 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 pengganti sementara hingga perangkat lunak server ditingkatkan versinya.

Alternatifnya adalah memodifikasi aplikasi agar menggunakan SSLSocketFactory khusus untuk berkomunikasi dengan server. Pabrik harus didesain untuk membuat instance SSLSocket hanya dengan protokol yang telah diaktifkan, yang telah didukung dengan benar oleh server.

Dukungan untuk Profil Terkelola

Administrator perangkat bisa menambahkan profil terkelola ke perangkat. Profil ini dimiliki oleh administrator, sehingga memberi kontrol kepada administrator atas profil terkelola sekaligus membiarkan profil pribadi pengguna, dan ruang storagenya, di bawah kontrol pengguna. Perubahan ini bisa memengaruhi perilaku aplikasi yang ada dengan cara berikut.

Menangani maksud

Administrator perangkat bisa membatasi akses ke aplikasi sistem dari profil terkelola. Dalam hal ini, jika suatu aplikasi memicu sebuah maksud dari profil terkelola yang biasanya ditangani oleh aplikasi itu, dan tidak ada penangan yang cocok untuk maksud tersebut pada profil terkelola, maksud itu akan menyebabkan sebuah pengecualian. Misalnya, administrator perangkat bisa membatasi aplikasi pada profil terkelola agar tidak mengakses aplikasi kamera di sistem. Jika aplikasi Anda menjalankan profil terkelola dan memanggil startActivityForResult() untuk MediaStore.ACTION_IMAGE_CAPTURE, dan tidak ada aplikasi di profil terkelola yang bisa menangani maksud tersebut, ini akan mengakibatkan ActivityNotFoundException.

Anda bisa mencegahnya dengan memeriksa apakah setidaknya ada satu penangan untuk setiap maksud sebelum memicunya. Untuk memeriksa penangan yang valid, panggil Intent.resolveActivity(). Anda bisa melihat contohnya dilakukan dalam Mengambil Foto dengan Mudah: Mengambil Foto dengan Aplikasi Kamera.

Berbagi file di semua profil

Setiap profil memiliki file-storage sendiri. Berhubung URI file merujuk ke suatu lokasi tertentu dalam file-storage, berarti URI file yang valid di satu profil akan menjadi tidak valid di profil lainnya. Biasanya ini bukan masalah untuk aplikasi, yang biasanya cuma mengakses file yang dibuatnya. Akan tetapi, jika aplikasi melampirkan sebuah file ke suatu maksud, maka tidak aman untuk melampirkan URI file, karena di beberapa situasi, maksud tersebut mungkin akan ditangani pada profil lain. Misalnya, administrator perangkat dapat menetapkan bahwa kejadian menjepret gambar harus ditangani oleh aplikasi kamera pada profil pribadi. Jika maksud dipicu oleh suatu aplikasi pada profil terkelola, kamera harus bisa menuliskan gambar ke lokasi yang bisa dibaca oleh aplikasi profil terkelola tersebut.

Agar aman, bila Anda perlu melampirkan file ke suatu maksud yang mungkin berasal dari satu profil ke profil lain, maka Anda harus membuat dan menggunakan materi URI untuk file tersebut. Untuk informasi selengkapnya tentang berbagi file URI materi, lihat Berbagi File. Misalnya, administrator perangkat dapat memasukkan ACTION_IMAGE_CAPTURE ke daftar putih agar ditangani oleh kamera dalam profil pribadi. EXTRA_OUTPUT maksud pemicu harus berisi URI materi yang menetapkan tempat menyimpan foto. Aplikasi kamera bisa menuliskan gambar ke lokasi yang ditetapkan oleh URI itu, dan aplikasi yang memicu maksud tersebut akan dapat membaca file itu, sekalipun aplikasi berada di profil lain.

Dukungan widget layar kunci telah dibuang

Android 5.0 membuang dukungan untuk widget layar kunci dan tetap mendukung widget di layar beranda.