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

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

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.

Vérifier si votre application est concernée

If your app uses any native code, then you should rebuild your app with support for 16 KB devices. If you are unsure if your app uses native code, you can use the APK Analyzer to identify whether any native code is present and then check the alignment of ELF segments for any shared libraries that you find.

If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices. Nevertheless, we recommend that you test your app in a 16 KB environment to verify that there are no unexpected regressions in app behavior.

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 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 hors connexion invalide les pistes audio directes ou hors connexion 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 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.