Renforcement de l'audio en arrière-plan

À partir d'Android 17, le framework audio applique des restrictions sur les interactions audio en arrière-plan, y compris la lecture audio, les requêtes de focus audio et les API de modification du volume, afin de s'assurer que ces modifications sont lancées intentionnellement par l'utilisateur.

Si un développeur d'application souhaite contrôler l'audio sans activité visible, il doit s'assurer que l'application dispose d'un service de premier plan (qui n'est pas de type SHORT_SERVICE) démarré avec des fonctionnalités Pendant l'utilisation (WIU, While-In-Use). Un service de premier plan se voit accorder des capacités WIU s'il est démarré en réponse à un MediaSessionEvent ou lorsque l'application est visible par l'utilisateur.

Si l'application tente d'appeler des API audio alors qu'elle ne se trouve pas dans un cycle de vie valide, les API de lecture audio et de modification du volume échouent silencieusement, sans générer d'exception ni fournir de message d'échec. L'API de focus audio échoue avec le code de résultat AUDIOFOCUS_REQUEST_FAILED.

L'objectif de ces restrictions est de réduire les bugs audio en arrière-plan involontaires. Voici quelques exemples :

• Les applications qui lisent du contenu audio sans service de premier plan peuvent être figées. Lorsque l'application est finalement dégelée, elle reprend la lecture audio de manière inattendue, potentiellement des heures plus tard.
• Les applications qui lisent de l'audio sans service de premier plan sont soumises à diverses restrictions d'exécution, ce qui entraîne des performances audio saccadées.
• La lecture est détachée du cycle de vie de l'activité, ce qui peut entraîner une fuite de la session de lecture ou des événements de focus qui se poursuivent sans que l'utilisateur puisse arrêter la lecture.

Nous encourageons les développeurs à tester leurs applications et à nous faire part de leurs commentaires sur le changement de comportement si des cas d'utilisation audio intentionnels sont affectés de manière négative. Veuillez signaler tout problème à l'aide de cet outil de suivi des problèmes de compatibilité des applications Android 17.

Identifier les cas d'utilisation de l'audio en arrière-plan concernés

Vérifiez l'implémentation de la lecture audio et déterminez si votre application prévoit de fournir une fonctionnalité d'interaction audio en arrière-plan, même dans des circonstances conditionnelles.

Si votre application ne prévoit de lire du contenu audio ou d'utiliser des API audio que lorsqu'elle affiche une activité visible par l'utilisateur, y compris en mode Picture-in-picture (PIP), elle n'est pas concernée par ces modifications.

Si votre application fournit une fonctionnalité VOIP, y compris les applications d'appel vidéo, elle doit déjà répondre aux exigences introduites pour la lecture (généralement en utilisant les API Telecom recommandées) pour enregistrer l'audio avec succès. Il est donc peu probable qu'elle soit affectée.

Si votre application prévoit de continuer la lecture audio lorsque l'écran est éteint ou lorsque l'utilisateur a complètement fermé votre activité (ce qui est le cas le plus souvent dans les applications de streaming musical ou de podcast), votre application est considérée comme fournissant une fonctionnalité audio en arrière-plan et doit répondre aux nouvelles exigences.

Scénarios audio en arrière-plan susceptibles d'être affectés

Si votre application ne suit pas le modèle de poursuite d'une interaction audio initiée alors qu'elle était ouverte ou en réponse à un déclencheur utilisateur explicite, il est probable que la fonctionnalité de votre application soit supprimée silencieusement.

Par exemple, si votre application démarre un service de premier plan en réponse à BOOT_COMPLETE et tente d'interagir avec l'audio, elle sera supprimée.

Bonnes pratiques pour l'audio en arrière-plan afin de limiter l'impact

• Utilisez le composant MediaSessionService de la bibliothèque Jetpack media3 pour gérer la lecture audio en arrière-plan.

  Si vous le faites, votre application ne sera probablement pas affectée par le renforcement en arrière-plan, car la bibliothèque aide à gérer le cycle de vie de la lecture.

• Si vous n'utilisez pas la bibliothèque media3, vous devrez démarrer manuellement un FGS mediaPlayback. Démarrez toujours un service de premier plan lorsque l'application est au premier plan si un son en arrière-plan peut se produire.

  Par exemple, si votre application est une application de streaming vidéo qui est généralement réservée au premier plan, mais qui contient une fonctionnalité permettant à l'utilisateur de continuer à lire la vidéo lorsque l'écran est éteint, votre application doit toujours démarrer un service de premier plan lorsque le déclencheur de lecture initié par l'utilisateur se produit.

  Cela garantit que le service de premier plan est démarré avec les fonctionnalités WIU.

• Maintenez le mediaPlayback FGS actif en cas de défaillance temporaire de moins de 10 minutes.

  Si votre application présente un échec temporaire, tel qu'un problème de mise en mémoire tampon en raison de l'activité réseau, ou s'il existe une interruption temporaire attendue telle que AUDIOFOCUS_LOSS_TRANSIENT, l'intention de lecture doit se poursuivre. Votre FGS doit donc rester actif.

• Arrêtez le service de premier plan à la fin de la lecture et ne redémarrez la lecture que si l'utilisateur la reprend explicitement.

  En cas de signal permanent de fin de lecture (par exemple, contenu terminé sans lecture automatique, AUDIOFOCUS_LOSS, événement de pause de l'UMO ou événement de touche multimédia) ou d'échec irrécupérable, votre application doit cesser l'interaction audio, arrêter le service de premier plan et mettre fin à la session multimédia. Tout cela correspond à la conception de l'utilisateur de la "fin" de l'interaction audio en arrière-plan souhaitée. Après cela, votre application ne pourra plus interagir avec l'audio en arrière-plan.

  Par la suite, si l'utilisateur reprend explicitement la lecture, par exemple via l'UI de votre application ou le bouton de lecture de l'objet média universel, l'intention de démarrer la lecture audio doit revenir, ce qui entraîne le démarrage d'un nouveau FGS.

• Testez le comportement de lecture audio avec les commandes adb shell.

Tester les modifications sur Android 16 et Android 17

Cette fonctionnalité est déjà implémentée au niveau "avertissement" à partir d'Android 16. Cela signifie que les applications peuvent utiliser adb shell cmd audio set-enable-hardening pour tester manuellement l'application des mesures de renforcement de la sécurité de l'audio en arrière-plan.

Pour activer l'application sur les appareils exécutant Android 16, exécutez la commande suivante :

adb shell cmd audio set-enable-hardening 1

Pour désactiver l'application sur les appareils exécutant Android 17, exécutez la commande suivante :

adb shell cmd audio set-enable-hardening 0

Nous vous recommandons également d'utiliser logcat ou la commande adb adb dumpsys audio pour identifier si l'application a rencontré des échecs silencieux en raison de l'application du renforcement audio. Si c'est le cas, le journal comportera une entrée préfixée par AudioHardening avec le nom de votre package.

Comprendre FGS avec la fonctionnalité "en cours d'utilisation"

En règle générale, les services de premier plan (FGS) doivent être lancés lorsqu'une application est au premier plan pour étendre les opérations déclenchées par l'utilisateur. Dans certains cas spécifiques, les applications sont autorisées à lancer un service de premier plan lorsqu'elles sont en arrière-plan. Toutefois, ces services de premier plan ne bénéficient généralement pas des fonctionnalités "pendant l'utilisation" (WIU, While-In-Use).

WIU agit comme une barrière de sécurité. Il empêche les services de premier plan démarrés en arrière-plan d'adopter certains comportements sensibles lorsque l'utilisateur n'est pas au courant de l'activité de l'application. Elle empêche l'application d'accéder à des données sensibles telles que la localisation, l'appareil photo ou le micro. À partir d'Android 17, elle bloque également les API audio qui nécessitent généralement un contexte d'UI visible.

Voici un guide pratique :

• Services de premier plan standards : les services démarrés lorsque l'application est visible ou lorsque la fonctionnalité de lancement d'activité en arrière-plan est accordée bénéficient d'un accès WIU.
• FGS démarré en arrière-plan (BFSL) : la plupart n'accordent pas l'accès à WIU. Les principales exceptions qui accordent le WIU sont les interactions impliquant une intention explicite de l'utilisateur, par exemple les clics sur les notifications, les interactions avec les widgets ou les événements de touches multimédias provenant d'un appareil externe.
• Le système a démarré FGS : les FGS qui ont démarré en utilisant la délégation system-server (par exemple, en utilisant la bibliothèque Telecom jetpack) ont accès à WIU.

Pour en savoir plus, consultez Restrictions concernant le démarrage d'un service de premier plan en arrière-plan.

Liste complète des API audio concernées

Fonction audio	Résultat	API concernées
Lecture audio	La lecture est mise en sourdine Aucune exception ni aucun message d'échec fournis par une API	AudioTrack.write() (NDK) AAudioStream_write OpenSL ES pour Android Toutes les bibliothèques multimédias côté client qui gèrent la lecture, telles que media3, ExoPlayer et Oboe, peuvent également être concernées.
Demande de priorité audio	Renvoie AUDIOFOCUS_REQUEST_FAILED Aucun effet sur la lecture audio des autres applications, aucune priorité audio acquise	AudioManager.requestAudioFocus()
API de volume et de mode Sonnerie	Aucun effet sur le mode ou le volume de la sonnerie (l'appel de méthode est ignoré silencieusement) Aucune exception ni aucun message d'échec fournis par une API	AudioManager.setStreamVolume() AudioManager.setStreamMute() AudioManager.adjustStreamVolume() AudioManager.adjustVolume() AudioManager.adjustSuggestedStreamVolume() AudioManager.setRingerMode()