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 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 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 (API cấp 37) có những thay đổi sau đây giúp sửa đổi hoặc mở rộng nhiều chức năng cốt lõi của hệ thống Android.

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

Android 17 mang đến tính năng giới hạn bộ nhớ ứng dụng dựa trên tổng dung lượng RAM của thiết bị để tạo một môi trường ổn định và có thể xác định hơn cho các ứng dụng và người dùng Android. Các giới hạn này tập trung vào tình trạng rò rỉ bộ nhớ và các điểm ngoại lệ khác trước khi chúng kích hoạt tình trạng không ổn định trên toàn hệ thống, dẫn đến hiện tượng kết xuất gián đoạn giao diện người dùng, mức tiêu hao pin cao hơn và ứng dụng bị tắt. Mặc dù dự kiến sẽ có tác động không đáng kể đến phần lớn các phiên hoạt động của ứng dụng, nhưng bạn nên làm theo các phương pháp hay nhất sau đây về bộ nhớ, bao gồm cả việc thiết lập một đường cơ sở cho bộ nhớ.

Bạn có thể xác định xem phiên hoạt động của ứng dụng có bị ảnh hưởng hay không bằng cách gọi getDescription trong ApplicationExitInfo; nếu ứng dụng của bạn bị ảnh hưởng, lý do thoát sẽ là REASON_OTHER và nội dung mô tả sẽ chứa chuỗi "MemoryLimiter:AnonSwap" cùng với các thông tin khác. Bạn cũng có thể sử dụng hồ sơ dựa trên trình kích hoạt với TRIGGER_TYPE_ANOMALY để nhận các kết xuất heap được thu thập khi đạt đến giới hạn bộ nhớ.

Tài liệu Quản lý bộ nhớ của ứng dụng cung cấp thông tin giúp bạn chẩn đoán các vấn đề về bộ nhớ của ứng dụng và tối ưu hoá mức tiêu thụ tài nguyên của ứng dụng.

Kiểm thử hành vi của ứng dụng trong điều kiện hạn chế về bộ nhớ

Bạn có thể dùng Cầu gỡ lỗi Android (adb) để điều chỉnh hoặc tắt giới hạn bộ nhớ trên mọi thiết bị áp đặt giới hạn này. Lệnh shell am cung cấp 3 lệnh con để điều chỉnh hạn mức bộ nhớ. (Các lệnh này không ảnh hưởng đến thiết bị không áp đặt giới hạn bộ nhớ.)

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

Hướng dẫn bộ giới hạn bộ nhớ bỏ qua một số hoặc tất cả các quy trình. Việc truyền một UID (Mã nhận dạng người dùng Android) sẽ hướng dẫn trình giới hạn bộ nhớ bỏ qua việc thực thi trên tất cả các quy trình liên kết với UID đó. Bạn cũng có thể truyền all (bỏ qua tất cả ứng dụng) hoặc none (không bỏ qua ứng dụng nào). Việc truyền none sẽ ghi đè mọi lệnh gọi trước đó đến am memory-limiter ignore.

Nếu hướng dẫn trình giới hạn bộ nhớ bỏ qua một UID, bạn vẫn có thể áp dụng giới hạn bộ nhớ theo cách thủ công cho một quy trình trong ứng dụng bằng cách gọi am memory-limiter manual.

manual

Hướng dẫn hệ thống áp đặt một hạn chế về bộ nhớ đối với quy trình có PID (Mã nhận dạng quy trình) được chỉ định. Hạn chế về bộ nhớ được chỉ định dưới dạng số nguyên (số MB); ví dụ: truyền 30 chỉ định rằng quy trình bị giới hạn ở 30 MB bộ nhớ. Truyền max sẽ xoá tất cả các giới hạn bộ nhớ trên quy trình đó. Việc truyền none sẽ xoá mọi hạn mức thủ công được đặt trên quy trình, khôi phục hạn mức mặc định của hệ thống (nếu có).

status

Báo cáo trạng thái hiện tại của bộ giới hạn bộ nhớ. Trạng thái này bao gồm cả giới hạn bộ nhớ áp dụng cho các quy trình hiển thị và không hiển thị.

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ề bảo mật thiết bị và ứng dụng.

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

In a future release, we plan to deprecate the usesCleartextTraffic element. Apps that need to make unencrypted (HTTP) connections should migrate to using a network security configuration file, which lets you specify which domains your app needs to make cleartext connections to.

Be aware that network security configuration files are only supported on API levels 24 and higher. If your app has a minimum API level lower than 24, you should do both of the following:

  • Set the usesCleartextTraffic attribute to true
  • Use a network configuration file

If your app's minimum API level is 24 or higher, you can use a network configuration file and you don't need to set usesCleartextTraffic.

Hạn chế cấp quyền URI ngầm ẩn

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

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

Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.

If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException. The exception's message string contains information about the key limit. If the app calls getNumericErrorCode() on the exception, the return value depends on what API level the app targets:

  • Apps targeting Android 17 (API level 37) or higher: getNumericErrorCode() returns the new ERROR_TOO_MANY_KEYS value.
  • All other apps: getNumericErrorCode() returns ERROR_INCORRECT_USAGE.

Chặn lưu lượng truy cập vòng lặp 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

Kể từ Android 17, khi cấu hình của thiết bị thay đổi (ví dụ: thông qua thao tác xoay) và ứng dụng không tự xử lý việc này, thì chế độ hiển thị IME trước đó sẽ không được khôi phục.

Nếu ứng dụng của bạn trải qua một thay đổi về cấu hình mà ứng dụng không xử lý và ứng dụng cần bàn phím hiển thị sau khi thay đổi, thì bạn phải yêu cầu rõ ràng điều này. Bạn có thể gửi yêu cầu này theo một trong những cách sau:

  • Đặt thuộc tính android:windowSoftInputMode thành stateAlwaysVisible.
  • Yêu cầu bàn phím mềm theo phương thức lập trình trong phương thức onCreate() của hoạt động hoặc thêm phương thức onConfigurationChanged().

Dữ liệu đầu vào của con người

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 con người như bàn phím và bàn di chuột.

Bàn di chuột cung cấp các sự kiện tương đối theo mặc định 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 ở chế độ 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 giới thiệu tính năng ghép nối lại tự động, một điểm cải tiến ở cấp hệ thống được thiết kế để tự động giải quyết tình trạng mất liên kết Bluetooth.

Trước đây, nếu mất liên kết, người dùng phải chuyển đến phần Cài đặt theo cách thủ công để huỷ liên kết rồi liên kết lại thiết bị ngoại vi. Tính năng này dựa trên việc cải thiện tính bảo mật của Android 16 bằng cách cho phép hệ thống thiết lập lại các mối liên kết ở chế độ nền mà không yêu cầu người dùng chuyển đến phần Cài đặt theo cách thủ công để hủy ghép nối và ghép nối lại các thiết bị ngoại vi.

Mặc dù hầu hết các ứng dụng sẽ không yêu cầu thay đổi mã, nhưng nhà phát triển cần lưu ý đến những thay đổi sau đây về hành vi trong ngăn xếp Bluetooth:

  • Ngữ cảnh ghép nối mới: ACTION_PAIRING_REQUEST hiện bao gồm phần bổ sung EXTRA_PAIRING_CONTEXT cho phép các ứng dụng phân biệt giữa yêu cầu ghép nối tiêu chuẩn và nỗ lực ghép nối lại do hệ thống tự động khởi tạo.
  • Cập nhật khoá có điều kiện: Các khoá bảo mật hiện có sẽ chỉ được thay thế nếu quá trình ghép nối lại thành công và kết nối mới đáp ứng hoặc vượt quá mức bảo mật của mối liên kết trước đó.
  • Đã sửa đổi thời gian dự định: Giờ đây, ý định ACTION_KEY_MISSING chỉ được truyền đi nếu không thể tự động ghép nối lại. Điều này giúp giảm việc xử lý lỗi không cần thiết trong ứng dụng nếu hệ thống khôi phục thành công mối liên kết ở chế độ nền.
  • Thông báo cho người dùng: Hệ thống quản lý việc ghép nối lại thông qua các thông báo và hộp thoại mới trên giao diện người dùng. Người dùng sẽ được nhắc xác nhận việc thử ghép nối lại để đảm bảo họ biết về việc kết nối lại.

Nhà sản xuất thiết bị ngoại vi và nhà phát triển ứng dụng đồng hành nên xác minh rằng phần cứng và ứng dụng xử lý các quá trình chuyển đổi liên kết một cách suôn sẻ. Để kiểm thử hành vi này, hãy mô phỏng tình trạng mất liên kết từ xa bằng một trong các phương thức sau:

  • Xoá thông tin liên kết khỏi thiết bị ngoại vi theo cách thủ công
  • Huỷ ghép nối thiết bị theo cách thủ công trong phần: Cài đặt > Thiết bị đã kết nối