Seperti rilis sebelumnya, Android 13 menyertakan perubahan perilaku yang dapat memengaruhi aplikasi Anda. Perubahan perilaku berikut ini berlaku khusus bagi aplikasi yang menargetkan Android 13 atau yang lebih tinggi. Jika aplikasi menargetkan Android 13 atau yang lebih tinggi, Anda harus memodifikasi aplikasi untuk mendukung perilaku ini dengan benar, jika berlaku.
Pastikan Anda meninjau daftar perubahan perilaku yang memengaruhi semua aplikasi yang berjalan di Android 13.
Privasi
Izin notifikasi memengaruhi tampilan layanan latar depan
Jika menolak izin notifikasi, pengguna tidak akan melihat notifikasi yang terkait dengan layanan latar depan di panel samping notifikasi. Namun, pengguna masih melihat notifikasi yang terkait dengan layanan latar depan di Pengelola Tugas Layanan Latar Depan (FGS), terlepas dari diberikan atau tidaknya izin notifikasi.
Izin runtime baru untuk perangkat Wi-Fi di sekitar
Pada versi Android sebelumnya, pengguna perlu memberikan izin
ACCESS_FINE_LOCATION
pada aplikasi untuk menyelesaikan beberapa kasus penggunaan Wi-Fi umum.
Dengan alasan sulit bagi pengguna untuk mengaitkan izin akses lokasi dengan fungsi
Wi-Fi, Android 13 (API level 33) memperkenalkan izin runtime dalam
grup izin
NEARBY_DEVICES
untuk aplikasi yang mengelola koneksi perangkat ke titik
akses di sekitar melalui Wi-Fi. Izin ini,
NEARBY_WIFI_DEVICES,
memenuhi kasus penggunaan Wi-Fi seperti berikut:
- Menemukan atau menghubungkan ke perangkat di sekitar, seperti printer atau perangkat transmisi media.
Alur kerja ini memungkinkan aplikasi Anda menyelesaikan tugas semacam ini:
- Menerima informasi AP di luar band, seperti melalui BLE.
- Menemukan dan menghubungkan ke perangkat melalui Wi-Fi Aware dan menghubungkannya menggunakan hotspot khusus lokal.
- Menemukan dan menghubungkan ke perangkat melalui Wi-Fi Langsung.
- Memulai koneksi ke SSID yang dikenal, seperti mobil atau perangkat smart home.
- Memulai hotspot khusus lokal.
- Mendekatkan ke perangkat Wi-Fi Aware di sekitar.
Selama aplikasi Anda tidak memperoleh informasi lokasi fisik dari API
Wi-Fi, mintalah NEARBY_WIFI_DEVICES, bukan ACCESS_FINE_LOCATION saat Anda
menargetkan Android 13 atau yang lebih tinggi dan gunakan API Wi-Fi. Saat Anda mendeklarasikan
izin NEARBY_WIFI_DEVICES, tegaskan bahwa aplikasi Anda tidak pernah
memperoleh informasi lokasi fisik dari API Wi-Fi. Untuk melakukannya, tetapkan atribut
android:usesPermissionFlags ke neverForLocation. Proses ini
serupa dengan yang Anda lakukan di Android 12 (API level 31) dan yang lebih tinggi saat Anda
menegaskan bahwa informasi perangkat Bluetooth tidak pernah digunakan untuk
lokasi.
Pelajari lebih lanjut cara meminta izin untuk mengakses perangkat Wi-Fi di sekitar.
Izin media terperinci
READ_MEDIA_AUDIO.Jika aplikasi menargetkan Android 13 atau yang lebih tinggi dan harus
mengakses file media yang telah
dibuat oleh aplikasi lain, Anda harus
meminta satu atau beberapa izin media terperinci berikut, bukan izin
READ_EXTERNAL_STORAGE:
| Jenis media | Izin meminta |
|---|---|
| Gambar dan foto | READ_MEDIA_IMAGES |
| Video | READ_MEDIA_VIDEO |
| File audio | READ_MEDIA_AUDIO |
Jika sebelumnya pengguna memberi aplikasi Anda izin READ_EXTERNAL_STORAGE,
sistem akan otomatis memberikan izin media terperinci ke aplikasi Anda.
Jika tidak, sistem akan menampilkan dialog yang ditampilkan ke pengguna saat aplikasi Anda
meminta izin yang ditampilkan dalam tabel sebelumnya. Pada gambar 1, aplikasi
meminta izin READ_MEDIA_AUDIO.
Jika Anda meminta izin
READ_MEDIA_IMAGES dan izin READ_MEDIA_VIDEO secara bersamaan,
hanya satu dialog izin sistem yang akan muncul.
Penggunaan sensor tubuh di latar belakang memerlukan izin baru
Android 13 memperkenalkan konsep akses "saat digunakan" untuk sensor tubuh, seperti detak jantung, suhu, dan persentase oksigen darah. Model akses ini sangat mirip dengan yang diperkenalkan oleh sistem untuk lokasi di Android 10 (API level 29).
Jika aplikasi Anda menargetkan Android 13 dan memerlukan akses ke informasi
sensor tubuh saat berjalan di latar belakang, Anda harus mendeklarasikan izin
BODY_SENSORS_BACKGROUND
yang baru selain izin
BODY_SENSORS
yang ada.
Performa dan baterai
Pemakaian Resource Baterai
Jika pengguna menempatkan aplikasi Anda dalam
status "dibatasi" untuk
penggunaan baterai di latar belakang
saat aplikasi Anda menargetkan Android 13, sistem tidak akan mengirimkan
siaran BOOT_COMPLETED atau siaran LOCKED_BOOT_COMPLETED hingga
aplikasi dimulai karena alasan lain.
Pengalaman pengguna
Kontrol media berasal dari PlaybackState
Untuk aplikasi yang menargetkan Android 13 (API level 33) dan versi lebih tinggi, sistem memperoleh
kontrol media dari tindakan
PlaybackState. Hal ini
memungkinkan sistem untuk menampilkan kumpulan kontrol yang lebih beragam dan secara teknis
konsisten antara perangkat ponsel dan tablet, dan juga selaras dengan cara kontrol
media dirender di platform Android lain seperti Android Auto dan
Android TV.
Gambar 2 menunjukkan contoh tampilannya di perangkat ponsel dan tablet.
Sebelum Android 13, sistem menampilkan hingga lima tindakan dari notifikasi
MediaStyle sesuai urutan ketika ditambahkan.
Dalam mode ringkas—misalnya, dalam setelan cepat yang diciutkan—hingga
tiga tindakan yang ditentukan dengan setShowActionsInCompactView()
dapat ditampilkan.
Mulai Android 13, sistem menampilkan hingga lima tombol tindakan berdasarkan
PlaybackState seperti yang dijelaskan dalam tabel berikut. Dalam mode ringkas, hanya tiga
slot tindakan pertama yang akan ditampilkan. Untuk aplikasi yang tidak menargetkan Android 13 atau yang
tidak menyertakan PlaybackState, sistem akan menampilkan kontrol berdasarkan
daftar Action yang ditambahkan ke notifikasi MediaStyle sebagaimana yang telah dijelaskan di
paragraf sebelumnya.
| Slot | Tindakan | Kriteria |
|---|---|---|
| 1 | Putar |
Status PlaybackState saat ini adalah salah satu dari berikut:
|
| Memuat indikator lingkaran berputar |
Status PlaybackState saat ini adalah salah satu dari berikut:
|
|
| Jeda | Status PlaybackState saat ini bukan satu pun dari yang disebutkan di atas. |
|
| 2 | Sebelumnya | Tindakan PlaybackState menyertakan ACTION_SKIP_TO_PREVIOUS. |
| Kustom | Tindakan PlaybackState tidak menyertakan ACTION_SKIP_TO_PREVIOUS, dan tindakan kustom PlaybackState menyertakan tindakan kustom yang belum dilakukan. |
|
| Kosong | Tambahan PlaybackState menyertakan nilai boolean true untuk kunci SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV. |
|
| 3 | Berikutnya | Tindakan PlaybackState menyertakan ACTION_SKIP_TO_NEXT. |
| Kustom | Tindakan PlaybackState tidak menyertakan ACTION_SKIP_TO_NEXT, dan tindakan kustom PlaybackState menyertakan tindakan kustom yang belum dilakukan. |
|
| Kosong | Tambahan PlaybackState menyertakan nilai boolean true untuk kunci SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT. |
|
| 4 | Kustom | Tindakan kustom PlaybackState menyertakan tindakan kustom yang belum dilakukan. |
| 5 | Kustom | Tindakan kustom PlaybackState menyertakan tindakan kustom yang belum dilakukan. |
Tindakan kustom ditempatkan sesuai urutan penambahannya ke
PlaybackState.
Tema warna aplikasi diterapkan secara otomatis ke konten WebView
Untuk aplikasi yang menargetkan Android 13 (API level 33) atau yang lebih tinggi, metode setForceDark()
tidak digunakan lagi, sehingga tidak ada pengoperasian jika metode tersebut dipanggil.
Sebagai gantinya, WebView kini selalu menetapkan
prefers-color-scheme kueri media sesuai dengan atribut tema aplikasi,
isLightTheme. Dengan kata
lain, jika isLightTheme adalah true atau tidak ditentukan, prefers-color-scheme adalah
light; jika tidak, ini adalah dark. Perilaku ini berarti bahwa gaya terang atau gelap konten web diterapkan secara otomatis agar cocok dengan tema aplikasi jika konten mendukungnya.
Untuk sebagian besar aplikasi, perilaku baru ini harus menerapkan gaya aplikasi yang sesuai secara otomatis, tetapi Anda harus menguji aplikasi untuk memeriksa kasus apa pun saat Anda mungkin mengontrol setelan mode gelap secara manual.
Jika Anda masih perlu menyesuaikan perilaku tema warna aplikasi, gunakan
metode
setAlgorithmicDarkeningAllowed(). Untuk kompatibilitas mundur dengan versi Android sebelumnya, sebaiknya gunakan metode setAlgorithmicDarkeningAllowed() yang setara di AndroidX.
Lihat dokumentasi untuk metode tersebut guna mempelajari lebih lanjut perilaku yang dapat Anda
harapkan dalam aplikasi, bergantung pada
targetSdkVersion dan setelan tema
aplikasi.
Layanan Google Play
Izin diperlukan untuk ID iklan
Aplikasi yang menggunakan ID iklan layanan Google Play dan
menargetkan Android 13 (API level 33) dan yang lebih tinggi harus
mendeklarasikan izin normal AD_ID dalam file manifes aplikasinya, seperti berikut:
<manifest ...>
<!-- Required only if your app targets Android 13 or higher. -->
<uses-permission android:name="com.google.android.gms.permission.AD_ID"/>
<application ...>
...
</application>
</manifest>
Jika aplikasi Anda tidak mendeklarasikan izin ini saat menargetkan Android 13 atau yang lebih tinggi, ID iklan akan otomatis dihapus dan diganti dengan string nol.
Jika aplikasi Anda menggunakan SDK yang mendeklarasikan izin AD_ID dalam manifes
library, izin tersebut akan digabungkan dengan file manifes aplikasi
secara default. Dalam hal ini, Anda tidak perlu mendeklarasikan izin di file
manifes aplikasi Anda.
Untuk mempelajari lebih lanjut, lihat ID Iklan di Bantuan Konsol Play.
Pembatasan non-SDK yang diperbarui
Android 13 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 13, 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 13. Untuk mempelajari lebih lanjut antarmuka non-SDK secara umum, baca Pembatasan antarmuka non-SDK.