Android 10 améliore l'expérience utilisateur qui nécessite que plusieurs captures audio actives se produisent simultanément, par exemple si l'utilisateur souhaite contrôler un appel VoIP ou un enregistreur vidéo avec des commandes vocales fournies par un service d'accessibilité.
Le framework audio implémente la politique autorisant uniquement certaines applications privilégiées à capturer simultanément avec des applications normales.
La politique de concurrence est mise en œuvre en mettant sous silence l'audio capturé plutôt qu'en empêchant une application de démarrer la capture. Cela permet au framework de répondre de manière dynamique aux changements dans le nombre et les types de cas d'utilisation de capture active, sans empêcher une application de démarrer la capture dans le cas où elle peut récupérer un accès complet au microphone une fois qu'une autre application a terminé la capture.
La conséquence pour le HAL audio et le sous-système audio est qu'ils doivent prendre en charge simultanément plusieurs flux d'entrée actifs, même si dans certains cas, un seul flux fournit un son non silencieux à un client actif.
Exigences en matière de CDD
Voir CDD pour connaître les exigences relatives à la prise en charge de la capture simultanée.
Capturer des situations à partir de l'audio HAL
Un scénario de capture simultanée peut entraîner différentes situations en termes de nombre de flux d'entrée actifs, de sélection de périphérique d'entrée ou de configuration de prétraitement.
La concurrence peut se produire entre les éléments suivants :
- Plusieurs flux d'entrée du processeur d'application (AP)
- Flux d'entrée et appel vocal
- Flux d'entrée et DSP audio implémentant une détection de mots clés de faible consommation
Activité simultanée des flux d'entrée AP
Le fichier de configuration de la politique audio audio_policy_configuration.xml est utilisé par la structure audio pour déterminer combien de flux d'entrée peuvent être ouverts et actifs simultanément.
Au minimum, le HAL audio doit prendre en charge au moins une instance de chaque profil d'entrée ( mixPort du sink de rôle ) répertorié dans le fichier de configuration ouvert et actif .
Sélection de l'appareil
Lorsque plusieurs clients actifs sont attachés au même flux d'entrée HAL, le framework sélectionne le périphérique approprié pour ce flux d'entrée en fonction de la priorité du cas d'utilisation.
Lorsque plusieurs flux d'entrée sont actifs, chaque flux peut avoir une sélection de périphérique différente.
Si la technologie est compatible, il est recommandé que le HAL audio et le sous-système permettent la capture de différents flux à partir de différents appareils, tels qu'un casque Bluetooth et un micro intégré.
En cas d'incompatibilité (par exemple, deux appareils partagent la même interface audio numérique ou back-end), le HAL audio doit choisir quel flux contrôle la sélection de l'appareil.
Dans ce cas:
- L'état résultant doit être cohérent et offrir la même sélection de périphérique lorsque le même scénario est répété.
- Lorsque l’état de concurrence prend fin, le flux actif restant doit être acheminé vers le périphérique initialement demandé sur ce flux.
Si un ordre de priorité est défini par le HAL audio entre les cas d'utilisation actifs, suivez le même ordre que celui trouvé dans source_priority() dans frameworks/av/services/audiopolicy/common/include/policy.h
Sélection de prétraitement
Le framework audio peut demander un prétraitement sur un flux d'entrée à l'aide des méthodes HAL addEffect() ou removeEffect() .
Pour le prétraitement sur un flux d'entrée donné, le framework audio active uniquement la configuration correspondant au cas d'utilisation actif le plus prioritaire sur le flux d'entrée. Cependant, il peut y avoir un certain chevauchement lors de l'activation et de la désactivation du cas d'utilisation, provoquant l'exécution de deux processus actifs simultanés (par exemple, deux instances d'annuleur d'écho) sur le même flux d'entrée. Dans ce cas, l'implémentation HAL choisit quelle demande est acceptée ; il garde une trace des demandes actives et restaure l'état correct lorsque l'un ou l'autre processus est désactivé.
Lorsque plusieurs flux de capture sont actifs simultanément, différentes requêtes de prétraitement peuvent être exécutées sur différents flux.
Les implémentations de HAL et du sous-système audio doivent permettre d'appliquer différents prétraitements à différents flux, même s'ils partagent le même périphérique d'entrée. Autrement dit, le prétraitement doit être appliqué après la démultiplexage des flux de la source de capture principale.
Si cela n'est pas possible pour des raisons techniques sur un sous-système audio donné, le HAL audio doit appliquer des règles de priorité similaires à celles répertoriées dans Sélection du périphérique .
Appel vocal simultané et capture depuis AP
La capture depuis le point d'accès peut avoir lieu pendant qu'un appel vocal est actif. Cette situation n'est pas nouvelle dans Android 10 et n'est pas directement liée à la fonctionnalité de capture simultanée, mais il est utile de mentionner les directives pour ce scénario.
Deux types différents de capture depuis le point d'accès sont nécessaires lors d'un appel.
- Capturer les chemins d'appel RX et TX
- Capture à partir d'un périphérique d'entrée (par exemple, un micro intégré)
Capturer les appels RX et TX
La capture des appels RX et TX est déclenchée par l'utilisation de la source audio AudioSource.VOICE_UPLINK ou AudioSource.VOICE_DOWNLINK et/ou du périphérique AudioDevice.IN_TELEPHONY_RX .
Les HAL audio doivent être exposés sur le profil d'entrée ( mixPort du sink de rôle) avec une route disponible à partir du périphérique AudioDevice.IN_TELEPHONY_RX .
Lorsqu'un appel est connecté (le mode audio est AudioMode.IN_CALL ), il devrait être possible d'avoir au moins un flux de capture actif à partir du périphérique AudioDevice.IN_TELEPHONY_RX .
Capture à partir de périphériques d'entrée lorsqu'un appel est actif
Lorsqu'un appel est actif (le mode audio est AudioMode.IN_CALL ), il devrait être possible d'ouvrir et d'activer les flux d'entrée de l'AP comme spécifié dans la section Activité simultanée des flux d'entrée de l'AP .
Cependant, la priorité en matière de sélection de périphérique et de prétraitement doit toujours être déterminée par l'appel vocal en cas de conflit avec les demandes des flux d'entrée du point d'accès.
Capture simultanée depuis DSP et AP
Lorsque le sous-système audio contient un DSP prenant en charge les fonctions de détection de contexte audio ou de mot clé de faible consommation, l'implémentation doit prendre en charge la capture simultanée à partir du point d'accès et du DSP audio. Cela inclut à la fois la capture par le DSP pendant la phase de détection initiale et la capture par l'AP avec AudioSource.HOTWORD après que la détection soit déclenchée par le DSP.
Cela devrait être reflété par l'indicateur de capture simultanée signalé par le déclencheur sonore HAL via le descripteur d'implémentation : ISoundTriggerHw.Properties.concurrentCapture = true .
Le HAL audio doit également exposer et saisir un profil spécifique à la capture de mots clés identifié par l'indicateur AudioInputFlag.HW_HOTWORD . L'implémentation doit prendre en charge l'ouverture et l'activation d'un nombre de flux sur ce profil au moins égal au nombre de modèles sonores pouvant être chargés simultanément par le déclencheur sonore HAL.
La capture à partir de ce profil d'entrée devrait être possible pendant que d'autres profils d'entrée sont actifs.
Implication pour les implémentations de l'Assistant
Exigences relatives à l'utilisation des données et à la notification des utilisateurs
Étant donné que l'utilisation simultanée du micro, en cas d'abus, peut entraîner une fuite des données privées des utilisateurs, nous avons besoin que les conditions et garanties suivantes soient appliquées aux applications préchargées privilégiées qui demandent à détenir le rôle d'assistant.
- Les données collectées via le microphone ne doivent pas quitter l'appareil à moins que l'utilisateur n'interagisse avec l'Assistant. Par exemple, après le déclenchement du mot clé.
- Les applications écoutant simultanément doivent fournir des repères visuels à l'utilisateur une fois le mot clé détecté. Cela aide les utilisateurs à comprendre que les conversations ultérieures passeront par une autre application, telle que l'Assistant.
- Les utilisateurs doivent avoir la possibilité de désactiver le microphone ou les déclencheurs de l'Assistant.
- Lorsque des enregistrements audio sont stockés, les utilisateurs doivent avoir la possibilité d'accéder, de consulter et de supprimer les enregistrements à tout moment.
Améliorations fonctionnelles pour Android 10
Les assistants ne se bloquent pas
Sur Android 9 ou version antérieure, lorsqu'il y a deux assistants toujours actifs sur l'appareil, un seul d'entre eux peut écouter son mot clé. Il était donc nécessaire de basculer entre les deux assistants. Sous Android 10, l'Assistant par défaut peut écouter simultanément avec l'autre Assistant. Cela se traduit par une expérience beaucoup plus fluide pour les utilisateurs disposant des deux assistants.
Applications maintenant le micro ouvert
Lorsque des applications comme Shazam ou Waze maintiennent le micro ouvert, l'assistant par défaut peut toujours écouter le mot clé.
Pour les applications Assistant autres que celles par défaut, il n'y a aucun changement de comportement pour Android 10.
Exemple d'implémentation audio HAL
Un exemple d'implémentation audio HAL conforme aux directives de ce document peut être trouvé dans AOSP .