Modifications de comportement : applications ciblant Android 14 ou version ultérieure

Comme les versions précédentes, Android 14 inclut des modifications de comportement susceptibles d'affecter votre application. Les modifications de comportement suivantes s'appliquent exclusivement aux applications qui ciblent Android 14 (niveau d'API 34) ou version ultérieure. Si votre application cible Android 14 ou une version ultérieure, vous devez la modifier pour prendre en charge ces comportements correctement, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui affectent toutes les applications exécutées sous Android 14, quel que soit le targetSdkVersion de l'application.

Fonctionnalité de base

Le type de service au premier plan doit être indiqué

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

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

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

Application de l'autorisation BLUETOOTH_CONNECT dans BluetoothAdapter

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

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

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

Mises à jour 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 renforce le comportement des rappels et du réseau

自引入以来，JobScheduler 会预期您的应用在几秒内从 onStartJob 或 onStopJob 返回。在 Android 14 之前，如果作业运行时间太长，则会静默停止并失败。如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台且在主线程上超出了授权的时间，应用会触发 ANR，并显示错误消息“对 onStartJob 没有响应”或“对 onStopJob 没有响应”。请考虑迁移到 WorkManager，该版本可支持异步处理，或将所有繁重工作迁移到后台线程。

JobScheduler 还引入了，如果使用 setRequiredNetworkType 或 setRequiredNetwork 约束条件，则需要声明 ACCESS_NETWORK_STATE 权限。如果应用在调度作业时未声明 ACCESS_NETWORK_STATE 权限，并且以 Android 14 或更高版本为目标平台，则会导致 SecurityException。

Tiles lance l'API

Pour les applications ciblant la version 14 ou ultérieure, TileService#startActivityAndCollapse(Intent) est obsolète et génère désormais une exception en cas d'appel. Si votre application lance des activités à partir de cartes, utilisez plutôt TileService#startActivityAndCollapse(PendingIntent).

Confidentialité

Accès partiel aux photos et aux vidéos

Android 14 introduit l'accès aux photos sélectionnées, qui permet aux utilisateurs d'autoriser des applications à accéder à des images et des vidéos spécifiques de leur bibliothèque, plutôt que d'accorder l'accès à tous les contenus multimédias d'un type donné.

Cette modification n'est activée que si votre application cible Android 14 (niveau d'API 34) ou version ultérieure. Si vous n'utilisez pas encore le sélecteur de photos, nous vous recommandons de le mettre en œuvre dans votre application pour offrir une expérience cohérente de sélection d'images et de vidéos, tout en améliorant la confidentialité des utilisateurs sans avoir à demander d'autorisations de stockage.

Si vous gérez votre propre sélecteur de galerie à l'aide d'autorisations de stockage et que vous devez garder un contrôle total sur votre implémentation, adaptez votre implémentation pour utiliser la nouvelle autorisation READ_MEDIA_VISUAL_USER_SELECTED. Si votre application n'utilise pas la nouvelle autorisation, le système l'exécute en mode de compatibilité.

Expérience utilisateur

Notifications d'intent plein écran sécurisées

Avec Android 11 (niveau d'API 30), toutes les applications pouvaient utiliser Notification.Builder.setFullScreenIntent pour envoyer des intents en plein écran lorsque le téléphone était verrouillé. Vous pouvez l'accorder automatiquement lors de l'installation de l'application en déclarant l'autorisation USE_FULL_SCREEN_INTENT dans le fichier AndroidManifest.

Les notifications d'intent plein écran sont conçues pour les notifications à priorité très élevée nécessitant l'attention immédiate de l'utilisateur, comme les appels entrants ou les paramètres d'alarme configurés par l'utilisateur. Pour les applications ciblant Android 14 (niveau d'API 34) ou version ultérieure, les applications autorisées à utiliser cette autorisation sont limitées à celles qui proposent uniquement des appels et des alarmes. Le Google Play Store révoque les autorisations USE_FULL_SCREEN_INTENT par défaut pour toutes les applications qui ne correspondent pas à ce profil. La date limite pour appliquer ces modifications de stratégie est le 31 mai 2024.

Cette autorisation reste activée pour les applications installées sur le téléphone avant que l'utilisateur passe à Android 14. Les utilisateurs peuvent activer et désactiver cette autorisation.

Vous pouvez utiliser la nouvelle API NotificationManager.canUseFullScreenIntent pour vérifier si votre application dispose de l'autorisation. Sinon, elle peut utiliser le nouvel intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT pour ouvrir la page des paramètres permettant aux utilisateurs d'accorder l'autorisation.

Sécurité

Restrictions concernant les intents implicites et en attente

对于以 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，则系统会抛出异常：

Kotlin

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

Java

// Throws an 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);

Les broadcasts receivers enregistrés lors de l'exécution doivent spécifier le comportement d'exportation

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

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

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

Chargement de code dynamique plus sécurisé

如果您的应用以 Android 14（API 级别 34）或更高版本为目标平台，并使用动态代码加载 (DCL) 功能，则必须将所有动态加载的文件标记为只读。否则，系统会抛出异常。我们建议应用尽可能避免动态加载代码，因为这样做会大大增加应用因代码注入或代码篡改而遭到入侵的风险。

如果必须动态加载代码，请使用以下方法，在动态文件（例如 DEX、JAR 或 APK 文件）打开并写入任何内容之前立即将其设为只读：

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

处理已存在的动态加载文件

为防止系统对现有动态加载的文件抛出异常，我们建议您先删除并重新创建文件，然后再尝试在应用中重新动态加载这些文件。重新创建文件时，请按照上述指南在写入时将文件标记为只读。或者，您可以将现有文件重新标记为只读，但在这种情况下，我们强烈建议您先验证文件的完整性（例如，对照可信值检查文件的签名）以保护应用免遭恶意操作的影响。

Restrictions supplémentaires concernant le démarrage d'activités en arrière-plan

Pour les applications ciblant Android 14 (niveau d'API 34) ou version ultérieure, le système limite davantage le moment où les applications sont autorisées à démarrer des activités en arrière-plan:

• Lorsqu'une application envoie un PendingIntent à l'aide de PendingIntent#send() ou de méthodes similaires, elle doit l'activer si elle souhaite accorder ses propres privilèges de lancement d'activité en arrière-plan pour démarrer l'intent en attente. Pour l'activer, l'application doit transmettre un bundle ActivityOptions avec setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED).
• Lorsqu'une application visible associe un service à une autre application en arrière-plan à l'aide de la méthode bindService(), elle doit désormais l'activer si elle souhaite accorder ses propres privilèges de lancement d'activité en arrière-plan au service lié. Pour l'activer, l'application doit inclure l'indicateur BIND_ALLOW_ACTIVITY_STARTS lors de l'appel de la méthode bindService().

Ces modifications étendent l'ensemble de restrictions existant pour protéger les utilisateurs en empêchant les applications malveillantes d'utiliser les API de manière abusive pour lancer des activités perturbatrices en arrière-plan.

Traversée de répertoire ZIP

Pour les applications ciblant Android 14 (niveau d'API 34) ou version ultérieure, Android empêche la faille de traversée de répertoires ZIP de la manière suivante : ZipFile(String) et ZipInputStream.getNextEntry() génèrent une erreur ZipException si les noms des entrées de fichiers ZIP contiennent ".." ou commencent par "/".

Les applications peuvent désactiver cette validation en appelant dalvik.system.ZipPathValidator.clearCallback().

Consentement de l'utilisateur requis pour chaque session de capture MediaProjection

Pour les applications ciblant Android 14 (niveau d'API 34) ou version ultérieure, une SecurityException est générée par MediaProjection#createVirtualDisplay dans l'un des scénarios suivants:

• Votre application met en cache le Intent renvoyé par MediaProjectionManager#createScreenCaptureIntent et le transmet plusieurs fois à MediaProjectionManager#getMediaProjection.
• Votre application appelle MediaProjection#createVirtualDisplay plusieurs fois sur la même instance MediaProjection.

Votre application doit demander à l'utilisateur de donner son consentement avant chaque session de capture. Une session de capture unique correspond à un appel unique sur MediaProjection#createVirtualDisplay, et chaque instance MediaProjection ne doit être utilisée qu'une seule fois.

Gérer les modifications de configuration

Si votre application doit appeler MediaProjection#createVirtualDisplay pour gérer les modifications de configuration (telles que l'orientation ou la taille de l'écran), vous pouvez suivre ces étapes pour mettre à jour VirtualDisplay pour l'instance MediaProjection existante:

1. Appelez VirtualDisplay#resize avec les nouvelles largeurs et hauteurs.
2. Fournissez un nouveau Surface avec de nouvelles largeurs et hauteurs définies pour VirtualDisplay#setSurface.

Enregistrer un rappel

Votre application doit enregistrer un rappel pour gérer les cas où l'utilisateur ne donne pas son consentement pour poursuivre une session de capture. Pour ce faire, implémentez Callback#onStop et demandez à votre application de publier toutes les ressources associées (telles que VirtualDisplay et Surface).

Si votre application n'enregistre pas ce rappel, MediaProjection#createVirtualDisplay génère une exception IllegalStateException lorsque votre application l'appelle.

Mise à jour des restrictions non SDK

Android 14 inclut des listes à jour d'interfaces non SDK limitées grâce à la collaboration avec les développeurs Android et aux derniers tests internes. Dans la mesure du possible, nous nous assurons que des alternatives publiques sont disponibles avant de limiter les interfaces non SDK.

Si votre application ne cible pas Android 14, certaines de ces modifications ne vous affecteront peut-être pas immédiatement. Cependant, bien que vous puissiez actuellement utiliser certaines interfaces non SDK (en fonction du niveau d'API cible de votre application), l'utilisation d'un champ ou d'une méthode non SDK présente toujours un risque élevé d'endommager votre application.

Si vous n'êtes pas sûr que votre application utilise des interfaces non SDK, vous pouvez tester votre application pour le savoir. Si votre application repose sur des interfaces non SDK, vous devriez commencer à planifier une migration vers des alternatives SDK. Nous comprenons néanmoins que certaines applications ont des cas d'utilisation valides pour utiliser des interfaces non SDK. Si vous ne trouvez pas d'alternative à l'utilisation d'une interface non SDK pour une fonctionnalité de votre application, vous devriez demander une nouvelle API publique.

Pour en savoir plus sur les modifications apportées à cette version d'Android, consultez Mises à jour des restrictions des interfaces non SDK dans Android 14. Pour en savoir plus sur les interfaces non SDK de manière générale, consultez la section Restrictions concernant les interfaces non SDK.