Android 10 mejora la experiencia del usuario que requiere más de una captura de audio activa al mismo tiempo, por ejemplo, si el usuario desea controlar una llamada VoIP o una grabadora de video con comandos de voz proporcionados por un servicio de accesibilidad.
El marco de audio implementa la política que permite que solo ciertas aplicaciones privilegiadas capturen simultáneamente con aplicaciones normales.
La política de concurrencia se implementa silenciando el audio capturado en lugar de evitar que una aplicación comience a capturar. Esto permite que el marco aborde dinámicamente los cambios en la cantidad y los tipos de casos de uso de captura activa, sin evitar que una aplicación comience a capturar en un caso en el que puede recuperar el acceso completo al micrófono después de que otra aplicación haya terminado de capturar.
La consecuencia para la HAL de audio y el subsistema de audio es que deben admitir varios flujos de entrada activos simultáneamente, incluso si, en algunos casos, solo un flujo proporciona audio no silencioso a un cliente activo.
Requisitos de DDC
Consulte CDD para conocer los requisitos de soporte de captura concurrente.
Captura situaciones de audio HAL
Un escenario de captura simultánea puede generar diferentes situaciones en términos de la cantidad de flujos de entrada activos, la selección del dispositivo de entrada o la configuración de preprocesamiento.
La concurrencia puede ocurrir entre lo siguiente:
- Varios flujos de entrada del procesador de aplicaciones (AP)
- Flujos de entrada y una llamada de voz
- Flujos de entrada y un DSP de audio que implementa una detección de palabras activas de bajo consumo
Actividad concurrente de flujos de entrada AP
El marco de trabajo de audio utiliza el archivo de configuración de políticas de audio audio_policy_configuration.xml para determinar cuántos flujos de entrada se pueden abrir y activar simultáneamente.
Como mínimo, la HAL de audio debe admitir al menos una instancia de cada perfil de entrada ( mixPort o sink de roles) enumerados en el archivo de configuración abierto y activo .
Selección de dispositivo
Cuando se conectan varios clientes activos al mismo flujo de entrada de HAL, el marco selecciona el dispositivo adecuado para este flujo de entrada en función de la prioridad del caso de uso.
Cuando varios flujos de entrada están activos, cada flujo puede tener una selección de dispositivo diferente.
Si la tecnología es compatible, se recomienda que el HAL de audio y el subsistema permitan capturar diferentes transmisiones desde diferentes dispositivos, como un auricular Bluetooth y un micrófono incorporado.
Si hay una incompatibilidad (por ejemplo, dos dispositivos comparten la misma interfaz de audio digital o back-end), la HAL de audio debe elegir qué flujo controla la selección del dispositivo.
En este caso:
- El estado resultante debe ser coherente y ofrecer la misma selección de dispositivos cuando se repite el mismo escenario.
- Cuando finaliza el estado de simultaneidad, el flujo activo restante debe enrutarse al dispositivo solicitado inicialmente en este flujo.
Si la HAL de audio define un orden de prioridad entre casos de uso activos, siga el mismo orden que se encuentra en source_priority() en frameworks/av/services/audiopolicy/common/include/policy.h
Selección de preprocesamiento
El marco de trabajo de audio puede solicitar preprocesamiento en un flujo de entrada utilizando los métodos HAL addEffect() o removeEffect() .
Para el preprocesamiento en un flujo de entrada determinado, el marco de audio permite solo la configuración correspondiente al caso de uso activo de mayor prioridad en el flujo de entrada. Sin embargo, puede haber cierta superposición durante la activación y desactivación del caso de uso, lo que hace que dos procesos activos simultáneos (por ejemplo, dos instancias de cancelador de eco) se ejecuten en el mismo flujo de entrada. En este caso, la implementación de HAL elige qué solicitud se acepta; realiza un seguimiento de las solicitudes activas y restaura el estado correcto cuando cualquiera de los procesos está deshabilitado.
Cuando varios flujos de captura están activos simultáneamente, se pueden ejecutar diferentes solicitudes de preprocesamiento en diferentes flujos.
Las implementaciones de subsistemas de audio y HAL deben permitir que se apliquen diferentes preprocesamientos a diferentes flujos, incluso si comparten el mismo dispositivo de entrada. Es decir, se debe aplicar el preprocesamiento después de demultiplexar los flujos desde la fuente de captura principal.
Si no es posible por motivos técnicos en un subsistema de audio determinado, la HAL de audio debe aplicar reglas de prioridad similares a las que se enumeran en Selección de dispositivo .
Llamada de voz simultánea y captura desde AP
La captura desde el AP puede ocurrir mientras una llamada de voz está activa. Esta situación no es nueva en Android 10 y no está directamente relacionada con la función de captura simultánea, pero es útil mencionar las pautas para este escenario.
Se necesitan dos tipos diferentes de captura del AP durante una llamada.
- Captura de rutas de RX y TX de llamadas
- Capturar desde un dispositivo de entrada (por ejemplo, un micrófono incorporado)
Captura de llamada RX y TX
La captura de llamadas RX y TX se activa mediante el uso de la fuente de audio AudioSource.VOICE_UPLINK o AudioSource.VOICE_DOWNLINK y/o el dispositivo AudioDevice.IN_TELEPHONY_RX .
Las HAL de audio deben exponerse en el perfil de entrada ( mixPort del sink de roles) con una ruta disponible desde el dispositivo AudioDevice.IN_TELEPHONY_RX .
Cuando se conecta una llamada (el modo de audio es AudioMode.IN_CALL ), debería ser posible tener al menos un flujo de captura activo desde el dispositivo AudioDevice.IN_TELEPHONY_RX .
Captura de dispositivos de entrada cuando una llamada está activa
Cuando una llamada está activa (el modo de audio es AudioMode.IN_CALL ), debería ser posible abrir y activar flujos de entrada desde el AP como se especifica en la sección Actividad concurrente de flujos de entrada de AP .
Sin embargo, la prioridad para la selección de dispositivos y el preprocesamiento siempre debe ser impulsada por la llamada de voz en caso de que haya un conflicto con las solicitudes de los flujos de entrada de AP.
Captura simultánea de DSP y AP
Cuando el subsistema de audio contiene un DSP que admite contexto de audio de baja potencia o funciones de detección de palabras activas, la implementación debe admitir la captura simultánea desde el AP y el DSP de audio. Esto incluye tanto la captura por parte del DSP durante la fase de detección inicial como la captura por parte del AP con AudioSource.HOTWORD después de que el DSP activa la detección.
Esto debería reflejarse en el indicador de captura simultánea notificado por el disparador de sonido HAL a través del descriptor de implementación: ISoundTriggerHw.Properties.concurrentCapture = true .
La HAL de audio también debe exponer un perfil de entrada específico para la captura de palabras activas identificadas por el indicador AudioInputFlag.HW_HOTWORD . La implementación debe admitir la apertura y activación de una cantidad de flujos en este perfil al menos igual a la cantidad de modelos de sonido que puede cargar simultáneamente el activador de sonido HAL.
La captura desde este perfil de entrada debería ser posible mientras otros perfiles de entrada están activos.
Implicación para las implementaciones del Asistente
Requisitos sobre el uso de datos y notificación al usuario
Debido a que el uso simultáneo del micrófono, si se abusa, puede filtrar datos privados del usuario, necesitamos que se apliquen las siguientes condiciones y garantías a las aplicaciones precargadas privilegiadas que solicitan tener el rol de Asistente.
- Los datos recopilados a través del micrófono no deben salir del dispositivo a menos que el usuario esté interactuando con el Asistente. Por ejemplo, después de que se active la palabra activa.
- Las aplicaciones que escuchan al mismo tiempo deben proporcionar señales visuales al usuario después de que se detecte la palabra activa. Esto ayuda a los usuarios a comprender que las conversaciones posteriores pasarían por una aplicación diferente, como Assistant.
- Los usuarios deben tener la capacidad de apagar el micrófono o los activadores del Asistente.
- Cuando se almacenan grabaciones de audio, los usuarios deben tener la capacidad de acceder, revisar y eliminar grabaciones en cualquier momento.
Mejoras funcionales para Android 10
Los asistentes no se bloquean entre sí
En Android 9 o inferior, cuando hay dos asistentes siempre activos en el dispositivo, solo uno de ellos podría estar escuchando su palabra activa. Por lo tanto, era necesario cambiar entre los dos Asistentes. En Android 10, el Asistente predeterminado puede estar escuchando simultáneamente con el otro Asistente. Esto da como resultado una experiencia mucho más fluida para los usuarios con ambos asistentes.
Aplicaciones con el micrófono abierto
Cuando aplicaciones como Shazam o Waze mantienen el micrófono abierto, el Asistente predeterminado aún puede estar escuchando la palabra activa.
Para las aplicaciones del Asistente no predeterminadas, no hay cambios en el comportamiento de Android 10.
Ejemplo de implementación de HAL de audio
Puede encontrar un ejemplo de una implementación de HAL de audio que cumple con las pautas de este documento en AOSP .