Changements de comportement : toutes les applications

La plate-forme Android 15 inclut des modifications de comportement susceptibles d'affecter votre application. Les modifications de comportement suivantes s'appliquent à toutes les applications lorsqu'elles s'exécutent sous Android 15 : quel que soit targetSdkVersion. Vous devez tester votre application, puis la modifier afin de les prendre en charge correctement, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui ne concernent 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

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

Pour prendre en charge le comportement souhaité, en plus des restrictions existantes, le système annule également tous les intents en attente lorsque l'application passe à l'état "Arrêtée" sur un appareil équipé d'Android 15. Lorsque les actions de l'utilisateur suppriment l'application de l'état d'arrêt, la diffusion ACTION_BOOT_COMPLETED est transmise à 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é arrêtée.

Compatibilité avec les tailles de page de 16 Ko

Historically, Android has only supported 4 KB memory page sizes, which has optimized system memory performance for the average amount of total memory that Android devices have typically had. Beginning with Android 15, AOSP supports devices that are configured to use a page size of 16 KB (16 KB devices). If your app uses any NDK libraries, either directly or indirectly through an SDK, then you will need to rebuild your app for it to work on these 16 KB devices.

As device manufacturers continue to build devices with larger amounts of physical memory (RAM), many of these devices will adopt 16 KB (and eventually greater) page sizes to optimize the device's performance. Adding support for 16 KB page size devices enables your app to run on these devices and helps your app benefit from the associated performance improvements. Without recompiling, apps might not work on 16 KB devices when they are productionized in future Android releases.

To help you add support for your app, we've provided guidance on how to check if your app is impacted, how to rebuild your app (if applicable), and how to test your app in a 16 KB environment using emulators (including Android 15 system images for the Android Emulator).

Avantages et gains de performances

Les appareils configurés avec des tailles 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:

  • Diminution du temps de lancement des applications lorsque la mémoire système est forte: 3,16 % de moins en moyenne, avec des améliorations plus importantes (jusqu'à 30%) pour certaines applications que nous avons testées
  • Réduction de la consommation d'énergie lors du lancement de l'application: réduction de 4,56% en moyenne
  • Lancement plus rapide des caméras: 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: amélioration de 1,5% (environ 0,8 seconde) en moyenne

Ces améliorations sont basées sur nos tests initiaux et 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 de 16 Ko. Si vous ne savez pas si votre application utilise du code natif, vous pouvez utiliser l'analyseur d'APK pour déterminer la présence de code natif.

Si votre application n'utilise que du code écrit en langage de programmation Java ou Kotlin, y compris toutes les bibliothèques ou tous les SDK, elle est déjà compatible avec les appareils de 16 Ko. Néanmoins, 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 son comportement.

Modifications requises pour que certaines applis prennent en charge 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.

Police d'emoji basée sur PNG supprimée

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.

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. Exiger des applications qu'elles répondent aux exigences de niveaux d'API modernes permet de renforcer la 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é. Tentative d'installation d'une application ciblant une API plus ancienne entraîne un échec de l'installation, avec un message semblable à celui-ci apparaissant 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 est inférieure à targetSdkVersion que 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

Appareil photo et contenus multimédias

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

La lecture directe et le déchargement de la piste audio invalident désormais les pistes audio précédemment ouvertes ou les déchargent lorsque les limites de ressources sont atteintes

Avant Android 15, si une application demandait la lecture directe ou la déchargeait alors qu'une autre application lisait du contenu 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 de déchargement et que les limites de ressources sont atteintes, le système invalide tous les objets AudioTrack actuellement ouverts, ce qui empêche de traiter la nouvelle requête de canal.

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

Expérience utilisateur et UI du système

Android 15 inclut certaines modifications visant à créer un environnement plus cohérent, une expérience utilisateur intuitive.

Animations pour la prévisualisation du Retour activées pour les applis qui l'ont activée

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.

Les widgets sont 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.

Abandons

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

L'abandon signifie que nous ne prenons plus en charge officiellement les API, mais qu'elles restent disponibles pour les développeurs. Pour en savoir plus sur les concernant les abandons de cette version d'Android, consultez la page relative aux abandons.