Thay đổi về hành vi: tất cả ứng dụng

Nền tảng Android 17 có các thay đổi về hành vi có thể ảnh hưởng đến ứng dụng của bạn. Những thay đổi về hành vi sau đây áp dụng cho tất cả ứng dụng khi chạy trên Android 17, bất kể targetSdkVersion. Bạn nên kiểm thử ứng dụng rồi sửa đổi để hỗ trợ những thay đổi này cho phù hợp (nếu cần).

Ngoài ra, hãy nhớ tham khảo danh sách các thay đổi về hành vi chỉ ảnh hưởng đến những ứng dụng nhắm đến Android 17.

Chức năng cốt lõi

Android 17 (cấp độ API 37) bao gồm những thay đổi sau đây giúp sửa đổi hoặc mở rộng nhiều khả năng cốt lõi của hệ thống Android.

Giới hạn bộ nhớ ứng dụng

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.

Quyền riêng tư

Android 17 có những thay đổi sau đây để cải thiện quyền riêng tư của người dùng.

Bảo vệ mã OTP qua tin nhắn 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.

Bảo mật

Android 17 có những điểm cải tiến sau đây về tính bảo mật của thiết bị và ứng dụng.

Kế hoạch ngừng sử dụng usesClearTraffic

Trong một bản phát hành trong tương lai, chúng tôi dự định sẽ ngừng sử dụng phần tử usesCleartextTraffic. Những ứng dụng cần tạo kết nối không mã hoá (HTTP) nên di chuyển sang sử dụng tệp cấu hình bảo mật mạng. Tệp này cho phép bạn chỉ định những miền mà ứng dụng cần tạo kết nối văn bản thô.

Xin lưu ý rằng các tệp cấu hình bảo mật mạng chỉ được hỗ trợ trên API cấp 24 trở lên. Nếu ứng dụng của bạn có cấp độ API tối thiểu thấp hơn 24, bạn nên thực hiện cả hai việc sau:

  • Đặt thuộc tính usesCleartextTraffic thành true
  • Sử dụng tệp cấu hình mạng

Nếu cấp độ API tối thiểu của ứng dụng là 24 trở lên, bạn có thể sử dụng tệp cấu hình mạng và không cần đặt usesCleartextTraffic.

Hạn chế các quyền ngầm định đối với URI

Hiện tại, nếu một ứng dụng khởi chạy một ý định có URI với thao tác ACTION_SEND, ACTION_SEND_MULTIPLE hoặc ACTION_IMAGE_CAPTURE, thì hệ thống sẽ tự động cấp quyền đọc và ghi URI cho ứng dụng đích. Kể từ Android 18, hệ thống sẽ không tự động cấp các quyền này nữa. Vì lý do này, bạn nên cấp quyền URI có liên quan một cách rõ ràng cho các ứng dụng thay vì dựa vào hệ thống để cấp quyền.

Để phát hiện việc sử dụng các ý định này trong ứng dụng, hãy dùng StrictMode với detectImplicitUriPermissionGrant() để kích hoạt lỗi vi phạm:

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

Ngoài ra, bạn có thể theo dõi các trường hợp ngoại lệ đã ghi nhật ký có chứa thông báo Please set the grant explicitly in the app xuất hiện khi hệ thống ngầm đặt quyền truy cập. Bạn có thể theo dõi các nhật ký này bằng lệnh adb sau:

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

Để cấp các quyền cần thiết một cách rõ ràng, hãy thêm cờ FLAG_GRANT_READ_URI_PERMISSION vào ý định ACTION_SEND và ACTION_SEND_MULTIPLE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Thêm cả cờ FLAG_GRANT_READ_URI_PERMISSION và FLAG_GRANT_WRITE_URI_PERMISSION cho các ý định 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);

Giới hạn kho khoá cho mỗi ứng dụng

Các ứng dụng nên tránh tạo quá nhiều khoá trong Kho khoá Android, vì đây là một tài nguyên dùng chung cho tất cả ứng dụng trên thiết bị. Kể từ Android 17, hệ thống sẽ áp dụng giới hạn về số lượng khoá mà một ứng dụng có thể sở hữu. Giới hạn là 50.000 khoá đối với các ứng dụng không phải là ứng dụng hệ thống nhắm đến Android 17 (cấp độ API 37) trở lên và 200.000 khoá đối với tất cả các ứng dụng khác. Các ứng dụng hệ thống có giới hạn là 200.000 khoá, bất kể chúng nhắm đến cấp độ API nào.

Nếu một ứng dụng cố gắng tạo các khoá vượt quá hạn mức, thì quá trình tạo sẽ không thành công với KeyStoreException. Chuỗi thông báo của ngoại lệ chứa thông tin về giới hạn khoá. Nếu ứng dụng gọi getNumericErrorCode() trên ngoại lệ, thì giá trị trả về sẽ phụ thuộc vào cấp độ API mà ứng dụng nhắm đến:

  • Ứng dụng nhắm đến Android 17 (API cấp 37) trở lên: getNumericErrorCode() sẽ trả về giá trị ERROR_TOO_MANY_KEYS mới.
  • Tất cả các ứng dụng khác: getNumericErrorCode() trả về ERROR_INCORRECT_USAGE.

Chặn lưu lượng truy cập loopback trên nhiều hồ sơ

Kể từ Android 17, lưu lượng truy cập vòng lặp liên hồ sơ không còn được phép theo mặc định. Lưu lượng truy cập vòng lặp trong cùng một hồ sơ sẽ không bị ảnh hưởng. Thay đổi này áp dụng cho tất cả ứng dụng chạy trên Android 17 trở lên, bất kể ứng dụng nhắm đến cấp độ API nào.

Trải nghiệm người dùng và giao diện người dùng hệ thống

Android 17 có những thay đổi sau đây nhằm tạo ra trải nghiệm người dùng nhất quán và trực quan hơn.

Khôi phục chế độ hiển thị IME mặc định sau khi xoay

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.

Hoạt động đầu vào của người dùng

Android 17 có những thay đổi sau đây ảnh hưởng đến cách ứng dụng tương tác với các thiết bị đầu vào của người dùng, chẳng hạn như bàn phím và bàn di chuột.

Theo mặc định, bàn di chuột sẽ gửi các sự kiện tương đối trong quá trình ghi lại con trỏ

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.

Nội dung nghe nhìn

Android 17 có những thay đổi sau đây về hành vi của nội dung nghe nhìn.

Tăng cường bảo mật âm thanh nền

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.

Khả năng kết nối

Android 17 có những thay đổi sau đây để tăng cường khả năng kết nối của thiết bị.

Tự động ghép nối lại khi mất liên kết 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