Android 10 mejora la experiencia del usuario que requiere que se realice más de una captura de audio activa simultáneamente, 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 se capturen simultáneamente con aplicaciones normales.
La política de concurrencia se implementa silenciando el audio capturado en lugar de impedir 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 impedir que una aplicación comience a capturar en un caso en el que pueda recuperar el acceso completo al micrófono después de que otra aplicación haya terminado de capturar.
La consecuencia para el 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 para la compatibilidad con capturas simultáneas.
Captura situaciones desde audio HAL
Un escenario de captura simultánea puede dar lugar a diferentes situaciones en términos de número de flujos de entrada activos, selección de dispositivos de entrada o configuración de preprocesamiento.
La concurrencia puede ocurrir entre lo siguiente:
- Varios flujos de entrada desde el procesador de aplicaciones (AP)
- Secuencias 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 audio utiliza el archivo de configuración de política de audio audio_policy_configuration.xml para determinar cuántos flujos de entrada se pueden abrir y activar simultáneamente.
Como mínimo, el HAL de audio debe admitir al menos una instancia de cada perfil de entrada ( mixPort del sink de funciones) que figura en el archivo de configuración abierto y activo .
Selección de dispositivo
Cuando varios clientes activos están conectados al mismo flujo de entrada HAL, el marco selecciona el dispositivo apropiado para este flujo de entrada según la prioridad del caso de uso.
Cuando hay varios flujos de entrada 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 unos auriculares Bluetooth y un micrófono integrado.
Si hay una incompatibilidad (por ejemplo, dos dispositivos comparten la misma interfaz de audio digital o back-end), el HAL de audio debe elegir qué transmisión controla la selección del dispositivo.
En este caso:
- El estado resultante debe ser consistente y ofrecer la misma selección de dispositivos cuando se repite el mismo escenario.
- Cuando finaliza el estado de concurrencia, el flujo activo restante debe enrutarse al dispositivo solicitado inicialmente en este flujo.
Si el 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 audio puede solicitar el 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 habilita 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 provoca 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 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 varias secuencias de captura están activas simultáneamente, es posible que se ejecuten diferentes solicitudes de preprocesamiento en diferentes secuencias.
Las implementaciones de HAL y del subsistema de audio deberían permitir que se apliquen diferentes preprocesamientos a diferentes transmisiones, incluso si comparten el mismo dispositivo de entrada. Es decir, el procesamiento previo debe aplicarse después de desmultiplexar las transmisiones desde la fuente de captura principal.
Si no es posible por razones técnicas en un subsistema de audio determinado, el HAL de audio debe aplicar reglas de prioridad similares a las enumeradas 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.
Durante una llamada se necesitan dos tipos diferentes de captura desde el AP.
- Captura de rutas RX y TX de llamadas
- Capturar desde un dispositivo de entrada (por ejemplo, un micrófono incorporado)
Captura de llamadas 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 .
Los HAL de audio deben exponerse en el perfil de entrada ( mixPort del sink de funciones) 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 una secuencia de captura activa desde el dispositivo AudioDevice.IN_TELEPHONY_RX .
Captura desde 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 del dispositivo y el procesamiento previo siempre debe estar determinada por la llamada de voz en caso de que haya un conflicto con las solicitudes de los flujos de entrada del AP.
Captura simultánea desde 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 informado por el activador de sonido HAL a través del descriptor de implementación: ISoundTriggerHw.Properties.concurrentCapture = true .
El HAL de audio también debe exponer e ingresar un perfil específico para la captura de palabras clave identificadas por el indicador AudioInputFlag.HW_HOTWORD . La implementación debe admitir la apertura y activación de una cantidad de transmisiones en este perfil al menos igual a la cantidad de modelos de sonido que el activador de sonido HAL puede cargar simultáneamente.
La captura desde este perfil de entrada debería ser posible mientras otros perfiles de entrada estén activos.
Implicaciones 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 de él, puede filtrar datos privados del usuario, necesitamos que se apliquen las siguientes condiciones y garantías a las aplicaciones privilegiadas precargadas que solicitan tener la función 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 activa la palabra activa.
- Las aplicaciones que escuchan simultáneamente deben proporcionar señales visuales al usuario después de que se detecta la palabra activa. Esto ayuda a los usuarios a comprender que otras conversaciones se realizarán a través de una aplicación diferente, como el Asistente.
- Los usuarios deberían poder 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 versiones anteriores, cuando hay dos Asistentes siempre activos en el dispositivo, solo uno de ellos podría estar escuchando su palabra clave. Por lo tanto, era necesario alternar entre los dos Asistentes. En Android 10, el Asistente predeterminado puede escuchar simultáneamente con el otro Asistente. Esto da como resultado una experiencia mucho más fluida para los usuarios con ambos Asistentes.
Aplicaciones que mantienen 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 para Android 10.
Ejemplo de implementación de audio HAL
Puede encontrar un ejemplo de una implementación de audio HAL que cumple con las pautas de este documento en AOSP .