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 mise au point audio et les API de modification du volume, afin de s'assurer que ces modifications sont lancées intentionnellement par l'utilisateur.

Toutes les applications exécutées sur Android 17 qui présentent ces interactions audio en arrière-plan doivent avoir une activité visible ou exécuter un service de premier plan qui n'est pas de type SHORT_SERVICE. Cela s'applique que l'application cible ou non le niveau d'API 37.

Si une application cible Android 17 (niveau d'API 37), une restriction supplémentaire s'applique. Si l'application s'exécute en arrière-plan, elle doit exécuter un service de premier plan doté de fonctionnalités pendant l'utilisation. (Un service de premier plan bénéficie de fonctionnalités WIU s'il est démarré en réponse à une opération initiée par l'utilisateur ou lorsque l'application est visible par l'utilisateur.) Toutefois, l'exigence de fonctionnalités WIU est levée si l'application a reçu l'autorisation alarme exacte et qu'elle apporte des modifications aux flux audio dotés de l'attribut USAGE_ALARM.

Si l'application tente d'appeler des API audio alors qu'elle n'est pas dans un cycle de vie valide, les API de lecture audio et de modification du volume échouent de manière silencieuse, sans générer d'exception ni fournir de message d'échec. L'API de sélection audio échoue avec le code de résultat AUDIOFOCUS_REQUEST_FAILED.

Pourquoi ce changement ?

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

• Les applications qui lisent du contenu audio sans service de premier plan peuvent être gelées. Lorsque l'application est finalement débloquée, elle reprend la lecture audio de manière inattendue, potentiellement plusieurs heures plus tard.
• Les applications qui lisent du contenu audio sans service de premier plan sont soumises à diverses restrictions d'exécution, ce qui entraîne des performances audio instables.
• La lecture est dissocié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 sélection 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 ce changement de comportement si des cas d'utilisation audio intentionnels sont affectés négativement. Veuillez signaler tout problème à l'aide de l'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

Auditez l'implémentation de la lecture audio et déterminez si votre application est destinée à fournir une fonctionnalité d'interaction audio en arrière-plan, même dans des circonstances conditionnelles.

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

Si votre application propose des fonctionnalités VOIP, y compris les applications d'appel vidéo, elle doit déjà respecter les exigences introduites pour la lecture (généralement en utilisant les API de télécommunication recommandées) afin d'enregistrer correctement l'audio. Elle ne devrait donc pas être affectée.

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

Scénarios d'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 lorsqu'elle était ouverte ou en réponse à un déclencheur explicite de l'utilisateur, il est probable que ses fonctionnalités soient supprimées de manière silencieuse.

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 concernant l'audio en arrière-plan pour 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 vous 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 service de premier plan mediaPlayback. Démarrez toujours un service de premier plan lorsque l'application est au premier plan si un contenu audio en arrière-plan peut être lu.

  Par exemple, si votre application est une application de streaming vidéo qui n'est généralement exécutée qu'au premier plan, mais qui contient une affordance utilisateur permettant de continuer la lecture 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 pendant les défaillances temporaires de moins de 10 minutes.

  Si votre application rencontre un échec temporaire, tel qu'un problème de mise en mémoire tampon dû à l'activité réseau, ou s'il existe une interruption temporaire attendue, telle que AUDIOFOCUS_LOSS_TRANSIENT, l'intention de lecture doit continuer. 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, le contenu est terminé sans lecture automatique, un AUDIOFOCUS_LOSS, un événement de pause de l'UMO ou un événement de touche multimédia) ou d'échec irrécupérable, votre application doit arrêter l'interaction audio, arrêter le service de premier plan et mettre fin à la session multimédia. Toutes ces actions correspondent à la conception de l'utilisateur de "terminer" 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'interface utilisateur de votre application ou le bouton de lecture de l'objet multimédia universel, l'intent de démarrage de la lecture audio doit être renvoyé, ce qui entraîne le démarrage d'un nouveau service de premier plan.

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

Test des modifications…

Vous pouvez tester la conformité de votre application sur les appareils exécutant Android 17 ou version ultérieure (à partir de la version bêta 3) en exécutant la commande ADB suivante :

adb shell cmd audio set-enable-hardening <enable|disable|throw>

Cette commande comporte les options suivantes :

• enable : active toutes les restrictions de renforcement audio pour toutes les applications. L'exigence concernant les services de premier plan WIU s'applique, que l'application cible ou non Android 17 (niveau d'API 37). De plus, l'exigence est appliquée même si l'application apporte des modifications aux flux d'alarmes et dispose de l'autorisation d'alarme exacte.

• disable : désactive toutes les restrictions de renforcement audio.

• throw : active toutes les restrictions de renforcement audio pour toutes les applications, comme enable. De plus, cette option active les échecs bruyants, en générant une exception IllegalStateException pour les interactions de volume et de sélection. Pour la lecture audio, la méthode d'écriture renvoie systématiquement un code d'erreur. Pour les modes de lecture sans écritures explicites, l'application plante.

Utilisez adb dumpsys audio ou logcat pour déterminer si l'application a rencontré des échecs silencieux en raison de l'application du renforcement audio. Si c'est le cas, une entrée précédée de AudioHardening s'affiche avec le nom de votre package. Si le message contient level: full, votre application exécute un service de premier plan, mais celui-ci ne dispose pas de la fonctionnalité "pendant l'utilisation". Si le message contient level: partial, votre application n'exécute aucun service de premier plan.

Comprendre les services de premier plan avec la fonctionnalité "pendant l'utilisation"

En règle générale, les services de premier plan 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 d'utilisation en cours (WIU).

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

Voici un tableau de référence :

• Services de premier plan standards : les services démarrés lorsque l'application est visible ou que la capacité de lancement d'activité en arrière-plan est accordée bénéficient d'un accès WIU.
• Services de premier plan démarrés en arrière-plan (BFSL) : la plupart n'accordent pas l'accès WIU. Les principales exceptions qui accordent l'autorisation 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 d'un appareil externe.
• FGS démarré par le système : les services de premier plan bénéficient d'un accès WIU s'ils sont démarrés par délégation du serveur système (par exemple, à partir de la bibliothèque Jetpack Telecom) ou par des liaisons système représentant un état de premier plan élevé pour exécuter une fonctionnalité dédiée (par exemple, pour un VoiceInteractionService).

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