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

Kể từ Android 16, chúng tôi sẽ điều chỉnh hạn mức thời gian chạy thực thi công việc thông thường và công việc khẩn cấp dựa trên các yếu tố sau:

• Ứng dụng nằm trong nhóm chờ của ứng dụng nào: trong Android 16, các nhóm chờ đang hoạt động sẽ bắt đầu được thực thi theo hạn mức thời gian chạy lớn.
• Nếu lệnh bắt đầu thực thi trong khi ứng dụng ở trạng thái trên cùng: trong Android 16, các lệnh bắt đầu trong khi ứng dụng hiển thị với người dùng và tiếp tục sau khi ứng dụng trở nên không hiển thị sẽ tuân thủ hạn mức thời gian chạy của lệnh.
• Nếu lệnh đang thực thi trong khi chạy Dịch vụ trên nền trước: trong Android 16, những lệnh đang thực thi đồng thời với một dịch vụ trên nền trước sẽ tuân thủ hạn mức thời gian chạy lệnh. Nếu bạn đang tận dụng các công việc để chuyển dữ liệu do người dùng yêu cầu, hãy cân nhắc sử dụng công việc chuyển dữ liệu do người dùng yêu cầu.

Thay đổi này ảnh hưởng đến các tác vụ được lên lịch bằng WorkManager, JobScheduler và DownloadManager. Để gỡ lỗi lý do một công việc bị dừng, bạn nên ghi nhật ký lý do công việc của bạn bị dừng bằng cách gọi WorkInfo.getStopReason() (đối với các công việc JobScheduler, hãy gọi JobParameters.getStopReason()).

Để biết thông tin về cách trạng thái của ứng dụng ảnh hưởng đến những tài nguyên mà ứng dụng có thể sử dụng, hãy xem phần Hạn mức tài nguyên quản lý nguồn. Để biết thêm thông tin về các phương pháp hay nhất giúp tối ưu hoá pin, hãy tham khảo hướng dẫn về cách tối ưu hoá mức sử dụng pin cho các API lập lịch tác vụ.

Bạn cũng nên tận dụng API JobScheduler#getPendingJobReasonsHistory mới được ra mắt trong Android 16 để biết lý do một công việc chưa được thực thi.

Thử nghiệm

Để kiểm thử hành vi của ứng dụng, bạn có thể bật chế độ ghi đè một số hoạt động tối ưu hoá hạn ngạch công việc nhất định miễn là ứng dụng đang chạy trên thiết bị Android 16.

Để tắt chế độ thực thi "trạng thái hàng đầu sẽ tuân thủ hạn mức thời gian chạy của công việc", hãy chạy lệnh adb sau:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

Để tắt việc thực thi "các công việc đang thực thi đồng thời với một dịch vụ trên nền trước sẽ tuân thủ hạn ngạch thời gian chạy công việc", hãy chạy lệnh adb sau:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

Để kiểm thử một số hành vi của nhóm chế độ chờ của ứng dụng, bạn có thể đặt nhóm chế độ chờ của ứng dụng bằng lệnh adb sau:

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

Để biết ứng dụng của bạn nằm trong nhóm chế độ chờ ứng dụng nào, bạn có thể lấy nhóm chế độ chờ ứng dụng của ứng dụng bằng lệnh adb sau:

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

JobInfo.Builder#setImportantWhileForeground(boolean) 方法用于在调度应用位于前台或暂时豁免于后台限制时指示作业的优先级。

自 Android 12（API 级别 31）起，此方法已废弃。从 Android 16 开始，它不再有效，系统会忽略调用此方法。

此功能移除也适用于 JobInfo#isImportantWhileForeground()。从 Android 16 开始，如果调用该方法，该方法会返回 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

Android 应用可以为广播接收器定义优先级，以控制接收器接收和处理广播的顺序。对于清单声明的接收器，应用可以使用 android:priority 属性来定义优先级；对于上下文注册的接收器，应用可以使用 IntentFilter#setPriority() API 来定义优先级。发送广播时，系统会按接收器的优先级（从高到低）将其传送给接收器。

在 Android 16 中，无法保证使用 android:priority 属性或 IntentFilter#setPriority() 在不同进程中传送广播的顺序。广播优先级仅在同一应用进程内有效，而不会跨所有进程有效。

此外，广播优先级将自动限制在 (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1) 的范围内。只有系统组件才能将 SYSTEM_LOW_PRIORITY、SYSTEM_HIGH_PRIORITY 设置为广播优先级。

如果您的应用执行以下任一操作，可能会受到影响：

1. 您的应用声明了具有相同广播 intent 的多个进程，并且希望根据优先级以特定顺序接收这些 intent。
2. 您的应用进程与其他进程交互，并期望以特定顺序接收广播 intent。

如果进程需要相互协调，则应使用其他协调渠道进行通信。

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 引入了对 16 KB 内存页面的支持，以优化平台性能。Android 16 添加了兼容模式，让一些针对 4 KB 内存页面构建的应用可以在配置为 16 KB 内存页面的设备上运行。

当您的应用在搭载 Android 16 或更高版本的设备上运行时，如果 Android 检测到您的应用具有 4 KB 对齐的内存页面，则会自动使用兼容模式并向用户显示通知对话框。在 AndroidManifest.xml 中设置 android:pageSizeCompat 属性以启用向后兼容模式，将会阻止应用启动时显示对话框。如需使用 android:pageSizeCompat 属性，请使用 Android 16 SDK 编译您的应用。

为了实现最佳性能、可靠性和稳定性，应用仍应以 16 KB 对齐。如需了解详情，请参阅我们近期发布的博文，了解如何更新应用以支持 16 KB 的内存页面。

兼容模式对话框：当系统检测到 4 KB 对齐的应用在 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 为已正确迁移到预测性返回的应用的三按钮导航栏引入了预测性返回支持。长按返回按钮会启动预测性返回动画，让您预览返回滑动手势会打开的界面。

此行为适用于系统中支持预测性返回动画的所有区域，包括系统动画（返回主屏幕、跨任务和跨 activity）。

“三按钮”导航模式下的预测性返回动画。

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

从 Android 16 QPR 2 开始，Android 会自动将主题应用于应用图标，以打造一致的主屏幕体验。如果应用未提供自己的带主题的应用图标，就会发生这种情况。应用可以通过在自适应图标中添加单色图层来控制主题化应用图标的设计，并在 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

虚拟设备所有者是创建和管理虚拟设备的可信应用或特权应用。虚拟设备所有者在虚拟设备上运行应用，然后将应用投影到远程设备的显示屏上，例如个人电脑、虚拟现实设备或车载信息娱乐系统。虚拟设备所有者使用的是本地设备，例如手机。

手机上的虚拟设备所有者创建将应用投影到远程显示屏的虚拟设备。

按应用替换项

在搭载 Android 16（API 级别 36）的设备上，虚拟设备所有者可以替换其管理的特定虚拟设备上的应用设置。例如，为了改进应用布局，虚拟设备所有者在将应用投影到外部显示屏上时，可以忽略屏幕方向、宽高比和可调整大小性限制。

常见的重大更改

Android 16 的行为可能会影响应用在汽车显示屏或 Chromebook 等大屏幕设备规格上的界面，尤其是那些专为竖屏小显示屏设计的布局。如需了解如何让应用适应所有设备类型，请参阅关于自适应布局。

参考

配套应用串流

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 cung cấp tính năng bảo mật mặc định chống lại các cuộc tấn công chuyển hướng Intent thông thường, với khả năng tương thích tối thiểu và các thay đổi cần thiết cho nhà phát triển.

Chúng tôi đang giới thiệu các giải pháp tăng cường bảo mật theo mặc định để khai thác các lỗ hổng chuyển hướng Intent. Trong hầu hết các trường hợp, các ứng dụng sử dụng ý định thông thường sẽ không gặp phải bất kỳ vấn đề nào về khả năng tương thích; chúng tôi đã thu thập các chỉ số trong suốt quá trình phát triển để theo dõi những ứng dụng có thể gặp phải sự cố.

Chuyển hướng ý định trong Android xảy ra khi kẻ tấn công có thể kiểm soát một phần hoặc toàn bộ nội dung của ý định dùng để chạy một thành phần mới trong bối cảnh một ứng dụng dễ bị tấn công, trong khi ứng dụng nạn nhân chạy một ý định cấp phụ không đáng tin cậy trong một trường bổ sung của một ("cấp cao nhất") Ý định. Điều này có thể dẫn đến việc ứng dụng của kẻ tấn công chạy các thành phần riêng tư trong bối cảnh ứng dụng nạn nhân, kích hoạt các hành động đặc quyền hoặc giành quyền truy cập URI vào dữ liệu nhạy cảm, có khả năng dẫn đến hành vi trộm cắp dữ liệu và thực thi mã tuỳ ý.

Chọn không xử lý việc chuyển hướng ý định

Android 16 giới thiệu một API mới cho phép các ứng dụng chọn không sử dụng các biện pháp bảo vệ bảo mật khi chạy. Điều này có thể cần thiết trong một số trường hợp cụ thể khi hành vi bảo mật mặc định gây trở ngại cho các trường hợp sử dụng ứng dụng hợp lệ.

Quan trọng: Bạn nên thận trọng khi chọn không sử dụng các biện pháp bảo vệ bảo mật và chỉ chọn khi thực sự cần thiết, vì điều này có thể làm tăng nguy cơ xuất hiện các lỗ hổng bảo mật. Hãy đánh giá cẩn thận tác động tiềm ẩn đối với tính bảo mật của ứng dụng trước khi sử dụng API này.

Đối với các ứng dụng biên dịch dựa trên SDK Android 16 (cấp độ API 36) trở lên

Bạn có thể trực tiếp sử dụng phương thức removeLaunchSecurityProtection() trên đối tượng Intent.

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

Đối với các ứng dụng biên dịch dựa trên Android 15 (cấp độ API 35) trở xuống

Mặc dù không nên, nhưng bạn có thể sử dụng tính năng phản chiếu để truy cập vào phương thức removeLaunchSecurityProtection().

Thận trọng: Việc sử dụng tính năng phản chiếu có thể khiến mã của bạn dễ bị lỗi và dễ bị hỏng hơn, đặc biệt là nếu API cơ bản thay đổi trong các phiên bản Android sau này. Bất cứ khi nào có thể, hãy cập nhật SDK biên dịch để nhắm đến Android 16 (cấp độ API 36) trở lên để sử dụng trực tiếp 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.