Partage de l'entrée audio

L'entrée audio provient généralement du micro intégré, d'un micro externe ou d'une audio connectée à l'appareil. L'entrée audio peut aussi provenir une conversation téléphonique.

Il arrive parfois que deux applications ou plus souhaitent toutes les deux effectuer une "capture" d'écran. la même entrée audio. Ils peuvent effectuer des tâches différentes. Par exemple, certaines applications qui reçoivent du contenu audio peuvent être du type « enregistrement », comme un simple enregistreur vocal, tandis que d'autres applications peuvent "écouter", comme l'Assistant Google ou un service d'accessibilité pour répondre aux commandes vocales.

Dans les deux cas, ces applications souhaitent recevoir une entrée audio. Sur cette page, nous utilisons le terme "capture" qu'une l'appli enregistre ou écoute.

Si deux applications ou plus veulent enregistrer du son en même temps, il peut y avoir un problème en acheminant le signal audio de la même source à tous. Cette page décrit comment le système Android partage l'entrée audio entre plusieurs applications qui capturent du contenu audio.

Comportement antérieur à Android 10

Avant Android 10, le flux audio d'entrée ne pouvait être capturé que par une seule application à la fois en temps réel. Si une appli enregistrait ou écoutait déjà du contenu audio, elle pourrait créer un objet AudioRecord, mais une erreur est renvoyée lorsque vous appelez la méthode AudioRecord.startRecording() et l'enregistrement ne démarre pas.

La seule exception à cette règle était lorsqu'une application privilégiée (comme l'Assistant Google ou un d'accessibilité) disposait de l'autorisation android.permission.CAPTURE_AUDIO_HOTWORD et ont utilisé une source audio de type HOTWORD Dans ce cas, une autre application peut lancer l'enregistrement. Lorsque cela s'est produit, application privilégiée a été arrêtée et la nouvelle application a capturé l'entrée.

Une autre modification a été ajoutée sous Android 9: seules les applications exécutées au premier plan (ou un service de premier plan) pourrait capturer l'entrée audio. Lorsqu'une application sans un service de premier plan ou un composant d'interface utilisateur de premier plan a commencé à capturer, l'application a continué de courir, mais a reçu un silence, même s'il s'agissait de la seule appli capturant l'audio à ce moment-là.

Comportement d'Android 10

Avant Android 10, le comportement était le suivant : "premier arrivé, premier servi". Lorsqu'une application commence à enregistrer du contenu audio, aucune autre application ne peut accéder jusqu'à ce que l'application qui capture le son s'arrête.

Android 10 impose un schéma de priorité qui peut changer le flux audio d'entrée. entre les applications pendant leur exécution. Dans la plupart des cas, si une nouvelle application acquiert l'entrée audio, l'application précédemment capturée continue de s'exécuter, mais reçoit du silence. Dans certains le système peut continuer à fournir du contenu audio aux deux applications. Les différents scénarios de partage sont expliqués ci-dessous.

Ce schéma est semblable à la façon dont le ciblage audio gère plusieurs applications l'utilisation de la sortie audio. Toutefois, le ciblage audio est géré les demandes programmatiques pour se concentrer et libérer l'attention, tandis que le changement d'entrée décrit ici repose sur une règle de priorisation appliquée automatiquement dès qu'une nouvelle application commence à enregistrer du contenu audio.

Pour la capture audio, Android distingue deux types d'applications:

  • "Normal" les applications sont installées par l'utilisateur.
  • "Privilégié" applications sont préinstallées sur l'appareil. y compris l'Assistant Google et tous les services d'accessibilité.

De plus, une application est traitée différemment si elle utilise une expression "sensible à la confidentialité" source audio: CAMCORDER ou VOICE_COMMUNICATION.

Voici les règles de priorisation pour l'utilisation et le partage des entrées audio:

  • Les applications privilégiées ont une priorité plus élevée que les applications ordinaires.
  • Les applications dont l'interface utilisateur au premier plan est visible ont une priorité plus élevée que les applications en arrière-plan.
  • Les applications qui enregistrent du contenu audio à partir d'une source sensible à la confidentialité ont une priorité plus élevée que les autres.
  • Deux applications ordinaires ne peuvent jamais enregistrer du son en même temps.
  • Dans certains cas, une application privilégiée peut partager l'entrée audio avec une autre application.
  • Si deux applications d'arrière-plan de même priorité capturent du contenu audio, la dernière application lancée a une priorité plus élevée.

Scénarios de partage

Lorsque deux applications essaient d'enregistrer du contenu audio, ils peuvent tous les deux recevoir le signal d'entrée, ou l'un d'eux peut recevoir couper le son.

Il existe quatre scénarios principaux:

  • Assistant + application standard
  • Service d'accessibilité + application ordinaire
  • Deux applications ordinaires
  • Appel vocal + application standard

Assistant + application standard

L'Assistant est une application privilégiée, car il est préinstallé et contient rôle RoleManager.ROLE_ASSISTANT. Toute autre application préinstallée avec ce rôle est traitée de la même manière.

Android partage l'audio d'entrée selon les règles suivantes:

  • L'Assistant peut recevoir des contenus audio (qu'ils soient au premier plan ou en arrière-plan) sauf si une autre appli utilise déjà une source audio sensible à la confidentialité.

  • L'appli reçoit du contenu audio, sauf si l'UI de l'Assistant est visible en haut de l'écran.

Notez que les deux applications ne reçoivent du son que lorsque l'Assistant est en arrière-plan. alors que l'autre application n'enregistre pas de contenu à partir d'une source audio sensible à la confidentialité.

Service d'accessibilité + application ordinaire

Un AccessibilityService nécessite une déclaration stricte.

Android partage l'audio d'entrée selon les règles suivantes:

  • Si l'UI du service est en haut, le service et l'application reçoivent tous deux l'entrée audio. Ce comportement offre des fonctionnalités telles que le contrôle d'un appel vocal ou d'une vidéo à l'aide de commandes vocales.

  • Si le service n'est pas en haut, ce scénario est traité comme le cas ordinaire de deux applications ci-dessous.

Deux applications ordinaires

Lorsque deux applications effectuent la capture simultanée, une seule reçoit le contenu audio et l'autre reçoit le son.

Android partage l'audio d'entrée selon les règles suivantes:

  • Si aucune des deux applications n'est sensible à la confidentialité, l'application avec une UI sur le dessus reçoit du contenu audio. Si aucune des deux applications n'a d'interface utilisateur, celle qui a commencé à capturer le plus récemment reçoit du contenu audio.
  • Si l'une des applications est sensible à la confidentialité, elle reçoit des données audio et l'autre application se coupe du son, même si elle dispose d'une interface utilisateur ou si elle a commencé à capturer des données. plus récemment.
  • Si les deux applis sont sensibles à la confidentialité, celle qui a commencé à capturer le plus reçoit récemment un son et l'autre reçoit le son.

Appel vocal + application standard

Un appel vocal est actif si le mode audio est renvoyé AudioManager.getMode() correspond à MODE_IN_CALL ou MODE_IN_COMMUNICATION

Android partage l'audio d'entrée selon les règles suivantes:

Comportement d'Android 11

Android 11 (niveau d'API 30) respecte le schéma de priorité d'Android 10 décrites ci-dessus. Il fournit également de nouvelles méthodes dans AudioRecord, MediaRecorder et AAudioStream qui activent et désactivent la possibilité de capturer du contenu audio simultanément, quel que soit le cas d'utilisation sélectionné.

Les nouvelles méthodes sont les suivantes:

Lorsque setPrivacySensitive() est défini sur true, le cas d'utilisation de la capture est privé, et même qu'un Assistant privilégié ne peut pas capturer simultanément. Ce paramètre remplace le comportement par défaut qui dépend de la source audio. Par exemple, VOICE_COMMUNICATION est privée par défaut, mais UNPROCESSED ne l'est pas.

Modifications de configuration

Lorsque plusieurs applications capturent le contenu audio simultanément, une ou deux d'entre elles seulement "actif" (réception de contenu audio) ; le son des autres participants est coupé (silencieur). Lorsque les applications actives changent, le framework audio peut reconfigurer les chemins audio selon les règles suivantes:

  • Le périphérique d'entrée audio de chaque application active peut changer (par exemple, le micro intégré à un casque Bluetooth connecté).
  • Le prétraitement associé à l'application active ayant la priorité la plus élevée est activé. Tout tout autre prétraitement est ignoré.

Étant donné qu'une application active peut être mise sous silence lorsqu'une application de priorité supérieure devient active, vous pouvez enregistrer un AudioManager.AudioRecordingCallback le AudioRecord ou MediaRecorder pour être averti en cas de modification de la configuration. Voici les modifications possibles:

  • Capturer avec ou sans mise sous silence
  • Appareil modifié
  • Prétraitement modifié
  • Propriétés du flux modifiées (taux d'échantillonnage, masque de canal, format d'échantillon)

Vous devez appeler AudioRecord.registerAudioRecordingCallback() avant le début de la capture. Le rappel n'est exécuté que lorsque l'application reçoit du contenu audio et qu'un changement se produit.

La méthode onRecordingConfigChanged() renvoie un AudioRecordingConfiguration contenant l'état actuel de la capture audio. Utilisez les éléments suivants : pour en savoir plus sur ce changement:

isClientSilenced()
Renvoie la valeur "true" si le son renvoyé au client est actuellement mis sous silence conformément aux règles de capture.
getAudioDevice()
Renvoie l'appareil audio actif.
getEffects()
Renvoie l'effet de prétraitement actif. Notez que l'effet actif peut être différent de ceux renvoyés par getClientEffects() si le client n'est pas l'application active dont la priorité est la plus élevée.
getFormat()
Renvoie les propriétés du flux. Notez que les données audio réelles reçues par le client respectent toujours le format requis renvoyé par getClientFormat(). Le framework effectue automatiquement le rééchantillonnage, le canal et la conversion de format nécessaires, du format utilisé au niveau de l'interface matérielle vers le format spécifié par le client.
AudioRecord.getActiveRecordingConfiguration().
Renvoie la configuration d'enregistrement active.

Vous pouvez obtenir une vue d'ensemble de tous les enregistrements actifs sur l'appareil en appelant AudioManager.getActiveRecordingConfigurations()