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

Comme dans les versions précédentes, Android 15 apporte des modifications de comportement susceptibles d'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

We are making the following changes to foreground services with Android 15.

• New media processing foreground service type
• Restrictions on BOOT_COMPLETED broadcast receivers launching foreground services

Data sync foreground service timeout behavior

Android 15 introduces a new timeout behavior to dataSync for apps targeting Android 15 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(), a failure will occur with this error message: "A foreground service of <fgs_type> did not stop within its timeout: <component_name>". In Beta 2, the failure message is shown as an ANR, but in a future Beta release, this failure message will throw a custom exception.

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

New media processing foreground service type

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(), a failure will occur with this error message: "A foreground service of <fgs_type> did not stop within its timeout: <component_name>". In Beta 2, the failure message is shown as an ANR, but in a future Beta release, this failure message will throw a custom exception.

To avoid getting an ANR, 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.

Restrictions on BOOT_COMPLETED broadcast receivers launching foreground services

De nouvelles restrictions s'appliquent aux broadcast receivers BOOT_COMPLETED qui lancent les services de premier plan. Les récepteurs BOOT_COMPLETED ne sont pas autorisés à lancer les types de services de premier plan suivants:

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (cette restriction s'applique à microphone depuis Android 14)

Si un récepteur BOOT_COMPLETED tente de lancer l'un de ces types de services de premier plan, le système génère une erreur ForegroundServiceStartNotAllowedException.

Restrictions on starting foreground services while an app holds the SYSTEM_ALERT_WINDOW permission

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

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

Si votre application tente de démarrer un service de premier plan à partir de l'arrière-plan sans remplir ces nouvelles exigences (et qu'elle ne dispose pas d'une 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 cette modification. Si votre application reçoit un ForegroundServiceStartNotAllowedException, vérifiez l'ordre des opérations et assurez-vous qu'elle dispose déjà d'une fenêtre de superposition active avant de tenter de démarrer un service de premier plan en arrière-plan. Vous pouvez vérifier si votre fenêtre de superposition est actuellement visible en appelant View.getWindowVisibility(). Vous pouvez également ignorer View.onWindowVisibilityChanged() afin d'être averti chaque fois que la visibilité change.

Modification des conditions dans lesquelles les applications peuvent modifier l'état général du mode Ne pas déranger

Apps that target Android 15 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 d'OpenJDK 17

Android 15 poursuit le travail d'actualisation des bibliothèques principales d'Android pour s'aligner sur les fonctionnalités des dernières versions d'OpenJDK LTS.

L'un des changements suivants peut affecter la compatibilité des applications ciblant Android 15:

• Modifications apportées aux API de mise en forme de chaînes: la validation de l'index d'argument, des indicateurs, de la largeur et de la précision 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 indice d'argument de 1 (%1 dans la chaîne de format).

• Modifications du type de composant de Arrays.asList(...).toArray(): lorsque vous utilisez Arrays.asList(...).toArray(), le type de composant du tableau obtenu est désormais Object, et non le type des éléments du tableau sous-jacent. Par conséquent, le code suivant génère une exception ClassCastException:

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

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

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

• Modification du traitement du code de langue: lorsque vous utilisez l'API Locale, les codes des langues pour l'hébreu, le yiddish et l'indonésien ne sont plus convertis dans leurs formes obsolètes (hébreu: iw, yiddish: ji et indonésien: in). Lorsque vous spécifiez le code de langue pour l'une de ces langues, utilisez plutôt les codes ISO 639-1 (hébreu: he, indonésien: yi0 et yiddish) :id

• Modifications apportées aux séquences d'entrée 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 règle générale, cette modification ne devrait pas entraîner de dysfonctionnement de 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().

Sécurité

Android 15 inclut des modifications qui renforcent la sécurité du système afin de protéger les applications et les utilisateurs contre les applications malveillantes.

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 d'arrière-plan de mettre d'autres applications au premier plan, d'élever leurs privilèges et d'abuser des interactions utilisateur. Le lancement de l'activité en arrière-plan est limité depuis Android 10 (niveau d'API 29).

Empêcher les applications qui ne correspondent pas à l'UID principal de la pile de lancer des activités

Des applications malveillantes peuvent lancer l'activité d'une autre application dans la même tâche, puis se superposer, ce qui donne l'illusion d'être cette application. Cette attaque de "détournement de tâches" contourne les restrictions actuelles de lancement en arrière-plan, car elle se déroule toutes dans la même tâche visible. Pour atténuer ce risque, Android 15 ajoute un indicateur qui empêche les applications qui ne correspondent pas à l'UID principal de la pile de lancer des activités. Pour activer toutes les activités de votre application, mettez à jour l'attribut allowCrossUidActivitySwitchFromBelow dans le fichier AndroidManifest.xml de votre application:

<application android:allowCrossUidActivitySwitchFromBelow="false" >

Les nouvelles mesures de sécurité sont actives si toutes les conditions suivantes sont remplies:

• L'application qui effectue le lancement cible Android 15.
• L'application située au-dessus de la pile de tâches cible Android 15.
• Les nouvelles protections sont activées pour toute activité visible.

Si les mesures de sécurité sont activées, les applications peuvent revenir à l'accueil plutôt que la dernière application visible si elles terminent leur propre tâche.

Autres modifications

En plus de la restriction de la correspondance UID, les modifications suivantes sont également incluses:

• Modifiez les créateurs PendingIntent pour qu'ils bloquent le lancement des activités en arrière-plan par défaut. Cela empêche les applications de créer accidentellement un PendingIntent susceptible d'être utilisé de manière abusive par des acteurs malveillants.
• N'affichez une application au premier plan que si l'expéditeur PendingIntent le permet. Ce changement vise à empêcher les applications malveillantes d'abuser de la possibilité de démarrer des activités en arrière-plan. Par défaut, les applications ne sont pas autorisées à placer la pile de tâches au premier plan, sauf si le créateur autorise les droits de lancement des activités en arrière-plan ou si l'expéditeur dispose de droits de lancement des activités en arrière-plan.
• Contrôlez la manière dont l'activité principale d'une pile de tâches peut terminer sa tâche. Si l'activité principale termine une tâche, Android revient à la dernière tâche 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é.
• Empêchez le lancement d'activités arbitraires provenant d'autres applications dans votre propre tâche. Ce changement empêche les applications malveillantes d'attaquer les utilisateurs d'hameçonnage en créant des activités qui semblent provenir d'autres applications.
• Empêchez les fenêtres non visibles d'être prises en compte pour le lancement d'activités d'arrière-plan. Cela permet d'empêcher les applications malveillantes d'utiliser de manière abusive les lancements d'activités en arrière-plan pour afficher du contenu indésirable ou malveillant auprès des utilisateurs.

Intents plus sûrs

Android 15 introduces new security measures to make intents safer and more robust. These changes are aimed at preventing potential vulnerabilities and misuse of intents that can be exploited by malicious apps. There are two main improvements to the security of intents in Android 15:

• Match target intent-filters: Intents that target specific components must accurately match the target's intent-filter specifications. If you send an intent to launch another app's activity, the target intent component needs to align with the receiving activity's declared intent-filters.
• Intents must have actions: Intents without an action will no longer match any intent-filters. This means that intents used to start activities or services must have a clearly defined action.

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

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

Expérience utilisateur et UI du système

Android 15 inclut des modifications destinées à créer une expérience utilisateur plus cohérente et intuitive.

Modifications des encarts de fenêtre

Il existe deux modifications liées aux encarts de fenêtre dans Android 15: l'application bord à bord est appliquée par défaut, et il existe également des modifications de configuration, telles que la configuration par défaut des barres système.

Edge-to-edge enforcement

Apps are edge-to-edge by default on devices running Android 15 if the app is targeting Android 15.

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 and R.attr#navigationBarColor are deprecated and don't affect gesture navigation.
  • setNavigationBarContrastEnforced and R.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 and R.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 and R.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 and R.attr#statusBarColor are deprecated and have no effect on Android 15.
  • setStatusBarContrastEnforced and R.attr#statusBarContrastEnforced are deprecated but still have an effect on Android 15.
• Display cutout
  • layoutInDisplayCutoutMode of non-floating windows must be LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. SHORT_EDGES, NEVER and DEFAULT are interpreted as ALWAYS 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, 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 uses SHORT_EDGES, NEVER or DEFAULT instead of LAYOUT_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 set window.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 as TopAppBar, BottomAppBar, and NavigationBar, 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 the windowInsets parameter to apply the insets manually for BottomAppBar, TopAppBar, BottomNavigation, and NavigationRail. Likewise, use the contentWindowInsets parameter for Scaffold.
• If your app uses views and Material Components (com.google.android.material), most views-based Material Components such as BottomNavigationView, BottomAppBar, NavigationRailView, or NavigationView, handle insets and require no additional work. However, you need to add android:fitsSystemWindows="true" if using AppBarLayout.
• For custom composables, apply the insets manually as padding. If your content is within a Scaffold, you can consume insets using the Scaffold padding values. Otherwise, apply padding using one of the WindowInsets.
• If your app is using views and BottomSheet, SideSheet or custom containers, apply padding using ViewCompat.setOnApplyWindowInsetsListener. For RecyclerView, apply padding using this listener and also add clipToPadding="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, you 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 now deprecated:

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#isStatusBarContrastEnforced
• Window#setDecorFitsSystemWindows
• Window#setNavigationBarColor
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor
• Window#setStatusBarContrastEnforced

Stable configuration

If your app targets Android 15 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 élégantTextHeight est défini par défaut sur "true"

Pour les applications ciblant Android 15, l'attribut elegantTextHeight TextView devient true par défaut, en remplaçant la police compacte utilisée par défaut par certains scripts associés à de grandes métriques verticales par un autre plus lisible. La police compacte a été introduite pour éviter de perturber les mises en page. Android 13 (niveau d'API 33) empêche bon nombre de ces failles 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 elle ne sera probablement pas compatible avec les prochaines versions. Ainsi, si votre application est compatible avec les scripts suivants (arabe, laotien, birman, gujarati, kannada, malayalam, odia, télougou ou thaï), testez-la en définissant elegantTextHeight sur true.

Modification de la largeur de TextView pour les formes de lettres complexes

Dans les versions précédentes d'Android, certaines polices cursives ou certaines langues présentant une mise en forme complexe peuvent 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 intérieures supplémentaires à gauche pour éviter le rognage.

É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 ou version ultérieure. Vous pouvez activer ou désactiver ce comportement en appelant l'API setUseBoundsForWidth sur TextView.

L'ajout d'une marge intérieure à gauche peut entraîner un désalignement pour les mises en page existantes. C'est pourquoi cette 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 anglais dans une police cursive. Certaines lettres sont tronqué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" />

Disposition standard pour le texte en thaï. Certaines lettres sont tronquées. Voici le code XML correspondant:

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

Mise en page pour le même texte thaï 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 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 afin qu'elle corresponde à la hauteur de la ligne de la police correspondant aux paramètres régionaux actuels. Par exemple, si le contenu était en japonais, car la hauteur de ligne de la police japonaise est légèrement supérieure à celle d'une police latine, la hauteur du texte est devenue légèrement plus importante. Toutefois, malgré ces différences de hauteur de ligne, l'élément EditText a été dimensionné de manière uniforme, quels que soient les paramètres régionaux utilisés, comme illustré dans l'image suivante:

Pour les applications ciblant Android 15, une hauteur de ligne minimale est désormais réservée à EditText afin qu'il corresponde à la police de référence pour les paramètres régionaux spécifiés, comme illustré dans l'image suivante:

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

Appareil photo et contenu multimédia

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 les demandes de priorité audio

Apps that target Android 15 must be the top app or running an audio-related 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.

A foreground service is considered audio-related if its type is mediaPlayback, camera, microphone, or phoneCall.

You can learn more about audio focus at Manage audio focus.

Mise à jour des restrictions non SDK

Android 15 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 15, some of these changes might not immediately affect you. However, while it's possible for your app to access some non-SDK interfaces depending on your app's target API level, using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you can't find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API.

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 15. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.