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, indépendamment de targetSdkVersion. Vous devez tester votre application, puis la modifier si nécessaire pour 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 de 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 des tailles de page de 16 Ko

À l'origine, Android n'acceptait que les tailles de page de mémoire de 4 Ko, ce qui permet d'optimiser les performances de la mémoire système pour la quantité moyenne de mémoire totale dont disposent généralement les appareils Android. À partir d'Android 15, Android est compatible avec les appareils configurés pour utiliser une taille de page de 16 Ko (appareils de 16 Ko).

À mesure que les fabricants d'appareils continuent de créer des appareils avec de plus grandes quantités de mémoire physique (RAM), un grand nombre de ces appareils seront probablement configurés avec des tailles de page de 16 Ko (voire plus) afin d'optimiser leurs performances. L'ajout de la compatibilité avec les appareils 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. Pour vous aider, nous avons détaillé comment vérifier si votre application est concernée, recréer votre application (le cas échéant) et tester votre application dans un environnement de 16 Ko à l'aide d'émulateurs et d'appareils physiques.

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 applications prennent en charge 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 dans lequel ils peuvent empêcher les applications sensibles des regards indiscrets grâce à une couche d'authentification supplémentaire. Étant donné que les applications de l'espace privé ont une visibilité limitée, certains types d'applications doivent prendre des mesures supplémentaires pour pouvoir afficher les applications dans l'espace privé d'un utilisateur et interagir avec elles.

Toutes les applications

Étant donné que les applications de l'espace privé sont conservées dans un profil utilisateur distinct, comme les profils professionnels, les applications 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 utilise une logique liée aux applications de profil professionnel qui fait cette hypothèse, vous devez ajuster cette logique.

Lanceurs d'applications

Si vous développez une application de lanceur, 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 pour l'appareil, c'est-à-dire qu'elle doit disposer du rôle ROLE_HOME.
  2. Votre application doit déclarer l'autorisation normale ACCESS_HIDDEN_PROFILES dans son fichier manifeste.

Les applications de lancement qui déclarent l'autorisation ACCESS_HIDDEN_PROFILES doivent gérer les cas d'utilisation suivants concernant les espaces privés:

  1. Votre application doit disposer d'un conteneur de lanceur distinct pour les applications installées dans l'espace privé.
  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é.
  4. Lorsque l'application est verrouillée, aucune application du conteneur d'espace privé ne doit être visible via des mécanismes tels que la recherche.

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

L'espace privé comprend un bouton "Install Apps" (Installer des applications) qui lance un intent 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.

Augmentation de la version minimale du SDK cible de 23 à 24

Android 15 s'appuie sur les modifications apportées dans Android 14 et étend cette sécurité. Sous Android 15, les applications dont la targetSdkVersion est inférieure à 24 ne peuvent pas être installées. Exiger que les applications respectent les niveaux d'API modernes permet de renforcer la sécurité et la confidentialité.

Les logiciels malveillants ciblent souvent des niveaux d'API inférieurs afin de contourner les mesures de sécurité et de protection de la confidentialité introduites dans les versions plus récentes 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). Cette modification d'Android 15 rend plus difficile pour les logiciels malveillants de contourner les améliorations de sécurité et de confidentialité. Si vous tentez d'installer une application ciblant un niveau d'API inférieur, l'installation échouera et un message semblable au suivant s'affichera 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, toutes 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

Appareil photo et contenu multimédia

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 désormais les pistes audio précédemment ouvertes ou déchargées 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 des modifications destinées à créer une expérience utilisateur plus cohérente et intuitive.

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

À partir d'Android 15, l'option pour les développeurs pour les animations de prévisualisation du Retour a été supprimée. Les animations système telles que le retour à l'écran d'accueil, le multitâche et l'activité multi-activité s'affichent désormais pour les applications qui ont activé la prévisualisation du geste Retour soit entièrement, soit au niveau de l'activité. Si votre application est concernée, procédez comme suit:

  • Assurez-vous que votre application a bien été migrée pour utiliser la prévisualisation du geste Retour.
  • Assurez-vous que vos transitions de fragment fonctionnent avec la navigation avec prévisualisation du Retour.
  • Abandonnez les transitions d'animation et de framework, et utilisez plutôt les transitions d'animateur et d'androidx.
  • Éloignez-vous des piles "Retour" que FragmentManager n'a pas connaissance. Utilisez plutôt des piles "Retour" gérées par FragmentManager ou par le composant Navigation.

Les widgets sont désactivés lorsque l'utilisateur force l'arrêt d'une application.

Si un utilisateur force l'arrêt d'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 lorsque celle-ci est arrêtée de force.

Le système les réactivera la prochaine fois que l'utilisateur lancera l'application.

Pour en savoir plus, consultez Modifications de l'état d'arrêt d'un package.

Abandons

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

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