Perubahan perilaku: semua aplikasi

Platform Android 17 menyertakan perubahan perilaku yang mungkin memengaruhi aplikasi Anda. Perubahan perilaku berikut ini 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.

Pastikan Anda juga meninjau daftar perubahan perilaku yang hanya memengaruhi aplikasi yang menargetkan Android 17.

Fungsi inti

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

Batas memori aplikasi

Android 17 introduces app memory limits based on the device's total RAM to create a more stable and deterministic environment for your apps and Android users. These limits focus on memory leaks and other outliers before they trigger system-wide instability resulting in UI stuttering, higher battery drain, and apps being killed. While we anticipate minimal impact on the vast majority of app sessions, we recommend the following memory best practices, including establishing a baseline for memory.

You can determine if your app session was impacted by calling getDescription in ApplicationExitInfo; if your app was affected, the exit reason will be REASON_OTHER and the description will contain the string "MemoryLimiter:AnonSwap" along with other information. You can also use trigger-based profiling with TRIGGER_TYPE_ANOMALY to get heap dumps that are collected when the memory limit is hit.

The Manage your app's memory documentation gives information to help you diagnose your app's memory issues and optimize its resource consumption.

Test your app's behavior under the memory constraints

You can use Android Debug Bridge (adb) to adjust or disable the memory limits on any device that imposes them. The shell command am provides three subcommands to adjust the memory limits. (These commands have no effect on a device which does not impose memory limits.)

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

Instructs the memory limiter to ignore some or all processes. Passing a UID (Android User ID) instructs the memory limiter to ignore enforcement on all processes associated with that UID. You can also pass all (ignore all apps) or none (do not ignore any apps). Passing none overrides any previous calls to am memory-limiter ignore.

If you instruct the memory limiter to ignore a UID, you can still apply a manual memory limit to a process within the app by calling am memory-limiter manual.

manual

Instructs the system to impose a memory constraint on the process with the specified PID (Process ID). The memory constraint is specified as an integer number of MB; for example, passing 30 specifies that the process is limited to 30 MB of memory. Passing max removes all memory limits on that process. Passing none removes any manual limits set on the process, restoring the system's default limit (if any).

status

Reports the current status of the memory limiter. The status includes the memory limits imposed on visible and non-visible processes.

Privasi

Android 17 mencakup perubahan berikut untuk meningkatkan privasi pengguna.

Perlindungan OTP SMS

Beginning with Android 17, Android is expanding its protection for SMS messages containing one-time passwords (OTP).

In previous versions of Android, this protection was primarily focused on the SMS Retriever format. Delivery of messages containing an SMS retriever hash was delayed for most apps for three hours. However, certain apps (like the default SMS handler) were exempt from the delay, and the app that owned the hash was also exempted.

Beginning with Android 17, the protection is also applied to WebOTP format messages. If an app has permission to read SMS messages but is not the intended recipient of a WebOTP message (as determined by domain verification), the message is not accessible to the app until three hours after the message's receipt. This change is intended to improve user security by ensuring that only apps associated with the domain mentioned in the message can programmatically read the verification code.

During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay. This change applies to all apps, regardless of their target API level.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

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 ke penggunaan file konfigurasi keamanan jaringan, yang memungkinkan Anda menentukan domain yang perlu dihubungkan oleh aplikasi Anda menggunakan koneksi cleartext.

Perlu diketahui bahwa file konfigurasi keamanan jaringan hanya didukung di level API 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

Saat ini, jika aplikasi meluncurkan intent dengan URI yang memiliki tindakan ACTION_SEND, ACTION_SEND_MULTIPLE, atau ACTION_IMAGE_CAPTURE, sistem akan otomatis memberikan izin URI baca dan tulis ke aplikasi target. Mulai Android 18, sistem tidak akan otomatis memberikan izin ini lagi. Oleh karena itu, sebaiknya aplikasi memberikan izin URI yang relevan secara eksplisit, bukan mengandalkan sistem untuk memberikannya.

Untuk mendeteksi penggunaan intent ini di aplikasi Anda, gunakan StrictMode dengan detectImplicitUriPermissionGrant() untuk memicu pelanggaran:

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);

Atau, Anda dapat memantau pengecualian yang dicatat dan berisi pesan Please set the grant explicitly in the app yang muncul saat sistem secara implisit menetapkan pemberian izin. Anda dapat memantau log ini menggunakan perintah adb berikut:

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

Untuk memberikan izin yang diperlukan secara eksplisit, tambahkan tanda FLAG_GRANT_READ_URI_PERMISSION ke maksud ACTION_SEND dan ACTION_SEND_MULTIPLE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Sertakan flag FLAG_GRANT_READ_URI_PERMISSION dan FLAG_GRANT_WRITE_URI_PERMISSION untuk intent ACTION_IMAGE_CAPTURE:

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 yang berlebihan di Android Keystore, karena merupakan 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 di luar batas, pembuatan akan gagal dengan error 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 (level API 37) atau yang lebih tinggi: getNumericErrorCode() menampilkan nilai ERROR_TOO_MANY_KEYS baru.
  • Semua aplikasi lainnya: getNumericErrorCode() menampilkan ERROR_INCORRECT_USAGE.

Memblokir traffic loopback antar-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 API level yang ditargetkan aplikasi.

Pengalaman pengguna dan UI sistem

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

Memulihkan visibilitas IME default setelah rotasi

Mulai dari Android 17, saat konfigurasi perangkat berubah (misalnya, melalui rotasi), dan hal ini tidak ditangani oleh aplikasi itu sendiri, visibilitas IME sebelumnya tidak 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 mengirimkan peristiwa relatif secara default selama pengambilan pointer

Mulai Android 17, jika aplikasi meminta pengambilan pointer menggunakan View.requestPointerCapture() dan pengguna menggunakan touchpad, sistem akan mengenali gerakan pointer dan gestur men-scroll dari sentuhan pengguna dan melaporkannya ke aplikasi dengan cara yang sama seperti gerakan pointer dan roda scroll dari mouse yang diambil. Dalam sebagian besar kasus, hal ini menghilangkan kebutuhan aplikasi yang mendukung mouse yang direkam 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, dan malah mengirimkan lokasi jari absolut mentah ke aplikasi dalam format yang serupa dengan sentuhan layar sentuh. Jika aplikasi 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 di 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 dalam siklus proses yang valid, API pemutaran audio dan perubahan volume akan gagal 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 mencakup perubahan berikut untuk meningkatkan kualitas konektivitas perangkat.

Penyambungan ulang otomatis untuk kehilangan koneksi Bluetooth

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

Sebelumnya, jika koneksi hilang, pengguna harus membuka Setelan secara manual untuk membatalkan penyambungan dan menyambungkan kembali perangkat periferal. Fitur ini dibuat berdasarkan peningkatan keamanan Android 16 dengan memungkinkan sistem membangun kembali koneksi di latar belakang tanpa mengharuskan pengguna membuka Setelan secara manual untuk membatalkan penyambungan dan menyambungkan kembali perangkat 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 ekstra EXTRA_PAIRING_CONTEXT yang memungkinkan aplikasi membedakan antara permintaan penyambungan standar dan upaya penyambungan ulang yang dimulai sistem secara mandiri.
  • Update kunci bersyarat: Kunci keamanan yang ada hanya akan diganti jika penyambungan ulang berhasil dan koneksi baru memenuhi atau melampaui tingkat keamanan sambungan sebelumnya.
  • Waktu intent yang diubah: Intent ACTION_KEY_MISSING kini disiarkan hanya jika upaya penyambungan ulang otomatis 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 upaya penyambungan ulang tersebut.

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

  • Menghapus informasi penggabungan secara manual dari perangkat periferal
  • Batalkan penyambungan perangkat secara manual di: Setelan > Perangkat terhubung