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 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 lai khác trước khi chúng kích hoạt tình trạng bất ổn 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à các ứ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 ứng dụng, nhưng bạn nên áp dụng 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

Kể từ Android 17, Android sẽ mở rộng phạm vi bảo vệ cho các tin nhắn SMS chứa mật khẩu một lần (OTP).

Trong các phiên bản Android trước, tính năng bảo vệ này chủ yếu tập trung vào định dạng SMS Retriever. Việc gửi tin nhắn chứa hàm băm của trình truy xuất SMS bị trì hoãn trong 3 giờ đối với hầu hết các ứng dụng. Tuy nhiên, một số ứng dụng (chẳng hạn như trình xử lý SMS mặc định) được miễn áp dụng độ trễ và ứng dụng sở hữu hàm băm cũng được miễn áp dụng.

Kể từ Android 17, biện pháp bảo vệ này cũng được áp dụng cho các thông báo định dạng WebOTP. Nếu một ứng dụng có quyền đọc tin nhắn SMS nhưng không phải là người nhận dự kiến của một tin nhắn WebOTP (theo kết quả xác minh miền), thì ứng dụng đó sẽ không truy cập được vào tin nhắn cho đến 3 giờ sau khi nhận được tin nhắn. Thay đổi này nhằm mục đích cải thiện tính bảo mật cho người dùng bằng cách đảm bảo rằng chỉ những ứng dụng được liên kết với miền được đề cập trong thông báo mới có thể đọc mã xác minh theo phương thức lập trình.

Trong khoảng thời gian trì hoãn 3 giờ này, thông báo truyền tin SMS_RECEIVED_ACTION sẽ bị giữ lại và các truy vấn cơ sở dữ liệu của nhà cung cấp SMS sẽ được lọc. Sau thời gian trễ, các ứng dụng này có thể nhận được tin nhắn SMS. Thay đổi này áp dụng cho tất cả ứng dụng, bất kể cấp độ API mục tiêu của ứng dụng.

Một số ứng dụng như ứng dụng trợ lý SMS mặc định, các ứng dụng đồng hành của thiết bị thông minh, v.v. được miễn trừ khỏi quy định về độ trễ này. Tất cả các ứng dụng dựa vào việc đọc tin nhắn SMS để trích xuất OTP đều phải chuyển sang sử dụng API SMS Retriever hoặc SMS User Consent để đảm bảo chức năng tiếp tục hoạt động.

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

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ác quyền ngầm định đối với URI

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:

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

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:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

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:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

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 loopback trên nhiều hồ sơ

Beginning with Android 17, cross-profile loopback traffic is no longer permitted by default. Loopback traffic within the same profile is not affected. This change applies to all apps running on Android 17 or higher, regardless of what API level the app targets.

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

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ỏ

Kể từ Android 17, nếu một ứng dụng yêu cầu chụp con trỏ bằng View.requestPointerCapture() và người dùng sử dụng bàn di chuột, thì hệ thống sẽ nhận dạng chuyển động của con trỏ và cử chỉ di chuyển từ các thao tác chạm của người dùng, đồng thời báo cáo các thao tác đó cho ứng dụng theo cách tương tự như chuyển động của con trỏ và bánh xe di chuyển từ chuột được chụp. Trong hầu hết các trường hợp, điều này giúp các ứng dụng hỗ trợ chuột được ghi lại không cần thêm logic xử lý đặc biệt cho bàn di chuột. Để biết thêm thông tin chi tiết, hãy xem tài liệu về View.POINTER_CAPTURE_MODE_RELATIVE.

Trước đây, hệ thống không cố gắng nhận dạng cử chỉ từ bàn di chuột mà thay vào đó, hệ thống sẽ gửi vị trí ngón tay thô, tuyệt đối đến ứng dụng ở định dạng tương tự như các lần chạm trên màn hình cảm ứng. Nếu vẫn cần dữ liệu tuyệt đối này, ứng dụng nên gọi phương thức View.requestPointerCapture(int) mới bằng View.POINTER_CAPTURE_MODE_ABSOLUTE.

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

Bắt đầu từ Android 17, khung âm thanh sẽ thực thi các quy tắc hạn chế đối với hoạt động tương tác âm thanh ở chế độ nền, bao gồm cả việc phát âm thanh, yêu cầu lấy tiêu điểm âm thanh và các API thay đổi âm lượng để đảm bảo rằng người dùng chủ ý bắt đầu những thay đổi này.

Nếu ứng dụng cố gắng gọi các API âm thanh khi ứng dụng không ở trong một vòng đời hợp lệ, thì các API phát âm thanh và thay đổi âm lượng sẽ âm thầm không hoạt động mà không đưa ra một ngoại lệ hoặc cung cấp thông báo lỗi. API quyền phát âm thanh không thành công với mã kết quả AUDIOFOCUS_REQUEST_FAILED.

Để biết thêm thông tin, bao gồm cả các chiến lược giảm thiểu, hãy xem phần Tăng cường bảo mật cho âm thanh nền.

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