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 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-sendat, pengurasan baterai yang lebih tinggi, dan aplikasi dihentikan. Meskipun kami memperkirakan hanya ada sedikit dampak pada sebagian besar sesi aplikasi, sebaiknya ikuti praktik terbaik memori berikut, termasuk membuat tolok ukur 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 pembuatan profil berbasis pemicu dengan TRIGGER_TYPE_ANOMALY untuk mendapatkan dump heap yang dikumpulkan saat batas memori tercapai.

Dokumentasi Mengelola memori aplikasi memberikan informasi untuk membantu Anda mendiagnosis masalah memori aplikasi dan mengoptimalkan konsumsi sumber dayanya.

Menguji perilaku aplikasi Anda dalam batasan memori

Anda dapat menggunakan Android Debug Bridge (adb) untuk menyesuaikan atau menonaktifkan batas memori di perangkat 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

Memerintahkan 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). Penerusan none akan menggantikan 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 dalam 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 mencakup batas memori yang diterapkan pada proses yang terlihat dan tidak terlihat.

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 introduces autonomous re-pairing, a system-level enhancement designed to automatically resolve Bluetooth bond loss.

Previously, if a bond was lost, users had to manually navigate to Settings to unpair and then re-pair the peripheral. This feature builds upon the security improvement of Android 16 by allowing the system to re-establish bonds in the background without requiring users to manually navigate to Settings to unpair and re-pair peripherals.

While most apps will not require code changes, developers should be aware of the following behavior changes in Bluetooth stack:

  • New pairing context: The ACTION_PAIRING_REQUEST now includes the EXTRA_PAIRING_CONTEXT extra which allows apps to distinguish between a standard pairing request and an autonomous system-initiated re-pairing attempt.
  • Conditional key updates: Existing security keys will only be replaced if the re-pairing is successful and new connection meets or exceeds the security level of the previous bond.
  • Modified intent timing: The ACTION_KEY_MISSING intent is now broadcast only if the autonomous re-pairing attempt fails. This reduces unnecessary error handling in the app if the system successfully recovers the bond in the background.
  • User notification: The system manages re-pairing via new UI notifications and dialogs. Users will be prompted to confirm the re-pairing attempt to ensure they are aware of the reconnection.

Peripheral device manufacturers and companion app developers should verify that hardware and app gracefully handle bond transitions. To test this behavior, simulate a remote bond loss using either of the following methods:

  • Manually remove the bond information from the peripheral device
  • Manually unpair the device in: Settings > Connected devices