Changements de comportement : toutes les applications

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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 d'arrêt du package

The intention of the package FLAG_STOPPED state (which users can engage in AOSP builds by long-pressing an app icon and selecting "Force Stop") has always been to keep apps in this state until the user explicitly removes the app from this state by directly launching the app or indirectly interacting with the app (through the sharesheet or a widget, selecting the app as live wallpaper, etc.). In Android 15, we've updated the behavior of the system to be aligned with this intended behavior. Apps should only be removed from the stopped state through direct or indirect user action.

To support the intended behavior, in addition to the existing restrictions, the system also cancels all pending intents when the app enters the stopped state on a device running Android 15. When the user's actions remove the app from the stopped state, the ACTION_BOOT_COMPLETED broadcast is delivered to the app providing an opportunity to re-register any pending intents.

You can call the new ApplicationStartInfo.wasForceStopped() method to confirm whether the app was put into the stopped state.

Compatibilité avec les tailles de page de 16 ko

Auparavant, Android n'acceptait que des pages de 4 Ko de mémoire, ce qui optimisée des performances de la mémoire système pour la quantité moyenne de mémoire totale les appareils Android ont généralement eu. À partir d'Android 15, AOSP prend en charge appareils configurés pour utiliser une taille de page de 16 Ko appareils). Si votre application utilise des bibliothèques du NDK, directement ou indirectement via un SDK, vous devez recompiler votre application pour qu'elle fonctionnent sur ces appareils de 16 Ko.

Alors que les fabricants d’appareils continuent à construire des appareils avec de plus grandes quantités mémoire physique (RAM), un grand nombre de ces appareils adopteront un débit de 16 Ko (et et éventuellement plus) pour optimiser les performances de l'appareil. Ajout... la compatibilité avec les appareils dont la taille de page est de 16 Ko permet à votre application de s'exécuter sur ces appareils et aide votre application à bénéficier des performances associées et d'améliorations. Sans recompilation, les applications risquent de ne pas fonctionner sur les appareils de 16 Ko. lorsqu'ils seront mis en production dans les prochaines versions d'Android.

Pour vous aider à proposer la prise en charge de votre application, nous vous fournissons des conseils sur la façon de vérifier si votre application est concernée, comment recompilez votre application (le cas échéant) et comment la tester dans un environnement de 16 Ko utilisant des émulateurs (y compris Android 15) ; images système 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 recompiler pour qu'elle soit compatible avec les appareils 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 toutes les bibliothèques partagées que vous trouvez.

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 ko. 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égressions inattendues dans le comportement de l'application.

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

Private space is a new feature in Android 15 that lets users create a separate space on their device where they can keep sensitive apps away from prying eyes, under an additional layer of authentication. Because apps in the private space have restricted visibility, some types of apps need to take additional steps to be able to see and interact with apps in a user's private space.

All apps

Because apps in the private space are kept in a separate user profile, similar to work profiles, apps shouldn't assume that any installed copies of their app that aren't in the main profile are in the work profile. If your app has logic related to work profile apps that make this assumption, you'll need to adjust this logic.

Medical apps

When a user locks the private space, all apps in the private space are stopped, and those apps can't perform foreground or background activities, including showing notifications. This behavior might critically impact the use and function of medical apps installed in the private space.

The private space setup experience warns users that the private space is not suitable for apps that need to perform critical foreground or background activities, such as showing notifications from medical apps. However, apps can't determine whether or not they're being used in the private space, so they can't show a warning to the user for this case.

For these reasons, if you develop a medical app, review how this feature might impact your app and take appropriate actions—such as informing your users not to install your app in the private space—to avoid disrupting critical app capabilities.

Launcher apps

If you develop a launcher app, you must do the following before apps in the private space will be visible:

1. Your app must be assigned as the default launcher app for the device—that is, possessing the ROLE_HOME role.
2. Your app must declare the ACCESS_HIDDEN_PROFILES normal permission in your app's manifest file.

Launcher apps that declare the ACCESS_HIDDEN_PROFILES permission must handle the following private space use cases:

1. Your app must have a separate launcher container for apps installed in the private space. Use the getLauncherUserInfo() method to determine which type of user profile is being handled.
2. The user must be able to hide and show the private space container.
3. The user must be able to lock and unlock the private space container. Use the requestQuietModeEnabled() method to lock (by passing true) or unlock (by passing false) the private space.

4. While locked, no apps in the private space container should be visible or discoverable through mechanisms such as search. Your app should register a receiver for the ACTION_PROFILE_AVAILABLE and ACTION_PROFILE_UNAVAILABLE broadcasts and update the UI in your app when the locked or unlocked state of the private space container changes. Both of these broadcasts include EXTRA_USER, which your app can use to refer to the private profile user.

   You can also use the isQuietModeEnabled() method to check whether the private space profile is locked or not.

App store apps

The private space includes an "Install Apps" button that launches an implicit intent to install apps into the user's private space. In order for your app to receive this implicit intent, declare an <intent-filter> in your app's manifest file with a <category> of CATEGORY_APP_MARKET.

Suppression de la police d'emoji basée sur le format 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 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 introduit des mesures robustes pour lutter contre la fraude par code secret à usage unique (OTP) et protéger le contenu sensible de l'utilisateur, en se concentrant sur le renforcement des protections du service Notification Listener et du partage d'écran. Parmi les principales améliorations, citons la suppression des codes OTP des notifications accessibles aux applications non approuvées, le masquage des notifications lors du partage d'écran et la sécurisation des activités des applications lorsque des codes OTP sont publiés. Ces modifications visent à protéger le contenu sensible de l'utilisateur contre les acteurs non autorisés.

Les développeurs doivent tenir compte des points suivants pour s'assurer que leurs applications sont compatibles avec les modifications apportées à Android 15:

Masquage de l'OTP

Android empêche les applications non approuvées qui implémentent un NotificationListenerService de lire le contenu non masqué des notifications dans lesquelles un code OTP a été détecté. Ces restrictions ne s'appliquent pas aux applications de confiance telles que les associations de gestionnaires d'appareils associés.

Protection du partage d'écran

• Le contenu des notifications est masqué pendant les sessions de partage d'écran afin de préserver la confidentialité de l'utilisateur. Si l'application implémente setPublicVersion(), Android affiche la version publique de la notification, qui sert de notification de remplacement dans les contextes non sécurisés. Sinon, le contenu de la notification est masqué sans autre contexte.
• Les contenus sensibles, comme la saisie de mots de passe, sont masqués pour les spectateurs à distance afin d'éviter de révéler les informations sensibles de l'utilisateur.
• Les activités des applications qui publient des notifications pendant le partage d'écran où un code OTP a été détecté sont masquées. Le contenu de l'application est masqué pour le téléspectateur à distance lors du lancement.
• En plus de l'identification automatique des champs sensibles par Android, les développeurs peuvent marquer manuellement des parties de leur application comme sensibles à l'aide de setContentSensitivity, qui sont masquées pour les spectateurs à distance lors du partage d'écran.
• Les développeurs peuvent activer ou désactiver l'option Désactiver les protections lors du partage d'écran sous Options pour les développeurs afin d'être exemptés des protections lors du partage d'écran à des fins de démonstration ou de test. L'enregistreur d'écran système par défaut est exempté de ces modifications, car les enregistrements restent sur l'appareil.

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 hors connexion invalide les pistes audio directes ou hors connexion 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 interface utilisateur du système

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

Animations pour prévisualiser le retour en arrière activées pour les applications qui ont activé cette fonctionnalité

Beginning in Android 15, the developer option for predictive back animations has been removed. System animations such as back-to-home, cross-task, and cross-activity now appear for apps that have opted in to the predictive back gesture either entirely or at an activity level. If your app is affected, take the following actions:

• Ensure that your app has been properly migrated to use the predictive back gesture.
• Ensure that your fragment transitions work with predictive back navigation.
• Migrate away from animation and framework transitions and use animator and androidx transitions instead.
• Migrate away from back stacks that FragmentManager doesn't know about. Use back stacks managed by FragmentManager or by the Navigation component instead.

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

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.

Chip de la barre d'état de la projection multimédia pour avertir les utilisateurs du partage d'écran, du cast et de l'enregistrement

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

Check if your app is impacted

By default, your app includes the status bar chip and automatically suspends screen projection when the lock screen activates.

To learn more about how to test your app for these use cases, see Status bar chip and auto stop.

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

In Android 15, apps that start a network request outside of a valid process lifecycle receive an exception. Typically, an UnknownHostException or other socket-related IOException. Network requests that happen outside of a valid lifecycle are usually due to apps unknowingly continuing a network request even after the app is no longer active.

To mitigate this exception, ensure your network requests are lifecycle aware and cancelled upon leaving a valid process lifecycle by using lifecycle aware components. If it is important that the network request should happen even when the user leaves the application, consider scheduling the network request using WorkManager or continue a user visible task using Foreground Service.

Abandons

À chaque version, des API Android spécifiques peuvent devenir obsolètes ou nécessiter un refactoring 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 supprimons officiellement les API obsolètes et orientons les développeurs vers d'autres API à utiliser à la place.

L'abandon signifie que nous avons mis fin à la prise en charge officielle des 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 des abandons.