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 Anda menguji aplikasi, lalu memodifikasinya sesuai yang diperlukan 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 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. In Android 17, limits are set conservatively to establish system baselines, targeting extreme 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 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 Pengambilan SMS. Pengiriman pesan yang berisi hash pengambilan SMS ditunda 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 ini 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 bertujuan 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 penyedia SMS kueri database difilter. Pesan SMS tersedia untuk aplikasi ini setelah penundaan. Perubahan ini berlaku untuk semua aplikasi, terlepas dari level API targetnya.

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

Keamanan

Android 17 menyertakan peningkatan berikut untuk keamanan perangkat dan aplikasi.

Paket 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 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 API level 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 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 yang 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 API level 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 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

Beginning with Android 17, if an app requests pointer capture using View.requestPointerCapture() and the user uses a touchpad, the system recognizes pointer movement and scrolling gestures from the user's touches and reports them to the app in the same way as pointer and scroll wheel movements from a captured mouse. In most cases, this removes the need for apps that support captured mice to add special handling logic for touchpads. For more details, see the documentation for View.POINTER_CAPTURE_MODE_RELATIVE.

Previously, the system did not attempt to recognize gestures from the touchpad, and instead delivered the raw, absolute finger locations to the app in a similar format to touchscreen touches. If an app still requires this absolute data, it should call the new View.requestPointerCapture(int) method with View.POINTER_CAPTURE_MODE_ABSOLUTE instead.

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 dalam siklus proses yang valid, pemutaran audio dan API 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 menyertakan perubahan berikut untuk meningkatkan konektivitas perangkat.

Pemasangan ulang otomatis untuk kehilangan ikatan Bluetooth

Android 17 memperkenalkan pemasangan ulang otomatis, peningkatan tingkat sistem yang dirancang untuk otomatis mengatasi kehilangan koneksi Bluetooth.

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

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

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

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

  • Hapus informasi koneksi dari perangkat periferal secara manual
  • Batalkan pemasangan perangkat secara manual di: Setelan > Perangkat terhubung