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. Di Android 17, batas ditetapkan secara konservatif untuk menetapkan dasar sistem, yang menargetkan kebocoran memori ekstrem dan anomali lainnya sebelum memicu ketidakstabilan di seluruh sistem yang mengakibatkan ketersendatan UI, baterai cepat habis, dan aplikasi dihentikan. Meskipun kami mengantisipasi dampak minimal pada sebagian besar sesi aplikasi, sebaiknya ikuti praktik terbaik memori berikut, termasuk menetapkan 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

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). 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, 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

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

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 yang berisi pesan Please set the grant explicitly in the app yang muncul saat sistem secara implisit menetapkan pemberian. 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 yang 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

Beginning with Android 17, when the device's configuration changes (for example, through rotation), and this is not handled by the app itself, the previous IME visibility is not restored.

If your app undergoes a configuration change that it does not handle, and the app needs the keyboard to be visible after the change, you must explicitly request this. You can make this request in one of the following ways:

  • Set the android:windowSoftInputMode attribute to stateAlwaysVisible.
  • Programmatically request the soft keyboard in your activity's onCreate() method, or add the onConfigurationChanged() method.

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 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 diambil 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 mirip 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 sebagai gantinya.

Media

Android 17 menyertakan perubahan berikut pada perilaku media.

Penguatan audio latar belakang

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code AUDIOFOCUS_REQUEST_FAILED.

For more information, including mitigation strategies, see Background audio hardening.

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