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 (cấp độ API 37) có những thay đổi sau đây nhằm 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 introduces app memory limits based on the device's total RAM to create a more stable and deterministic environment for your applications and Android users. In Android 17, limits are set conservatively to establish system baselines, targeting extreme 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 LeakCanary task in the Android Studio Profiler.

To help you find memory leaks, Android Studio Panda adds LeakCanary integration directly in the Android Studio Profiler as a dedicated task, contextualized within the IDE and fully integrated with your source code.

Bảo mật

Android 17 có những điểm cải tiến sau đây về khả năng 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

Hiện tại, nếu một ứng dụng chạy một ý định có URI với thao tác Send, SendMultiple hoặc ImageCapture, thì hệ thống sẽ tự động cấp quyền đọc và ghi URI cho ứng dụng đích. Chúng tôi dự định thay đổi hành vi này trong Android 18. Vì lý do này, bạn nên cấp quyền URI một cách rõ ràng cho các ứng dụng có liên quan thay vì dựa vào hệ thống để cấp quyền.

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.

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

Nhập liệu 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ị nhập liệu 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 nắm bắt 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 nhằm 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 tự động ghép nối lại, một tính năng nâng cao ở cấp hệ thống được thiết kế để tự động giải quyết tình trạng mất kết nối Bluetooth.

Trước đây, nếu mất kết nối, người dùng phải tự chuyển đến phần Cài đặt để huỷ ghép nối rồi ghép nối lại thiết bị ngoại vi. Tính năng này dựa trên tính năng cải thiện bảo mật của Android 16 bằng cách cho phép hệ thống thiết lập lại kết nối trong nền mà không yêu cầu người dùng tự chuyển đến phần Cài đặt để hủy ghép nối và ghép nối lại 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 nên lưu ý đến những thay đổi về hành vi sau đây trong ngăn xếp Bluetooth:

  • Bối 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 ứ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 tự động ghép nối lại do hệ thố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 kết nối trước đó.
  • Thời gian ý định đã sửa đổi: Ý định ACTION_KEY_MISSING hiện chỉ được truyền đi nếu nỗ lực tự động ghép nối lại không thành công. Đ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 kết nối trong 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 nỗ lực 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 kết nối 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 kết nối từ xa bằng một trong các phương thức sau:

  • Xoá thông tin kết nối theo cách thủ công khỏi thiết bị ngoại vi
  • 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