Changements de comportement: applications ciblant Android 15 ou version ultérieure

Comme les versions précédentes, Android 15 apporte des modifications de comportement pouvant affecter votre application. Les modifications de comportement suivantes s'appliquent exclusivement aux applications qui ciblent Android 15 ou version ultérieure. Si votre application cible Android 15 ou une version ultérieure, vous devez la modifier pour qu'elle prenne en charge ces comportements, le cas échéant.

Veillez également à consulter la liste des modifications de comportement qui affectent toutes les applications exécutées sur Android 15, quel que soit le targetSdkVersion de votre application.

Fonctionnalité de base

Android 15 modifie ou étend diverses fonctionnalités de base du système Android.

Modifications apportées aux services de premier plan

Nous apportons les modifications suivantes aux services de premier plan avec Android 15.

• Comportement de délai avant expiration du service de premier plan de synchronisation des données
• Nouveau type de service de premier plan de traitement multimédia
• Restrictions concernant les broadcast receivers BOOT_COMPLETED qui lancent des services de premier plan
• Restrictions concernant le démarrage des services de premier plan lorsqu'une application détient l'autorisation SYSTEM_ALERT_WINDOW

Comportement du délai avant expiration du service de premier plan de synchronisation des données

Android 15 introduces a new timeout behavior to dataSync for apps targeting Android 15 (API level 35) or higher. This behavior also applies to the new mediaProcessing foreground service type.

The system permits an app's dataSync services to run for a total of 6 hours in a 24-hour period, after which the system calls the running service's Service.onTimeout(int, int) method (introduced in Android 15). At this time, the service has a few seconds to call Service.stopSelf(). When Service.onTimeout() is called, the service is no longer considered a foreground service. If the service does not call Service.stopSelf(), the system throws an internal exception. The exception is logged in Logcat with the following message:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"

To avoid problems with this behavior change, you can do one or more of the following:

1. Have your service implement the new Service.onTimeout(int, int) method. When your app receives the callback, make sure to call stopSelf() within a few seconds. (If you don't stop the app right away, the system generates a failure.)
2. Make sure your app's dataSync services don't run for more than a total of 6 hours in any 24-hour period (unless the user interacts with the app, resetting the timer).
3. Only start dataSync foreground services as a result of direct user interaction; since your app is in the foreground when the service starts, your service has the full six hours after the app goes to the background.
4. Instead of using a dataSync foreground service, use an alternative API.

If your app's dataSync foreground services have run for 6 hours in the last 24, you cannot start another dataSync foreground service unless the user has brought your app to the foreground (which resets the timer). If you try to start another dataSync foreground service, the system throws ForegroundServiceStartNotAllowedException with an error message like "Time limit already exhausted for foreground service type dataSync".

Testing

To test your app's behavior, you can enable data sync timeouts even if your app is not targeting Android 15 (as long as the app is running on an Android 15 device). To enable timeouts, run the following adb command:

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

You can also adjust the timeout period, to make it easier to test how your app behaves when the limit is reached. To set a new timeout period, run the following adb command:

adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds

Nouveau type de service de premier plan de traitement multimédia

Android 15 introduces a new foreground service type, mediaProcessing. This service type is appropriate for operations like transcoding media files. For example, a media app might download an audio file and need to convert it to a different format before playing it. You can use a mediaProcessing foreground service to make sure the conversion continues even while the app is in the background.

The system permits an app's mediaProcessing services to run for a total of 6 hours in a 24-hour period, after which the system calls the running service's Service.onTimeout(int, int) method (introduced in Android 15). At this time, the service has a few seconds to call Service.stopSelf(). If the service does not call Service.stopSelf(), the system throws an internal exception. The exception is logged in Logcat with the following message:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"

To avoid having the exception, you can do one of the following:

1. Have your service implement the new Service.onTimeout(int, int) method. When your app receives the callback, make sure to call stopSelf() within a few seconds. (If you don't stop the app right away, the system generates a failure.)
2. Make sure your app's mediaProcessing services don't run for more than a total of 6 hours in any 24-hour period (unless the user interacts with the app, resetting the timer).
3. Only start mediaProcessing foreground services as a result of direct user interaction; since your app is in the foreground when the service starts, your service has the full six hours after the app goes to the background.
4. Instead of using a mediaProcessing foreground service, use an alternative API, like WorkManager.

If your app's mediaProcessing foreground services have run for 6 hours in the last 24, you cannot start another mediaProcessing foreground service unless the user has brought your app to the foreground (which resets the timer). If you try to start another mediaProcessing foreground service, the system throws ForegroundServiceStartNotAllowedException with an error message like "Time limit already exhausted for foreground service type mediaProcessing".

For more information about the mediaProcessing service type, see Changes to foreground service types for Android 15: Media processing.

Testing

To test your app's behavior, you can enable media processing timeouts even if your app is not targeting Android 15 (as long as the app is running on an Android 15 device). To enable timeouts, run the following adb command:

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

You can also adjust the timeout period, to make it easier to test how your app behaves when the limit is reached. To set a new timeout period, run the following adb command:

adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds

Restrictions concernant les broadcast receivers BOOT_COMPLETED qui lancent des services de premier plan

There are new restrictions on BOOT_COMPLETED broadcast receivers launching foreground services. BOOT_COMPLETED receivers are not allowed to launch the following types of foreground services:

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (this restriction has been in place for microphone since Android 14)

If a BOOT_COMPLETED receiver tries to launch any of those types of foreground services, the system throws ForegroundServiceStartNotAllowedException.

Testing

To test your app's behavior, you can enable these new restrictions even if your app is not targeting Android 15 (as long as the app is running on an Android 15 device). Run the following adb command:

adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name

To send a BOOT_COMPLETED broadcast without restarting the device, run the following adb command:

adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name

Restrictions concernant le démarrage des services de premier plan lorsqu'une application détient l'autorisation SYSTEM_ALERT_WINDOW

Auparavant, si une application détenait l'autorisation SYSTEM_ALERT_WINDOW, elle pouvait lancer un service de premier plan même si elle était actuellement en arrière-plan (comme indiqué dans la section Exclusions des restrictions de démarrage en arrière-plan).

Si une application cible Android 15, cette exemption est désormais plus restreinte. L'application doit désormais disposer de l'autorisation SYSTEM_ALERT_WINDOW et également d'une fenêtre de superposition visible. Autrement dit, l'application doit d'abord lancer une fenêtre TYPE_APPLICATION_OVERLAY et la fenêtre doit être visible avant de démarrer un service de premier plan.

Si votre application tente de démarrer un service de premier plan en arrière-plan sans répondre à ces nouvelles exigences (et qu'elle ne fait l'objet d'aucune autre exception), le système génère une exception ForegroundServiceStartNotAllowedException.

Si votre application déclare l'autorisation SYSTEM_ALERT_WINDOW et lance des services de premier plan en arrière-plan, elle peut être affectée par ce changement. Si votre application reçoit un ForegroundServiceStartNotAllowedException, vérifiez l'ordre des opérations de votre application et assurez-vous qu'elle dispose déjà d'une fenêtre de superposition active avant qu'elle ne tente de démarrer un service de premier plan en arrière-plan. Vous pouvez vérifier si votre fenêtre superposée est actuellement visible en appelant View.getWindowVisibility(), ou vous pouvez remplacer View.onWindowVisibilityChanged() pour recevoir une notification chaque fois que la visibilité change.

Tests

Pour tester le comportement de votre application, vous pouvez activer ces nouvelles restrictions même si votre application ne cible pas Android 15 (à condition qu'elle s'exécute sur un appareil Android 15). Pour activer ces nouvelles restrictions sur le démarrage des services de premier plan en arrière-plan, exécutez la commande adb suivante:

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

Modifications apportées au moment où les applications peuvent modifier l'état global du mode Ne pas déranger

Les applications qui ciblent Android 15 (niveau d'API 35) ou version ultérieure ne peuvent plus modifier l'état ou la règle globaux du mode Ne pas déranger sur un appareil (en modifiant les paramètres utilisateur ou en désactivant le mode Ne pas déranger). Au lieu de cela, les applications doivent fournir un AutomaticZenRule, que le système combine dans une stratégie globale avec le schéma existant de stratégie la plus restrictive. Les appels aux API existantes qui affectaient auparavant l'état global (setInterruptionFilter, setNotificationPolicy) entraînent la création ou la mise à jour d'un AutomaticZenRule implicite, qui est activé ou désactivé en fonction du cycle d'appel de ces appels d'API.

Notez que ce changement n'affecte le comportement observable que si l'application appelle setInterruptionFilter(INTERRUPTION_FILTER_ALL) et s'attend à ce que cet appel désactive un AutomaticZenRule précédemment activé par ses propriétaires.

Modifications apportées à l'API OpenJDK

Android 15 poursuit le travail d'actualisation des principales bibliothèques Android afin de s'adapter aux fonctionnalités des dernières versions d'OpenJDK LTS.

Certaines de ces modifications peuvent avoir un impact sur la compatibilité des applications ciblant Android 15 (niveau d'API 35) :

• Modifications apportées aux API de mise en forme des chaînes : la validation de l'index, des indicateurs, de la largeur et de la précision des arguments est désormais plus stricte lors de l'utilisation des API String.format() et Formatter.format() suivantes :

  • String.format(String, Object[])
  • String.format(Locale, String, Object[])
  • Formatter.format(String, Object[])
  • Formatter.format(Locale, String, Object[])

  Par exemple, l'exception suivante est générée lorsqu'un index d'argument de 0 est utilisé (%0 dans la chaîne de format) :

  IllegalFormatArgumentIndexException: Illegal format argument index = 0
  

  Dans ce cas, le problème peut être résolu en utilisant un index d'argument de 1 (%1 dans la chaîne de format).

• Modifications apportées au type de composant de Arrays.asList(...).toArray() : lorsque vous utilisez Arrays.asList(...).toArray(), le type de composant du tableau résultant est désormais Object, et non le type des éléments du tableau sous-jacent. Le code suivant génère donc une ClassCastException :

  String[] elements = (String[]) Arrays.asList("one", "two").toArray();
  

  Dans ce cas, pour conserver String comme type de composant dans le tableau résultant, vous pouvez utiliser Collection.toArray(Object[]) à la place :

  String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
  

• Modifications apportées à la gestion des codes de langue : lorsque vous utilisez l'API Locale, les codes de langue pour l'hébreu, le yiddish et l'indonésien ne sont plus convertis dans leur forme obsolète (hébreu : iw, yiddish : ji et indonésien : in). Lorsque vous spécifiez le code de langue pour l'un de ces paramètres régionaux, utilisez les codes de la norme ISO 639-1 à la place (hébreu : he, yiddish : yi et indonésien : id).

• Modifications apportées aux séquences d'entiers aléatoires : suite aux modifications apportées dans https://bugs.openjdk.org/browse/JDK-8301574, les méthodes Random.ints() suivantes renvoient désormais une séquence de nombres différente de celle des méthodes Random.nextInt() :

  • Random.ints(long)
  • Random.ints(long, int, int)
  • Random.ints(int, int)
  • Random.ints()

  En général, ce changement ne devrait pas entraîner de comportement cassant pour l'application, mais votre code ne doit pas s'attendre à ce que la séquence générée à partir des méthodes Random.ints() corresponde à Random.nextInt().

La nouvelle API SequencedCollection peut affecter la compatibilité de votre application après que vous avez mis à jour compileSdk dans la configuration de compilation de votre application pour utiliser Android 15 (niveau d'API 35) :

• Collision avec les fonctions d'extension MutableList.removeFirst() et MutableList.removeLast() dans kotlin-stdlib

  Le type List en Java est mappé sur le type MutableList en Kotlin. Étant donné que les API List.removeFirst() et List.removeLast() ont été introduites dans Android 15 (niveau d'API 35), le compilateur Kotlin résout les appels de fonction, par exemple list.removeFirst(), de manière statique vers les nouvelles API List au lieu des fonctions d'extension dans kotlin-stdlib.

  Si une application est recompilée avec compileSdk défini sur 35 et minSdk défini sur 34 ou une valeur inférieure, puis que l'application est exécutée sur Android 14 ou une version antérieure, une erreur d'exécution est générée :

  java.lang.NoSuchMethodError: No virtual method
  removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
  

  L'option lint NewApi existante dans le plug-in Android Gradle peut détecter ces nouvelles utilisations d'API.

  ./gradlew lint
  
  MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi]
        list.removeFirst()
  

  Pour corriger l'exception d'exécution et les erreurs Lint, les appels de fonction removeFirst() et removeLast() peuvent être remplacés par removeAt(0) et removeAt(list.lastIndex) respectivement en Kotlin. Si vous utilisez Android Studio Ladybug | 2024.1.3 ou version ultérieure, une option de correction rapide est également disponible pour ces erreurs.

  Envisagez de supprimer @SuppressLint("NewApi") et lintOptions { disable 'NewApi' } si l'option lint a été désactivée.

• Collision avec d'autres méthodes en Java

  De nouvelles méthodes ont été ajoutées aux types existants, par exemple List et Deque. Ces nouvelles méthodes peuvent ne pas être compatibles avec les méthodes portant le même nom et ayant les mêmes types d'arguments dans d'autres interfaces et classes. En cas de collision de signature de méthode avec incompatibilité, le compilateur javac génère une erreur au moment de la compilation. Exemple :

  Exemple d'erreur 1 :

  javac MyList.java
  
  MyList.java:135: error: removeLast() in MyList cannot implement removeLast() in List
    public void removeLast() {
                ^
    return type void is not compatible with Object
    where E is a type-variable:
      E extends Object declared in interface List
  

  Exemple d'erreur 2 :

  javac MyList.java
  
  MyList.java:7: error: types Deque<Object> and List<Object> are incompatible;
  public class MyList implements  List<Object>, Deque<Object> {
    both define reversed(), but with unrelated return types
  1 error
  

  Exemple d'erreur 3 :

  javac MyList.java
  
  MyList.java:43: error: types List<E#1> and MyInterface<E#2> are incompatible;
  public static class MyList implements List<Object>, MyInterface<Object> {
    class MyList inherits unrelated defaults for getFirst() from types List and MyInterface
    where E#1,E#2 are type-variables:
      E#1 extends Object declared in interface List
      E#2 extends Object declared in interface MyInterface
  1 error
  

  Pour corriger ces erreurs de compilation, la classe qui implémente ces interfaces doit remplacer la méthode par un type de retour compatible. Exemple :

  @Override
  public Object getFirst() {
      return List.super.getFirst();
  }
  

Sécurité

Android 15 inclut des modifications qui favorisent la sécurité du système pour aider à protéger les applications et les utilisateurs contre les applications malveillantes.

Versions TLS limitées

Android 15 restricts the usage of TLS versions 1.0 and 1.1. These versions had previously been deprecated in Android, but are now disallowed for apps targeting Android 15.

Lancement sécurisé des activités en arrière-plan

Android 15 protège les utilisateurs des applications malveillantes et leur donne plus de contrôle sur leurs appareils en ajoutant des modifications qui empêchent les applications malveillantes en arrière-plan le fait de placer d'autres applications au premier plan, d'élever leurs privilèges et d'abuser l'interaction de l'utilisateur. Le lancement des activités en arrière-plan est limité depuis Android 10 (niveau d'API 29).

Autres modifications

En plus de la restriction concernant la mise en correspondance des identifiants uniques, ces modifications inclus:

• Modification des créateurs PendingIntent pour bloquer les lancements d'activités en arrière-plan par défaut. Cela permet d'éviter que les applications ne créent accidentellement un PendingIntent qui pourrait être utilisé de manière abusive par des acteurs malveillants.
• Ne pas mettre une application au premier plan, sauf si l'expéditeur PendingIntent l'y autorise Cette modification vise à empêcher les applications malveillantes d'utiliser de manière abusive la possibilité de démarrer des activités en arrière-plan. Par défaut, les applications ne sont pas autorisé à faire passer la pile de tâches au premier plan, sauf si le créateur l'autorise droits de lancement de l'activité en arrière-plan ou si l'expéditeur a une activité en arrière-plan les droits de lancement.
• Contrôlez la façon dont l'activité principale d'une pile de tâches peut terminer sa tâche. Si l'activité de premier plan termine une tâche, Android revient à la tâche qui était la dernière active. De plus, si une activité non principale termine sa tâche, Android revient à l'écran d'accueil. Il ne bloque pas la fin de cette activité non principale.
• Empêcher le lancement d'activités arbitraires provenant d'autres applications dans la vôtre tâche. Ce changement empêche les applications malveillantes d'hameçonnage des utilisateurs en créant activités qui semblent provenir d'autres applications.
• Empêcher les fenêtres non visibles d'être prises en compte pour l'activité en arrière-plan lancements. Cela permet d'empêcher les applications malveillantes d'abuser des lancements d'activités en arrière-plan pour afficher des contenus indésirables ou malveillants aux utilisateurs.

Intents plus sûrs

Android 15 introduit de nouvelles mesures de sécurité facultatives pour rendre les intents plus sûrs et plus robustes. Ces changements visent à prévenir les failles potentielles et l'usage abusif des intents qui peuvent être exploités par des applications malveillantes. Il y a deux Principales améliorations apportées à la sécurité des intents dans Android 15:

• Correspondre aux filtres d'intent cibles : les intents qui ciblent des composants spécifiques doivent correspondre précisément aux spécifications des filtres d'intent de la cible. Si vous envoyez une pour lancer l'activité d'une autre application, le composant d'intent cible doit s'aligner sur les filtres d'intent déclarés de l'activité de réception.
• Les intents doivent comporter des actions : les intents sans action ne correspondent plus à aucun filtre d'intent. Cela signifie que les intents utilisés pour démarrer des activités ou des services doivent avoir une action clairement définie.

Pour vérifier comment votre application réagit à ces modifications, utilisez StrictMode dans votre application. Pour afficher les détails journaux sur les violations d'utilisation de Intent, ajoutez la méthode suivante:

fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        .detectUnsafeIntentLaunch()
        .build()
    )
}

public void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
            .detectUnsafeIntentLaunch()
            .build());
}

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.

Modifications des encarts de fenêtre

Android 15 apporte deux modifications liées aux marges intérieures de la fenêtre: l'affichage bord à bord est appliqué par défaut, et des modifications de configuration sont également apportées, comme la configuration par défaut des barres système.

Application bord à bord

Les applications sont de bord à bord par défaut sur les appareils exécutant Android 15 si elles ciblent Android 15 (niveau d'API 35).

Il s'agit d'un changement incompatible qui peut avoir un impact négatif sur l'UI de votre application. Ces modifications affectent les zones suivantes de l'UI :

• Barre de navigation avec poignée de geste
  • Transparence par défaut.
  • Le décalage inférieur est désactivé. Le contenu s'affiche donc derrière la barre de navigation système, sauf si des encarts sont appliqués.
  • setNavigationBarColor et R.attr#navigationBarColor sont obsolètes et n'ont aucune incidence sur la navigation par gestes.
  • setNavigationBarContrastEnforced et R.attr#navigationBarContrastEnforced n'ont toujours aucune incidence sur la navigation par gestes.
• Navigation à trois boutons
  • L'opacité est définie sur 80 % par défaut, et la couleur peut correspondre à celle de l'arrière-plan de la fenêtre.
  • Le décalage inférieur est désactivé. Le contenu s'affiche donc derrière la barre de navigation système, sauf si des encarts sont appliqués.
  • setNavigationBarColor et R.attr#navigationBarColor sont définis par défaut pour correspondre à l'arrière-plan de la fenêtre. Pour que cette valeur par défaut s'applique, l'arrière-plan de la fenêtre doit être un drawable de couleur. Cette API est obsolète, mais continue d'affecter la navigation à trois boutons.
  • setNavigationBarContrastEnforced et R.attr#navigationBarContrastEnforced sont définis sur "true" par défaut, ce qui ajoute un arrière-plan opaque à 80 % à la navigation à trois boutons.
• Barre d'état
  • Transparence par défaut.
  • Le décalage supérieur est désactivé. Le contenu s'affiche donc derrière la barre d'état, sauf si des encarts sont appliqués.
  • setStatusBarColor et R.attr#statusBarColor sont obsolètes et n'ont aucun effet sur Android 15.
  • setStatusBarContrastEnforced et R.attr#statusBarContrastEnforced sont obsolètes, mais ont toujours un effet sur Android 15.
• Encoche
  • Le layoutInDisplayCutoutMode des fenêtres non flottantes doit être LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. SHORT_EDGES, NEVER et DEFAULT sont interprétés comme ALWAYS afin que les utilisateurs ne voient pas de barre noire causée par l'encoche et que l'écran semble bord à bord.

L'exemple suivant montre une application avant et après le ciblage d'Android 15 (niveau d'API 35), et avant et après l'application des encarts. Cet exemple n'est pas exhaustif. L'affichage peut être différent sur Android Auto.

Éléments à vérifier si votre application est déjà bord à bord

Si votre application est déjà bord à bord et applique des encarts, vous ne serez pas affecté, sauf dans les scénarios suivants. Toutefois, même si vous pensez ne pas être concerné, nous vous recommandons de tester votre application.

• Vous avez une fenêtre non flottante, telle qu'un Activity qui utilise SHORT_EDGES, NEVER ou DEFAULT au lieu de LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. Si votre application plante au lancement, cela peut être dû à votre écran de démarrage. Vous pouvez mettre à niveau la dépendance core splashscreen vers 1.2.0-alpha01 ou version ultérieure, ou définir window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always.
• Il peut y avoir des écrans à faible trafic avec une UI masquée. Vérifiez que ces écrans moins visités ne comportent pas d'UI masquée. Voici quelques exemples d'écrans à faible trafic :
  • Écrans d'accueil ou de connexion
  • Pages de paramètres

Éléments à vérifier si votre application n'est pas encore bord à bord

Si votre application n'est pas déjà bord à bord, vous êtes très probablement concerné. En plus des scénarios pour les applications déjà bord à bord, vous devez tenir compte des éléments suivants :

• Si votre application utilise des composants Material 3 (androidx.compose.material3) dans Compose, tels que TopAppBar, BottomAppBar et NavigationBar, ces composants ne sont probablement pas concernés, car ils gèrent automatiquement les encarts.
• Si votre application utilise des composants Material 2 (androidx.compose.material) dans Compose, ces composants ne gèrent pas automatiquement les encarts. Cependant, vous pouvez accéder aux encarts et les appliquer manuellement. Dans androidx.compose.material 1.6.0 et versions ultérieures, utilisez le paramètre windowInsets pour appliquer manuellement les encarts pour BottomAppBar, TopAppBar, BottomNavigation et NavigationRail. De même, utilisez le paramètre contentWindowInsets pour Scaffold.
• Si votre application utilise des vues et des composants Material (com.google.android.material), la plupart des composants Material basés sur des vues, tels que BottomNavigationView, BottomAppBar, NavigationRailView ou NavigationView, gèrent les encarts et ne nécessitent aucun travail supplémentaire. Cependant, vous devez ajouter android:fitsSystemWindows="true" si vous utilisez AppBarLayout.
• Pour les composables personnalisés, appliquez les encarts manuellement en tant que marge intérieure. Si votre contenu se trouve dans un Scaffold, vous pouvez utiliser des encarts à l'aide des valeurs de marge intérieure Scaffold. Sinon, appliquez une marge intérieure à l'aide de l'une des WindowInsets.
• Si votre application utilise des vues et des conteneurs BottomSheet, SideSheet ou personnalisés, appliquez une marge intérieure à l'aide de ViewCompat.setOnApplyWindowInsetsListener. Pour RecyclerView, appliquez la marge intérieure en utilisant cet écouteur et ajoutez également clipToPadding="false".

Éléments à vérifier si votre application doit offrir une protection de l'arrière-plan personnalisée

Si votre application doit offrir une protection d'arrière-plan personnalisée à la navigation à trois boutons ou à la barre d'état, elle doit placer un composable ou une vue derrière la barre système à l'aide de WindowInsets.Type#tappableElement() pour obtenir la hauteur de la barre de navigation à trois boutons ou WindowInsets.Type#statusBars.

Autres ressources bord à bord

Consultez les guides Vues bord à bord et Compose bord à bord pour obtenir d'autres conseils sur l'application des encarts.

API obsolètes

Les API suivantes sont obsolètes, mais pas désactivées :

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor (pour la navigation à trois boutons, avec un canal alpha de 80 %)
• Window#isStatusBarContrastEnforced
• Window#setNavigationBarColor (pour la navigation à trois boutons, avec une opacité de 80 %)
• Window#setStatusBarContrastEnforced

Les API suivantes sont obsolètes et désactivées :

• R.attr#navigationBarColor (pour la navigation par gestes)
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#setDecorFitsSystemWindows
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#setNavigationBarColor (pour la navigation par gestes)
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor

Configuration stable

If your app targets Android 15 (API level 35) or higher, Configuration no longer excludes the system bars. If you use the screen size in the Configuration class for layout calculation, you should replace it with better alternatives like an appropriate ViewGroup, WindowInsets, or WindowMetricsCalculator depending on your need.

Configuration has been available since API 1. It is typically obtained from Activity.onConfigurationChanged. It provides information like window density, orientation, and sizes. One important characteristic about the window sizes returned from Configuration is that it previously excluded the system bars.

The configuration size is typically used for resource selection, such as /res/layout-h500dp, and this is still a valid use case. However, using it for layout calculation has always been discouraged. If you do so, you should move away from it now. You should replace the use of Configuration with something more suitable depending on your use case.

If you use it to calculate the layout, use an appropriate ViewGroup, such as CoordinatorLayout or ConstraintLayout. If you use it to determine the height of the system navbar, use WindowInsets. If you want to know the current size of your app window, use computeCurrentWindowMetrics.

The following list describes the fields affected by this change:

• Configuration.screenWidthDp and screenHeightDp sizes no longer exclude the system bars.
• Configuration.smallestScreenWidthDp is indirectly affected by changes to screenWidthDp and screenHeightDp.
• Configuration.orientation is indirectly affected by changes to screenWidthDp and screenHeightDp on close-to-square devices.
• Display.getSize(Point) is indirectly affected by the changes in Configuration. This was deprecated beginning in API level 30.
• Display.getMetrics() has already worked like this since API level 33.

L'attribut elegantTextHeight est défini sur "true" par défaut

Pour les applications ciblant Android 15 (niveau d'API 35), l'attribut TextView elegantTextHeight devient true par défaut, remplaçant la police compacte utilisée par défaut par certains scripts qui ont de grandes métriques verticales par une police beaucoup plus lisible. La police compacte a été introduite pour éviter la rupture des mises en page. Android 13 (niveau d'API 33) empêche de nombreuses ruptures en permettant à la mise en page du texte d'étirer la hauteur verticale à l'aide de l'attribut fallbackLineSpacing.

Dans Android 15, la police compacte reste dans le système. Votre application peut donc définir elegantTextHeight sur false pour obtenir le même comportement qu'auparavant, mais il est peu probable qu'elle soit compatible avec les versions à venir. Par conséquent, si votre application est compatible avec les scripts suivants: arabe, lao, birman, tamoul, gujarati, kannada, malayalam, oriya, télougou ou thaï, testez-la en définissant elegantTextHeight sur true.

La largeur de TextView change pour les formes de lettres complexes

Dans les versions précédentes d'Android, certaines polices cursives ou langues à forme complexe pouvaient dessiner les lettres dans la zone du caractère précédent ou suivant. Dans certains cas, ces lettres étaient tronquées au début ou à la fin. À partir d'Android 15, un TextView alloue une largeur pour dessiner suffisamment d'espace pour ces lettres et permet aux applications de demander des marges supplémentaires à gauche pour éviter le recadrage.

Étant donné que cette modification affecte la façon dont un TextView détermine la largeur, TextView alloue plus de largeur par défaut si l'application cible Android 15 (niveau d'API 35) ou version ultérieure. Vous pouvez activer ou désactiver ce comportement en appelant l'API setUseBoundsForWidth sur TextView.

Étant donné que l'ajout d'une marge intérieure à gauche peut entraîner un désalignement des mises en page existantes, la marge intérieure n'est pas ajoutée par défaut, même pour les applications qui ciblent Android 15 ou version ultérieure. Toutefois, vous pouvez ajouter une marge intérieure supplémentaire pour empêcher le rognage en appelant setShiftDrawingOffsetForStartOverhang.

Les exemples suivants montrent comment ces modifications peuvent améliorer la mise en page du texte pour certaines polices et langues.

Mise en page standard pour le texte en anglais dans une police cursive. Certaines lettres sont coupées. Voici le code XML correspondant:

<TextView
    android:fontFamily="cursive"
    android:text="java" />

Mise en page pour le même texte en anglais avec une largeur et une marge intérieure supplémentaires. Voici le code XML correspondant:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

Mise en page standard pour le texte thaïlandais. Certaines lettres sont coupées. Voici le code XML correspondant:

<TextView
    android:text="คอมพิวเตอร์" />

Mise en page du même texte thaïlandais avec une largeur et une marge intérieure supplémentaires. Voici le code XML correspondant:

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

Hauteur de ligne par défaut tenant compte des paramètres régionaux pour EditText

In previous versions of Android, the text layout stretched the height of the text to meet the line height of the font that matched the current locale. For example, if the content was in Japanese, because the line height of the Japanese font is slightly larger than the one of a Latin font, the height of the text became slightly larger. However, despite these differences in line heights, the EditText element was sized uniformly, regardless of the locale being used, as illustrated in the following image:

For apps targeting Android 15 (API level 35), a minimum line height is now reserved for EditText to match the reference font for the specified Locale, as shown in the following image:

If needed, your app can restore the previous behavior by specifying the useLocalePreferredLineHeightForMinimum attribute to false, and your app can set custom minimum vertical metrics using the setMinimumFontMetrics API in Kotlin and Java.

Appareil photo et médias

Android 15 apporte les modifications suivantes au comportement de l'appareil photo et des contenus multimédias pour les applications qui ciblent Android 15 ou version ultérieure.

Restrictions concernant la demande de priorité audio

Les applications qui ciblent Android 15 (niveau d'API 35) doivent être l'application principale ou exécuter un service de premier plan pour demander la priorité audio. Si une application tente de demander la sélection alors qu'elle ne remplit pas l'une de ces conditions, l'appel renvoie AUDIOFOCUS_REQUEST_FAILED.

Pour en savoir plus sur la mise au point audio, consultez Gérer la mise au point audio.

Mise à jour des restrictions non SDK

Android 15 inclut des listes à jour d'interfaces non SDK limitées grâce à la collaboration avec les développeurs Android et aux derniers tests internes. Dans la mesure du possible, nous nous assurons que des alternatives publiques sont disponibles avant de limiter les interfaces non SDK.

Si votre application ne cible pas Android 15, certaines de ces modifications ne vous affecteront peut-être pas immédiatement. Cependant, bien que votre application puisse accéder à certaines interfaces non SDK en fonction de son niveau d'API cible, l'utilisation d'un champ ou d'une méthode non SDK présente toujours un risque élevé d'endommager votre application.

Si vous n'êtes pas sûr que votre application utilise des interfaces non SDK, vous pouvez tester votre application pour le savoir. Si votre application repose sur des interfaces non SDK, vous devriez commencer à planifier une migration vers des alternatives SDK. Nous comprenons néanmoins que certaines applications ont des cas d'utilisation valides pour utiliser des interfaces non SDK. Si vous ne trouvez pas d'alternative à l'utilisation d'une interface non SDK pour une fonctionnalité de votre application, vous devriez demander une nouvelle API publique.

Pour en savoir plus sur les modifications apportées à cette version d'Android, consultez Mises à jour des restrictions d'interface non SDK dans Android 15. Pour en savoir plus sur les interfaces non SDK en général, consultez la section Restrictions concernant les interfaces non SDK.