Perubahan perilaku: Aplikasi yang menargetkan Android 14 atau yang lebih tinggi

Seperti rilis sebelumnya, Android 14 menyertakan perubahan perilaku yang mungkin memengaruhi aplikasi Anda. Perubahan perilaku berikut ini berlaku khusus bagi aplikasi yang menargetkan Android 14 (level API 34) atau yang lebih tinggi. Jika aplikasi Anda menargetkan Android 14 atau yang lebih tinggi, Anda harus memodifikasi aplikasi untuk mendukung perilaku ini dengan benar, jika berlaku.

Pastikan Anda juga meninjau daftar perubahan perilaku yang memengaruhi semua aplikasi yang berjalan di Android 14, terlepas dari targetSdkVersion aplikasi.

Fungsi inti

Jenis layanan latar depan wajib diisi

Jika menargetkan Android 14 (API level 34) atau yang lebih tinggi, aplikasi Anda harus menentukan setidaknya satu jenis layanan latar depan untuk setiap layanan latar depan dalam aplikasi Anda. Anda harus memilih jenis layanan latar depan yang mewakili kasus penggunaan aplikasi. Sistem mengharapkan layanan latar depan yang memiliki jenis tertentu untuk memenuhi kasus penggunaan tertentu.

Jika kasus penggunaan di aplikasi Anda tidak terkait dengan salah satu jenis ini, sebaiknya migrasikan logika untuk menggunakan WorkManager atau tugas transfer data yang dimulai pengguna

Penerapan izin BLUETOOTH_CONNECT di BluetoothAdapter

对于以 Android 14（API 级别 34）或更高版本为目标平台的应用，在调用 BluetoothAdapter getProfileConnectionState() 方法时，Android 14 会强制执行 BLUETOOTH_CONNECT 权限。

此方法已需要 BLUETOOTH_CONNECT 权限，但未强制执行。确保您的应用在应用的 AndroidManifest.xml 文件中声明 BLUETOOTH_CONNECT，如以下代码段所示，并在调用 getProfileConnectionState 之前检查用户是否已授予相应权限。

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

Update OpenJDK 17

Android 14 continues the work of refreshing Android's core libraries to align with the features in the latest OpenJDK LTS releases, including both library updates and Java 17 language support for app and platform developers.

A few of these changes can affect app compatibility:

  • Changes to regular expressions: Invalid group references are now disallowed to more closely follow the semantics of OpenJDK. You might see new cases where an IllegalArgumentException is thrown by the java.util.regex.Matcher class, so make sure to test your app for areas that use regular expressions. To enable or disable this change while testing, toggle the DISALLOW_INVALID_GROUP_REFERENCE flag using the compatibility framework tools.
  • UUID handling: The java.util.UUID.fromString() method now does more strict checks when validating the input argument, so you might see an IllegalArgumentException during deserialization. To enable or disable this change while testing, toggle the ENABLE_STRICT_VALIDATION flag using the compatibility framework tools.
  • ProGuard issues: In some cases, the addition of the java.lang.ClassValue class causes an issue if you try to shrink, obfuscate, and optimize your app using ProGuard. The problem originates with a Kotlin library that changes runtime behaviour based on whether Class.forName("java.lang.ClassValue") returns a class or not. If your app was developed against an older version of the runtime without the java.lang.ClassValue class available, then these optimizations might remove the computeValue method from classes derived from java.lang.ClassValue.

JobScheduler memperkuat perilaku callback dan jaringan

自从引入后，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 peluncuran kartu

Untuk aplikasi yang menargetkan 14 dan yang lebih tinggi, TileService#startActivityAndCollapse(Intent) tidak digunakan lagi dan kini menampilkan pengecualian saat dipanggil. Jika aplikasi Anda meluncurkan aktivitas dari kartu, gunakan TileService#startActivityAndCollapse(PendingIntent) sebagai gantinya.

Privasi

Akses sebagian ke foto dan video

Android 14 memperkenalkan Akses Foto yang Dipilih, yang memungkinkan pengguna memberikan akses ke gambar dan video tertentu di galeri mereka, bukan memberikan akses ke semua media dari jenis tertentu.

Perubahan ini hanya diaktifkan jika aplikasi Anda menargetkan Android 14 (API level 34) atau yang lebih tinggi. Jika Anda belum menggunakan pemilih foto, sebaiknya terapkan di aplikasi Anda untuk memberikan pengalaman yang konsisten dalam memilih gambar dan video yang juga meningkatkan privasi pengguna tanpa harus meminta izin penyimpanan apa pun.

Jika Anda mengelola pemilih galeri Anda sendiri menggunakan izin penyimpanan dan perlu mempertahankan kontrol penuh atas implementasi Anda, sesuaikan implementasi Anda untuk menggunakan izin READ_MEDIA_VISUAL_USER_SELECTED baru. Jika aplikasi Anda tidak menggunakan izin baru, sistem akan menjalankan aplikasi Anda dalam mode kompatibilitas.

Pengalaman pengguna

Notifikasi Intent layar penuh yang aman

Dengan Android 11 (API level 30), aplikasi apa pun dapat menggunakan Notification.Builder.setFullScreenIntent untuk mengirim intent layar penuh saat ponsel terkunci. Anda dapat memberikannya secara otomatis saat penginstalan aplikasi dengan mendeklarasikan izin USE_FULL_SCREEN_INTENT di AndroidManifest.

Notifikasi intent layar penuh dirancang untuk notifikasi dengan prioritas sangat tinggi yang meminta perhatian segera pengguna, seperti setelan panggilan telepon masuk atau jam alarm yang dikonfigurasi oleh pengguna. Untuk aplikasi yang menargetkan Android 14 (API level 34) atau yang lebih tinggi, aplikasi yang diizinkan untuk menggunakan izin ini terbatas pada aplikasi yang hanya menyediakan panggilan dan alarm. Google Play Store mencabut izin USE_FULL_SCREEN_INTENT default untuk aplikasi apa pun yang tidak sesuai dengan profil ini. Batas waktu untuk perubahan kebijakan ini adalah 31 Mei 2024.

Izin ini tetap diaktifkan untuk aplikasi yang diinstal di ponsel sebelum pengguna mengupdate ke Android 14. Pengguna dapat mengaktifkan dan menonaktifkan izin ini.

Anda dapat menggunakan API baru NotificationManager.canUseFullScreenIntent untuk memeriksa apakah aplikasi Anda memiliki izin. Jika tidak, aplikasi Anda dapat menggunakan intent baru ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT untuk meluncurkan halaman setelan tempat pengguna dapat memberikan izin.

Keamanan

Pembatasan ke intent yang implisit dan tertunda

Untuk aplikasi yang menargetkan Android 14 (API level 34) atau yang lebih tinggi, Android membatasi pengiriman intent implisit ke komponen aplikasi internal dengan cara berikut:

  • Intent implisit hanya dikirim ke komponen yang diekspor. Aplikasi harus menggunakan intent eksplisit untuk mengirim ke komponen yang tidak diekspor, atau menandai komponen sebagai diekspor.
  • Jika aplikasi membuat intent tertunda yang dapat berubah dengan intent yang tidak menentukan komponen atau paket, sistem akan menampilkan pengecualian.

Perubahan ini mencegah aplikasi berbahaya agar tidak mencegat intent implisit yang dimaksudkan untuk digunakan oleh komponen internal aplikasi.

Misalnya, berikut ini filter intent yang dapat dideklarasikan dalam file manifes aplikasi Anda:

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

Jika aplikasi Anda mencoba meluncurkan aktivitas ini menggunakan intent implisit, pengecualian ActivityNotFoundException akan ditampilkan:

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"));

Untuk meluncurkan aktivitas yang tidak diekspor, aplikasi Anda harus menggunakan intent eksplisit:

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

Penerima siaran yang terdaftar runtime harus menentukan perilaku ekspor

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

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

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

Pemuatan kode dinamis yang lebih aman

Jika aplikasi Anda menargetkan Android 14 (level API 34) atau yang lebih tinggi dan menggunakan Pemuatan Kode Dinamis (DCL), semua file yang dimuat secara dinamis harus ditandai sebagai hanya baca. Jika tidak, sistem akan menampilkan pengecualian. Sebaiknya aplikasi menghindari memuat kode secara dinamis jika memungkinkan, karena hal itu akan sangat meningkatkan risiko aplikasi disusupi oleh injeksi kode atau sabotase kode.

Jika Anda harus memuat kode secara dinamis, gunakan pendekatan berikut untuk menetapkan file yang dimuat secara dinamis (seperti file DEX, JAR, atau APK) sebagai file hanya baca, segera setelah file dibuka dan sebelum konten apa pun ditulis:

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

Menangani file yang dimuat secara dinamis dan sudah ada

Agar pengecualian tidak ditampilkan untuk file yang dimuat secara dinamis dan sudah ada, sebaiknya hapus dan buat ulang file sebelum Anda mencoba lagi memuatnya secara dinamis di aplikasi Anda. Saat Anda membuat ulang file, ikuti panduan sebelumnya untuk menandai file sebagai hanya baca pada waktu penulisan. Atau, Anda dapat melabeli ulang file yang ada sebagai hanya baca, tetapi dalam kasus ini, kami sangat menyarankan Anda untuk memverifikasi integritas file terlebih dahulu (misalnya dengan memeriksa tanda tangan file terhadap nilai tepercaya) untuk membantu melindungi aplikasi Anda dari tindakan berbahaya.

Batasan tambahan dalam memulai aktivitas dari latar belakang

Untuk aplikasi yang menargetkan Android 14 (API level 34) atau yang lebih tinggi, sistem akan lebih membatasi kapan aplikasi diizinkan untuk memulai aktivitas dari latar belakang:

  • Saat mengirim PendingIntent menggunakan PendingIntent#send() atau metode serupa, aplikasi harus memilih ikut serta jika ingin memberikan hak istimewa peluncuran aktivitas latar belakangnya sendiri untuk memulai intent yang tertunda. Untuk ikut serta, aplikasi harus meneruskan paket ActivityOptions dengan setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED).
  • Saat aplikasi yang terlihat mengikat layanan dari aplikasi lain yang ada di latar belakang menggunakan metode bindService(), aplikasi yang terlihat kini harus memilih ikut serta jika ingin memberikan hak istimewa peluncuran aktivitas latar belakangnya ke layanan terikat. Untuk ikut serta, aplikasi harus menyertakan flag BIND_ALLOW_ACTIVITY_STARTS saat memanggil metode bindService().

Perubahan ini memperluas rangkaian pembatasan yang ada untuk melindungi pengguna dengan mencegah aplikasi berbahaya agar tidak menyalahgunakan API untuk memulai aktivitas yang mengganggu dari latar belakang.

Zip path traversal

Untuk aplikasi yang menargetkan Android 14 (API level 34) atau yang lebih tinggi, Android mencegah Kerentanan Zip Path Traversal dengan cara berikut: ZipFile(String) dan ZipInputStream.getNextEntry() menampilkan ZipException jika nama entri file zip berisi ".." atau dimulai dengan "/".

Aplikasi dapat memilih untuk tidak mengikuti validasi ini dengan memanggil dalvik.system.ZipPathValidator.clearCallback().

Untuk aplikasi yang menargetkan Android 14 (API level 34) atau yang lebih tinggi, SecurityException akan ditampilkan oleh MediaProjection#createVirtualDisplay dalam salah satu skenario berikut:

Aplikasi Anda harus meminta pengguna untuk memberikan izin sebelum setiap sesi pengambilan. Satu sesi pengambilan adalah satu pemanggilan di MediaProjection#createVirtualDisplay, dan setiap instance MediaProjection hanya boleh digunakan satu kali.

Menangani perubahan konfigurasi

Jika aplikasi Anda perlu memanggil MediaProjection#createVirtualDisplay untuk menangani perubahan konfigurasi (seperti perubahan orientasi layar atau ukuran layar), Anda dapat mengikuti langkah-langkah berikut untuk mengupdate VirtualDisplay untuk instance MediaProjection yang ada:

  1. Panggil VirtualDisplay#resize dengan lebar dan tinggi baru.
  2. Berikan Surface baru dengan lebar dan tinggi baru ke VirtualDisplay#setSurface.

Mendaftarkan callback

Aplikasi Anda harus mendaftarkan callback untuk menangani kasus saat pengguna tidak memberikan izin untuk melanjutkan sesi pengambilan. Untuk melakukannya, terapkan Callback#onStop dan minta aplikasi Anda merilis resource terkait (seperti VirtualDisplay dan Surface).

Jika aplikasi Anda tidak mendaftarkan callback ini, MediaProjection#createVirtualDisplay akan menampilkan IllegalStateException saat aplikasi Anda memanggilnya.

Pembatasan non-SDK yang diperbarui

Android 14 menyertakan daftar terbaru antarmuka non-SDK yang dibatasi berdasarkan kolaborasi dengan developer Android dan pengujian internal terbaru. Jika memungkinkan, kami akan memastikan ketersediaan alternatif publik sebelum membatasi antarmuka non-SDK.

Jika aplikasi Anda tidak menargetkan Android 14, beberapa perubahan ini mungkin tidak langsung memengaruhi Anda. Namun, meskipun saat ini Anda dapat menggunakan beberapa antarmuka non-SDK (bergantung pada API level target aplikasi Anda), penggunaan metode atau kolom non-SDK tetap sangat berisiko merusak aplikasi Anda.

Jika tidak yakin apakah aplikasi Anda menggunakan antarmuka non-SDK atau tidak, Anda dapat menguji aplikasi untuk mencari tahu. Jika aplikasi Anda mengandalkan antarmuka non-SDK, sebaiknya mulailah merencanakan migrasi ke alternatif SDK. Meskipun begitu, kami paham bahwa beberapa aplikasi memiliki kasus penggunaan yang valid untuk menggunakan antarmuka non-SDK. Jika tidak dapat menemukan alternatif penggunaan antarmuka non-SDK untuk fitur dalam aplikasi Anda, sebaiknya minta API publik baru.

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 14. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.