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

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 kustom:

    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 bagian yang diarsir. 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 atau yang lebih baru, sistem membuat beberapa perubahan pada cara verifikasi Link Aplikasi Android . Perubahan ini meningkatkan keandalan pengalaman penautan aplikasi dan memberikan kontrol lebih kepada developer aplikasi dan pengguna akhir.

Jika Anda mengandalkan verifikasi Link Aplikasi Android untuk membuka link web di aplikasi, periksa apakah Anda menggunakan format yang benar saat menambahkan filter intent untuk verifikasi Link Aplikasi Android. Khususnya, pastikan filter intent ini menyertakan kategori BROWSABLE dan mendukung skema https.

Anda juga dapat memverifikasi secara manual link aplikasi Anda untuk menguji keandalan deklarasi.

Pengoptimalan perilaku picture-in-picture

Android 12 memperkenalkan peningkatan perilaku untuk mode picture-in-picture (PiP), dan peningkatan kosmetik yang direkomendasikan untuk animasi transisi bagi navigasi gestur dan navigasi berbasis elemen.

Lihat Peningkatan picture-in-picture untuk informasi selengkapnya.

Mendesain ulang toast

Di Android 12, tampilan toast telah didesain ulang. Toast sekarang hanya boleh berisi dua baris teks dan menampilkan ikon aplikasi di samping teks.

Gambar perangkat Android yang menampilkan pop-up toast bertuliskan 'Sending message' di samping ikon aplikasi

Lihat Ringkasan toast untuk detail lebih lanjut.

Keamanan dan privasi

Perkiraan lokasi

Di perangkat yang menjalankan Android 12 atau yang lebih tinggi, pengguna dapat meminta akurasi perkiraan lokasi untuk aplikasi Anda.

Cookie Modern SameSite di WebView

Komponen WebView Android didasarkan pada Chromium, yaitu project open source yang mendukung browser Chrome Google. Chromium memperkenalkan perubahan pada penanganan cookie pihak ketiga untuk memberikan keamanan dan privasi yang lebih serta menawarkan transparansi dan kontrol yang lebih besar kepada pengguna. Mulai Android 12, perubahan ini juga disertakan dalam WebView saat aplikasi menargetkan Android 12 (API level 31) atau yang lebih baru.

Atribut SameSite cookie mengontrol apakah cookie dapat dikirim dengan setiap permintaan atau hanya dengan permintaan situs yang sama. Perubahan perlindungan privasi berikut akan mengoptimalkan 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 adalah mengidentifikasi dependensi cookie lintas situs dalam alur penggunaan yang 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 WebView Android 12. 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 flag 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 (API level 31) dengan targetSdkVersion.

    Jika menggunakan pendekatan ini, Anda harus menggunakan perangkat yang menjalankan Android 12.

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.

Sensor gerakan memiliki batas kecepatan

Untuk melindungi informasi yang berpotensi sensitif tentang pengguna, jika aplikasi Anda menargetkan Android 12 atau yang lebih baru, sistem akan menempatkan pembatasan pada kecepatan refresh data dari sensor gerakan dan sensor posisi tertentu.

Pelajari pembatasan kapasitas sensor lebih lanjut.

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.

Pelajari lebih lanjut dalam panduan tentang hibernasi aplikasi.

Deklarasi atribusi dalam audit akses data

API audit 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 menargetkan Android 12 atau yang lebih baru, Anda harus mendeklarasikan tag atribusi dalam file manifes aplikasi.

Pembatasan cadangan ADB

Untuk membantu melindungi data aplikasi pribadi, Android 12 mengubah perilaku perintah adb backup default. Untuk aplikasi yang menargetkan Android 12 (API level 31) atau yang lebih baru, saat pengguna menjalankan perintah adb backup, data aplikasi akan dikecualikan dari 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.

Mengekspor komponen dengan lebih aman

Jika aplikasi Anda menargetkan Android 12 atau yang lebih baru dan berisi aktivitas, layanan, atau penerima siaran yang menggunakan filter intent, Anda harus secara eksplisit mendeklarasikan atribut android:exported untuk komponen aplikasi ini.

Jika komponen aplikasi menyertakan kategori LAUNCHER, tetapkan android:exported ke true. Dalam sebagian besar kasus lain, tetapkan android:exported ke false.

Cuplikan kode berikut menampilkan contoh layanan yang berisi filter intent yang atribut android:exported-nya ditetapkan ke false:

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

Menguji perubahan mutabilitas intent yang tertunda

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Peluncuran intent yang tidak aman

Untuk meningkatkan keamanan platform, Android 12 dan yang lebih baru menyediakan fitur proses debug yang mendeteksi peluncuran intent yang tidak aman. Saat sistem mendeteksi peluncuran yang tidak aman tersebut, pelanggaran StrictMode akan terjadi.

Performa

Pembatasan peluncuran layanan latar depan

Aplikasi yang menargetkan Android 12 atau yang lebih baru tidak dapat 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, akan terjadi pengecualian (kecuali untuk beberapa kasus khusus).

Pertimbangkan penggunaan WorkManager untuk menjadwalkan dan memulai pekerjaan yang dipercepat saat aplikasi berjalan di latar belakang. Untuk menyelesaikan tindakan yang sensitif terhadap waktu yang diminta pengguna, mulai layanan latar depan dalam alarm yang tepat.

Izin alarm yang tepat

Untuk mendorong aplikasi menghemat resource sistem, aplikasi yang menargetkan Android 12 dan yang lebih baru dan menyetel alarm yang tepat harus memiliki akses ke kemampuan "Alarm & pengingat" yang muncul dalam layar Akses aplikasi khusus di setelan sistem.

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

Alarm yang tepat sebaiknya hanya digunakan untuk fitur yang dilihat pengguna. Pelajari kasus penggunaan yang dapat diterima untuk menyetel alarm yang tepat lebih lanjut.

Menonaktifkan perubahan perilaku

Saat menyiapkan aplikasi untuk menargetkan Android 12, Anda dapat menonaktifkan sementara perubahan perilaku dalam varian build yang dapat di-debug untuk tujuan pengujian. Untuk melakukannya, selesaikan salah satu dari tugas berikut:

  • Pada layar setelan Opsi Developer, pilih Perubahan Kompatibilitas Aplikasi. Pada layar yang muncul, ketuk nama aplikasi Anda, lalu nonaktifkan REQUIRE_EXACT_ALARM_PERMISSION.

  • Pada jendela terminal di mesin pengembangan, jalankan perintah berikut:

    adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME

Pembatasan trampolin notifikasi

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 trampolin notifikasi.

Untuk meningkatkan performa aplikasi dan UX, aplikasi yang menargetkan Android 12 atau yang lebih baru tidak dapat memulai aktivitas dari layanan atau penerima siaran yang digunakan sebagai trampolin 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 trampolin 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 trampolin notifikasi

Saat menguji aplikasi, setelah mengetuk notifikasi, Anda dapat mengidentifikasi layanan atau penerima siaran mana yang bertindak sebagai trampolin 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.

Mengupdate aplikasi Anda

Jika aplikasi Anda memulai aktivitas dari layanan atau penerima siaran yang bertindak sebagai trampolin 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, misalnya untuk melakukan logging, gunakan tambahan saat memposting notifikasi. Untuk logging terpusat, gunakan ActivityLifecycleCallbacks atau observer siklus proses Jetpack.

Mengaktifkan/menonaktifkan perilaku

Saat menguji versi aplikasi yang dapat di-debug, Anda dapat mengaktifkan dan menonaktifkan batasan ini menggunakan flag kompatibilitas aplikasi NOTIFICATION_TRAMPOLINE_BLOCK.

Pencadangan dan pemulihan

Terdapat perubahan pada cara kerja pencadangan dan pemulihan di aplikasi yang berjalan di dan menargetkan Android 12 (API level 31). Ada dua bentuk pencadangan dan pemulihan Android:

  • Pencadangan cloud: Data pengguna disimpan di Google Drive pengguna agar dapat dipulihkan di perangkat tersebut atau di perangkat baru.
  • Transfer perangkat ke perangkat (D2D): Data pengguna dikirim langsung ke perangkat baru pengguna dari perangkat lama mereka, seperti dengan menggunakan kabel.

Untuk informasi selengkapnya tentang cara pencadangan dan pemulihan data, lihat Mencadangkan data pengguna dengan Pencadangan Otomatis dan Mencadangkan pasangan nilai kunci dengan Android Backup Service.

Perubahan fungsi transfer D2D

Untuk aplikasi yang berjalan di dan menargetkan Android 12 dan versi lebih tinggi:

  • Menentukan aturan yang disertakan dan dikecualikan dengan mekanisme konfigurasi XML tidak memengaruhi transfer D2D, meskipun masih memengaruhi pencadangan dan pemulihan berbasis cloud (seperti pencadangan Google Drive). Untuk menentukan aturan transfer D2D, Anda harus menggunakan konfigurasi baru yang dibahas di bagian berikutnya.

  • Di perangkat dari beberapa produsen perangkat, menentukan android:allowBackup="false" akan menonaktifkan pencadangan ke Google Drive, tetapi tidak menonaktifkan transfer D2D untuk aplikasi.

Format penyertaan dan pengecualian yang baru

Aplikasi yang berjalan di dan menargetkan Android 12 dan versi yang lebih tinggi menggunakan format berbeda untuk konfigurasi XML. Format ini menjadi pembeda antara pencadangan Google Drive dan transfer D2D dengan mengharuskan Anda menentukan aturan penyertaan dan pengecualian secara terpisah untuk pencadangan cloud dan untuk transfer D2D.

Secara opsional, Anda juga dapat menggunakannya untuk menentukan aturan pencadangan, yang dalam hal ini mengabaikan konfigurasi yang digunakan sebelumnya pada perangkat yang menjalankan Android 12 atau yang lebih baru. Konfigurasi lama masih diperlukan untuk perangkat yang menjalankan Android 11 atau yang lebih lama.

Perubahan format XML

Berikut adalah format yang digunakan untuk konfigurasi pencadangan dan pemulihan di Android 11 dan yang lebih lama:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

Berikut ini menunjukkan perubahan dalam format yang dicetak tebal.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

Untuk informasi selengkapnya, lihat bagian yang sesuai dalam panduan untuk mencadangkan data pengguna dengan Pencadangan Otomatis.

Flag manifes untuk aplikasi

Arahkan aplikasi ke konfigurasi XML baru menggunakan atribut android:dataExtractionRules di file manifes. Saat Anda mengarahkan kursor ke konfigurasi XML baru, atribut android:fullBackupContent yang mengarah ke konfigurasi lama akan diabaikan di perangkat yang menjalankan Android 12 atau yang lebih baru. Contoh kode berikut menunjukkan entri file manifes yang baru:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

Konektivitas

Izin Bluetooth

Android 12 memperkenalkan izin BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE, dan BLUETOOTH_CONNECT . Izin ini mempermudah aplikasi yang menargetkan Android 12 untuk berinteraksi dengan perangkat Bluetooth, terutama untuk aplikasi yang tidak memerlukan akses ke lokasi perangkat.

Guna menyiapkan perangkat untuk menargetkan Android 12 atau yang lebih baru, perbarui logika aplikasi Anda. Dibandingkan mendeklarasikan kumpulan izin Bluetooth lama, deklarasikan kumpulan izin Bluetooth yang lebih modern.

Peer-to-Peer + Koneksi Internet Serentak

Untuk aplikasi yang menargetkan Android 12 (API level 31) atau yang lebih baru, perangkat yang mendukung peer-to-peer dan koneksi internet serentak dapat mempertahankan koneksi Wi-Fi simultan ke perangkat pembanding dan jaringan penyedia internet utama, untuk menjadikan pengalaman pengguna lebih lancar. Aplikasi yang menargetkan Android 11 (API level 30) atau yang lebih lama masih mengalami perilaku lama, dengan jaringan Wi-Fi utama terputus sebelum terhubung ke perangkat pembanding.

Kompatibilitas

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

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

Untuk memberikan pengalaman pengguna yang lebih baik pada perangkat yang mendukung jaringan Wi-Fi serentak, 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;
    ...
  }
  ...
};

API native mDNSResponder

Android 12 berubah saat aplikasi dapat berinteraksi dengan daemon mDNSResponder menggunakan API native mDNSResponder. Sebelumnya, saat aplikasi mendaftarkan layanan di jaringan dan memanggil metode getSystemService(), layanan NSD sistem akan memulai daemon mDNSResponder, meskipun aplikasi belum memanggil metode NsdManager apa pun. Daemon kemudian membuat perangkat berlangganan ke grup multicast semua-node, sehingga sistem akan lebih sering aktif dan menggunakan daya tambahan. Untuk meminimalkan penggunaan baterai, di Android 12 dan yang lebih baru, sistem sekarang memulai daemon mDNSResponder hanya saat diperlukan untuk peristiwa NSD dan menghentikannya setelahnya.

Karena perubahan ini memengaruhi kapan daemon mDNSResponder tersedia, aplikasi yang menganggap bahwa daemon mDNSResponder akan dimulai setelah memanggil metode getSystemService() mungkin menerima pesan dari sistem yang menyatakan daemon mDNSResponder tidak tersedia. Aplikasi yang menggunakan NsdManager dan tidak menggunakan API native mDNSResponder tidak akan terpengaruh oleh perubahan ini.

Library vendor

Library bersama native 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 (API level 31) atau yang lebih baru. Library hanya dapat diakses jika diminta secara eksplisit dengan menggunakan tag <uses-native-library> .

Jika aplikasi menargetkan Android 11 (API level 30) atau yang lebih lama, 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 diperbarui

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 Pembaruan pembatasan antarmuka non-SDK di Android 12. Untuk mempelajari lebih lanjut antarmuka non-SDK secara umum, baca Pembatasan antarmuka non-SDK.