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).
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é
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:
- Your app must be assigned as the default launcher app for the device—that
is, possessing the
ROLE_HOME
role. - 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:
- 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. - The user must be able to hide and show the private space container.
- The user must be able to lock and unlock the private space container. Use
the
requestQuietModeEnabled()
method to lock (by passingtrue
) or unlock (by passingfalse
) the private space. 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
andACTION_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 includeEXTRA_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 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 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 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.
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 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 parFragmentManager
ou par le composant Navigation.
Widgets désactivés lorsque l'utilisateur force l'arrêt d'une application
If a user force-stops an app on a device running Android 15, the system temporarily disables all the app's widgets. The widgets are grayed out, and the user cannot interact with them. This is because beginning with Android 15, the system cancels all an app's pending intents when the app is force-stopped.
The system re-enables those widgets the next time the user launches the app.
For more information, see Changes to package stopped state.
Les chips de la barre d'état de la projection multimédia alertent les utilisateurs du partage, de la diffusion et de 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
Dans Android 15, les applications qui lancent une requête réseau en dehors d'un cycle de vie de processus valide reçoivent une exception. En règle générale, il s'agit d'un UnknownHostException
ou d'un autre IOException
associé à un socket. Les requêtes réseau qui se produisent en dehors d'un cycle de vie valide sont généralement dues au fait que les applications poursuivent une requête réseau sans le savoir, même après que l'application n'est plus active.
Pour atténuer cette exception, assurez-vous que vos requêtes réseau sont compatibles avec le cycle de vie et annulées lorsque vous quittez un cycle de vie de processus valide à l'aide de composants compatibles avec le cycle de vie. S'il est important que la requête réseau se produise même lorsque l'utilisateur quitte l'application, envisagez de planifier la requête réseau à l'aide de WorkManager ou de poursuivre une tâche visible par l'utilisateur à l'aide d'un service de premier plan.
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.