การเปลี่ยนแปลงลักษณะการทำงาน: แอปที่กำหนดเป้าหมายเป็น Android 14 ขึ้นไป

เช่นเดียวกับรุ่นก่อนหน้า Android 14 มีการเปลี่ยนแปลงลักษณะการทำงานที่อาจส่งผลต่อแอปของคุณ การเปลี่ยนแปลงลักษณะการทำงานต่อไปนี้มีผลเฉพาะกับแอปที่กำหนดเป้าหมายเป็น Android 14 (ระดับ API 34) ขึ้นไป หากแอปกำหนดเป้าหมายเป็น Android 14 ขึ้นไป คุณควรแก้ไขแอปให้รองรับลักษณะการทำงานเหล่านี้อย่างเหมาะสม ในกรณีที่เกี่ยวข้อง

อย่าลืมตรวจสอบรายการการเปลี่ยนแปลงลักษณะการทำงานที่มีผลกับแอปทั้งหมด ที่ทำงานบน Android 14 ไม่ว่าtargetSdkVersion ของแอปจะเป็นอย่างไร

ฟังก์ชันหลัก

ต้องระบุประเภทบริการที่ทำงานอยู่เบื้องหน้า

หากแอปกำหนดเป้าหมายเป็น Android 14 (API ระดับ 34) ขึ้นไป แอปต้องระบุประเภทบริการที่ทำงานอยู่เบื้องหน้าอย่างน้อย 1 ประเภทสำหรับบริการที่ทำงานอยู่เบื้องหน้าแต่ละรายการภายในแอป คุณควรเลือกประเภทบริการที่ทำงานอยู่เบื้องหน้าที่แสดงถึง Use Case ของแอป ระบบคาดหวังว่าบริการที่ทำงานอยู่เบื้องหน้าซึ่งมีประเภทหนึ่งๆ จะเป็นไปตาม Use Case ที่เฉพาะเจาะจง

หากกรณีการใช้งานในแอปของคุณไม่เกี่ยวข้องกับประเภทใดเลย เราขอแนะนำให้ย้ายข้อมูลตรรกะของคุณเพื่อใช้ WorkManager หรือการโอนข้อมูลที่เริ่มต้นโดยผู้ใช้

การบังคับใช้สิทธิ์ BLUETOOTH_CONNECT ใน BluetoothAdapter

Android 14 จะบังคับใช้สิทธิ์ BLUETOOTH_CONNECT เมื่อเรียกใช้เมธอด BluetoothAdapter getProfileConnectionState() สำหรับแอปที่กำหนดเป้าหมายเป็น Android 14 (API ระดับ 34) ขึ้นไป

วิธีนี้ต้องใช้สิทธิ์ BLUETOOTH_CONNECT อยู่แล้ว แต่ยังไม่ได้บังคับใช้ ตรวจสอบว่าแอปได้ประกาศ BLUETOOTH_CONNECT ในไฟล์ AndroidManifest.xml ของแอปดังที่แสดงในข้อมูลโค้ดต่อไปนี้และตรวจสอบว่าผู้ใช้ให้สิทธิ์แล้วก่อนที่จะเรียกใช้ getProfileConnectionState

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

การอัปเดต OpenJDK 17

Android 14 ยังคงปรับปรุงไลบรารีหลักของ Android ให้สอดคล้องกับฟีเจอร์ใน OpenJDK LTS เวอร์ชันล่าสุด ซึ่งรวมถึงทั้งการอัปเดตไลบรารีและการรองรับภาษา Java 17 สําหรับนักพัฒนาแอปและแพลตฟอร์ม

การเปลี่ยนแปลงบางอย่างอาจส่งผลต่อความเข้ากันได้ของแอป

  • การเปลี่ยนแปลงนิพจน์ทั่วไป: ตอนนี้ระบบไม่อนุญาตให้ใช้การอ้างอิงกลุ่มที่ไม่ถูกต้องเพื่อให้สอดคล้องกับความหมายของ OpenJDK มากขึ้น คุณอาจเห็นกรณีใหม่ซึ่งคลาส java.util.regex.Matcher แสดงข้อยกเว้น IllegalArgumentException ดังนั้นโปรดทดสอบแอปในส่วนที่ใช้นิพจน์ทั่วไป หากต้องการเปิดหรือปิดใช้การเปลี่ยนแปลงนี้ขณะทดสอบ ให้สลับ Flag DISALLOW_INVALID_GROUP_REFERENCE โดยใช้เครื่องมือเฟรมเวิร์กความเข้ากันได้
  • การจัดการ UUID: ตอนนี้เมธอด java.util.UUID.fromString() จะตรวจสอบอย่างเข้มงวดมากขึ้นเมื่อตรวจสอบอาร์กิวเมนต์อินพุต คุณจึงอาจเห็น IllegalArgumentException ระหว่างการแปลงข้อมูลย้อนกลับ หากต้องการเปิดหรือปิดใช้การเปลี่ยนแปลงนี้ขณะทดสอบ ให้สลับ Flag ENABLE_STRICT_VALIDATION โดยใช้เครื่องมือเฟรมเวิร์กความเข้ากันได้
  • ปัญหาเกี่ยวกับ ProGuard: ในบางกรณี การเพิ่มคลาส java.lang.ClassValue จะทำให้เกิดปัญหาหากคุณพยายามบีบอัด สร้างความสับสน และเพิ่มประสิทธิภาพแอปโดยใช้ ProGuard ปัญหานี้เกิดจากไลบรารี Kotlin ที่เปลี่ยนลักษณะการทํางานรันไทม์โดยขึ้นอยู่กับว่า Class.forName("java.lang.ClassValue") แสดงผลคลาสหรือไม่ หากแอปของคุณพัฒนาขึ้นโดยใช้รันไทม์เวอร์ชันเก่าที่ไม่มีคลาส java.lang.ClassValue อยู่ การเพิ่มประสิทธิภาพเหล่านี้อาจนําเมธอด computeValue ออกจากคลาสที่มาจาก java.lang.ClassValue

JobScheduler เสริมการทำงานของแฮนเดิลการเรียกกลับและลักษณะการทำงานของเครือข่าย

自从引入后，JobScheduler 期望您的应用从 onStartJob 或 onStopJob。在 Android 14 之前，如果作业运行时间过长，系统会停止作业并静默失败。如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台， 超过在主线程上授予的时间，应用会触发 ANR 显示“没有响应 onStartJob”错误消息或 “onStopJob没有回复”。

此 ANR 可能是由以下 2 种情况造成的： 1.有工作阻塞主线程，阻止回调 onStartJob 或者onStopJob在预期时间内执行并完成。 2. 开发者在 JobScheduler 中运行阻塞工作 回调 onStartJob 或 onStopJob，阻止从 在预期的时限内完成

要解决第 1 个问题，您需要进一步调试阻塞主线程的因素 您可以使用以下代码 ApplicationExitInfo#getTraceInputStream()，用于获取 Tombstone ANR 发生时的跟踪信息如果您能够手动重现 ANR 问题 您可以录制系统轨迹，并使用 Android Studio 或 Perfetto，以便更好地了解应用上运行的 在发生 ANR 时调用主线程 请注意，直接使用 JobScheduler API 或使用 androidx 库 WorkManager 时可能会发生这种情况。

如需解决问题 2，请考虑迁移到 WorkManager，它支持将 onStartJob 或 onStopJob 中的任何处理封装在异步线程中。

JobScheduler 还引入了一项要求，即如果使用 setRequiredNetworkType 或 setRequiredNetwork 约束条件，则必须声明 ACCESS_NETWORK_STATE 权限。如果您的应用未声明 ACCESS_NETWORK_STATE 权限 Android 14 或更高版本，则会导致 SecurityException。

API การเปิดตัวไทล์

For apps targeting 14 and higher, TileService#startActivityAndCollapse(Intent) is deprecated and now throws an exception when called. If your app launches activities from tiles, use TileService#startActivityAndCollapse(PendingIntent) instead.

ความเป็นส่วนตัว

สิทธิ์เข้าถึงรูปภาพและวิดีโอบางส่วน

Android 14 เปิดตัวการเข้าถึงรูปภาพที่เลือก ซึ่งช่วยให้ผู้ใช้สามารถให้สิทธิ์แอปเข้าถึงรูปภาพและวิดีโอที่เฉพาะเจาะจงในคลังได้ แทนที่จะให้สิทธิ์เข้าถึงสื่อทั้งหมดในประเภทหนึ่งๆ

การเปลี่ยนแปลงนี้จะเปิดใช้ก็ต่อเมื่อแอปกำหนดเป้าหมายเป็น Android 14 (API ระดับ 34) ขึ้นไปเท่านั้น หากคุณยังไม่ได้ใช้เครื่องมือเลือกรูปภาพ เราขอแนะนำให้ติดตั้งใช้งานในแอปเพื่อให้ผู้ใช้ได้รับประสบการณ์ที่สม่ำเสมอในการเลือกรูปภาพและวิดีโอ รวมถึงช่วยเพิ่มความเป็นส่วนตัวของผู้ใช้โดยไม่ต้องขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล

หากคุณดูแลรักษาเครื่องมือเลือกแกลเลอรีของคุณเองโดยใช้สิทธิ์เข้าถึงพื้นที่เก็บข้อมูลและต้องการควบคุมการติดตั้งใช้งานอย่างเต็มรูปแบบ ให้ปรับการติดตั้งใช้งานเพื่อใช้สิทธิ์ READ_MEDIA_VISUAL_USER_SELECTED ใหม่ หากแอปของคุณไม่ได้ใช้สิทธิ์ใหม่ ระบบจะเรียกใช้แอปในโหมดความเข้ากันได้

ประสบการณ์ของผู้ใช้

รักษาความปลอดภัยให้กับการแจ้งเตือน Intent แบบเต็มหน้าจอ

With Android 11 (API level 30), it was possible for any app to use Notification.Builder.setFullScreenIntent to send full-screen intents while the phone is locked. You could auto-grant this on app install by declaring USE_FULL_SCREEN_INTENT permission in the AndroidManifest.

Full-screen intent notifications are designed for extremely high-priority notifications demanding the user's immediate attention, such as an incoming phone call or alarm clock settings configured by the user. For apps targeting Android 14 (API level 34) or higher, apps that are allowed to use this permission are limited to those that provide calling and alarms only. The Google Play Store revokes default USE_FULL_SCREEN_INTENT permissions for any apps that don't fit this profile. The deadline for these policy changes is May 31, 2024.

This permission remains enabled for apps installed on the phone before the user updates to Android 14. Users can turn this permission on and off.

You can use the new API NotificationManager.canUseFullScreenIntent to check if your app has the permission; if not, your app can use the new intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT to launch the settings page where users can grant the permission.

ความปลอดภัย

ข้อจำกัดของ Intent โดยนัยและ Intent ที่รอดำเนินการ

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，Android 会通过以下方式限制应用向内部应用组件发送隐式 intent：

  • 隐式 intent 只能传送到导出的组件。应用必须使用显式 intent 传送到未导出的组件，或将该组件标记为已导出。
  • 如果应用通过未指定组件或软件包的 intent 创建可变待处理 intent，系统会抛出异常。

这些变更可防止恶意应用拦截意在供应用内部组件使用的隐式 intent。

例如，下面是可以在应用的清单文件中声明的 intent 过滤器：

<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>

如果应用尝试使用隐式 intent 启动此 activity，则系统会抛出 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"));

如需启动非导出的 activity，应用应改用显式 intent：

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 ที่ลงทะเบียนรันไทม์ต้องระบุลักษณะการส่งออก

Apps and services that target Android 14 (API level 34) or higher and use context-registered receivers are required to specify a flag to indicate whether or not the receiver should be exported to all other apps on the device: either RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED, respectively. This requirement helps protect apps from security vulnerabilities by leveraging the features for these receivers introduced in Android 13.

Exception for receivers that receive only system broadcasts

If your app is registering a receiver only for system broadcasts through Context#registerReceiver methods, such as Context#registerReceiver(), then it shouldn't specify a flag when registering the receiver.

การโหลดโค้ดแบบไดนามิกที่ปลอดภัยยิ่งขึ้น

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.

ข้อจำกัดเพิ่มเติมในการเริ่มต้นกิจกรรมจากเบื้องหลัง

สำหรับแอปที่กำหนดเป้าหมายเป็น Android 14 (API ระดับ 34) ขึ้นไป ระบบจะจำกัดเพิ่มเติมว่าแอปจะได้รับอนุญาตให้เริ่มกิจกรรมจากเบื้องหลังเมื่อใด

  • เมื่อแอปส่ง PendingIntent โดยใช้ PendingIntent#send() หรือวิธีการที่คล้ายกัน แอปต้องเลือกใช้หากต้องการมอบสิทธิ์การเริ่มกิจกรรมเบื้องหลังของตนเองเพื่อเริ่ม Intent ที่รอดำเนินการ หากต้องการเลือกใช้ แอปควรส่ง ActivityOptions Bundle ที่มีsetPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
  • เมื่อแอปที่มองเห็นได้เชื่อมโยงบริการของแอปอื่นที่อยู่ในเบื้องหลังโดยใช้เมธอด bindService() ตอนนี้แอปที่มองเห็นได้ต้องเลือกใช้หากต้องการมอบสิทธิ์การเริ่มกิจกรรมเบื้องหลังของตนเองให้กับบริการที่เชื่อมโยง หากต้องการเลือกใช้ แอปควรระบุ Flag BIND_ALLOW_ACTIVITY_STARTS เมื่อเรียกใช้เมธอด bindService()

การเปลี่ยนแปลงเหล่านี้จะขยายชุดข้อจำกัดที่มีอยู่เพื่อปกป้องผู้ใช้โดยการป้องกันการที่แอปที่เป็นอันตรายจะละเมิด API เพื่อเริ่มกิจกรรมที่รบกวนจากเบื้องหลัง

Zip Path Traversal

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

For apps targeting Android 14 (API level 34) or higher, a SecurityException is thrown by MediaProjection#createVirtualDisplay in either of the following scenarios:

Your app must ask the user to give consent before each capture session. A single capture session is a single invocation on MediaProjection#createVirtualDisplay, and each MediaProjection instance must be used only once.

Handle configuration changes

If your app needs to invoke MediaProjection#createVirtualDisplay to handle configuration changes (such as the screen orientation or screen size changing), you can follow these steps to update the VirtualDisplay for the existing MediaProjection instance:

  1. Invoke VirtualDisplay#resize with the new width and height.
  2. Provide a new Surface with the new width and height to VirtualDisplay#setSurface.

Register a callback

Your app should register a callback to handle cases where the user doesn't grant consent to continue a capture session. To do this, implement Callback#onStop and have your app release any related resources (such as the VirtualDisplay and Surface).

If your app doesn't register this callback, MediaProjection#createVirtualDisplay throws an IllegalStateException when your app invokes it.

ข้อจำกัดที่อัปเดตแล้วสำหรับ SDK ที่ไม่ใช่ SDK

Android 14 มีรายการอัปเดตของอินเทอร์เฟซที่ไม่ใช่ SDK ซึ่งถูกจำกัด โดยการทำงานร่วมกับนักพัฒนาแอป Android และการทดสอบภายในล่าสุด เราจะตรวจสอบว่ามีทางเลือกอื่นที่เผยแพร่ต่อสาธารณะพร้อมใช้งานก่อนที่จะจำกัดอินเทอร์เฟซที่ไม่ใช่ SDK ทุกครั้งที่ทำได้

หากแอปไม่ได้กำหนดเป้าหมายเป็น Android 14 การเปลี่ยนแปลงบางอย่างเหล่านี้ อาจไม่มีผลกับคุณในทันที อย่างไรก็ตาม แม้ว่าปัจจุบันคุณจะใช้ อินเทอร์เฟซที่ไม่ใช่ SDK บางรายการได้ (ขึ้นอยู่กับระดับ API เป้าหมายของแอป) แต่การใช้เมธอดหรือฟิลด์ที่ไม่ใช่ SDK ใดๆ ก็มีความเสี่ยงสูงที่จะทำให้แอป ขัดข้องเสมอ

หากต้องการดูว่าแอปใช้อินเทอร์เฟซที่ไม่ใช่ SDK อยู่หรือเปล่า คุณสามารถทดสอบ แอป ดูได้ หากแอปของคุณใช้อินเทอร์เฟซที่ไม่ใช่ SDK คุณควรเริ่มวางแผนย้ายไปใช้ทางเลือกอื่นที่เป็น SDK อย่างไรก็ตาม เราเข้าใจว่าแอปบางแอปมี Use Case ที่ถูกต้องสำหรับการใช้อินเทอร์เฟซที่ไม่ใช่ SDK หากไม่พบวิธีอื่นแทนการใช้อินเทอร์เฟซที่ไม่ใช่ SDK สำหรับฟีเจอร์ในแอป คุณควรขอ API สาธารณะใหม่

ดูข้อมูลเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงใน Android เวอร์ชันนี้ได้ที่การอัปเดตข้อจํากัดอินเทอร์เฟซที่ไม่ใช่ SDK ใน Android 14 ดูข้อมูลเพิ่มเติมเกี่ยวกับอินเทอร์เฟซที่ไม่ใช่ SDK โดยทั่วไปได้ที่ข้อจำกัดเกี่ยวกับอินเทอร์เฟซที่ไม่ใช่ SDK