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 (API level 34) atau yang lebih tinggi. Jika aplikasi menargetkan Android 14 atau yang lebih tinggi, Anda harus memodifikasi aplikasi untuk mendukung perilaku ini dengan benar, jika berlaku.

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

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

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

Penerapan izin BLUETOOTH_CONNECT di BluetoothAdapter

Android 14 menerapkan izin BLUETOOTH_CONNECT saat memanggil metode BluetoothAdapter getProfileConnectionState() untuk aplikasi yang menargetkan Android 14 (API level 34) atau yang lebih tinggi.

Metode ini sudah memerlukan izin BLUETOOTH_CONNECT, tetapi tidak diterapkan. Pastikan aplikasi Anda mendeklarasikan BLUETOOTH_CONNECT dalam file AndroidManifest.xml aplikasi seperti yang ditunjukkan dalam cuplikan berikut dan periksa apakah pengguna telah memberikan izin sebelum memanggil getProfileConnectionState.

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

Update OpenJDK 17

Android 14 melanjutkan pekerjaan memuat ulang library inti Android agar selaras dengan fitur dalam rilis OpenJDK LTS terbaru, termasuk update library dan dukungan bahasa Java 17 untuk developer aplikasi dan platform.

Beberapa perubahan ini dapat memengaruhi kompatibilitas aplikasi:

  • Perubahan pada ekspresi reguler: Referensi grup yang tidak valid kini tidak diizinkan untuk mengikuti semantik OpenJDK lebih dekat. Anda mungkin melihat kasus baru saat IllegalArgumentException ditampilkan oleh class java.util.regex.Matcher, jadi pastikan untuk menguji aplikasi Anda untuk area yang menggunakan ekspresi reguler. Untuk mengaktifkan atau menonaktifkan perubahan ini saat menguji, alihkan flag DISALLOW_INVALID_GROUP_REFERENCE menggunakan alat framework kompatibilitas.
  • Penanganan UUID: Metode java.util.UUID.fromString() kini melakukan pemeriksaan yang lebih ketat saat memvalidasi argumen input, sehingga Anda mungkin melihat IllegalArgumentException selama deserialisasi. Untuk mengaktifkan atau menonaktifkan perubahan ini saat menguji, alihkan flag ENABLE_STRICT_VALIDATION menggunakan alat framework kompatibilitas.
  • Masalah ProGuard: Dalam beberapa kasus, penambahan class java.lang.ClassValue menyebabkan masalah jika Anda mencoba untuk menyusutkan, meng-obfuscate, dan mengoptimalkan aplikasi menggunakan ProGuard. Masalah ini berasal dari library Kotlin yang mengubah perilaku runtime berdasarkan apakah Class.forName("java.lang.ClassValue") menampilkan class atau tidak. Jika aplikasi Anda dikembangkan terhadap runtime versi lama tanpa class java.lang.ClassValue yang tersedia, pengoptimalan ini mungkin akan menghapus metode computeValue dari class yang berasal dari 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

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

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

Aplikasi dan layanan yang menargetkan Android 14 (API level 34) atau yang lebih tinggi dan menggunakan penerima yang terdaftar dalam konteks harus menentukan flag untuk menunjukkan apakah penerima harus diekspor ke semua aplikasi lain di perangkat: RECEIVER_EXPORTED atau RECEIVER_NOT_EXPORTED. Persyaratan ini membantu melindungi aplikasi dari kerentanan keamanan dengan memanfaatkan fitur untuk penerima yang diperkenalkan di Android 13 ini.

Pengecualian untuk penerima yang hanya menerima siaran sistem

Jika aplikasi Anda mendaftarkan penerima hanya untuk siaran sistem melalui metode Context#registerReceiver, seperti Context#registerReceiver(), aplikasi tidak boleh menentukan flag saat mendaftarkan penerima.

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 pemuatan kode secara dinamis jika memungkinkan, karena hal itu akan sangat meningkatkan risiko aplikasi disusupi oleh injeksi kode atau modifikasi 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.

Untuk mempelajari perubahan dalam rilis Android ini lebih lanjut, baca Pembaruan pembatasan antarmuka non-SDK di Android 14. Untuk mempelajari lebih lanjut antarmuka non-SDK secara umum, baca Pembatasan antarmuka non-SDK.