Thay đổi về hành vi: Ứng dụng nhắm đến Android 14 trở lên

Giống như các bản phát hành trước, Android 14 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 chỉ áp dụng cho ứng dụng nhắm đến Android 14 (API cấp 34) trở lên. Nếu ứng dụng của bạn nhắm đến Android 14 trở lên, bạn nên điều chỉnh ứng dụng để hỗ trợ những hành vi 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 ảnh hưởng đến tất cả ứng dụng chạy trên Android 14 bất kể targetSdkVersion của ứng dụng.

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

Bắt buộc phải có loại dịch vụ trên nền trước

如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台，则必须为应用中的每个前台服务至少指定一项前台服务类型。您应选择一个能代表应用用例的前台服务类型。系统需要特定类型的前台服务满足特定用例。

注意：Android 14 针对运行状况和远程消息传递用例引入了前台服务类型。系统还为简短服务、特殊用例和系统豁免保留新的类型。

如果应用中的用例与这些类型均不相关，强烈建议您迁移逻辑以使用 WorkManager 或用户发起的数据传输作业。

Thực thi quyền BLUETOOTH_CONNECT trong BluetoothAdapter

Android 14 enforces the BLUETOOTH_CONNECT permission when calling the BluetoothAdapter getProfileConnectionState() method for apps targeting Android 14 (API level 34) or higher.

This method already required the BLUETOOTH_CONNECT permission, but it was not enforced. Make sure your app declares BLUETOOTH_CONNECT in your app's AndroidManifest.xml file as shown in the following snippet and check that a user has granted the permission before calling getProfileConnectionState.

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

Nội dung cập nhật OpenJDK 17

Android 14 将继续更新 Android 的核心库，以与最新 OpenJDK LTS 版本中的功能保持一致，包括适合应用和平台开发者的库更新和 Java 17 语言支持。

以下变更可能会影响应用兼容性：

• 对正则表达式的更改：现在，为了更严格地遵循 OpenJDK 的语义，不允许无效的组引用。您可能会看到 java.util.regex.Matcher 类抛出 IllegalArgumentException 的新情况，因此请务必测试应用中使用正则表达式的情形。如需在测试期间启用或停用此变更，请使用兼容性框架工具切换 DISALLOW_INVALID_GROUP_REFERENCE 标志。
• UUID 处理：现在，验证输入参数时，java.util.UUID.fromString() 方法会执行更严格的检查，因此您可能会在反序列化期间看到 IllegalArgumentException。如需在测试期间启用或停用此变更，请使用兼容性框架工具切换 ENABLE_STRICT_VALIDATION 标志。
• ProGuard 问题：有时，在您尝试使用 ProGuard 缩减、混淆和优化应用时，添加 java.lang.ClassValue 类会导致问题。问题源自 Kotlin 库，该库会根据 Class.forName("java.lang.ClassValue") 是否会返回类更改运行时行为。如果您的应用是根据没有 java.lang.ClassValue 类的旧版运行时开发的，则这些优化可能会将 computeValue 方法从派生自 java.lang.ClassValue 的类中移除。

JobScheduler củng cố hành vi gọi lại và hành vi mạng

Since its introduction, JobScheduler expects your app to return from onStartJob or onStopJob within a few seconds. Prior to Android 14, if a job runs too long, the job is stopped and fails silently. If your app targets Android 14 (API level 34) or higher and exceeds the granted time on the main thread, the app triggers an ANR with the error message "No response to onStartJob" or "No response to onStopJob".

This ANR may be a result of 2 scenarios: 1. There is work blocking the main thread, preventing the callbacks onStartJob or onStopJob from executing and completing within the expected time limit. 2. The developer is running blocking work within the JobScheduler callback onStartJob or onStopJob, preventing the callback from completing within the expected time limit.

To address #1, you will need to further debug what is blocking the main thread when the ANR occurs, you can do this using ApplicationExitInfo#getTraceInputStream() to get the tombstone trace when the ANR occurs. If you're able to manually reproduce the ANR, you can record a system trace and inspect the trace using either Android Studio or Perfetto to better understand what is running on the main thread when the ANR occurs. Note that this can happen when using JobScheduler API directly or using the androidx library WorkManager.

To address #2, consider migrating to WorkManager, which provides support for wrapping any processing in onStartJob or onStopJob in an asynchronous thread.

JobScheduler also introduces a requirement to declare the ACCESS_NETWORK_STATE permission if using setRequiredNetworkType or setRequiredNetwork constraint. If your app does not declare the ACCESS_NETWORK_STATE permission when scheduling the job and is targeting Android 14 or higher, it will result in a SecurityException.

Tiles launch API

对于以 Android 14 及更高版本为目标平台的应用， TileService#startActivityAndCollapse(Intent) 已弃用，现在会抛出 调用时抛出异常。如果您的应用从功能块启动 activity，请使用 TileService#startActivityAndCollapse(PendingIntent)。

Quyền riêng tư

Quyền truy cập một phần vào ảnh và video

Android 14 introduces Selected Photos Access, which allows users to grant apps access to specific images and videos in their library, rather than granting access to all media of a given type.

This change is only enabled if your app targets Android 14 (API level 34) or higher. If you don't use the photo picker yet, we recommend implementing it in your app to provide a consistent experience for selecting images and videos that also enhances user privacy without having to request any storage permissions.

If you maintain your own gallery picker using storage permissions and need to maintain full control over your implementation, adapt your implementation to use the new READ_MEDIA_VISUAL_USER_SELECTED permission. If your app doesn't use the new permission, the system runs your app in a compatibility mode.

Trải nghiệm người dùng

Thông báo bảo mật về ý định toàn màn hình

在 Android 11（API 级别 30）中，任何应用都可以在手机处于锁定状态时使用 Notification.Builder.setFullScreenIntent 发送全屏 intent。您可以通过在 AndroidManifest 中声明 USE_FULL_SCREEN_INTENT 权限，在应用安装时自动授予此权限。

全屏 intent 通知适用于需要用户立即注意的极高优先级通知，例如用户来电或用户配置的闹钟设置。对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，获准使用此权限的应用仅限于提供通话和闹钟的应用。对于不适合此情况的任何应用，Google Play 商店会撤消其默认的 USE_FULL_SCREEN_INTENT 权限。这些政策变更的截止日期为 2024 年 5 月 31 日。

在用户更新到 Android 14 之前，在手机上安装的应用仍拥有此权限。用户可以开启和关闭此权限。

您可以使用新 API NotificationManager.canUseFullScreenIntent 检查应用是否具有该权限；如果没有，应用可以使用新 intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT 启动设置页面，在该页面中，用户可以授予权限。

Bảo mật

Các quy tắc hạn chế đối với ý định ngầm ẩn và ý định đang chờ xử lý

Đối với ứng dụng nhắm đến Android 14 (API cấp 34) trở lên, Android hạn chế việc ứng dụng gửi ý định ngầm ẩn đến các thành phần ứng dụng nội bộ theo những cách sau:

• Ý định ngầm ẩn chỉ được gửi đến các thành phần đã xuất. Ứng dụng phải sử dụng một ý định tường minh để phân phối tới các thành phần chưa xuất hoặc đánh dấu thành phần đó là đã xuất.
• Nếu một ứng dụng tạo ý định đang chờ xử lý có thể thay đổi với một ý định không chỉ định thành phần hoặc gói, thì hệ thống sẽ gửi ra một ngoại lệ.

Những thay đổi này ngăn các ứng dụng độc hại can thiệp vào ý định ngầm ẩn mà thành phần nội bộ của ứng dụng sử dụng.

Ví dụ: bạn có thể khai báo bộ lọc ý định trong tệp kê khai của ứng dụng:

<activity
    android:name=".AppActivity"
    android:exported="false">
    <intent-filter>
        <action android:name="com.example.action.APP_ACTION" />
        <category android:name="android.intent.category.DEFAULT" />
    </intent-filter>
</activity>

Nếu ứng dụng của bạn cố gắng chạy hoạt động này bằng cách sử dụng một ý định ngầm ẩn, thì hệ thống sẽ gửi ra một ngoại lệ ActivityNotFoundException:

Kotlin

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(Intent("com.example.action.APP_ACTION"))

Java

// Throws an ActivityNotFoundException exception when targeting Android 14.
context.startActivity(new Intent("com.example.action.APP_ACTION"));

Để khởi chạy hoạt động không xuất, ứng dụng của bạn nên sử dụng ý định tường minh:

Kotlin

// This makes the intent explicit.
val explicitIntent =
        Intent("com.example.action.APP_ACTION")
explicitIntent.apply {
    package = context.packageName
}
context.startActivity(explicitIntent)

Java

// This makes the intent explicit.
Intent explicitIntent =
        new Intent("com.example.action.APP_ACTION")
explicitIntent.setPackage(context.getPackageName());
context.startActivity(explicitIntent);

Broadcast receiver đã đăng ký trong thời gian chạy phải chỉ định hành vi xuất

Các ứng dụng và dịch vụ nhắm đến Android 14 (API cấp 34) trở lên và sử dụng trình thu thập dữ liệu đã đăng ký theo bối cảnh phải chỉ định cờ để cho biết liệu có nên xuất bộ thu sang tất cả ứng dụng khác trên thiết bị hay không: RECEIVER_EXPORTED hoặc RECEIVER_NOT_EXPORTED. Yêu cầu này giúp bảo vệ ứng dụng khỏi các lỗ hổng bảo mật bằng cách tận dụng các tính năng được giới thiệu trong Android 13 dành cho những bộ thu này.

Ngoại lệ đối với các bộ thu chỉ nhận tin do hệ thống truyền ra

Nếu ứng dụng của bạn chỉ đăng ký bộ nhận cho tin do hệ thống truyền ra qua các phương thức Context#registerReceiver (ví dụ: Context#registerReceiver()), thì bạn không nên chỉ định cờ khi đăng ký bộ nhận.

Tải mã động an toàn hơn

If your app targets Android 14 (API level 34) or higher and uses Dynamic Code Loading (DCL), all dynamically-loaded files must be marked as read-only. Otherwise, the system throws an exception. We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.

If you must dynamically load code, use the following approach to set the dynamically-loaded file (such as a DEX, JAR, or APK file) as read-only as soon as the file is opened and before any content is written:

Kotlin

val jar = File("DYNAMICALLY_LOADED_FILE.jar")
val os = FileOutputStream(jar)
os.use {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly()
    // Then write the actual file content
}
val cl = PathClassLoader(jar, parentClassLoader)

Java

File jar = new File("DYNAMICALLY_LOADED_FILE.jar");
try (FileOutputStream os = new FileOutputStream(jar)) {
    // Set the file to read-only first to prevent race conditions
    jar.setReadOnly();
    // Then write the actual file content
} catch (IOException e) { ... }
PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);

Handle dynamically-loaded files that already exist

To prevent exceptions from being thrown for existing dynamically-loaded files, we recommend deleting and recreating the files before you try to dynamically load them again in your app. As you recreate the files, follow the preceding guidance for marking the files read-only at write time. Alternatively, you can re-label the existing files as read-only, but in this case, we strongly recommend that you verify the integrity of the files first (for example, by checking the file's signature against a trusted value), to help protect your app from malicious actions.

Hạn chế bổ sung khi bắt đầu hoạt động ở chế độ nền

Đối với các ứng dụng nhắm đến Android 14 (API cấp 34) trở lên, hệ thống sẽ áp dụng nhiều quy tắc hạn chế hơn khi các ứng dụng được phép bắt đầu hoạt động ở chế độ nền:

• Khi gửi một PendingIntent bằng PendingIntent#send() hoặc các phương thức tương tự, giờ đây ứng dụng phải chọn sử dụng nếu muốn cấp đặc quyền khởi chạy hoạt động của riêng mình ở chế độ nền để bắt đầu ý định đang chờ xử lý. Để chọn sử dụng, ứng dụng phải truyền gói ActivityOptions có setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED).
• Khi một ứng dụng đang hiển thị thực hiện việc liên kết với dịch vụ của một ứng dụng khác ở chế độ nền bằng phương thức bindService(), thì ứng dụng đang hiển thị đó phải chọn sử dụng nếu muốn cấp các đặc quyền khởi chạy hoạt động của riêng mình ở chế độ nền với dịch vụ liên kết. Để chọn sử dụng, ứng dụng phải dùng cờ BIND_ALLOW_ACTIVITY_STARTS khi gọi phương thức bindService().

Những thay đổi này mở rộng nhóm quy tắc hạn chế hiện có để bảo vệ người dùng bằng cách ngăn các ứng dụng độc hại lợi dụng API để bắt đầu các hoạt động gây gián đoạn ở chế độ nền.

Truyền tải qua đường dẫn Zip

For apps targeting Android 14 (API level 34) or higher, Android prevents the Zip Path Traversal Vulnerability in the following way: ZipFile(String) and ZipInputStream.getNextEntry() throws a ZipException if zip file entry names contain ".." or start with "/".

Apps can opt-out from this validation by calling dalvik.system.ZipPathValidator.clearCallback().

Bắt buộc phải có sự đồng ý của người dùng cho mỗi phiên chụp MediaProjection

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，在以下任一情况下，MediaProjection#createVirtualDisplay 都会抛出 SecurityException：

• 您的应用会缓存从 MediaProjectionManager#createScreenCaptureIntent 返回的 Intent，并多次将其传递给 MediaProjectionManager#getMediaProjection。
• 您的应用在同一 MediaProjection 实例上多次调用 MediaProjection#createVirtualDisplay。

您的应用必须在每次捕获会话之前征求用户同意。单次捕获会话是对 MediaProjection#createVirtualDisplay 的单次调用，并且每个 MediaProjection 实例只能使用一次。

处理配置变更

如果您的应用需要调用 MediaProjection#createVirtualDisplay 来处理配置更改（例如屏幕方向或屏幕大小更改），您可以按照以下步骤更新现有 MediaProjection 实例的 VirtualDisplay：

1. 使用新的宽度和高度调用 VirtualDisplay#resize。
2. 向 VirtualDisplay#setSurface 提供新的 Surface，并为其指定新的宽度和高度。

注册回调

您的应用应注册回调，以处理用户不同意继续拍摄会话的情况。为此，请实现 Callback#onStop，并让应用释放所有相关资源（例如 VirtualDisplay 和 Surface）。

如果您的应用未注册此回调，当您的应用调用它时，MediaProjection#createVirtualDisplay 会抛出 IllegalStateException。

Các quy tắc hạn chế mới cập nhật đối với yếu tố ngoài SDK

Android 14 包含更新后的受限非 SDK 接口列表（基于与 Android 开发者之间的协作以及最新的内部测试）。在限制使用非 SDK 接口之前，我们会尽可能确保有可用的公开替代方案。

如果您的应用并非以 Android 14 为目标平台，其中一些变更可能不会立即对您产生影响。然而，虽然您目前仍可以使用一些非 SDK 接口（具体取决于应用的目标 API 级别），但只要您使用任何非 SDK 方法或字段，终归存在导致应用出问题的显著风险。

如果您不确定自己的应用是否使用了非 SDK 接口，则可以测试您的应用来进行确认。如果您的应用依赖于非 SDK 接口，您应该开始计划迁移到 SDK 替代方案。然而，我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案，应请求新的公共 API。

如需详细了解此 Android 版本中的变更，请参阅 Android 14 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息，请参阅对非 SDK 接口的限制。