Android 10 améliore l'expérience utilisateur qui nécessite plusieurs captures audio actives 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 règle qui autorise uniquement certaines applications privilégiées à capturer simultanément avec les applications standards.
La règle de simultanéité est implémentée en mettant en sourdine l'audio capturé plutôt qu'en empêchant une application de démarrer la capture. Cela permet au framework de s'adapter dynamiquement aux changements du nombre et des types de cas d'utilisation de capture actifs, sans empêcher une application de commencer la capture dans un cas où elle peut récupérer l'accès complet au micro après 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 plusieurs flux d'entrée actifs simultanément, même si, dans certains cas, un seul flux fournit un son non silencieux à un client actif.
Exigences concernant la CDD
Consultez la section CDD pour connaître les exigences concernant la prise en charge de la capture simultanée.
Capturer des situations à partir du HAL audio
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 simultanéité peut se produire entre les éléments suivants :
- Plusieurs flux d'entrée du processeur d'applications (AP)
- Flux d'entrée et appel vocal
- Flux d'entrée et DSP audio implémentant une détection de mot clé à faible consommation d'énergie
Activité simultanée des flux d'entrée AP
Le fichier de configuration des règles audio audio_policy_configuration.xml est utilisé par le framework audio pour déterminer le nombre de flux d'entrée pouvant être ouverts et actifs simultanément.
Au minimum, l'audio HAL doit prendre en charge au moins une instance de chaque profil d'entrée (mixPort du rôle sink) listée dans le fichier de configuration ouvert et actif.
Le choix parmi les appareils
Lorsque plusieurs clients actifs sont associés au même flux d'entrée HAL, le framework sélectionne l'appareil approprié pour ce flux d'entrée en fonction de la priorité du cas d'utilisation.
Lorsque plusieurs flux d'entrée sont actifs, chacun peut avoir une sélection d'appareil différente.
Si la technologie est compatible, il est recommandé que le HAL audio et le sous-système permettent à différents flux de capturer des données à partir de différents appareils, tels qu'un casque Bluetooth et un micro intégré.
En cas d'incompatibilité (par exemple, si deux appareils partagent la même interface audio numérique ou le même backend), la 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 d'appareils lorsque le même scénario est répété.
- Lorsque l'état de concurrence se termine, le flux actif restant doit être routé vers l'appareil initialement demandé sur ce flux.
Si un ordre de priorité est défini par l'audio HAL 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 du 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 d'un flux d'entrée donné, le framework audio n'active que la configuration correspondant au cas d'utilisation actif de priorité la plus élevée sur le flux d'entrée. Toutefois, il peut y avoir un chevauchement lors de l'activation et de la désactivation des cas d'utilisation, ce qui peut entraîner l'exécution simultanée de deux processus actifs (par exemple, deux instances de l'annuleur d'écho) sur le même flux d'entrée. Dans ce cas, l'implémentation HAL choisit la requête à accepter. Elle assure le suivi des requêtes actives et restaure l'état correct lorsque l'un des 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 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. En d'autres termes, le prétraitement doit être appliqué après le démultiplexage des flux à partir de la source de capture principale.
Si cela n'est pas possible pour des raisons techniques sur un sous-système audio donné, la HAL audio doit appliquer des règles de priorité semblables à celles listées dans Sélection de l'appareil.
Appel vocal et capture simultanés depuis l'AP
La capture depuis le point d'accès peut avoir lieu pendant un appel vocal. 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 consignes pour ce scénario.
Deux types de captures différents sont nécessaires à partir du point d'accès lors d'un appel.
- Capturer les chemins RX et TX des appels
- Capturer du contenu à partir d'un périphérique d'entrée (micro intégré, par exemple)
Capturer les données RX et TX des appels
La capture des RX et TX d'appel est déclenchée par l'utilisation de la source audio AudioSource.VOICE_UPLINK ou AudioSource.VOICE_DOWNLINK, et/ou de l'appareil AudioDevice.IN_TELEPHONY_RX.
Les HAL audio doivent être exposés sur le profil d'entrée (mixPort du rôle sink) avec un itinéraire disponible depuis l'appareil AudioDevice.IN_TELEPHONY_RX.
Lorsqu'un appel est connecté (mode audio AudioMode.IN_CALL), il devrait être possible d'avoir au moins un flux de capture actif à partir de l'appareil AudioDevice.IN_TELEPHONY_RX.
Capturer des données à 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 doit être possible d'ouvrir et d'activer les flux d'entrée de l'application, comme indiqué dans la section Activité simultanée des flux d'entrée de l'application.
Toutefois, la priorité pour la sélection de l'appareil et le prétraitement doit toujours être donnée à l'appel vocal en cas de conflit avec les requêtes des flux d'entrée AP.
Capture simultanée depuis le DSP et l'AP
Lorsque le sous-système audio contient un DSP prenant en charge les fonctions de contexte audio basse consommation ou de détection de mot clé, l'implémentation doit prendre en charge la capture simultanée à partir de l'AP et du DSP audio.
Cela inclut la capture par la DSP lors de la phase de détection initiale et la capture par l'AP avec AudioSource.HOTWORD une fois la détection déclenchée par la DSP.
Cela doit se refléter dans l'indicateur de capture simultanée signalé par le HAL de déclencheur sonore via le descripteur d'implémentation : ISoundTriggerHw.Properties.concurrentCapture = true.
Le HAL audio doit également exposer et saisir un profil spécifique pour la capture de mot clé identifié par l'indicateur AudioInputFlag.HW_HOTWORD. L'implémentation doit permettre d'ouvrir et d'activer sur ce profil un nombre de flux au moins égal au nombre de modèles sonores pouvant être chargés simultanément par le HAL de déclencheur audio.
La capture à partir de ce profil d'entrée devrait être possible lorsque d'autres profils d'entrée sont actifs.
Implications pour les implémentations de l'Assistant
Exigences concernant l'utilisation des données et la notification aux utilisateurs
Étant donné que l'utilisation simultanée du micro peut, en cas d'abus, entraîner la fuite de données utilisateur privées, nous devons appliquer les conditions et garanties suivantes aux applications préchargées privilégiées qui demandent à détenir le rôle d'Assistant.
- Les données collectées par le micro ne doivent pas quitter l'appareil, sauf si l'utilisateur interagit avec l'Assistant. Par exemple, après l'activation du mot clé.
- Les applications qui écoutent simultanément doivent fournir des repères visuels à l'utilisateur une fois le mot clé détecté. Cela permet aux utilisateurs de comprendre que les conversations ultérieures se dérouleront dans une autre application, comme l'Assistant.
- Les utilisateurs doivent pouvoir désactiver le micro ou les déclencheurs de l'Assistant.
- Lorsque des enregistrements audio sont stockés, les utilisateurs doivent pouvoir y accéder, les écouter et les supprimer à tout moment.
Améliorations fonctionnelles pour Android 10
Les assistants ne se bloquent pas mutuellement
Sur Android 9 ou version antérieure, lorsqu'il y a deux assistants toujours activés sur l'appareil, un seul d'entre eux peut écouter son mot clé. Il était donc nécessaire de passer d'un Assistant à l'autre. Dans Android 10, l'Assistant par défaut peut écouter en même temps que l'autre Assistant. Cela permet aux utilisateurs de bénéficier d'une expérience beaucoup plus fluide avec les deux assistants.
Applications qui maintiennent 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 d'assistance autres que celles par défaut, le comportement ne change pas sous Android 10.
Exemple d'implémentation de HAL audio
Un exemple d'implémentation de HAL audio conforme aux consignes de ce document est disponible dans AOSP.