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

Comme dans les versions précédentes, Android 14 apporte 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 qu'elle prenne en charge ces comportements, le cas échéant.

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

Fonctionnalité de base

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

Si votre application cible Android 14 (niveau d'API 34) ou une version ultérieure, elle doit spécifier au moins un type de service de premier plan pour chaque service de premier plan. Vous devez choisir un type de service de premier plan qui représente le cas d'utilisation de votre application. Le système s'attend à ce que des services de premier plan ayant un type particulier répondent à un cas d'utilisation particulier.

Si un cas d'utilisation dans votre application n'est associé à aucun de ces types, il est fortement recommandé de migrer votre logique pour utiliser WorkManager ou les tâches de transfert de données déclenchées par l'utilisateur.

Application de l'autorisation BLUETOOTH_CONNECT dans BluetoothAdapter

Android 14 applique l'autorisation BLUETOOTH_CONNECT lors de l'appel de la méthode BluetoothAdapter getProfileConnectionState() pour les applications ciblant Android 14 (niveau d'API 34) ou version ultérieure.

Cette méthode nécessitait déjà l'autorisation BLUETOOTH_CONNECT, mais elle n'a pas été appliquée. Assurez-vous que votre application déclare BLUETOOTH_CONNECT dans son fichier AndroidManifest.xml, comme indiqué dans l'extrait de code suivant, et vérifiez qu'un utilisateur a accordé l'autorisation avant d'appeler getProfileConnectionState.

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

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

Depuis son lancement, JobScheduler s'attend à ce que votre application soit renvoyée de onStartJob ou onStopJob en quelques secondes. Avant Android 14, si une tâche s'exécute trop longtemps, elle s'arrête et échoue en mode silencieux. Si votre application cible Android 14 (niveau d'API 34) ou une version ultérieure et dépasse le délai accordé sur le thread principal, elle déclenche une erreur ANR avec le message d'erreur "Aucune réponse à onStartJob" ou "Aucune réponse à onStopJob". Envisagez de migrer vers WorkManager, qui prend en charge le traitement asynchrone ou la migration des tâches lourdes vers un thread d'arrière-plan.

JobScheduler introduit également une exigence permettant de déclarer l'autorisation ACCESS_NETWORK_STATE si vous utilisez une contrainte setRequiredNetworkType ou setRequiredNetwork. Si votre application ne déclare pas l'autorisation ACCESS_NETWORK_STATE lors de la planification de la tâche et qu'elle cible Android 14 ou version ultérieure, elle génère une erreur SecurityException.

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

Les applications et les services qui ciblent Android 14 (niveau d'API 34) ou version ultérieure et utilisent des récepteurs enregistrés en contexte doivent spécifier un indicateur pour indiquer si le récepteur doit être exporté ou non vers toutes les autres applications de l'appareil: RECEIVER_EXPORTED ou RECEIVER_NOT_EXPORTED, respectivement. Cette exigence permet de protéger les applications contre les failles de sécurité en exploitant les fonctionnalités pour ces récepteurs introduites dans Android 13.

Exception pour les récepteurs qui ne reçoivent que des annonces du système

Si votre application n'enregistre un récepteur que pour les annonces du système via des méthodes Context#registerReceiver, telles que Context#registerReceiver(), elle ne doit pas spécifier d'indicateur lors de l'enregistrement du récepteur.

Chargement de code dynamique plus sécurisé

Si votre application cible Android 14 (niveau d'API 34) ou version ultérieure et utilise le chargement dynamique de code (DCL), tous les fichiers chargés dynamiquement doivent être marqués en lecture seule. Sinon, le système génère une exception. Nous vous recommandons d'éviter le chargement dynamique de code dans la mesure du possible, car cela augmente considérablement le risque qu'une application soit compromise par une injection ou une falsification de code.

Si vous devez charger le code de manière dynamique, utilisez l'approche suivante pour définir le fichier chargé dynamiquement (tel qu'un fichier DEX, JAR ou APK) en lecture seule dès que le fichier est ouvert et avant toute écriture :

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

Gérer les fichiers chargés dynamiquement préexistants

Pour éviter de générer des exceptions pour les fichiers existants chargés dynamiquement, nous vous recommandons de supprimer et de recréer les fichiers avant de réessayer de les charger dynamiquement dans votre application. Lorsque vous recréez les fichiers, suivez les instructions précédentes pour les marquer en lecture seule au moment de l'écriture. Vous pouvez également libeller à nouveau les fichiers existants en lecture seule, mais dans ce cas, nous vous recommandons vivement de vérifier d'abord l'intégrité des fichiers (par exemple, en vérifiant la signature du fichier correspond à une valeur de confiance), pour protéger votre application des actions malveillantes.

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

For apps targeting Android 14 (API level 34) or higher, the system further restricts when apps are allowed to start activities from the background:

These changes expand the existing set of restrictions to protect users by preventing malicious apps from abusing APIs to start disruptive activities from the background.

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

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 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 包含更新后的受限非 SDK 接口列表（基于与 Android 开发者之间的协作以及最新的内部测试）。在限制使用非 SDK 接口之前，我们会尽可能确保有可用的公开替代方案。

如果您的应用并非以 Android 14 为目标平台，其中一些变更可能不会立即对您产生影响。然而，虽然您目前仍可以使用一些非 SDK 接口（具体取决于应用的目标 API 级别），但只要您使用任何非 SDK 方法或字段，终归存在导致应用出问题的显著风险。

如果您不确定自己的应用是否使用了非 SDK 接口，则可以测试您的应用来进行确认。如果您的应用依赖于非 SDK 接口，您应该开始计划迁移到 SDK 替代方案。然而，我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案，应请求新的公共 API。

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.