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.

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

Pengalaman pengguna

Peningkatan perilaku picture-in-picture

Android 12 memperkenalkan penyempurnaan perilaku untuk mode picture-in-picture (PiP). Lihat Peningkatan picture-in-picture untuk informasi selengkapnya.

Notifikasi kustom

Android 12 mengubah tampilan dan perilaku 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 uji dengan template baru sesegera mungkin.

  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. Saat menguji, pertimbangkan hal berikut dan lakukan penyesuaian yang diperlukan:

    • Dimensi tampilan kustom telah berubah. 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. Dan juga, terdapat ruang horizontal yang menjadi lebih sedikit.

    • Semua notifikasi dapat diperluas untuk aplikasi yang menargetkan Android 12. Biasanya, hal ini berarti jika Anda menggunakan setCustomContentView, Anda juga dapat menggunakan setBigCustomContentView untuk memastikan status diciutkan dan diluaskan secara konsisten.

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

Pada aplikasi yang menargetkan Android 12, sistem membuat beberapa perubahan pada cara Android App Link diverifikasi. Perubahan ini meningkatkan keandalan pengalaman penautan aplikasi dan memberikan kontrol lebih kepada developer aplikasi dan pengguna akhir.

Jika Anda menargetkan Android 12 dan mengandalkan verifikasi Link Aplikasi Android untuk membuka link web di aplikasi, update deklarasi Link Aplikasi Android untuk mendukung proses verifikasi yang diubah. Anda juga dapat memanggil verifikasi domain secara manual untuk menguji keandalan deklarasi Anda.

Privasi

Perkiraan lokasi

Dialog ini memiliki dua kumpulan opsi, satu di atas
         yang lain
Gambar 1. Dialog izin sistem yang muncul saat aplikasi Anda menargetkan Android 12 dan meminta ACCESS_FINE_LOCATION dan ACCESS_COARSE_LOCATION dalam satu permintaan waktu proses.

Saat menggunakan aplikasi yang menargetkan Android 12, pengguna dapat meminta agar aplikasi memiliki akses hanya untuk memperkirakan informasi lokasi.

Jika aplikasi Anda menargetkan Android 12 dan meminta izin runtime ACCESS_FINE_LOCATION, Anda juga harus meminta ACCESS_COARSE_LOCATION. Anda harus menyertakan kedua izin tersebut dalam satu permintaan waktu proses.

Saat aplikasi Anda meminta ACCESS_FINE_LOCATION dan ACCESS_COARSE_LOCATION, dialog izin sistem menyertakan opsi baru berikut untuk pengguna, seperti yang ditunjukkan pada gambar 1:

  • Keakuratan: Memberikan akurasi lokasi yang diberikan oleh izin ACCESS_FINE_LOCATION.
  • Perkiraan: Memberikan akurasi lokasi yang diberikan oleh izin ACCESS_COARSE_LOCATION.

Pelajari lebih lanjut tentang perkiraan lokasi di Android 12.

Hibernasi aplikasi

Android 12 memperluas perilaku reset otomatis izin yang diperkenalkan di Android 11 (API level 30). Jika aplikasi Anda menargetkan Android 12 dan pengguna tidak berinteraksi dengan aplikasi Anda selama beberapa bulan, sistem akan secara otomatis mereset izin yang diberikan dan menempatkan aplikasi Anda dalam status hibernasi.

Aplikasi yang sedang dalam mode hibernasi memiliki karakteristik berikut:

  • Sistem mengoptimalkan ruang penyimpanan, daripada performa. Semua file di cache aplikasi akan dihapus.
  • Aplikasi tidak dapat menjalankan tugas atau pemberitahuan dari latar belakang.
  • Aplikasi tidak dapat menerima notifikasi push, termasuk pesan berprioritas tinggi yang dikirim melalui Firebase Cloud Messaging.

Ketika pengguna selanjutnya berinteraksi dengan aplikasi, aplikasi akan keluar dari hibernasi dan dapat membuat tugas, pemberitahuan, serta notifikasi lagi. Namun, Anda perlu menjadwalkan ulang tugas, pemberitahuan, dan notifikasi apa pun yang dijadwalkan sebelum aplikasi beralih ke hibernasi. Alur kerja ini mirip dengan ketika pengguna memaksa aplikasi untuk berhenti dari setelan sistem secara manual. Untuk mendukung alur kerja ini dengan lebih mudah, gunakan WorkManager. Anda juga dapat menambahkan logika penjadwalan ulang di penerima siaran ACTION_BOOT_COMPLETED yang dipanggil saat aplikasi keluar dari hibernasi dan setelah perangkat melakukan booting.

Meminta pengguna untuk menonaktifkan hibernasi

Jika Anda mengantisipasi bahwa kasus penggunaan di aplikasi terpengaruh oleh hibernasi, Anda dapat mengirim permintaan kepada pengguna untuk memberikan pengecualian kepada aplikasi dari hibernasi dan reset otomatis izin. Pengecualian ini berguna pada situasi saat pengguna mengharapkan aplikasi Anda berfungsi terutama di latar belakang, bahkan tanpa pengguna berinteraksi dengan aplikasi Anda, seperti saat aplikasi melakukan satu atau beberapa hal berikut:

  • Berikan keamanan keluarga dengan melaporkan lokasi anggota keluarga secara berkala.
  • Menyinkronkan data antara perangkat dan server aplikasi Anda.
  • Berkomunikasi dengan perangkat smart, seperti TV.
  • Sambungkan ke perangkat pendamping, seperti jam tangan.

Untuk meminta pengecualian, panggil intent yang berisi tindakan intent Intent.ACTION_APPLICATION_DETAILS_SETTINGS. Dari layar yang muncul, pengguna dapat menonaktifkan opsi yang disebut Hapus izin dan kosongkan ruang.

Menguji perilaku hibernasi

Untuk menempatkan aplikasi Anda dalam status hibernasi dengan tujuan pengujian, lakukan hal berikut:

  1. Aktifkan perilaku di perangkat Anda:

    adb shell device_config put app_hibernation app_hibernation_enabled true
    
  2. Ubah status aplikasi Anda sehingga masuk ke mode tidur. Perintah yang menyertakan tanda --global memaksa aplikasi Anda masuk ke "hibernasi penuh", untuk menyimulasikan situasi saat sistem menempatkan aplikasi Anda ke dalam hibernasi untuk semua pengguna di multi-pengguna.

    adb shell cmd app_hibernation set-state PACKAGE-NAME true && \
      adb shell cmd app_hibernation set-state --global PACKAGE-NAME true
    

Sensor gerakan memiliki batas kecepatan

Untuk melindungi informasi yang berpotensi sensitif tentang pengguna, jika aplikasi Anda menargetkan Android 12, sistem akan menempatkan pembatasan pada kecepatan refresh data dari sensor gerakan dan sensor posisi tertentu. Data ini mencakup nilai yang dicatat oleh perangkat akselerometer, giroskop, dan sensor medan geomagnetik.

Batas kecepatan refresh bergantung pada cara Anda mengakses data sensor:

  • Jika Anda memanggil metode registerListener(), frekuensi sample sensor dibatasi hingga 200 Hz. Hal ini berlaku untuk semua varian registerListener() metode yang kelebihan beban.
  • Jika Anda menggunakan class SensorDirectChannel, frekuensi sampel sensor dibatasi hingga RATE_NORMAL, yang biasanya sekitar 50 Hz.

Jika aplikasi Anda menargetkan Android 12 dan perlu mengumpulkan data sensor gerakan dengan kecepatan yang lebih tinggi, Anda harus mendeklarasikan izin HIGH_SAMPLING_RATE_SENSORS. Jika tidak, jika aplikasi Anda mencoba untuk mengumpulkan data sensor gerakan dengan kecepatan yang lebih tinggi tanpa menyatakan izin ini, SecurityException akan muncul.

Audit akses data

API pengauditan akses data, yang diperkenalkan di Android 11 (API level 30), memungkinkan Anda untuk membuat tag atribusi berdasarkan kasus penggunaan aplikasi. Tag ini memudahkan Anda untuk menentukan bagian mana dari aplikasi Anda yang menjalankan jenis akses data tertentu.

Jika aplikasi Anda menargetkan Android 12, Anda harus mendeklarasikan tag atribusi ini dalam file manifes aplikasi dengan menggunakan format yang akan ditampilkan dalam cuplikan kode berikut. Jika aplikasi Anda menargetkan Android 12 dan Anda mencoba menggunakan tag atribusi yang tidak deklarasikan dalam file manifes aplikasi, sistem akan membuat tag null untuk Anda dan mencatat pesan dalam Logcat.


<manifest ...>
    <!-- The value of "android:tag" must be a literal string, and the
         value of "android:label" must be a resource. The value of
         "android:label" should be user-readable. -->
    <attribution android:tag="sharePhotos"
                 android:label="@string/share_photos_attribution_label" />
    ...
</manifest>

Cookie Modern SameSite 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.

Pembatasan 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 disertakan dalam data sistem lainnya 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 yang lebih aman

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.

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>

Message di Android Studio

Jika aplikasi Anda berisi aktivitas, layanan, atau penerima siaran yang menggunakan filter intent, tetapi tidak mendeklarasikan android:exported, pesan peringatan berikut akan muncul bergantung pada versi Android Studio yang Anda gunakan:

Android Studio 2020.3.1 Canary 11 atau yang lebih baru

Pesan berikut akan muncul:

  1. Peringatan lint berikut akan muncul di file manifes:

    When using intent filters, please specify android:exported as well
    
  2. Saat Anda mencoba mengompilasi aplikasi, pesan error build berikut akan muncul:

    Manifest merger failed : Apps targeting Android 12 and higher are required \
    to specify an explicit value for android:exported when the corresponding \
    component has an intent filter defined.
    
Android Studio versi lama

Jika Anda mencoba menginstal aplikasi, 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'

Mutabilitas intent yang tertunda

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 yang tidak aman

Untuk meningkatkan keamanan platform, Android 12 menyediakan fitur proses debug yang memperingatkan Anda jika aplikasi akan menjalankan peluncuran yang tidak aman dari intent. Misalnya, aplikasi Anda mungkin melakukan peluncuran inten yang tidak aman yang dibuat ulang dari URI, atau peluncuran intent bertingkat yang tidak aman, yang ditentukan di bagian berikutnya.

Tentang intent bertingkat

Intent bertingkat adalah intent yang diteruskan sebagai tambahan ke dalam intent lain. Jika aplikasi Anda melakukan kedua tindakan berikut, pelanggaran StrictMode akan terjadi.

Mengonfigurasi aplikasi Anda untuk mendeteksi peluncuran intent yang tidak aman

Untuk memeriksa peluncuran intent yang tidak aman di aplikasi Anda, panggil detectUnsafeIntentLaunch() saat Anda 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 untuk beralih di antara komponen di dalam aplikasi, atau menjalankan tindakan atas nama aplikasi lain. Untuk meminimalkan besarnya pelanggaran StrictMode dalam kedua situasi ini, lakukan hal berikut:

  • Salin saja tambahan esensial ke dalam intent dan lakukan pembersihan dan validasi yang diperlukan. Aplikasi Anda mungkin akan menyalin tambahan dari satu intent ke intent lain yang digunakan untuk meluncurkan komponen baru. Hal ini terjadi saat aplikasi Anda memanggil putExtras(Intent) atau putExtras(Bundle). Jika aplikasi Anda melakukan salah satu operasi ini, salin saja tambahan yang diharapkan komponen penerima. Jika intent lain (yang menerima salinan) meluncurkan komponen yang tidak diekspor, bersihkan dan validasikan tambahan sebelum menyalinnya ke intent yang meluncurkan komponen.
  • Peluncuran internal intent bertingkat: Pastikan komponen ini tidak diekspor.
  • Peluncuran lintas aplikasi untuk intent bertingkat: Gunakan PendingIntent, bukan intent bertingkat. Dengan demikian, ketika PendingIntent tidak terpisahkan dari Intent yang memuatnya, komponen aplikasi dapat meluncurkan PendingIntent dengan 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.

Izin alarm yang tepat

Untuk mendorong aplikasi agar menghemat resource sistem, Android 12 memerlukan akses aplikasi khusus "Alarm & pengingat" ke aplikasi yang menargetkan Android 12 yang menyetel alarm yang tepat.

Untuk mendapatkan akses aplikasi khusus ini, minta izin SCHEDULE_EXACT_ALARM dalam manifes.

Alarm yang tepat hanya boleh digunakan untuk fitur yang dihadapi pengguna, seperti salah satu situasi yang dijelaskan di bagian kasus penggunaan yang dapat diterima.

Pengguna dan sistem dapat mencabut akses aplikasi khusus "Alarm & pengingat". Jika akses aplikasi khusus "Alarm & pengingat" dicabut untuk aplikasi Anda, aplikasi akan dihentikan dan semua alarm yang tepat di masa mendatang akan dibatalkan.

Jika akses aplikasi khusus "Alarm & pengingat" diberikan ke aplikasi Anda, sistem akan mengirimkan siaran ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED. Aplikasi Anda harus menerapkan penerima siaran yang melakukan hal berikut:

  1. Konfirmasikan bahwa aplikasi Anda masih memiliki akses aplikasi khusus. Untuk melakukannya, panggil canScheduleExactAlarms()
  2. Menjadwalkan ulang alarm apa pun yang tepat yang diperlukan aplikasi Anda, berdasarkan statusnya saat ini. Logika ini harus mirip dengan yang dilakukan aplikasi Anda saat menerima siaran ACTION_BOOT_COMPLETED.

Jika aplikasi Anda mencoba menggunakan API yang menyetel alarm yang tepat tetapi tidak diberi akses aplikasi khusus, SecurityException akan muncul.

Pertimbangkan apakah kasus penggunaan aplikasi Anda benar-benar memerlukan alarm yang tepat, seperti salah satu situasi yang dijelaskan di bagian kasus penggunaan yang dapat diterima. Untuk melakukan pekerjaan yang lebih lama, atau pekerjaan yang memerlukan akses jaringan, gunakan WorkManager atau JobScheduler. Untuk melakukan pekerjaan saat perangkat berada dalam mode Istirahatkan, buat alarm yang tidak tepat dengan menggunakan setAndAllowWhileIdle(), dan mulai tugas dari alarm.

Alarm yang tepat dan alarm yang tidak tepat

Aplikasi Anda akan menyetel alarm yang tepat saat memanggil metode seperti berikut:

Sebaliknya, Anda akan menyetel alarm tidak tepat saat memanggil metode seperti berikut:

Kasus penggunaan yang dapat diterima untuk izin ini

Opsi ini disebut &#39;Izinkan setelan alarm dan pengingat&#39;
Gambar 2. Halaman akses aplikasi khusus "Alarm & pengingat" di setelan sistem, tempat pengguna dapat mengizinkan aplikasi Anda untuk menyetel alarm yang tepat.

Aplikasi Anda harus menggunakan alarm yang tepat, serta mendeklarasikan izin terkait dan penerima siaran, hanya jika fungsi yang dilihat pengguna di aplikasi Anda memerlukan tindakan tepat waktu, seperti dalam situasi berikut:

  • Aplikasi Anda adalah aplikasi jam alarm atau aplikasi timer.
  • Aplikasi Anda memungkinkan pengguna menjadwalkan tindakan dengan waktu yang tepat, seperti notifikasi untuk tugas dan peristiwa.

Android 12 menganggap alarm yang tepat adalah gangguan yang penting dan sensitif terhadap waktu. Oleh karena itu, alarm yang tepat tidak terpengaruh oleh pembatasan peluncuran layanan latar depan baru.

Meminta pengguna untuk memberikan akses aplikasi

Jika perlu, Anda dapat mengarahkan pengguna ke layar Alarm & pengingat di setelan sistem, seperti yang ditunjukkan pada gambar 2. Caranya, ikuti langkah-langkah berikut:

  1. Di UI aplikasi, jelaskan kepada pengguna alasan aplikasi Anda perlu menjadwalkan alarm yang tepat.
  2. Panggil intent yang menyertakan tindakan intent ACTION_REQUEST_SCHEDULE_EXACT_ALARM.

Mengaktifkan perubahan perilaku

Guna mengaktifkan perubahan perilaku untuk tujuan pengujian, lakukan salah satu hal berikut:

  • Pada layar setelan Opsi Developer, pilih Perubahan Kompatibilitas Aplikasi. Pada layar yang muncul, ketuk nama aplikasi Anda, lalu aktifkan REQUIRE_EXACT_ALarm_PERMISSION.
  • Pada jendela terminal di mesin pengembangan, jalankan perintah berikut:

    adb shell am compat enable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
    

Pembatasan notifikasi trampolin

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.

Mengidentifikasi komponen aplikasi yang berfungsi sebagai notifikasi trampolin

Saat menguji aplikasi, setelah mengetuk notifikasi, Anda dapat mengidentifikasi layanan atau penerima siaran mana yang bertindak sebagai trampoline notifikasi di aplikasi Anda. Untuk melakukannya, lihat output dari perintah terminal berikut:

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

Bagian dari output menyertakan teks "NotifInteractionLog". Bagian ini berisi informasi yang diperlukan untuk mengidentifikasi komponen yang dimulai sebagai hasil dari ketukan notifikasi.

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 aktivitas yang dilihat pengguna setelah mereka mengetuk notifikasi.
  2. Gunakan objek PendingIntent yang Anda buat di langkah sebelumnya sebagai bagian dari membuat notifikasi.

Untuk mengidentifikasi asal aktivitas atau untuk melakukan logging, misalnya, gunakan tambahan saat memposting notifikasi. Untuk logging terpusat, gunakan ActivityLifecycleCallbacks atau pengamat siklus proses Jetpack.

Mengaktifkan/menonaktifkan perilaku

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

Pencadangan dan pemulihan

Android 12 mengubah cara kerja pencadangan dan pemulihan dalam aplikasi yang berjalan serta menargetkan Android 12 atau yang lebih tinggi. Untuk informasi selengkapnya, lihat Perubahan pada pencadangan dan pemulihan.

Konektivitas

Koneksi Peer-to-Peer + Koneksi Internet Serentak

Dimulai dengan Android 12, perangkat yang mendukung peer-to-peer dan koneksi internet secara bersamaan dapat mempertahankan koneksi Wi-Fi secara bersamaan pula ke perangkat peer dan jaringan penyedia internet utama, sehingga pengalaman pengguna menjadi lebih lancar. Fitur ini diaktifkan secara otomatis untuk semua aplikasi yang menargetkan API level 31 dan yang lebih tinggi. Aplikasi yang menargetkan API level yang lebih rendah masih mengalami perilaku lama dengan koneksi jaringan Wi-Fi utama terputus sebelum terhubung ke perangkat peer.

Kompatibilitas

WifiManager.getConnectionInfo() dapat menampilkan WifiInfo hanya untuk satu jaringan. Karena itu, perilaku API telah diubah dengan cara berikut di Android 12:

  • Jika hanya satu jaringan Wi-Fi yang tersedia, WifiInfo akan ditampilkan.
  • Jika lebih dari satu jaringan Wi-Fi tersedia dan aplikasi panggilan memicu sambungan peer-to-peer, WifiInfo yang sesuai dengan perangkat peer akan dikembalikan.
  • Jika lebih dari satu jaringan Wi-Fi tersedia dan aplikasi panggilan tidak memicu sambungan peer-to-peer, WifiInfo sambungan utama penyedia internet akan ditampilkan.

Untuk memberikan pengalaman pengguna yang lebih baik pada perangkat yang mendukung jaringan Wi-Fi serentah, kami merekomendasikan semua aplikasi—terutama aplikasi yang memicu koneksi peer-to-peer—bermigrasi untuk tidak memanggil WifiManager.getConnectionInfo() dan sebagai gantinya, gunakan NetworkCallback.onCapabilitiesChanged() untuk mendapatkan semua objek WifiInfo yang cocok dengan NetworkRequest yang digunakan untuk mendaftarkan NetworkCallback. getConnectionInfo() tidak digunakan lagi mulai di Android 12.

Contoh kode berikut menunjukkan cara mendapatkan WifiInfo di NetworkCallback:

Kotlin

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

Java

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

Mengaktifkan layar nonaktif untuk pembayaran NFC

Pada aplikasi yang menargetkan Android 12 dan lebih tinggi, Anda dapat mengaktifkan pembayaran NFC tanpa mengaktifkan layar perangkat dengan menyetel requireDeviceScreenOn ke false. Untuk informasi selengkapnya tentang pembayaran NFC dengan layar nonaktif atau terkunci, lihat Perilaku layar nonaktif dan layar kunci.

Library vendor

Library bersama bawaan yang disediakan oleh vendor

Library bersama native non-NDK yang disediakan oleh vendor silicon atau produsen perangkat tidak dapat diakses secara default jika aplikasi menargetkan Android 12 atau lebih tinggi. Library hanya dapat diakses jika diminta secara eksplisit dengan menggunakan tag <uses-native-library>.

Jika aplikasi menargetkan Android 11 atau yang lebih rendah, tag <uses-native-library> tidak diperlukan. Dalam hal ini, semua library bersama native dapat diakses terlepas dari apakah library tersebut merupakan library NDK atau bukan.

Pembatasan non-SDK yang diupdate

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 tentang antarmuka non-SDK secara umum, baca Pembatasan antarmuka non-SDK.