Perubahan perilaku: semua aplikasi

Platform Android 17 menyertakan perubahan perilaku yang mungkin memengaruhi aplikasi Anda. Perubahan perilaku berikut berlaku untuk semua aplikasi saat dijalankan di Android 17, terlepas dari targetSdkVersion. Sebaiknya uji aplikasi Anda, lalu modifikasi sesuai kebutuhan untuk mendukung perubahan ini, jika memungkinkan.

Selain itu, pastikan Anda meninjau daftar perubahan perilaku yang hanya memengaruhi aplikasi yang menargetkan Android 17.

Fungsi inti

Android 17 (API level 37) menyertakan perubahan berikut yang mengubah atau memperluas berbagai kemampuan inti sistem Android.

Batas memori aplikasi

Android 17 memperkenalkan batasan memori aplikasi berdasarkan total RAM perangkat untuk menciptakan lingkungan yang lebih stabil dan deterministik bagi aplikasi Anda dan pengguna Android. Batas ini berfokus pada kebocoran memori dan pencilan lainnya sebelum memicu ketidakstabilan di seluruh sistem yang mengakibatkan UI tersendat, baterai lebih cepat habis, dan aplikasi dihentikan. Meskipun kami mengantisipasi dampak minimal pada sebagian besar sesi aplikasi, sebaiknya ikuti praktik terbaik memori berikut, termasuk menetapkan dasar pengukuran untuk memori.

Anda dapat menentukan apakah sesi aplikasi Anda terpengaruh dengan memanggil getDescription di ApplicationExitInfo; jika aplikasi Anda terpengaruh, alasan keluar akan menjadi REASON_OTHER dan deskripsi akan berisi string "MemoryLimiter:AnonSwap" beserta informasi lainnya. Anda juga dapat menggunakan profiling berbasis pemicu dengan TRIGGER_TYPE_ANOMALY untuk mendapatkan heap dump yang dikumpulkan saat batas memori tercapai.

Dokumentasi Mengelola memori aplikasi memberikan informasi untuk membantu Anda mendiagnosis masalah memori aplikasi dan mengoptimalkan konsumsi resource-nya.

Menguji perilaku aplikasi Anda dalam batasan memori

Anda dapat menggunakan Android Debug Bridge (adb) untuk menyesuaikan atau menonaktifkan batas memori di perangkat apa pun yang memberlakukannya. Perintah shell am menyediakan tiga subperintah untuk menyesuaikan batas memori. (Perintah ini tidak berpengaruh pada perangkat yang tidak menerapkan batas memori.)

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

Menginstruksikan pembatas memori untuk mengabaikan beberapa atau semua proses. Meneruskan UID (ID Pengguna Android) akan menginstruksikan pembatas memori untuk mengabaikan penerapan pada semua proses yang terkait dengan UID tersebut. Anda juga dapat meneruskan all (abaikan semua aplikasi) atau none (jangan abaikan aplikasi apa pun). Meneruskan none akan mengganti panggilan sebelumnya ke am memory-limiter ignore.

Jika Anda menginstruksikan pembatas memori untuk mengabaikan UID, Anda masih dapat menerapkan batas memori manual ke proses dalam aplikasi dengan memanggil am memory-limiter manual.

manual

Menginstruksikan sistem untuk menerapkan batasan memori pada proses dengan PID (ID Proses) yang ditentukan. Batasan memori ditentukan sebagai bilangan bulat MB; misalnya, meneruskan 30 menentukan bahwa proses dibatasi hingga 30 MB memori. Meneruskan max akan menghapus semua batas memori pada proses tersebut. Meneruskan none akan menghapus batas manual yang ditetapkan pada proses, sehingga memulihkan batas default sistem (jika ada).

status

Melaporkan status pembatas memori saat ini. Status ini mencakup batas memori yang diberlakukan pada proses yang terlihat dan tidak terlihat.

Privasi

Android 17 menyertakan perubahan berikut untuk meningkatkan privasi pengguna.

Perlindungan OTP SMS

Mulai Android 17, Android memperluas perlindungannya untuk pesan SMS yang berisi sandi sekali pakai (OTP).

Pada versi Android sebelumnya, perlindungan ini terutama berfokus pada format SMS Retriever. Pengiriman pesan yang berisi hash pengambil SMS tertunda selama tiga jam untuk sebagian besar aplikasi. Namun, aplikasi tertentu (seperti pengendali SMS default) dikecualikan dari penundaan, dan aplikasi yang memiliki hash juga dikecualikan.

Mulai Android 17, perlindungan juga diterapkan pada pesan format WebOTP. Jika aplikasi memiliki izin untuk membaca pesan SMS, tetapi bukan penerima yang dituju dari pesan WebOTP (sebagaimana ditentukan oleh verifikasi domain), pesan tersebut tidak dapat diakses oleh aplikasi hingga tiga jam setelah pesan diterima. Perubahan ini ditujukan untuk meningkatkan keamanan pengguna dengan memastikan bahwa hanya aplikasi yang terkait dengan domain yang disebutkan dalam pesan yang dapat membaca kode verifikasi secara terprogram.

Selama penundaan tiga jam ini, siaran SMS_RECEIVED_ACTION ditahan dan kueri database penyedia SMS difilter. Pesan SMS tersedia untuk aplikasi ini setelah penundaan. Perubahan ini berlaku untuk semua aplikasi, terlepas dari level API targetnya.

Aplikasi tertentu seperti aplikasi bantuan SMS default, aplikasi pendamping perangkat terhubung, dll., dikecualikan dari penundaan ini. Semua aplikasi yang mengandalkan pembacaan pesan SMS untuk ekstraksi OTP harus beralih menggunakan API SMS Retriever atau SMS Izin Pengguna untuk memastikan fungsi yang berkelanjutan.

Keamanan

Android 17 menyertakan peningkatan berikut pada keamanan perangkat dan aplikasi.

Rencana penghentian penggunaan usesClearTraffic

Dalam rilis mendatang, kami berencana untuk menghentikan penggunaan elemen usesCleartextTraffic. Aplikasi yang perlu membuat koneksi yang tidak dienkripsi (HTTP) harus bermigrasi untuk menggunakan file konfigurasi keamanan jaringan, yang memungkinkan Anda menentukan domain yang perlu dibuat koneksi cleartext-nya oleh aplikasi.

Perlu diketahui bahwa file konfigurasi keamanan jaringan hanya didukung di API level 24 dan yang lebih tinggi. Jika aplikasi Anda memiliki level API minimum yang lebih rendah dari 24, Anda harus melakukan kedua hal berikut:

  • Tetapkan atribut usesCleartextTraffic ke true
  • Menggunakan file konfigurasi jaringan

Jika level API minimum aplikasi Anda adalah 24 atau yang lebih tinggi, Anda dapat menggunakan file konfigurasi jaringan dan tidak perlu menetapkan usesCleartextTraffic.

Membatasi pemberian URI implisit

Currently, if an app launches an intent with a URI that has the action ACTION_SEND, ACTION_SEND_MULTIPLE, or ACTION_IMAGE_CAPTURE, the system automatically grants the read and write URI permissions to the target app. Starting in Android 18, the system will no longer automatically grant these permissions. For this reason, we recommend that apps explicitly grant the relevant URI permissions instead of relying on the system to grant them.

To detect the usage of these intents in your app, use StrictMode with detectImplicitUriPermissionGrant() to trigger a violation:

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

Alternatively, you can monitor for logged exceptions containing the message Please set the grant explicitly in the app that appears when system implicitly sets the grant. You can monitor for these logs using the following adb command:

adb logcat | grep "Please set the grant explicitly in the app"

To explicitly grant the necessary permissions, add the FLAG_GRANT_READ_URI_PERMISSION flag to ACTION_SEND and ACTION_SEND_MULTIPLE intents:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Include both FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flags for ACTION_IMAGE_CAPTURE intents:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Batas keystore per aplikasi

Aplikasi harus menghindari pembuatan kunci dalam jumlah berlebihan di Android Keystore, karena ini adalah resource bersama untuk semua aplikasi di perangkat. Mulai dari Android 17, sistem menerapkan batas jumlah kunci yang dapat dimiliki aplikasi. Batasnya adalah 50.000 kunci untuk aplikasi non-sistem yang menargetkan Android 17 (level API 37) atau yang lebih tinggi, dan 200.000 kunci untuk semua aplikasi lainnya. Aplikasi sistem memiliki batas 200.000 kunci, terlepas dari level API yang ditargetkan.

Jika aplikasi mencoba membuat kunci melebihi batas, pembuatan akan gagal dengan KeyStoreException. String pesan pengecualian berisi informasi tentang batas kunci. Jika aplikasi memanggil getNumericErrorCode() pada pengecualian, nilai yang ditampilkan bergantung pada level API yang ditargetkan aplikasi:

  • Aplikasi yang menargetkan Android 17 (API level 37) atau yang lebih tinggi: getNumericErrorCode() menampilkan nilai ERROR_TOO_MANY_KEYS baru.
  • Semua aplikasi lainnya: getNumericErrorCode() menampilkan ERROR_INCORRECT_USAGE.

Memblokir traffic loopback lintas profil

Mulai Android 17, traffic loopback lintas profil tidak lagi diizinkan secara default. Traffic loopback dalam profil yang sama tidak terpengaruh. Perubahan ini berlaku untuk semua aplikasi yang berjalan di Android 17 atau yang lebih tinggi, terlepas dari level API yang ditargetkan aplikasi.

Pengalaman pengguna dan UI sistem

Android 17 menyertakan perubahan berikut yang dimaksudkan untuk menciptakan pengalaman pengguna yang lebih konsisten dan intuitif.

Memulihkan visibilitas IME default setelah rotasi

Mulai Android 17, saat konfigurasi perangkat berubah (misalnya, melalui rotasi), dan hal ini tidak ditangani oleh aplikasi itu sendiri, visibilitas IME sebelumnya tidak akan dipulihkan.

Jika aplikasi Anda mengalami perubahan konfigurasi yang tidak ditanganinya, dan aplikasi memerlukan keyboard agar terlihat setelah perubahan, Anda harus memintanya secara eksplisit. Anda dapat membuat permintaan ini dengan salah satu cara berikut:

  • Tetapkan atribut android:windowSoftInputMode ke stateAlwaysVisible.
  • Minta keyboard virtual secara terprogram dalam metode onCreate() aktivitas Anda, atau tambahkan metode onConfigurationChanged().

Input manusia

Android 17 menyertakan perubahan berikut yang memengaruhi cara aplikasi berinteraksi dengan perangkat input manusia seperti keyboard dan touchpad.

Touchpad memberikan peristiwa relatif secara default selama penangkapan pointer

Mulai Android 17, jika aplikasi meminta pengambilan pointer menggunakan View.requestPointerCapture() dan pengguna menggunakan touchpad, sistem akan mengenali gerakan pointer dan gestur scroll dari sentuhan pengguna dan melaporkannya ke aplikasi dengan cara yang sama seperti gerakan pointer dan roda scroll dari mouse yang diambil. Secara umum, hal ini menghilangkan kebutuhan aplikasi yang mendukung mouse yang ditangkap untuk menambahkan logika penanganan khusus untuk touchpad. Untuk mengetahui detail selengkapnya, lihat dokumentasi untuk View.POINTER_CAPTURE_MODE_RELATIVE.

Sebelumnya, sistem tidak mencoba mengenali gestur dari touchpad, tetapi mengirimkan lokasi jari mentah dan absolut ke aplikasi dalam format yang mirip dengan sentuhan layar sentuh. Jika masih memerlukan data absolut ini, aplikasi harus memanggil metode View.requestPointerCapture(int) baru dengan View.POINTER_CAPTURE_MODE_ABSOLUTE.

Media

Android 17 menyertakan perubahan berikut pada perilaku media.

Penguatan audio latar belakang

Mulai Android 17, framework audio menerapkan batasan pada interaksi audio latar belakang, termasuk pemutaran audio, permintaan fokus audio, dan API perubahan volume untuk memastikan bahwa perubahan ini dimulai secara sengaja oleh pengguna.

Jika aplikasi mencoba memanggil API audio saat aplikasi tidak berada dalam siklus proses yang valid, API pemutaran audio dan perubahan volume akan gagal secara otomatis tanpa menampilkan pengecualian atau memberikan pesan kegagalan. API fokus audio gagal dengan kode hasil AUDIOFOCUS_REQUEST_FAILED.

Untuk mengetahui informasi selengkapnya, termasuk strategi mitigasi, lihat Penguatan audio latar belakang.

Konektivitas

Android 17 menyertakan perubahan berikut untuk meningkatkan konektivitas perangkat.

Penyambungan ulang otonom untuk kehilangan ikatan Bluetooth

Android 17 memperkenalkan penyambungan ulang otonom, peningkatan level sistem yang dirancang untuk otomatis menyelesaikan masalah hilangnya ikatan Bluetooth.

Sebelumnya, jika ikatan hilang, pengguna harus membuka Setelan secara manual untuk melepas sambungan, lalu menyambungkan kembali periferal. Fitur ini dibuat berdasarkan peningkatan keamanan Android 16 dengan memungkinkan sistem membuat ulang ikatan di latar belakang tanpa mengharuskan pengguna membuka Setelan secara manual untuk melepas dan memasangkan kembali periferal.

Meskipun sebagian besar aplikasi tidak memerlukan perubahan kode, developer harus mengetahui perubahan perilaku berikut dalam stack Bluetooth:

  • Konteks penyambungan baru: ACTION_PAIRING_REQUEST kini menyertakan tambahan EXTRA_PAIRING_CONTEXT yang memungkinkan aplikasi membedakan antara permintaan penyambungan standar dan upaya penyambungan ulang yang dimulai sistem otonom.
  • Pembaruan kunci bersyarat: Kunci keamanan yang ada hanya akan diganti jika pemasangan ulang berhasil dan koneksi baru memenuhi atau melampaui tingkat keamanan ikatan sebelumnya.
  • Waktu intent yang diubah: Intent ACTION_KEY_MISSING kini disiarkan hanya jika upaya penyambungan ulang otonom gagal. Hal ini mengurangi penanganan error yang tidak perlu di aplikasi jika sistem berhasil memulihkan ikatan di latar belakang.
  • Notifikasi pengguna: Sistem mengelola penyambungan ulang melalui notifikasi dan dialog UI baru. Pengguna akan diminta untuk mengonfirmasi upaya penyambungan ulang untuk memastikan mereka mengetahui penyambungan ulang tersebut.

Produsen perangkat periferal dan developer aplikasi pendamping harus memverifikasi bahwa hardware dan aplikasi menangani transisi ikatan dengan baik. Untuk menguji perilaku ini, simulasikan hilangnya ikatan jarak jauh menggunakan salah satu metode berikut:

  • Menghapus informasi ikatan secara manual dari perangkat periferal
  • Lepaskan sambungan perangkat secara manual di: Setelan > Perangkat terhubung