การเปลี่ยนแปลงลักษณะการทำงาน: แอปที่กำหนดเป้าหมายเป็น 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 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" />

การอัปเดต 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. มีงานบล็อกเทรดหลัก ซึ่งทําให้ Callback onStartJob หรือ onStopJob ไม่สามารถดําเนินการและทํางานให้เสร็จภายในเวลาจํากัดที่คาดไว้ 2. นักพัฒนาแอปกำลังทำงานที่บล็อกภายในการเรียกกลับ onStartJob หรือ onStopJob ของ JobScheduler ซึ่งทำให้การเรียกกลับดำเนินการไม่เสร็จภายในเวลาจำกัดที่คาดไว้

ในการแก้ไขข้อ 1 คุณจะต้องแก้ไขข้อบกพร่องของสิ่งที่บล็อกเทรดหลักเพิ่มเติม เมื่อเกิด ANR ขึ้น คุณสามารถทำเช่นนี้ได้โดยใช้ ApplicationExitInfo#getTraceInputStream() เพื่อรับ Tombstone ติดตามเมื่อเกิด ANR หากคุณสร้าง ANR ซ้ำด้วยตนเองได้ คุณสามารถบันทึกการติดตามของระบบและตรวจสอบการติดตามได้โดยใช้ Android Studio หรือ Perfetto เพื่อให้เข้าใจได้ดีขึ้นถึงสิ่งที่กำลังทำงานอยู่ เทรดหลักเมื่อเกิด ANR โปรดทราบว่าปัญหานี้อาจเกิดขึ้นเมื่อใช้ JobScheduler API โดยตรง หรือใช้ WorkManager ซึ่งเป็นไลบรารี androidx

หากต้องการแก้ไขปัญหาที่ 2 ให้ลองเปลี่ยนไปใช้ WorkManager ซึ่งรองรับการรวมการประมวลผลใน onStartJob หรือ onStopJob ในเธรดแบบแอซิงโครนัส

JobScheduler ยังกำหนดให้ต้องประกาศสิทธิ์ ACCESS_NETWORK_STATE ด้วยหากใช้ข้อจำกัด setRequiredNetworkType หรือ setRequiredNetwork หากแอปของคุณไม่ได้ประกาศฟิลด์ สิทธิ์ ACCESS_NETWORK_STATE เมื่อกำหนดเวลางานและกำหนดเป้าหมาย Android 14 ขึ้นไปจะส่งผลให้เกิด SecurityException

Tiles Launch API

สำหรับแอปที่กำหนดเป้าหมายเป็น Android 14 ขึ้นไป ระบบจะเลิกใช้งาน TileService#startActivityAndCollapse(Intent) และตอนนี้จะแสดงข้อยกเว้นเมื่อเรียกใช้ หากแอปเปิดกิจกรรมจากการ์ด ให้ใช้ TileService#startActivityAndCollapse(PendingIntent) แทน

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

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

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.

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

การแจ้งเตือน 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 ที่ไม่ชัดแจ้งและที่รอดําเนินการ

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

  • ระบบจะส่ง Intent ที่ไม่ชัดแจ้งไปยังคอมโพเนนต์ที่ส่งออกเท่านั้น แอปต้องใช้ Intent ที่ชัดเจนเพื่อนำส่งไปยังคอมโพเนนต์ที่ไม่ได้ส่งออก หรือทำเครื่องหมายคอมโพเนนต์ว่าส่งออกแล้ว
  • หากแอปสร้าง PendingIntent ที่เปลี่ยนแปลงได้โดยมี Intent ที่ไม่ได้ระบุคอมโพเนนต์หรือแพ็กเกจ ระบบจะแสดงข้อยกเว้น

การเปลี่ยนแปลงเหล่านี้จะช่วยป้องกันไม่ให้แอปที่เป็นอันตรายขัดขวาง Intent แบบไม่เจาะจงปลายทางที่มีไว้สำหรับให้คอมโพเนนต์ภายในของแอปใช้งาน

ต่อไปนี้คือตัวอย่างตัวกรอง Intent ที่ประกาศได้ในไฟล์ Manifest ของแอป

<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 ที่ไม่ชัด ระบบจะแสดงข้อยกเว้น 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"));

หากต้องการเปิดกิจกรรมที่ไม่ได้ส่งออก แอปของคุณควรใช้ 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 ที่ลงทะเบียนรันไทม์ต้องระบุลักษณะการส่งออก

以 Android 14（API 级别 34）或更高版本为目标平台并使用上下文注册的接收器的应用和服务必须指定以下标志，以指明接收器是否应导出到设备上的所有其他应用：RECEIVER_EXPORTED 或 RECEIVER_NOT_EXPORTED。此要求有助于利用 Android 13 中引入的这些接收器的功能，来保护应用免受安全漏洞的影响。

仅接收系统广播的接收器的例外情况

如果您的应用仅通过 Context#registerReceiver 方法（例如 Context#registerReceiver()）针对系统广播注册接收器，那么它在注册接收器时不应指定标志。

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

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）或更高版本为目标平台的应用，系统会进一步限制允许应用在后台启动 activity 的时间：

这些更改扩大了一组现有限制条件的范围，目的是防止恶意应用滥用 API 以在后台启动干扰性活动，从而保护用户。

Zip Path Traversal

สําหรับแอปที่กําหนดเป้าหมายเป็น Android 14 (API ระดับ 34) ขึ้นไป Android จะป้องกันช่องโหว่ Path Traversal ของไฟล์ ZIP ดังนี้ ZipFile(String) และ ZipInputStream.getNextEntry() จะแสดงข้อผิดพลาด ZipException หากชื่อรายการไฟล์ ZIP มี ".." หรือขึ้นต้นด้วย "/"

แอปสามารถเลือกไม่ใช้การตรวจสอบนี้ได้โดยเรียกใช้ 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 ที่อัปเดตแล้ว

Android 14 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 14, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces (depending on your app's target API level), using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.

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