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:
![](https://developer.android.com/static/images/about/versions/12/custom-collapsed-view.png?authuser=8&hl=id)
![](https://developer.android.com/static/images/about/versions/12/custom-expanded-view.png?authuser=8&hl=id)
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.
Aktifkan perubahan notifikasi kustom:
- Ubah
targetSdkVersion
aplikasi Anda menjadiS
untuk mengaktifkan perilaku baru. - Kompilasi ulang.
- Instal aplikasi Anda di perangkat atau emulator yang menjalankan Android 12.
- Ubah
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 menggunakansetBigCustomContentView
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).
Perubahan verifikasi Link Aplikasi Android
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 rekomendasi peningkatan tampilan pada animasi transisi untuk kedua {i>gestures<i} navigasi dan navigasi berbasis elemen.
Lihat Picture-in-picture untuk mengetahui tidak akurat atau tidak sesuai.
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](https://developer.android.com/static/images/toast.png?authuser=8&hl=id)
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 sebagaiSameSite=Lax
. - Cookie dengan
SameSite=None
juga harus menentukan atributSecure
, 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:
Peringatan lint berikut akan muncul di file manifes:
When using intent filters, please specify android:exported as well
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:
- Buat objek
PendingIntent
yang dikaitkan dengan aktivitas yang dilihat pengguna setelah mereka mengetuk notifikasi. - 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 pencatatan terpusat, gunakan
ActivityLifecycleCallbacks
atau pengamat 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 sehingga nantinya dapat dipulihkan di perangkat tersebut atau perangkat baru.
- Transfer perangkat ke perangkat (D2D): Data pengguna dikirim langsung ke perangkat baru pengguna dari perangkat lama, seperti dengan menggunakan kabel.
Untuk informasi selengkapnya tentang cara pencadangan dan pemulihan data, lihat Mencadangkan pengguna data dengan Pencadangan Otomatis dan Cadangkan 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 sertakan dan kecualikan dengan XML mekanisme konfigurasi ini tidak mempengaruhi transfer D2D, meskipun masih memengaruhi pencadangan dan pemulihan berbasis cloud (seperti pencadangan Google Drive). Kepada menetapkan aturan transfer D2D, Anda harus menggunakan konfigurasi baru yang di bagian berikutnya.
Pada perangkat dari beberapa produsen perangkat, menentukan
android:allowBackup="false"
menonaktifkan pencadangan untuk 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, dalam hal ini konfigurasi yang sebelumnya digunakan akan diabaikan di perangkat yang menjalankan Android 12 atau lebih tinggi. Konfigurasi lama masih diperlukan untuk perangkat yang menjalankan Android 11 atau lebih rendah.
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 Anda ke konfigurasi XML baru dengan menggunakan
Atribut android:dataExtractionRules
di manifes Anda
. Bila Anda mengarahkan ke konfigurasi XML baru,
Atribut android:fullBackupContent
yang mengarah ke konfigurasi lama diabaikan
di perangkat yang menjalankan Android 12 atau yang lebih baru. Contoh kode berikut menunjukkan versi
entri file manifes:
<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.