Selamat datang di Pratinjau Developer Android 12. Beri kami masukan lebih awal dan sering, serta bantu kami menjadikan Android 12 sebagai rilis terbaik!

Perubahan perilaku: Aplikasi yang menargetkan Android 12

Seperti rilis sebelumnya, Android 12 menyertakan perubahan perilaku yang dapat memengaruhi aplikasi Anda. Perubahan perilaku berikut ini berlaku khusus bagi aplikasi yang menargetkan Android 12 atau yang lebih tinggi. Jika aplikasi Anda menargetkan Android 12, Anda harus memodifikasi aplikasi untuk mendukung perilaku ini dengan benar, jika berlaku.

Tabel berikut meringkas perubahan penting yang memengaruhi aplikasi jika aplikasi Anda menargetkan Android 12. Perlu diperhatikan bahwa tabel ini tidak memberikan kumpulan perubahan lengkap.

Perubahan penting Aplikasi yang terpengaruh
Pembatasan peluncuran layanan latar depan
Dengan beberapa pengecualian, aplikasi tidak dapat lagi memulai layanan latar depan saat berjalan di latar belakang. Upaya untuk melakukannya memberikan pengecualian.
Aplikasi yang memulai layanan latar depan saat aplikasi berjalan di latar belakang.
Komponen aplikasi yang berisi filter intent harus menyebutkan atribut yang diekspor
Komponen aplikasi yang menyertakan filter intent harus secara eksplisit menetapkan atribut android:exported. Aplikasi yang tidak menetapkan atribut tidak dapat diinstal di Android 12.
Aplikasi yang menyebutkan atribut <intent-filter> di dalam file manifesnya.
Peluncuran intent bertingkat tidak aman
Pengujian mode ketat kini dapat mendeteksi saat aplikasi menggunakan intent bertingkat dengan cara yang berbahaya.
Aplikasi yang meluncurkan aplikasi lain mengharapkan callback melalui intent internal.

Selain itu, pastikan Anda meninjau daftar perubahan perilaku yang memengaruhi semua aplikasi yang berjalan di Android 12.

Privasi

Perilaku cookie SameSite Modern di WebView

Komponen WebView Android didasarkan pada Chromium, yaitu proyek sumber terbuka yang mendukung browser Chrome Google. Selama setahun terakhir, Chromium telah memperkenalkan perubahan pada penanganan cookie pihak ketiga untuk memberikan lebih banyak keamanan dan privasi serta menawarkan lebih banyak transparansi dan kontrol kepada pengguna. Perubahan ini telah diluncurkan untuk banyak pengguna Chrome, dan dimulai dengan Android 12, perubahan tersebut kini hadir di WebView.

Atribut SameSite cookie mengontrol apakah cookie dapat dikirim dengan setiap permintaan atau hanya dengan permintaan situs yang sama. Versi dasar WebView di Android 12 (versi 89.0.4385.0) menyertakan perubahan perlindungan privasi berikut yang meningkatkan penanganan default cookie pihak ketiga dan membantu melindungi dari berbagi lintas situs yang tidak diinginkan:

  • Cookie tanpa atribut SameSite diperlakukan sebagai SameSite=Lax.
  • Cookie dengan SameSite=None juga harus menentukan atribut Secure, yang berarti cookie memerlukan konteks yang aman dan harus dikirim melalui HTTPS.
  • Link antara versi HTTP dan HTTPS situs sekarang diperlakukan sebagai permintaan lintas situs, sehingga cookie tidak dikirim kecuali jika ditandai dengan tepat sebagai SameSite=None; Secure.

Untuk developer, panduan umumnya yaitu mengidentifikasi dependensi cookie lintas situs dalam alur pengguna kritis dan memastikan bahwa atribut SameSite ditetapkan secara eksplisit dengan nilai yang sesuai jika diperlukan. Anda harus secara eksplisit menentukan cookie yang diizinkan agar dapat berfungsi di seluruh situs web atau di seluruh navigasi situs yang sama yang berpindah dari HTTP ke HTTPS.

Untuk panduan lengkap bagi developer web terkait perubahan ini, lihat SameSite Cookies Explained dan Schemeful SameSite.

Menguji perilaku SameSite di aplikasi Anda

Jika aplikasi Anda menggunakan WebView, atau jika Anda mengelola situs web atau layanan yang menggunakan cookie, sebaiknya uji alur Anda di Android 12 WebView. Jika menemukan masalah, Anda mungkin perlu memperbarui cookie untuk mendukung perilaku SameSite baru.

Perhatikan masalah pada login dan konten tersemat, serta alur login, pembelian, dan alur autentikasi lainnya jika pengguna memulai di halaman yang tidak aman dan bertransisi ke halaman yang aman.

Untuk menguji aplikasi dengan WebView, Anda harus mengaktifkan perilaku SameSite baru untuk aplikasi yang ingin diuji dengan menyelesaikan salah satu langkah berikut:

  • Aktifkan perilaku SameSite secara manual di perangkat pengujian dengan mengaktifkan tanda UI webview-enable-modern-cookie-same-site di devtools WebView.

    Dengan pendekatan ini, Anda dapat menguji perangkat yang menjalankan Android 5.0 (API level 21) atau yang lebih tinggi—termasuk Android 12 —dan WebView versi 89.0.4385.0 atau yang lebih tinggi.

  • Kompilasi aplikasi Anda untuk menargetkan Android 12 dengan targetSdkVersion.

    Jika menggunakan pendekatan ini, Anda harus menggunakan perangkat yang menjalankan Android 12 dan WebView versi 89.0.4385.0 atau yang lebih tinggi.

Untuk mengetahui informasi tentang proses debug jarak jauh untuk WebView di Android, lihat Memulai dengan Perangkat Android Proses Debug Jarak Jauh.

Referensi lainnya

Untuk mengetahui informasi peluncuran dan perilaku modern SameSite ke Chrome dan WebView selengkapnya, kunjungi halaman Update Chromium SameSite. Jika menemukan bug di WebView atau Chromium, Anda dapat melaporkannya di issue tracker Chromium publik.

Batasan cadangan ADB

Untuk membantu melindungi data aplikasi pribadi, Android 12 mengubah perilaku perintah adb backup default. Untuk aplikasi yang menargetkan Android 12, saat pengguna menjalankan perintah adb backup, data aplikasi tidak disertakan dalam data sistem lain yang diekspor dari perangkat.

Jika alur kerja pengujian atau pengembangan mengandalkan data aplikasi yang menggunakan adb backup, Anda kini dapat memilih untuk mengekspor data aplikasi dengan menyetel android:debuggable ke true di file manifes aplikasi.

Keamanan

Mengekspor komponen dengan lebih aman

Berikan ikon masukan Kami ingin mendengar masukan Anda tentang persyaratan baru ini yang berkaitan dengan ekspor komponen. Ikuti survei singkat untuk menyampaikan opini Anda. Secara khusus, beri tahu kami kasus penggunaan di aplikasi Anda yang terpengaruh oleh perubahan ini.

Jika aplikasi Anda menargetkan Android 12 dan berisi aktivitas, layanan, atau penerima siaran yang menggunakan filter intent, Anda harus secara eksplisit menyebutkan atributandroid:exported untuk komponen aplikasi ini.

Peringatan: Jika aktivitas, layanan, atau penerima siaran menggunakan filter intent dan tidak memiliki nilai android:exported yang dinyatakan secara eksplisit, aplikasi Anda tidak dapat diinstal di perangkat yang menjalankan Android 12.

Jika Anda mencoba menginstal aplikasi tersebut saat menggunakan Android Studio, Logcat akan menampilkan pesan error berikut:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

Jika aplikasi Anda tidak menyebutkan nilai untuk android:exported saat diperlukan, Logcat akan menampilkan pesan error berikut:

Targeting S+ (version 10000 and above) requires that an explicit value for \
android:exported be defined when intent filters are present

Cuplikan kode berikut menampilkan contoh layanan yang berisi filter intent dan dikonfigurasi dengan benar untuk Android 12:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Intent yang menunggu keputusan harus menyatakan mutabilitas

Berikan ikon masukan Kami ingin mendengar masukan Anda tentang persyaratan baru ini yang berkaitan dengan intent yang tertunda. Ikuti survei singkat untuk menyampaikan opini Anda. Secara khusus, beri tahu kami kasus penggunaan di aplikasi Anda yang terpengaruh oleh perubahan ini.

Jika aplikasi Anda menargetkan Android 12, Anda harus menentukan mutabilitas setiap objek PendingIntent yang dibuat oleh aplikasi Anda. Persyaratan tambahan ini meningkatkan keamanan aplikasi Anda.

Untuk menyatakan bahwa objek PendingIntent tertentu dapat diubah atau tidak, gunakan tanda PendingIntent.FLAG_MUTABLE atau PendingIntent.FLAG_IMMUTABLE. Jika aplikasi Anda mencoba membuat objek PendingIntent tanpa menyetel tanda mutabilitas, sistem akan menampilkan IllegalArgumentException, dan pesan berikut akan muncul di Logcat:

PACKAGE_NAME: Targeting S+ (version 10000 and above) requires that one of \
FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.

Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if \
some functionality depends on the PendingIntent being mutable, e.g. if \
it needs to be used with inline replies or bubbles.

Membuat intent tertunda yang tidak dapat diubah jika memungkinkan

Pada umumnya, aplikasi Anda harus membuat objek PendingIntent yang tidak dapat diubah, seperti yang ditampilkan dalam cuplikan kode berikut. Jika objek PendingIntent tidak dapat diubah, aplikasi tidak dapat mengubah intent untuk menyesuaikan hasil pemanggilan intent.

Kotlin

val pendingIntent = PendingIntent.getActivity(applicationContext,
        REQUEST_CODE, intent,
        /* flags */ PendingIntent.FLAG_IMMUTABLE)

Java

PendingIntent pendingIntent = PendingIntent.getActivity(getApplicationContext(),
        REQUEST_CODE, intent,
        /* flags */ PendingIntent.FLAG_IMMUTABLE);

Namun, aplikasi tertentu harus membuat objek PendingIntent yang dapat diubah:

Jika aplikasi Anda membuat objek PendingIntent yang dapat diubah, sebaiknya gunakan intent eksplisit dan isi ComponentName. Dengan begitu, setiap kali aplikasi lain memanggil PendingIntent dan meneruskan kontrol kembali ke aplikasi Anda, komponen yang sama di aplikasi Anda akan selalu dimulai.

Menguji perubahan mutabilitas intent yang tertunda

Untuk menentukan apakah aplikasi Anda tidak memiliki deklarasi mutabilitas, cari peringatan lint berikut di Android Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Selama Pratinjau Developer, Anda dapat menonaktifkan perilaku sistem ini untuk tujuan pengujian dengan menonaktifkan tanda kompatibilitas aplikasi PENDING_INTENT_EXPLICIT_MUTABILITY_REQUIRED.

Peluncuran intent bertingkat yang tidak aman

Untuk meningkatkan keamanan platform, Android 12 menyediakan fitur proses debug yang memperingatkan Anda jika aplikasi menjalankan peluncuran yang berbahaya dari intent bertingkat. Intent bertingkat adalah intent yang diteruskan sebagai tambahan dalam intent lain. Jika aplikasi Anda melakukan kedua tindakan berikut, pelanggaran StrictMode akan terjadi.

  1. Aplikasi Anda memisahkan intent bertingkat dari tambahan intent yang dikirim.
  2. Aplikasi Anda akan segera memulai komponen aplikasi menggunakan intent bertingkat tersebut, seperti meneruskan intent ke startActivity(), startService(), atau bindService().

Mengonfigurasikan aplikasi Anda untuk mendeteksi peluncuran intent bertingkat yang tidak aman

Untuk memeriksa peluncuran intent bertingkat yang berbahaya di aplikasi Anda, panggil detectUnsafeIntentLaunch() saat mengonfigurasi VmPolicy, seperti yang ditunjukkan dalam cuplikan kode berikut. Jika aplikasi Anda mendeteksi adanya pelanggaran StrictMode, Anda mungkin ingin menghentikan eksekusi aplikasi untuk melindungi informasi yang berpotensi sensitif.

Kotlin

fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        // Other StrictMode checks that you've previously added.
        // ...
        .detectUnsafeIntentLaunch()
        .penaltyLog()
        // Consider also adding penaltyDeath()
        .build())
}

Java

protected void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
        // Other StrictMode checks that you've previously added.
        // ...
        .detectUnsafeIntentLaunch()
        .penaltyLog()
        // Consider also adding penaltyDeath()
        .build());
}

Menggunakan intent dengan lebih bertanggung jawab

Aplikasi Anda mungkin meluncurkan intent bertingkat untuk beralih di antara komponen dalam aplikasi, atau menjalankan tindakan atas nama aplikasi lain. Untuk meminimalkan besarnya pelanggaran StrictMode dalam kedua situasi ini, lakukan hal berikut:

  • Peluncuran internal intent bertingkat: Pastikan komponen ini tidak diekspor.
  • Peluncuran lintas aplikasi untuk intent bertingkat: Gunakan PendingIntent, bukan intent bertingkat. Dengan demikian, jika PendingIntent tidak terpisahkan dari Intent yang memuatnya, komponen aplikasi dapat meluncurkan PendingIntent menggunakan identitas proses pemanggilan. Dengan konfigurasi ini, aplikasi penyedia dapat mengirim callback ke komponen apa pun, seperti komponen yang tidak diekspor, dari aplikasi pemanggil.

    Untuk detail cara mengidentifikasi situasi ini dan melakukan perubahan pada aplikasi Anda selengkapnya, baca entri blog tentang Intent Bertingkat Android di Media.

Performa

Pembatasan peluncuran layanan latar depan

Aplikasi yang menargetkan Android 12 tidak dapat lagi memulai layanan latar depan saat berjalan di latar belakang, kecuali untuk beberapa kasus khusus. Jika aplikasi mencoba memulai layanan latar depan saat berjalan di latar belakang, pengecualian terjadi (kecuali untuk beberapa kasus khusus). Pertimbangkan penggunaan WorkManager untuk menjadwalkan dan memulai pekerjaan saat aplikasi berjalan di latar belakang.

Untuk mempelajari lebih lanjut bagaimana aplikasi Anda terpengaruh, dan cara mengupdate aplikasi berdasarkan perubahan ini, baca panduan tentang pembatasan peluncuran layanan layar depan. Anda juga dapat melihat melalui WorkManagerSample di GitHub.

Trampoline notifikasi tidak dapat dibuat dari penerima siaran atau layanan

Berikan ikon masukan Kami ingin mendengar masukan Anda tentang perubahan ini pada perilaku trampoline notifikasi. Ikuti survei singkat untuk menyampaikan opini Anda. Secara khusus, beri tahu kami kasus penggunaan di aplikasi Anda yang terpengaruh oleh perubahan ini.

Saat pengguna berinteraksi dengan notifikasi, beberapa aplikasi merespons ketukan notifikasi dengan meluncurkan komponen aplikasi yang pada akhirnya memulai aktivitas sehingga akhirnya pengguna dapat melihat dan berinteraksi. Komponen aplikasi ini disebut sebagai trampoline notifikasi.

Untuk meningkatkan performa aplikasi dan UX, aplikasi yang menargetkan Android 12 tidak dapat memulai aktivitas dari layanan atau penerima siaran yang digunakan sebagai trampoline notifikasi. Dengan kata lain, setelah pengguna mengetuk notifikasi, atau tombol tindakan di notifikasi, aplikasi Anda tidak dapat memanggil startActivity() di dalam layanan atau penerima siaran.

Saat aplikasi Anda mencoba memulai aktivitas dari penerima siaran atau layanan yang bertindak sebagai trampoline notifikasi, sistem mencegah aktivitas dimulai, dan pesan berikut muncul di Logcat:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

Update aplikasi Anda

Jika aplikasi Anda memulai aktivitas dari layanan atau penerima siaran yang bertindak sebagai trampoline notifikasi, selesaikan langkah-langkah migrasi berikut:

  1. Buat objek PendingIntent yang dikaitkan dengan salah satu aktivitas berikut:

    • Aktivitas yang dilihat oleh pengguna setelah mereka mengetuk notifikasi (lebih dipilih).
    • Aktivitas trampoline, atau aktivitas yang memulai aktivitas yang dilihat oleh pengguna setelah mengetuk notifikasi.
  2. Gunakan objek PendingIntent yang Anda buat di langkah sebelumnya sebagai bagian dari membuat notifikasi.

Mengaktifkan/menonaktifkan perilaku

Saat menguji aplikasi selama Pratinjau Developer, Anda dapat mengaktifkan dan menonaktifkan pembatasan ini menggunakan tanda kompatibilitas aplikasi NOTIFICATION_TRAMPOLINE_BLOCK.

Pembatasan antarmuka non-SDK

Android 12 menyertakan daftar terbaru antarmuka non-SDK yang dibatasi berdasarkan kolaborasi dengan developer Android dan pengujian internal terbaru. Jika memungkinkan, kami akan memastikan ketersediaan alternatif publik sebelum membatasi antarmuka non-SDK.

Jika aplikasi Anda tidak menargetkan Android 12, beberapa perubahan ini mungkin tidak langsung memengaruhi Anda. Namun, meskipun saat ini Anda dapat menggunakan beberapa antarmuka non-SDK (bergantung pada API level target aplikasi Anda), penggunaan metode atau kolom non-SDK tetap sangat berisiko merusak aplikasi Anda.

Jika tidak yakin apakah aplikasi Anda menggunakan antarmuka non-SDK atau tidak, Anda dapat menguji aplikasi untuk mencari tahu. Jika aplikasi Anda mengandalkan antarmuka non-SDK, sebaiknya mulailah merencanakan migrasi ke alternatif SDK. Meskipun begitu, kami paham bahwa beberapa aplikasi memiliki kasus penggunaan yang valid untuk menggunakan antarmuka non-SDK. Jika tidak dapat menemukan alternatif penggunaan antarmuka non-SDK untuk fitur dalam aplikasi Anda, sebaiknya minta API publik baru.

Untuk mempelajari perubahan dalam rilis Android ini lebih lanjut, baca Update pembatasan antarmuka non-SDK di Android 12. Untuk mempelajari lebih lanjut antarmuka non-SDK secara umum, baca Pembatasan antarmuka non-SDK.

Perubahan notifikasi kustom

Android 12 mengubah tampilan notifikasi kustom sepenuhnya. Sebelumnya, notifikasi kustom dapat menggunakan seluruh area notifikasi serta menyediakan tata letak dan gaya sendiri. Hal ini mengakibatkan anti-pola yang dapat membingungkan pengguna atau menyebabkan masalah kompatibilitas tata letak di perangkat yang berbeda.

Untuk aplikasi yang menargetkan Android 12, notifikasi dengan tampilan konten kustom tidak akan lagi menggunakan area notifikasi lengkap; sebagai gantinya, sistem akan menerapkan template standar. Template ini memastikan bahwa notifikasi kustom memiliki dekorasi yang sama seperti notifikasi lainnya di semua status, seperti ikon notifikasi dan kemampuan perluasan (dalam status diciutkan) dan ikon notifikasi, nama aplikasi, dan kemampuan menciutkan (dalam status perluasan). Perilaku ini hampir sama dengan perilaku Notification.DecoratedCustomViewStyle.

Dengan cara ini, Android 12 membuat semua notifikasi menjadi konsisten secara visual dan mudah dipindai dengan perluasan notifikasi yang mudah ditemukan bagi pengguna.

Ilustrasi berikut menampilkan notifikasi kustom dalam template standar:

Contoh berikut menunjukkan cara merender notifikasi kustom dalam kondisi diciutkan dan diperluas:

Perubahan pada Android 12 memengaruhi aplikasi yang menentukan subkelas khusus Notification.Style, atau yang menggunakan metode setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews), dan setCustomHeadsUpContentView(RemoteViews) dari Notification.Builder.

Jika aplikasi Anda menggunakan notifikasi kustom sepenuhnya, sebaiknya lakukan pengujian dengan template baru secepatnya dan buat penyesuaian yang diperlukan:

  1. Aktifkan perubahan notifikasi khusus:

    1. Ubah targetSdkVersion aplikasi Anda menjadi S untuk mengaktifkan perilaku baru.
    2. Kompilasi ulang.
    3. Instal aplikasi Anda di perangkat atau emulator yang menjalankan Android 12.
  2. Uji semua notifikasi yang menggunakan tampilan kustom, dan pastikan terlihat seperti yang Anda harapkan di menu.

  3. Perhatikan pengukuran tampilan kustom. Secara umum, tinggi yang diberikan untuk notifikasi kustom kurang dari tinggi sebelumnya. Dalam status yang diciutkan, tinggi maksimum konten kustom telah turun dari 106 dp menjadi 48 dp. Selain itu, ruang horizontal menjadi lebih sedikit.

  4. Untuk memastikan status "Peringatan Dini" terlihat seperti yang Anda harapkan, jangan lupa untuk meningkatkan pentingnya saluran notifikasi menjadi "TINGGI" (Muncul di layar).

Konektivitas

Jika perangkat yang menargetkan Android 12 dan yang lebih tinggi berjalan di perangkat yang memiliki dukungan hardware, penggunaan koneksi peer-to-peer tidak akan memutuskan koneksi Wi-Fi yang ada saat membuat koneksi ke perangkat pembanding. Untuk memeriksa dukungan fitur ini, gunakan WifiManager.isMultiStaConcurrencySupported().