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

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é

L'espace privé est une nouvelle fonctionnalité d'Android 15 qui permet aux utilisateurs de créer un espace distinct sur leur appareil où ils peuvent protéger les applications sensibles des regards indiscrets, sous une couche d'authentification supplémentaire. Parce que les applications l'espace privé ont une visibilité limitée, certains types d'applications doivent des étapes supplémentaires pour pouvoir voir les applications et interagir avec elles dans les applications espace.

Toutes les applications

Comme les applis de l'espace privé sont conservées dans un profil utilisateur distinct, aux profils professionnels, les applications ne doivent pas supposer qu'aucune des copies de son application qui ne figurent pas dans le profil principal sont dans le profil professionnel. Si votre application a 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 convient aux applications qui doivent exécuter des opérations critiques au premier plan ou en arrière-plan activités, comme l'affichage de notifications d'applications médicales. Toutefois, les applications ne peuvent pas déterminer si elles sont utilisées ou non dans l'espace privé, il ne peut donc pas afficher d'avertissement à l'utilisateur pour ce cas.

Pour toutes ces raisons, si vous développez une application médicale, examinez impacter votre application et prendre les mesures appropriées, par exemple en informant vos utilisateurs de ne pas Installez votre application dans l'espace privé, pour éviter de perturber l'application critique. des fonctionnalités.

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'ACCESS_HIDDEN_PROFILES autorisation normale 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 distinct pour les applications installées dans l'espace privé. Utilisez la méthode getLauncherUserInfo() pour déterminer quel type de profil utilisateur est 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éverrouillez (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 recevez cet intent implicite, déclarez un objet <intent-filter>. dans le fichier manifeste de votre application avec une valeur <category> de CATEGORY_APP_MARKET

Suppression de la police d'emoji basée sur le format PNG

L'ancien fichier de polices des emoji au format PNG (NotoColorEmojiLegacy.ttf) a été et ne contient que le fichier basé sur les vecteurs. À partir d'Android 13 (API niveau 33), le fichier de police des emoji utilisé par le moteur de rendu du système est passé de fichier PNG en fichier vectoriel. Le système a conservé l'ancien fichier de polices sous Android 13 et 14 pour des raisons de compatibilité. les applications disposant de leurs propres moteurs de rendu de polices peuvent continuer à utiliser l'ancien fichier de polices jusqu'à ce qu'ils puissent effectuer la mise à niveau.

Pour vérifier si votre application est concernée, recherchez dans le code de votre application des références aux NotoColorEmojiLegacy.ttf.

Vous pouvez choisir d'adapter votre application de plusieurs façons:

  • Utiliser les API de la plate-forme pour le rendu du texte Vous pouvez effectuer le rendu du texte sur un bitmap Canvas et utilisez-le pour obtenir une image brute si nécessaire.
  • Ajoutez la prise en charge des polices COLRv1 à votre application. Bibliothèque Open Source FreeType est compatible avec COLRv1 dans la version 2.13.0 et plus élevée.
  • En dernier recours, vous pouvez regrouper l'ancien fichier de police des emoji (NotoColorEmoji.ttf) dans votre APK. Toutefois, dans ce cas, votre application ne bénéficiera pas des dernières mises à jour des emoji. Pour En savoir plus, consultez le 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 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 interface utilisateur du système

Android 15 inclut des modifications visant à 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é

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

Widgets désactivés lorsque l'utilisateur arrête de forcer 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.

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

Screen projection exploits expose private user data such as financial information because users don't realize their device screen is being shared. Android has until now shown screen cast and screen record icons on the status bar, but the icons are small and often overlooked. Also, stopping screen sharing or recording is cumbersome because controls are in Quick Settings.

Android 15 introduces a new status bar chip that is large and prominent, which should alert users to any in-progress screen projection. Users can tap the chip to stop their screen from being shared, cast, or recorded.

To provide an intuitive user experience, screen projection now automatically stops when the device screen is locked.

Benefits and performance gains

The new media projection status bar chip enhances the user experience as follows:

  • Alerts users to in-progress screen sharing, casting, or recording
  • Enable users to terminate screen projection by tapping the chip

Automatic suspension of screen projection when the device screen is locked ensures user privacy.

Check if your app is impacted

By default, your app includes the new status bar chip and automatically suspends screen projection when the lock screen activates. Test your app by implementing the onStop() method of the MediaProjection.Callback. Verify that your app responds appropriately when the screen projection stops as a result of the user tapping the status bar chip or when the lock screen activates.

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 abandonnons officiellement les API obsolètes et orientons les développeurs vers d'autres API à utiliser à la place.

La mise à l'écart 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.