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:
- Have your service implement the new
Service.onTimeout(int, int)
method. When your app receives the callback, make sure to callstopSelf()
within a few seconds. (If you don't stop the app right away, the system generates a failure.) - 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). - 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. - 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 introduit un nouveau type de service de premier plan, mediaProcessing
. Ce type de service convient aux opérations telles que le transcodage de fichiers multimédias. Par exemple, une application multimédia peut télécharger un fichier audio et avoir besoin de le convertir dans un autre format avant de le lire. Vous pouvez utiliser un service de premier plan mediaProcessing
pour vous assurer que la conversion se poursuit même lorsque l'application est en arrière-plan.
Le système autorise les services mediaProcessing
d'une application à s'exécuter pendant un total de six heures sur une période de 24 heures, après quoi le système appelle la méthode Service.onTimeout(int, int)
du service en cours d'exécution (introduite dans Android 15). À ce stade, le service dispose de quelques secondes pour appeler Service.stopSelf()
. Si le service n'appelle pas Service.stopSelf()
, le système génère une exception interne. L'exception est enregistrée dans Logcat avec le message suivant:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"
Pour éviter cette exception, vous pouvez effectuer l'une des opérations suivantes:
- Demandez à votre service d'implémenter la nouvelle méthode
Service.onTimeout(int, int)
. Lorsque votre application reçoit le rappel, veillez à appelerstopSelf()
dans un délai de quelques secondes. (Si vous n'arrêtez pas immédiatement l'application, le système génère une erreur.) - Assurez-vous que les services
mediaProcessing
de votre application ne s'exécutent pas pendant plus de six heures au total sur une période de 24 heures (sauf si l'utilisateur interagit avec l'application, ce qui réinitialise le minuteur). - Ne démarrez les services de premier plan
mediaProcessing
qu'en raison d'une interaction directe avec l'utilisateur. Étant donné que votre application est au premier plan au démarrage du service, votre service dispose de six heures complètes après le passage de l'application en arrière-plan. - Au lieu d'utiliser un service de premier plan
mediaProcessing
, utilisez une API alternative, comme WorkManager.
Si les services de premier plan mediaProcessing
de votre application ont fonctionné pendant six heures au cours des dernières 24 heures, vous ne pouvez pas démarrer un autre service de premier plan mediaProcessing
sauf si l'utilisateur a mis votre application au premier plan (ce qui réinitialise le minuteur). Si vous essayez de démarrer un autre service de premier plan mediaProcessing
, le système génère ForegroundServiceStartNotAllowedException
avec un message d'erreur tel que "Le délai est déjà écoulé pour le type de service de premier plan mediaProcessing".
Pour en savoir plus sur le type de service mediaProcessing
, consultez la section Modifications apportées aux types de services de premier plan pour Android 15: traitement multimédia.
Tests
Pour tester le comportement de votre application, vous pouvez activer les délais avant expiration du traitement multimédia même si votre application ne cible pas Android 15 (à condition qu'elle s'exécute sur un appareil Android 15). Pour activer les délais avant expiration, exécutez la commande adb
suivante:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
Vous pouvez également ajuster la période de délai avant expiration pour tester plus facilement le comportement de votre application lorsque la limite est atteinte. Pour définir un nouveau délai avant expiration, exécutez la commande adb
suivante:
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
De nouvelles restrictions s'appliquent au lancement de BOOT_COMPLETED
broadcast receivers
services de premier plan. Les broadcast receivers BOOT_COMPLETED
ne sont pas autorisés à lancer les types de services de premier plan suivants :
dataSync
camera
mediaPlayback
phoneCall
mediaProjection
microphone
(cette restriction est en place pour le pays suivant :microphone
) Android 14)
Si un récepteur BOOT_COMPLETED
tente de lancer l'un de ces types de premier plan
le système génère ForegroundServiceStartNotAllowedException
.
Tests
Pour tester le comportement de votre application, vous pouvez activer ces nouvelles restrictions même si votre
L'application ne cible pas Android 15 (tant qu'elle est exécutée sur un appareil équipé d'Android 15).
appareil). Exécutez la commande adb
suivante:
adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name
Pour envoyer une diffusion BOOT_COMPLETED
sans redémarrer l'appareil :
exécutez la commande adb
suivante:
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
Previously, if an app held the SYSTEM_ALERT_WINDOW
permission, it could launch
a foreground service even if the app was currently in the background (as
discussed in exemptions from background start restrictions).
If an app targets Android 15, this exemption is now narrower. The app now needs
to have the SYSTEM_ALERT_WINDOW
permission and also have a visible overlay
window. That is, the app needs to first launch a
TYPE_APPLICATION_OVERLAY
window and the window
needs to be visible before you start a foreground service.
If your app attempts to start a foreground service from the background without
meeting these new requirements (and it does not have some other exemption), the
system throws ForegroundServiceStartNotAllowedException
.
If your app declares the SYSTEM_ALERT_WINDOW
permission
and launches foreground services from the background, it may be affected by this
change. If your app gets a ForegroundServiceStartNotAllowedException
, check
your app's order of operations and make sure your app already has an active
overlay window before it attempts to start a foreground service from the
background. You can check if your overlay window is currently visible
by calling View.getWindowVisibility()
, or you
can override View.onWindowVisibilityChanged()
to get notified whenever the visibility changes.
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). To enable these new restrictions on starting foreground services
from the background, run the following adb
command:
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
Apps that target Android 15 (API level 35) and higher can no longer change the
global state or policy of Do Not Disturb (DND) on a device (either by modifying
user settings, or turning off DND mode). Instead, apps must contribute an
AutomaticZenRule
, which the system combines into a global policy with the
existing most-restrictive-policy-wins scheme. Calls to existing APIs that
previously affected global state (setInterruptionFilter
,
setNotificationPolicy
) result in the creation or update of an implicit
AutomaticZenRule
, which is toggled on and off depending on the call-cycle of
those API calls.
Note that this change only affects observable behavior if the app is calling
setInterruptionFilter(INTERRUPTION_FILTER_ALL)
and expects that call to
deactivate an AutomaticZenRule
that was previously activated by their owners.
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()
etFormatter.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 utilisezArrays.asList(...).toArray()
, le type de composant du tableau résultant est désormaisObject
, et non le type des éléments du tableau sous-jacent. Le code suivant génère donc uneClassCastException
: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 utiliserCollection.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 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éthodesRandom.nextInt()
: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()
etMutableList.removeLast()
danskotlin-stdlib
Le type
List
en Java est mappé sur le typeMutableList
en Kotlin. Étant donné que les APIList.removeFirst()
etList.removeLast()
ont été introduites dans Android 15 (niveau d'API 35), le compilateur Kotlin résout les appels de fonction, par exemplelist.removeFirst()
, de manière statique vers les nouvelles APIList
au lieu des fonctions d'extension danskotlin-stdlib
.Si une application est recompilée avec
compileSdk
défini sur35
etminSdk
défini sur34
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 de l'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()
etremoveLast()
peuvent être remplacés parremoveAt(0)
etremoveAt(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")
etlintOptions { 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
etDeque
. Ces nouvelles méthodes peuvent ne pas être compatibles avec les méthodes portant le même nom et les mêmes types d'arguments dans d'autres interfaces et classes. En cas de collision de signature de méthode avec incompatibilité, le compilateurjavac
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 ListExemple 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 errorExemple 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 errorPour 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 limite l'utilisation des versions 1.0 et 1.1 de TLS. Ces versions étaient auparavant obsolètes dans Android, mais elles ne sont désormais plus autorisées pour les applications ciblant 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 unPendingIntent
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:
Kotlin
fun onCreate() { StrictMode.setVmPolicy(VmPolicy.Builder() .detectUnsafeIntentLaunch() .build() ) }
Java
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
There are two changes related to window insets in Android 15: edge-to-edge is enforced by default, and there are also configuration changes, such as the default configuration of system bars.
Edge-to-edge enforcement
Apps are edge-to-edge by default on devices running Android 15 if the app is targeting Android 15 (API level 35).

This is a breaking change that might negatively impact your app's UI. The changes affect the following UI areas:
- Gesture handle navigation bar
- Transparent by default.
- Bottom offset is disabled so content draws behind the system navigation bar unless insets are applied.
setNavigationBarColor
andR.attr#navigationBarColor
are deprecated and don't affect gesture navigation.setNavigationBarContrastEnforced
andR.attr#navigationBarContrastEnforced
continue to have no effect on gesture navigation.
- 3-button navigation
- Opacity set to 80% by default, with color possibly matching the window background.
- Bottom offset disabled so content draws behind the system navigation bar unless insets are applied.
setNavigationBarColor
andR.attr#navigationBarColor
are set to match the window background by default. The window background must be a color drawable for this default to apply. This API is deprecated but continues to affect 3-button navigation.setNavigationBarContrastEnforced
andR.attr#navigationBarContrastEnforced
is true by default, which adds an 80% opaque background across 3-button navigation.
- Status bar
- Transparent by default.
- The top offset is disabled so content draws behind the status bar unless insets are applied.
setStatusBarColor
andR.attr#statusBarColor
are deprecated and have no effect on Android 15.setStatusBarContrastEnforced
andR.attr#statusBarContrastEnforced
are deprecated but still have an effect on Android 15.
- Display cutout
layoutInDisplayCutoutMode
of non-floating windows must beLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
.SHORT_EDGES
,NEVER
, andDEFAULT
are interpreted asALWAYS
so that users don't see a black bar caused by the display cutout and appear edge-to-edge.
The following example shows an app before and after targeting Android 15 (API level 35), and before and after applying insets.



What to check if your app is already edge-to-edge
If your app is already edge-to-edge and applies insets, you are mostly unimpacted, except in the following scenarios. However, even if you think you aren't impacted, we recommend you test your app.
- You have a non-floating window, such as an
Activity
that usesSHORT_EDGES
,NEVER
orDEFAULT
instead ofLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
. If your app crashes on launch, this might be due to your splashscreen. You can either upgrade the core splashscreen dependency to 1.2.0-alpha01 or later or setwindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
. - There might be lower-traffic screens with occluded UI. Verify these
less-visited screens don't have occluded UI. Lower-traffic screens include:
- Onboarding or sign-in screens
- Settings pages
What to check if your app is not already edge-to-edge
If your app is not already edge-to-edge, you are most likely impacted. In addition to the scenarios for apps that are already edge-to-edge, you should consider the following:
- If your app uses Material 3 Components (
androidx.compose.material3
) in compose, such asTopAppBar
,BottomAppBar
, andNavigationBar
, these components are likely not impacted because they automatically handle insets. - If your app is using Material 2 Components (
androidx.compose.material
) in Compose, these components don't automatically handle insets. However, you can get access to the insets and apply them manually. In androidx.compose.material 1.6.0 and later, use thewindowInsets
parameter to apply the insets manually forBottomAppBar
,TopAppBar
,BottomNavigation
, andNavigationRail
. Likewise, use thecontentWindowInsets
parameter forScaffold
. - If your app uses views and Material Components
(
com.google.android.material
), most views-based Material Components such asBottomNavigationView
,BottomAppBar
,NavigationRailView
, orNavigationView
, handle insets and require no additional work. However, you need to addandroid:fitsSystemWindows="true"
if usingAppBarLayout
. - For custom composables, apply the insets manually as padding. If your
content is within a
Scaffold
, you can consume insets using theScaffold
padding values. Otherwise, apply padding using one of theWindowInsets
. - If your app is using views and
BottomSheet
,SideSheet
or custom containers, apply padding usingViewCompat.setOnApplyWindowInsetsListener
. ForRecyclerView
, apply padding using this listener and also addclipToPadding="false"
.
What to check if your app must offer custom background protection
If your app must offer custom background protection to 3-button navigation or
the status bar, your app should place a composable or view behind the system bar
using WindowInsets.Type#tappableElement()
to get the 3-button
navigation bar height or WindowInsets.Type#statusBars
.
Additional edge-to-edge resources
See the Edge to Edge Views and Edge to Edge Compose guides for additional considerations on applying insets.
Deprecated APIs
The following APIs are deprecated but not disabled:
R.attr#enforceStatusBarContrast
R.attr#navigationBarColor
(for 3 button navigation, with 80% alpha)Window#isStatusBarContrastEnforced
Window#setNavigationBarColor
(for 3 button navigation, with 80% alpha)Window#setStatusBarContrastEnforced
The following APIs are deprecated and disabled:
R.attr#navigationBarColor
(for gesture navigation)R.attr#navigationBarDividerColor
R.attr#statusBarColor
Window#setDecorFitsSystemWindows
Window#getNavigationBarColor
Window#getNavigationBarDividerColor
Window#getStatusBarColor
Window#setNavigationBarColor
(for gesture navigation)Window#setNavigationBarDividerColor
Window#setStatusBarColor
Stable configuration
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
andscreenHeightDp
sizes no longer exclude the system bars.Configuration.smallestScreenWidthDp
is indirectly affected by changes toscreenWidthDp
andscreenHeightDp
.Configuration.orientation
is indirectly affected by changes toscreenWidthDp
andscreenHeightDp
on close-to-square devices.Display.getSize(Point)
is indirectly affected by the changes inConfiguration
. 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
.

elegantTextHeight
pour les applications ciblant Android 14 (niveau d'API 34) ou version antérieure.
elegantTextHeight
pour les applications ciblant Android 15.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.

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

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

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

<TextView android:text="คอมพิวเตอร์" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
Hauteur de ligne par défaut tenant compte des paramètres régionaux pour EditText
Dans les versions précédentes d'Android, la mise en page du texte étirait la hauteur du texte pour qu'elle corresponde à la hauteur de ligne de la police correspondant à la langue actuelle. Par exemple, si le contenu était en japonais, la hauteur de ligne de la police japonaise étant légèrement supérieure à celle d'une police latine, la hauteur du texte était légèrement plus élevée. Toutefois, malgré ces différences de hauteur de ligne, l'élément EditText
était redimensionné de manière uniforme, quelle que soit la langue utilisée, comme illustré dans l'image suivante:

EditText
pouvant contenir du texte en anglais (en), en japonais (ja) et en birman (my). La hauteur de l'EditText
est la même, même si ces langues ont des hauteurs de ligne différentes.Pour les applications ciblant Android 15 (niveau d'API 35), une hauteur de ligne minimale est désormais réservée à EditText
pour correspondre à la police de référence du paramètre régional spécifié, comme illustré dans l'image suivante:

EditText
pouvant contenir du texte en anglais (en), en japonais (ja) et en birman (my). La hauteur de EditText
inclut désormais un espace pour s'adapter à la hauteur de ligne par défaut des polices de ces langues.Si nécessaire, votre application peut restaurer le comportement précédent en spécifiant l'attribut useLocalePreferredLineHeightForMinimum
sur false
. Elle peut également définir des métriques verticales minimales personnalisées à l'aide de l'API setMinimumFontMetrics
en Kotlin et en 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
Apps that target Android 15 (API level 35) must be the top app or running a
foreground service in order to request audio focus. If an app
attempts to request focus when it does not meet one of these requirements, the
call returns AUDIOFOCUS_REQUEST_FAILED
.
You can learn more about audio focus at Manage audio focus.
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.