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

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.

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

Benefits and performance gains

Devices configured with 16 KB page sizes use slightly more memory on average, but also gain various performance improvements for both the system and apps:

• Lower app launch times while the system is under memory pressure: 3.16% lower on average, with more significant improvements (up to 30%) for some apps that we tested
• Reduced power draw during app launch: 4.56% reduction on average
• Faster camera launch: 4.48% faster hot starts on average, and 6.60% faster cold starts on average
• Improved system boot time: improved by 8% (approximately 950 milliseconds) on average

These improvements are based on our initial testing, and results on actual devices will likely differ. We'll provide additional analysis of potential gains for apps as we continue our testing.

Check if your app is impacted

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

The legacy, PNG-based emoji font file (NotoColorEmojiLegacy.ttf) has been removed, leaving just the vector-based file. Beginning with Android 13 (API level 33), the emoji font file used by the system emoji renderer changed from a PNG-based file to a vector based file. The system retained the legacy font file in Android 13 and 14 for compatibility reasons, so that apps with their own font renderers could continue to use the legacy font file until they were able to upgrade.

To check if your app is affected, search your app's code for references to the NotoColorEmojiLegacy.ttf file.

You can choose to adapt your app in a number of ways:

• Use platform APIs for text rendering. You can render text to a bitmap-backed Canvas and use that to get a raw image if necessary.
• Add COLRv1 font support to your app. The FreeType open source library supports COLRv1 in version 2.13.0 and higher.
• As a last resort, you can bundle the legacy emoji font file (NotoColorEmoji.ttf) into your APK, although in that case your app will be missing the latest emoji updates. For more information, see the Noto Emoji GitHub project page.

La version minimale du SDK cible est passée de 23 à 24.

Android 15 builds on the the changes that were made in Android 14 and extends this security further. In Android 15, apps with a targetSdkVersion lower than 24 can't be installed. Requiring apps to meet modern API levels helps to ensure better security and privacy.

Malware often targets lower API levels in order to bypass security and privacy protections that have been introduced in higher Android versions. For example, some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 Marshmallow (API level 23). This Android 15 change makes it harder for malware to avoid security and privacy improvements. Attempting to install an app targeting a lower API level results in an installation failure, with a message like the following one appearing in Logcat:

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

On devices upgrading to Android 15, any apps with a targetSdkVersion lower than 24 remain installed.

If you need to test an app targeting an older API level, use the following ADB command:

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

Sécurité et confidentialité

Android 15 introduces robust measures to combat one-time passcode (OTP) fraud and to protect the user's sensitive content, focusing on hardening the Notification Listener Service and screenshare protections. Key enhancements include redacting OTPs from notifications accessible to untrusted apps, hiding notifications during screenshare, and securing app activities when OTPs are posted. These changes aim to keep the user's sensitive content safe from unauthorized actors.

Developers need to be aware of the following to ensure their apps are compatible with the changes in Android 15:

OTP Redaction

Android will stop untrusted apps that implement a NotificationListenerService from reading unredacted content from notifications where an OTP has been detected. Trusted apps such as companion device manager associations are exempt from these restrictions.

Screenshare Protection

• Notification content is hidden during screen sharing sessions to preserve the user's privacy. If the app implements setPublicVersion(), Android shows the public version of the notification which serves as a replacement notification in insecure contexts. Otherwise, the notification content is redacted without any further context.
• Sensitive content like password input is hidden from remote viewers to prevent revealing the user's sensitive information.
• Activities from apps that post notifications during screenshare where an OTP has been detected will be hidden. App content is hidden from the remote viewer when launched.
• Beyond Android's automatic identification of sensitive fields, developers can manually mark parts of their app as sensitive using setContentSensitivity, which is hidden from remote viewers during screenshare.
• Developers can choose to toggle the Disable screen share protections option under Developer Options to be exempted from the screenshare protections for demo or testing purposes. The default system screen recorder is exempted from these changes, since the recordings remain on-device.

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.

Before Android 15, if an app requested direct or offload audio playback while another app was playing audio and the resource limits were reached, the app would fail to open a new AudioTrack.

Beginning with Android 15, when an app requests direct or offload playback and the resource limits are reached, the system invalidates any currently open AudioTrack objects which prevent fulfilling the new track request.

(Direct and offload audio tracks are typically opened for playback of compressed audio formats. Common use-cases for playing direct audio include streaming encoded audio over HDMI to a TV. Offload tracks are typically used to play compressed audio on a mobile device with hardware DSP acceleration.)

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 force l'arrêt d'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.

Les chips de la barre d'état de la projection multimédia alertent les utilisateurs du partage d'écran, de la diffusion 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 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.