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

Nền tảng Android 16 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 16, 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 16.

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

Android 16 (cấp độ API 36) có các 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.

Tối ưu hoá hạn mức JobScheduler

从 Android 16 开始，我们将根据以下因素调整常规作业和加急作业的执行运行时配额：

• 应用所处的应用待机存储分区：在 Android 16 中，活跃待机存储分区将开始通过宽松的运行时配额强制执行。
• 如果作业在应用处于前台状态时开始执行：在 Android 16 中，如果作业在应用对用户可见时开始执行，并在应用变为不可见后继续执行，则会遵守作业运行时配额。
• 如果作业在运行前台服务时执行：在 Android 16 中，与前台服务同时执行的作业将遵守作业运行时配额。如果您利用作业进行用户发起的数据传输，请考虑改用用户发起的数据传输作业。

此变更会影响使用 WorkManager、JobScheduler 和 DownloadManager 调度的任务。如需调试作业停止的原因，我们建议您通过调用 WorkInfo.getStopReason()（对于 JobScheduler 作业，请调用 JobParameters.getStopReason()）来记录作业停止的原因。

如需了解应用的状态如何影响其可使用的资源，请参阅电源管理资源限制。 如需详细了解电池优化方面的最佳实践，请参阅有关针对任务调度 API 优化电池使用的指南。

我们还建议利用 Android 16 中引入的新 JobScheduler#getPendingJobReasonsHistory API 来了解作业未执行的原因。

测试

如需测试应用的行为，只要应用在 Android 16 设备上运行，您就可以启用对某些作业配额优化功能的替换。

如需停用“顶级状态将遵守作业运行时配额”的强制执行，请运行以下 adb 命令：

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

如需停用“在与前台服务同时执行时，作业将遵守作业运行时配额”的强制执行，请运行以下 adb 命令：

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

如需测试特定应用待机分桶行为，您可以使用以下 adb 命令设置应用的应用待机分桶：

adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted

如需了解应用所在的待机分桶，您可以使用以下 adb 命令获取应用的待机分桶：

adb shell am get-standby-bucket APP_PACKAGE_NAME

Lý do dừng công việc trống bị bỏ qua

Công việc bị bỏ dở xảy ra khi đối tượng JobParameters liên kết với công việc đã được thu thập rác, nhưng JobService#jobFinished(JobParameters, boolean) chưa được gọi để báo hiệu công việc đã hoàn tất. Điều này cho biết rằng công việc có thể đang chạy và được lên lịch lại mà ứng dụng không biết.

Các ứng dụng dựa vào JobScheduler không duy trì tham chiếu mạnh đến đối tượng JobParameters và giờ đây, thời gian chờ sẽ được cấp lý do dừng công việc mới STOP_REASON_TIMEOUT_ABANDONED thay vì STOP_REASON_TIMEOUT.

Nếu lý do dừng mới bị bỏ dở thường xuyên xuất hiện, hệ thống sẽ thực hiện các bước giảm thiểu để giảm tần suất công việc.

Ứng dụng nên sử dụng lý do dừng mới để phát hiện và giảm số lượng công việc bị bỏ ngang.

Nếu đang sử dụng WorkManager, AsyncTask hoặc DownloadManager, bạn sẽ không bị ảnh hưởng vì các API này thay mặt ứng dụng quản lý vòng đời công việc.

Hoàn toàn không dùng JobInfo#setImportantWhileForeground nữa

Phương thức JobInfo.Builder#setImportantWhileForeground(boolean) cho biết tầm quan trọng của một công việc trong khi ứng dụng lên lịch chạy ở nền trước hoặc khi tạm thời được miễn các quy định hạn chế về chế độ nền.

Phương thức này không được dùng nữa kể từ Android 12 (API cấp 31). Kể từ Android 16, phương thức này không còn hoạt động hiệu quả và việc gọi phương thức này sẽ bị bỏ qua.

Việc xoá chức năng này cũng áp dụng cho JobInfo#isImportantWhileForeground(). Kể từ Android 16, nếu được gọi, phương thức này sẽ trả về false.

Phạm vi ưu tiên của chương trình phát sóng theo thứ tự không còn là phạm vi chung nữa

Ứng dụng Android được phép xác định mức độ ưu tiên trên broadcast receiver để kiểm soát thứ tự mà các broadcast receiver nhận và xử lý thông báo truyền tin. Đối với trình nhận được khai báo trong tệp kê khai, ứng dụng có thể sử dụng thuộc tính android:priority để xác định mức độ ưu tiên và đối với trình nhận được đăng ký theo ngữ cảnh, ứng dụng có thể sử dụng API IntentFilter#setPriority() để xác định mức độ ưu tiên. Khi gửi thông báo truyền tin, hệ thống sẽ phân phối thông báo đó đến các trình thu nhận theo thứ tự ưu tiên, từ cao nhất đến thấp nhất.

Trong Android 16, thứ tự phân phối thông báo truyền tin bằng thuộc tính android:priority hoặc IntentFilter#setPriority() trên các quy trình khác nhau sẽ không được đảm bảo. Mức độ ưu tiên của thông báo truyền tin sẽ chỉ được tuân thủ trong cùng một quy trình ứng dụng thay vì trên tất cả các quy trình.

Ngoài ra, mức độ ưu tiên của thông báo truyền tin sẽ tự động được giới hạn trong phạm vi (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY – 1). Chỉ các thành phần hệ thống mới được phép đặt SYSTEM_LOW_PRIORITY, SYSTEM_HIGH_PRIORITY làm mức độ ưu tiên truyền tin.

Ứng dụng của bạn có thể bị ảnh hưởng nếu thực hiện một trong những hành động sau:

1. Ứng dụng của bạn đã khai báo nhiều quy trình có cùng một ý định truyền tin và có kỳ vọng về việc nhận các ý định đó theo một thứ tự nhất định dựa trên mức độ ưu tiên.
2. Quy trình ứng dụng của bạn tương tác với các quy trình khác và có những kỳ vọng về việc nhận ý định truyền tin theo một thứ tự nhất định.

Nếu các quy trình cần phối hợp với nhau, thì các quy trình đó phải giao tiếp bằng các kênh phối hợp khác.

Thay đổi nội bộ của ART

Android 16 bao gồm các bản cập nhật mới nhất cho Android Runtime (ART) giúp cải thiện hiệu suất của Android Runtime (ART) và hỗ trợ thêm các tính năng Java. Thông qua Bản cập nhật hệ thống Google Play, hơn một tỷ thiết bị chạy Android 12 (API cấp 31) trở lên cũng có thể sử dụng các điểm cải tiến này.

Khi những thay đổi này được phát hành, các thư viện và mã ứng dụng dựa vào cấu trúc nội bộ của ART có thể không hoạt động chính xác trên các thiết bị chạy Android 16, cùng với các phiên bản Android cũ cập nhật mô-đun ART thông qua bản cập nhật hệ thống Google Play.

Việc dựa vào các cấu trúc nội bộ (chẳng hạn như giao diện không phải SDK) luôn có thể dẫn đến các vấn đề về khả năng tương thích, nhưng điều đặc biệt quan trọng là tránh dựa vào mã (hoặc thư viện chứa mã) tận dụng các cấu trúc ART nội bộ, vì các thay đổi về ART không liên quan đến phiên bản nền tảng mà thiết bị đang chạy và các thay đổi này sẽ được áp dụng cho hơn một tỷ thiết bị thông qua các bản cập nhật hệ thống của Google Play.

Tất cả nhà phát triển đều nên kiểm tra xem ứng dụng của họ có bị ảnh hưởng hay không bằng cách kiểm thử kỹ lưỡng ứng dụng trên Android 16. Ngoài ra, hãy kiểm tra các vấn đề đã biết để xem ứng dụng của bạn có phụ thuộc vào bất kỳ thư viện nào mà chúng tôi đã xác định là dựa vào cấu trúc ART nội bộ hay không. Nếu mã ứng dụng hoặc các phần phụ thuộc thư viện của bạn bị ảnh hưởng, hãy tìm các API công khai thay thế bất cứ khi nào có thể và yêu cầu API công khai cho các trường hợp sử dụng mới bằng cách tạo yêu cầu về tính năng trong công cụ theo dõi lỗi của chúng tôi.

Chế độ tương thích với kích thước trang 16 KB

Android 15 đã ra mắt tính năng hỗ trợ trang bộ nhớ 16 KB để tối ưu hoá hiệu suất của nền tảng. Android 16 bổ sung một chế độ tương thích, cho phép một số ứng dụng được tạo cho các trang bộ nhớ 4 KB chạy trên một thiết bị được định cấu hình cho các trang bộ nhớ 16 KB.

Khi ứng dụng của bạn đang chạy trên một thiết bị chạy Android 16 trở lên, nếu Android phát hiện thấy ứng dụng của bạn có các trang bộ nhớ được căn chỉnh 4 KB, thì Android sẽ tự động sử dụng chế độ tương thích và hiển thị hộp thoại thông báo cho người dùng. Việc đặt thuộc tính android:pageSizeCompat trong AndroidManifest.xml để bật chế độ tương thích ngược sẽ ngăn hộp thoại hiển thị khi ứng dụng khởi chạy. Để sử dụng thuộc tính android:pageSizeCompat, hãy biên dịch ứng dụng bằng SDK Android 16.

Để có hiệu suất, độ tin cậy và độ ổn định tốt nhất, ứng dụng của bạn vẫn phải được căn chỉnh 16 KB. Hãy xem bài đăng gần đây trên blog của chúng tôi về cách cập nhật ứng dụng để hỗ trợ trang bộ nhớ 16 KB để biết thêm thông tin chi tiết.

Hộp thoại chế độ tương thích sẽ hiển thị khi hệ thống phát hiện thấy một ứng dụng được căn chỉnh 4 KB có thể chạy tối ưu hơn nếu được căn chỉnh 16 KB.

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

Android 16 (cấp độ API 36) có các 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ông dùng các thông báo hỗ trợ tiếp cận gây gián đoạn nữa

Android 16 không dùng thông báo hỗ trợ tiếp cận nữa, được xác định bằng việc sử dụng announceForAccessibility hoặc gửi sự kiện hỗ trợ tiếp cận TYPE_ANNOUNCEMENT. Những điều này có thể tạo ra trải nghiệm người dùng không nhất quán cho người dùng TalkBack và trình đọc màn hình của Android, đồng thời các giải pháp thay thế sẽ phục vụ tốt hơn nhiều nhu cầu của người dùng trên nhiều công nghệ hỗ trợ của Android.

Ví dụ về các lựa chọn thay thế:

• Đối với các thay đổi đáng kể về giao diện người dùng như thay đổi cửa sổ, hãy sử dụng Activity.setTitle(CharSequence) và setAccessibilityPaneTitle(java.lang.CharSequence). Trong Compose, hãy sử dụng Modifier.semantics { paneTitle = "paneTitle" }
• Để thông báo cho người dùng về những thay đổi đối với giao diện người dùng quan trọng, hãy sử dụng setAccessibilityLiveRegion(int). Trong Compose, hãy sử dụng Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]} . Bạn nên sử dụng các thông báo này một cách tiết kiệm vì chúng có thể tạo thông báo mỗi khi Chế độ xem được cập nhật.
• Để thông báo cho người dùng về lỗi, hãy gửi AccessibilityEvent thuộc loại AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR và đặt AccessibilityNodeInfo#setError(CharSequence) hoặc sử dụng TextView#setError(CharSequence).

Tài liệu tham khảo cho API announceForAccessibility không dùng nữa bao gồm thêm thông tin chi tiết về các giải pháp thay thế được đề xuất.

Hỗ trợ thao tác bằng 3 nút

Android 16 hỗ trợ tính năng xem trước thao tác quay lại cho chế độ điều hướng bằng 3 nút cho các ứng dụng đã di chuyển đúng cách sang tính năng xem trước thao tác quay lại. Thao tác nhấn và giữ nút quay lại sẽ bắt đầu ảnh động xem trước thao tác quay lại, cho bạn xem trước vị trí mà thao tác vuốt ngược sẽ đưa bạn đến.

Hành vi này áp dụng cho tất cả các khu vực của hệ thống hỗ trợ ảnh động xem trước thao tác quay lại, bao gồm cả ảnh động hệ thống (quay lại màn hình chính, giữa các tác vụ và giữa các hoạt động).

Ảnh động xem trước thao tác quay lại ở chế độ điều hướng bằng 3 nút.

Biểu tượng ứng dụng theo chủ đề tự động

Kể từ Android 16 QPR 2, Android sẽ tự động áp dụng các giao diện cho biểu tượng ứng dụng để tạo trải nghiệm nhất quán trên màn hình chính. Tình trạng này xảy ra nếu một ứng dụng không cung cấp biểu tượng ứng dụng theo chủ đề riêng. Các ứng dụng có thể kiểm soát thiết kế của biểu tượng ứng dụng theo chủ đề bằng cách thêm một lớp đơn sắc vào biểu tượng thích ứng và xem trước giao diện của biểu tượng ứng dụng trong Android Studio.

Kiểu dáng thiết bị

Android 16 (cấp độ API 36) có các thay đổi sau đây đối với ứng dụng khi được chủ sở hữu thiết bị ảo chiếu lên màn hình.

Ghi đè của chủ sở hữu thiết bị ảo

Chủ sở hữu thiết bị ảo là một ứng dụng đáng tin cậy hoặc có đặc quyền, tạo và quản lý một thiết bị ảo. Chủ sở hữu thiết bị ảo chạy các ứng dụng trên một thiết bị ảo, sau đó chiếu các ứng dụng đó lên màn hình của một thiết bị từ xa, chẳng hạn như máy tính cá nhân, thiết bị thực tế ảo hoặc hệ thống thông tin giải trí trên ô tô. Chủ sở hữu thiết bị ảo nằm trên một thiết bị cục bộ, chẳng hạn như điện thoại di động.

Chủ sở hữu thiết bị ảo trên điện thoại tạo thiết bị ảo chiếu ứng dụng lên màn hình từ xa.

Ghi đè cho mỗi ứng dụng

Trên các thiết bị chạy Android 16 (cấp độ API 36), chủ sở hữu thiết bị ảo có thể ghi đè chế độ cài đặt ứng dụng trên một số thiết bị ảo mà chủ sở hữu thiết bị ảo quản lý. Ví dụ: để cải thiện bố cục ứng dụng, chủ sở hữu thiết bị ảo có thể bỏ qua các hạn chế về hướng, tỷ lệ khung hình và khả năng thay đổi kích thước khi chiếu ứng dụng lên màn hình ngoài.

Các thay đổi có thể gây lỗi thường gặp

Hành vi của Android 16 có thể ảnh hưởng đến giao diện người dùng của ứng dụng trên các hệ số hình dạng màn hình lớn, chẳng hạn như màn hình ô tô hoặc Chromebook, đặc biệt là các bố cục được thiết kế cho màn hình nhỏ ở hướng dọc. Để tìm hiểu cách giúp ứng dụng thích ứng với mọi hệ số hình dạng thiết bị, hãy xem bài viết Giới thiệu về bố cục thích ứng.

Tài liệu tham khảo

Truyền phát ứng dụng đồng hành

Bảo mật

Android 16 (cấp độ API 36) có các thay đổi giúp tăng cường bảo mật hệ thống để bảo vệ ứng dụng và người dùng khỏi các ứng dụng độc hại.

Cải thiện độ bảo mật để chống lại các cuộc tấn công chuyển hướng ý định

Android 16 针对一般的 Intent 重定向攻击提供了默认安全性，并且只需要最低限度的兼容性和开发者更改。

我们引入了默认安全加固解决方案，以应对 Intent 重定向漏洞。在大多数情况下，正常使用 intent 的应用不会遇到任何兼容性问题；我们在整个开发过程中收集了指标，以监控哪些应用可能会出现中断。

Intent 重定向在 Android 中出现，当攻击者可以部分或完全 控制用于在存在漏洞的应用上下文中启动新组件的 intent 内容时，而受害应用会在 intent 的 extra 字段中启动不受信任的子级 intent。这可能会导致攻击者应用在受害应用的上下文中启动私有组件、触发特权操作或获取对敏感数据的 URI 访问权限，从而可能导致数据窃取和任意代码执行。

选择停用 intent 重定向处理

Android 16 引入了一个新 API，允许应用选择停用启动安全保护。在默认安全行为会干扰合法应用用例的特定情况下，这可能是必要的。

重要提示： 选择停用安全保护时应谨慎，并且 仅在绝对必要时才应这样做，因为这可能会增加安全 漏洞的风险。在使用此 API 之前，请仔细评估其对应用安全性的潜在影响。

对于针对 Android 16（API 级别 36）SDK 或更高版本进行编译的应用

您可以直接对 Intent 对象使用 removeLaunchSecurityProtection() 方法。

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }

对于针对 Android 15（API 级别 35）或更低版本进行编译的应用

虽然不建议这样做，但您可以使用反射来访问 removeLaunchSecurityProtection() 方法。

注意： 使用反射可能会使您的代码更加脆弱且容易出错， 尤其是在底层 API 在未来的 Android 版本中发生更改的情况下。在条件允许的情况下，请更新您的编译 SDK 以面向 Android 16（API 级别 36）或更高版本，以便直接使用该 API。

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent", Intent::class.java)
try {
    val removeLaunchSecurityProtection = Intent::class.java.getDeclaredMethod("removeLaunchSecurityProtection")
    removeLaunchSecurityProtection.invoke(iSublevel)
} catch (e: Exception) {
    // Handle the exception, e.g., log it
} // Opt-out from the security hardening using reflection
iSublevel?.let { startActivity(it) }

Ứng dụng đồng hành không còn được thông báo về thời gian chờ phát hiện nữa

Android 16 giới thiệu một hành vi mới trong quy trình ghép nối thiết bị đồng hành để bảo vệ quyền riêng tư về vị trí của người dùng khỏi các ứng dụng độc hại. Tất cả ứng dụng đồng hành chạy trên Android 16 không còn được thông báo trực tiếp về thời gian chờ khám phá bằng RESULT_DISCOVERY_TIMEOUT. Thay vào đó, người dùng sẽ được thông báo về các sự kiện hết thời gian chờ bằng một hộp thoại trực quan. Khi người dùng đóng hộp thoại, ứng dụng sẽ được cảnh báo về lỗi liên kết với RESULT_USER_REJECTED.

Thời lượng tìm kiếm cũng được kéo dài từ 20 giây ban đầu, và người dùng có thể dừng quá trình khám phá thiết bị bất cứ lúc nào trong quá trình tìm kiếm. Nếu phát hiện được ít nhất một thiết bị trong 20 giây đầu tiên kể từ khi bắt đầu tìm kiếm, thì CDM sẽ ngừng tìm kiếm các thiết bị khác.

Khả năng kết nối

Android 16 (cấp độ API 36) có các thay đổi sau đây trong ngăn xếp Bluetooth để cải thiện khả năng kết nối với các thiết bị ngoại vi.

Cải thiện khả năng xử lý tình trạng mất liên kết

Kể từ Android 16, ngăn xếp Bluetooth đã được cập nhật để cải thiện tính bảo mật và trải nghiệm người dùng khi phát hiện thấy mất liên kết từ xa. Trước đây, hệ thống sẽ tự động xoá mối liên kết và bắt đầu một quy trình ghép nối mới, điều này có thể dẫn đến việc ghép nối lại ngoài ý muốn. Chúng tôi nhận thấy trong nhiều trường hợp, các ứng dụng không xử lý sự kiện mất liên kết một cách nhất quán.

Để hợp nhất trải nghiệm, Android 16 đã cải thiện khả năng xử lý mất liên kết với hệ thống. Nếu không xác thực được thiết bị Bluetooth đã liên kết trước đó khi kết nối lại, hệ thống sẽ ngắt kết nối đường liên kết, giữ lại thông tin liên kết cục bộ và hiển thị hộp thoại hệ thống thông báo cho người dùng về việc mất liên kết và hướng dẫn họ ghép nối lại.