Changements de comportement : toutes les applications

La plate-forme Android 15 apporte des modifications de comportement susceptibles d'affecter votre application. Les modifications de comportement suivantes s'appliquent à toutes les applications lorsqu'elles s'exécutent sur Android 15, peu importe la targetSdkVersion. Vous devez tester votre application, puis la modifier si nécessaire afin de prendre en charge ces modifications, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui n'affectent que les applications ciblant Android 15.

Fonctionnalité de base

Android 15 modifie ou étend diverses fonctionnalités de base du système Android.

Modifications apportées à l'état arrêté du package

L'état FLAG_STOPPED du package (que les utilisateurs peuvent activer dans les builds AOSP en appuyant de manière prolongée sur une icône d'application et en sélectionnant "Forcer l'arrêt") a toujours été de maintenir les applications dans cet état jusqu'à ce que l'utilisateur les en retire explicitement en les lançant directement ou en interagissant indirectement avec elles (via la Sharesheet ou un widget, en sélectionnant l'application comme fond d'écran animé, etc.). Dans Android 15, nous avons modifié le comportement du système pour qu'il corresponde à ce comportement prévu. Les applications ne doivent être supprimées de l'état "arrêté" que par une action directe ou indirecte de l'utilisateur.

Pour prendre en charge le comportement prévu, en plus des restrictions existantes, le système annule également tous les intents en attente lorsque l'application passe à l'état arrêté sur un appareil exécutant Android 15. Lorsque les actions de l'utilisateur retirent l'application de l'état d'arrêt, la diffusion ACTION_BOOT_COMPLETED est envoyée à l'application, ce qui lui permet de réenregistrer les intents en attente.

Vous pouvez appeler la nouvelle méthode ApplicationStartInfo.wasForceStopped() pour vérifier si l'application a été mise à l'arrêt.

Prise en charge des tailles de page de 16 ko

Historiquement, Android n'a pris en charge que les tailles de page de mémoire de 4 Ko, ce qui a optimisé les performances de la mémoire système pour la quantité moyenne de mémoire totale dont les appareils Android disposent généralement. À partir d'Android 15, AOSP est compatible avec les appareils configurés pour utiliser une taille de page de 16 ko (appareils 16 ko). Si votre application utilise des bibliothèques NDK, directement ou indirectement via un SDK, vous devrez la recompiler pour qu'elle fonctionne sur ces appareils de 16 Ko.

Alors que les fabricants d'appareils continuent de concevoir des appareils avec de plus grandes quantités de mémoire physique (RAM), beaucoup de ces appareils adopteront des tailles de page de 16 Ko (et éventuellement plus) pour optimiser les performances de l'appareil. L'ajout de la prise en charge des appareils avec une taille de page de 16 ko permet à votre application de s'exécuter sur ces appareils et de bénéficier des améliorations de performances associées. Sans recompilation, les applications ne fonctionneront pas sur les appareils 16 Ko dans les futures versions d'Android.

Pour vous aider à ajouter la compatibilité avec votre application, nous vous avons fourni des conseils sur la façon de vérifier si votre application est concernée, de recompiler votre application (le cas échéant) et de tester votre application dans un environnement de 16 ko à l'aide d'émulateurs (y compris les images système Android 15 pour Android Emulator).

Avantages et gains de performances

Les appareils configurés avec une taille de page de 16 Ko utilisent un peu plus de mémoire en moyenne, mais bénéficient également de diverses améliorations des performances pour le système et les applications:

• Temps de lancement des applications plus courts lorsque le système est soumis à une pression de mémoire: 3,16 % de moins en moyenne, avec des améliorations plus importantes (jusqu'à 30%) pour certaines applications que nous avons testées
• Consommation d'énergie réduite au démarrage de l'application: réduction de 4,56% en moyenne
• Lancement plus rapide de l'appareil photo: démarrage à chaud 4,48% plus rapide en moyenne et démarrage à froid 6,60% plus rapide en moyenne
• Amélioration du temps de démarrage du système: 8% (environ 950 millisecondes) en moyenne

Ces améliorations sont basées sur nos premiers tests. Les résultats sur les appareils réels seront probablement différents. Nous fournirons une analyse supplémentaire des gains potentiels pour les applications à mesure que nous poursuivrons nos tests.

Vérifier si votre application est concernée

Si votre application utilise du code natif, vous devez la reconstruire pour qu'elle soit compatible avec les appareils de 16 ko. Si vous n'êtes pas sûr que votre application utilise du code natif, vous pouvez utiliser l'analyseur d'APK pour identifier la présence de code natif, puis vérifier l'alignement des segments ELF pour les bibliothèques partagées que vous trouvez. Android Studio fournit également des fonctionnalités qui vous aident à détecter automatiquement les problèmes d'alignement.

Si votre application n'utilise que du code écrit en langage de programmation Java ou Kotlin, y compris tous ses SDK et bibliothèques, elle est déjà compatible avec les appareils 16 bits. Toutefois, nous vous recommandons de tester votre application dans un environnement de 16 ko pour vérifier qu'il n'y a pas de régression inattendue dans le comportement de l'application.

Modifications requises pour que certaines applications soient compatibles avec l'espace privé

L'espace privé est une nouvelle fonctionnalité d'Android 15 qui permet aux utilisateurs de créer un espace distinct sur leur appareil afin de tenir leurs applications sensibles loin des regards indiscrets, protégées par un niveau d'authentification renforcé. Étant donné que la visibilité des applications dans l'espace privé est limitée, certaines d'entre elles doivent prendre des mesures supplémentaires pour pouvoir voir et interagir avec les applications de l'espace privé d'un utilisateur.

Toutes les applications

Étant donné que les applications de l'espace privé sont conservées dans un profil utilisateur distinct, semblable aux profils professionnels, elles ne doivent pas supposer que les copies installées de leur application qui ne figurent pas dans le profil principal se trouvent dans le profil professionnel. Si votre application comporte une logique liée aux applications du profil professionnel qui font cette hypothèse, vous devrez ajuster cette logique.

Applis - Médecine

Lorsqu'un utilisateur verrouille l'espace privé, toutes les applications de l'espace privé sont arrêtées et ne peuvent pas effectuer d'activités de premier plan ni d'arrière-plan, y compris afficher des notifications. Ce comportement peut avoir un impact critique sur l'utilisation et le fonctionnement des applications médicales installées dans l'espace privé.

L'expérience de configuration de l'espace privé avertit les utilisateurs que l'espace privé n'est pas adapté aux applications qui doivent effectuer des activités critiques au premier plan ou en arrière-plan, comme l'affichage de notifications d'applications médicales. Toutefois, les applications ne peuvent pas déterminer si elles sont utilisées dans l'espace privé ou non. Elles ne peuvent donc pas afficher d'avertissement à l'utilisateur dans ce cas.

Pour ces raisons, si vous développez une application médicale, examinez l'impact potentiel de cette fonctionnalité sur votre application et prenez les mesures appropriées (par exemple, en informant vos utilisateurs de ne pas installer votre application dans l'espace privé) pour éviter de perturber les fonctionnalités essentielles de votre application.

Applications de lanceur

Si vous développez une application de lanceur d'applications, vous devez effectuer les opérations suivantes pour que les applications de l'espace privé soient visibles:

1. Votre application doit être définie comme application de lanceur par défaut de l'appareil, c'est-à-dire qu'elle doit posséder le rôle ROLE_HOME.
2. Votre application doit déclarer l'autorisation normale ACCESS_HIDDEN_PROFILES dans le fichier manifeste de votre application.

Les applications de lanceur d'applications qui déclarent l'autorisation ACCESS_HIDDEN_PROFILES doivent gérer les cas d'utilisation de l'espace privé suivants:

1. Votre application doit disposer d'un conteneur de lanceur d'applications distinct pour les applications installées dans l'espace privé. Utilisez la méthode getLauncherUserInfo() pour déterminer le type de profil utilisateur géré.
2. L'utilisateur doit pouvoir masquer et afficher le conteneur de l'espace privé.
3. L'utilisateur doit pouvoir verrouiller et déverrouiller le conteneur de l'espace privé. Utilisez la méthode requestQuietModeEnabled() pour verrouiller (en transmettant true) ou déverrouiller (en transmettant false) l'espace privé.

4. Lorsqu'il est verrouillé, aucune application du conteneur de l'espace privé ne doit être visible ni détectable par des mécanismes tels que la recherche. Votre application doit enregistrer un récepteur pour les diffusions ACTION_PROFILE_AVAILABLE et ACTION_PROFILE_UNAVAILABLE, et mettre à jour l'UI de votre application lorsque l'état verrouillé ou déverrouillé du conteneur de l'espace privé change. Ces deux diffusions incluent EXTRA_USER, que votre application peut utiliser pour faire référence à l'utilisateur du profil privé.

   Vous pouvez également utiliser la méthode isQuietModeEnabled() pour vérifier si le profil de l'espace privé est verrouillé ou non.

Applications de plate-forme de téléchargement d'applications

L'espace privé inclut un bouton "Installer des applications" qui lance une intention implicite pour installer des applications dans l'espace privé de l'utilisateur. Pour que votre application reçoive cet intent implicite, déclarez un <intent-filter> dans le fichier manifeste de votre application avec un <category> de CATEGORY_APP_MARKET.

Suppression de la police d'emoji basée sur PNG

L'ancien fichier de police d'emoji au format PNG (NotoColorEmojiLegacy.ttf) a été supprimé, ne laissant que le fichier vectoriel. À partir d'Android 13 (niveau d'API 33), le fichier de police d'emoji utilisé par le moteur d'affichage des emoji du système est passé d'un fichier basé sur PNG à un fichier basé sur des vecteurs. Pour des raisons de compatibilité, le système a conservé l'ancien fichier de polices dans Android 13 et 14 afin que les applications disposant de leurs propres moteurs de rendu de polices puissent continuer à utiliser l'ancien fichier de polices jusqu'à ce qu'elles puissent passer à la nouvelle version.

Pour vérifier si votre application est concernée, recherchez des références au fichier NotoColorEmojiLegacy.ttf dans le code de votre application.

Vous pouvez adapter votre application de différentes manières:

• Utilisez les API de la plate-forme pour l'affichage du texte. Vous pouvez afficher du texte dans un Canvas basé sur un bitmap et l'utiliser pour obtenir une image brute si nécessaire.
• Ajoutez la compatibilité avec les polices COLRv1 à votre application. La bibliothèque Open Source FreeType est compatible avec COLRv1 à partir de la version 2.13.0.
• En dernier recours, vous pouvez regrouper l'ancien fichier de police d'emoji (NotoColorEmoji.ttf) dans votre APK, mais dans ce cas, votre application ne disposera pas des dernières mises à jour des emoji. Pour en savoir plus, consultez la page du projet GitHub Noto Emoji.

Augmentation de la version minimale du SDK cible, qui passe de 23 à 24

Android 15 s'appuie sur des modifications apportées à Android 14 et étend cette la sécurité. Sous Android 15, les applications avec un Impossible d'installer targetSdkVersion de version antérieure à 24. Demander aux applications de répondre aux niveaux d'API modernes permet d'assurer une meilleure sécurité et confidentialité.

Les logiciels malveillants ciblent souvent des niveaux d'API inférieurs afin de contourner les mesures de sécurité et de confidentialité de protection qui ont été introduites dans les versions ultérieures d'Android. Par exemple, certaines applications de logiciel malveillant utilisent une targetSdkVersion de 22 pour éviter d'être soumises au modèle d'autorisation d'exécution introduit en 2015 par Android 6.0 Marshmallow (niveau d'API 23). Avec cette modification d'Android 15, il est plus difficile pour les logiciels malveillants de contourner la sécurité et de confidentialité. Si vous tentez d'installer une application ciblant un niveau d'API inférieur, l'installation échouera et le message suivant apparaîtra dans Logcat :

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 7

Sur les appareils passant à Android 15, les applications dont la version de targetSdkVersion est inférieure à 24 restent installées.

Si vous devez tester une application ciblant un niveau d'API plus ancien, utilisez la commande ADB suivante :

adb install --bypass-low-target-sdk-block FILENAME.apk

Sécurité et confidentialité

Android 15 引入了强大的措施来防范动态密码 (OTP) 欺诈并保护用户的敏感内容，重点是增强通知监听器服务和屏幕共享保护措施。主要增强功能包括从可供不可信应用访问的通知中隐去 OTP、在屏幕共享期间隐藏通知，以及在发布 OTP 时保护应用 activity。这些变更旨在保护用户的敏感内容，使其免受未经授权的操作者的侵害。

开发者需要注意以下事项，以确保其应用与 Android 15 中的变更兼容：

动态密码隐去

Android 会阻止实现 NotificationListenerService 的不受信任应用读取已检测到 OTP 的通知中的未隐去的内容。配套设备管理器关联等受信任应用不受这些限制。

屏幕共享保护

• 在屏幕共享会话期间，系统会隐藏通知内容，以保护用户的隐私。如果应用实现了 setPublicVersion()，Android 会显示通知的公开版本，该版本在不安全情境中用作替换通知。否则，系统会隐去通知内容，不提供任何其他背景信息。
• 系统会向远程观看者隐藏密码输入等敏感内容，以防止泄露用户的敏感信息。
• 如果在屏幕共享期间检测到动态密码，系统会隐藏在该时间段内发布通知的应用的活动。应用内容在启动时会向远程查看器隐藏。
• 除了 Android 自动识别敏感字段之外，开发者还可以使用 setContentSensitivity 手动将应用的部分标记为敏感，在屏幕共享期间，这些敏感字段会对远程观看者隐藏。
• 开发者可以选择切换开发者选项下的停用屏幕共享防护选项，以便出于演示或测试目的豁免屏幕共享防护。默认的系统屏幕录制工具不受这些更改的影响，因为录制内容会保留在设备上。

Appareil photo et médias

Android 15 apporte les modifications suivantes au comportement de l'appareil photo et des contenus multimédias pour toutes les applications.

La lecture audio directe et déchargée invalide les pistes audio directes ou déchargées précédemment ouvertes lorsque les limites de ressources sont atteintes.

Avant Android 15, si une application demandait la lecture audio directe ou de déchargement alors qu'une autre application diffusait de l'audio et que les limites de ressources étaient atteintes, l'application ne parvenait pas à ouvrir un nouveau AudioTrack.

À partir d'Android 15, lorsqu'une application demande la lecture directe ou le transfert et que les limites de ressources sont atteintes, le système invalide tous les objets AudioTrack actuellement ouverts qui empêchent de répondre à la nouvelle requête de piste.

(Les pistes audio directes et de déchargement sont généralement ouvertes pour la lecture de formats audio compressés. Les cas d'utilisation courants de la lecture audio directe incluent le streaming d'audio encodé via HDMI vers un téléviseur. Les pistes de déchargement sont généralement utilisées pour lire de l'audio compressé sur un appareil mobile avec accélération matérielle du DSP.)

Expérience utilisateur et UI du système

Android 15 inclut des modifications visant à créer une expérience utilisateur plus cohérente et intuitive.

Animations pour la prévisualisation du Retour activées pour les applications qui ont activé cette fonctionnalité

À partir d'Android 15, l'option pour les développeurs permettant d'activer les animations pour la prévisualisation du Retour a été supprimée. Les animations système telles que le retour à l'accueil, le passage d'une tâche à l'autre et le passage d'une activité à l'autre apparaissent désormais pour les applications qui ont activé le geste Retour prédictif entièrement ou au niveau d'une activité. Si votre application est concernée, procédez comme suit:

• Assurez-vous que votre application a été correctement migrée pour utiliser le geste de retour prédictif.
• Assurez-vous que vos transitions de fragment fonctionnent avec la navigation avec prévisualisation du Retour.
• Abandonnez les animations et les transitions de framework, et utilisez plutôt les transitions d'animateur et d'androidx.
• Migrez loin des piles "Retour" que FragmentManager ne connaît pas. Utilisez plutôt des piles "Retour" gérées par FragmentManager ou par le composant Navigation.

Widgets désactivés lorsque l'utilisateur arrête une application de force

Si un utilisateur arrête de forcer une application sur un appareil exécutant Android 15, le système désactive temporairement tous les widgets de l'application. Les widgets sont grisés et l'utilisateur ne peut pas interagir avec eux. En effet, à partir d'Android 15, le système annule tous les intents en attente d'une application lorsqu'elle est arrêtée de force.

Le système réactive ces widgets la prochaine fois que l'utilisateur lance l'application.

Pour en savoir plus, consultez la section Modifications apportées à l'état "Arrêté" du package.

Le chip de la barre d'état de la projection multimédia alerte les utilisateurs sur le partage, la diffusion et l'enregistrement d'écran

Les failles de projection d'écran exposent des données utilisateur privées telles que des informations financières, car les utilisateurs ne se rendent pas compte que l'écran de leur appareil est partagé.

Pour les applications exécutées sur des appareils équipés d'Android 15 QPR1 ou version ultérieure, un chip de barre d'état de grande taille et bien visible avertit les utilisateurs de toute projection d'écran en cours. Les utilisateurs peuvent appuyer sur le chip pour empêcher le partage, la diffusion ou l'enregistrement de leur écran. De plus, la projection d'écran s'arrête automatiquement lorsque l'écran de l'appareil est verrouillé.

Vérifier si votre application est concernée

Par défaut, votre application inclut le chip de la barre d'état et suspend automatiquement la projection d'écran lorsque l'écran de verrouillage s'active.

Pour en savoir plus sur le test de votre application pour ces cas d'utilisation, consultez la section Chip de barre d'état et arrêt automatique.

Restrictions d'accès au réseau en arrière-plan

在 Android 15 中，如果应用在有效的进程生命周期之外启动网络请求，则会收到异常。通常是 UnknownHostException 或其他与套接字相关的 IOException。在有效生命周期之外发生的网络请求通常是因为应用在不再活跃后，不知不觉地继续发出网络请求。

为缓解此异常，请使用生命周期感知型组件，确保您的网络请求具有生命周期感知功能，并在离开有效的进程生命周期时取消。如果您非常重视即使用户离开应用也要发出网络请求，请考虑使用 WorkManager 调度网络请求，或使用前台服务继续执行对用户可见的任务。

Abandons

À chaque version, des API Android spécifiques peuvent devenir obsolètes ou nécessiter une refactorisation pour offrir une meilleure expérience aux développeurs ou prendre en charge de nouvelles fonctionnalités de la plate-forme. Dans ce cas, nous abandonnons officiellement les API obsolètes et invitons les développeurs à utiliser d'autres API.

L'arrêt signifie que nous ne fournissons plus d'assistance officielle pour les API, mais qu'elles resteront disponibles pour les développeurs. Pour en savoir plus sur les abandons notables de cette version d'Android, consultez la page sur les abandons.