Android 10 mejora la experiencia del usuario que requiere que haya más de una captura de audio activa de manera simultánea, por ejemplo, si el usuario quiere controlar una llamada VoIP o una grabadora de video con comandos por voz que proporciona un servicio de accesibilidad.
El framework de audio implementa la política que permite que solo ciertas apps con privilegios capturen de forma simultánea con las apps normales.
La política de simultaneidad se implementa silenciando el audio capturado en lugar de evitar que una aplicación comience a capturar. Esto permite que el framework aborde de forma dinámica los cambios en la cantidad y los tipos de casos de uso de captura activa, sin impedir que una app comience a capturar en un caso en el que pueda recuperar el acceso completo al micrófono después de que otra app haya terminado de capturar.
La consecuencia para el HAL de audio y el subsistema de audio es que deben admitir varias transmisiones de entrada activas de forma simultánea, incluso si, en algunos casos, solo una transmisión proporciona audio no silencioso a un cliente activo.
Requisitos de CDD
Consulta el CDD para conocer los requisitos de compatibilidad con la captura simultánea.
Captura situaciones del HAL de audio
Una situación 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 procesamiento previo.
La simultaneidad puede ocurrir entre los siguientes elementos:
- Varias transmisiones 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 clave de baja potencia
Actividad simultánea de flujos de entrada de AP
El framework de audio usa el archivo de configuración de la política de audio audio_policy_configuration.xml para determinar cuántas transmisiones de entrada se pueden abrir y activar de forma simultánea.
Como mínimo, el HAL de audio debe admitir al menos una instancia de cada perfil de entrada (mixPort del rol sink) que se indica en el archivo de configuración abierto y activo.
Selección de dispositivos
Cuando varios clientes activos están conectados al mismo flujo de entrada de HAL, el framework selecciona el dispositivo adecuado para este flujo de entrada según la prioridad del caso de uso.
Cuando hay varias transmisiones de entrada activas, cada una puede tener una selección de dispositivos diferente.
Si la tecnología es compatible, se recomienda que el HAL de audio y el subsistema permitan que se capturen diferentes transmisiones desde diferentes dispositivos, como auriculares Bluetooth y micrófono integrado.
Si hay incompatibilidad (por ejemplo, dos dispositivos comparten la misma interfaz de audio digital o el backend), el HAL de audio debe elegir qué transmisión controla la selección del dispositivo.
En este caso, sería así:
- El estado resultante debe ser coherente y ofrecer la misma selección de dispositivos cuando se repite la misma situación.
- Cuando finaliza el estado de simultaneidad, la transmisión activa restante se debe enrutar al dispositivo solicitado inicialmente en esta transmisión.
Si el HAL de audio define un orden de prioridad entre casos de uso activos, sigue el mismo orden que se encuentra en source_priority() en frameworks/av/services/audiopolicy/common/include/policy.h.
Selección de procesamiento previo
El framework de audio puede solicitar el procesamiento previo en un flujo de entrada con los métodos HAL addEffect() o removeEffect().
Para el procesamiento previo en un flujo de entrada determinado, el framework de audio solo habilita la configuración correspondiente al caso de uso activo de mayor prioridad en el flujo de entrada. Sin embargo, es posible que haya cierta superposición durante la activación y desactivación del caso de uso, lo que provocaría que se ejecuten dos procesos activos simultáneos (por ejemplo, dos instancias del cancelador de eco) 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 restablece el estado correcto cuando se inhabilita cualquiera de los procesos.
Cuando varias transmisiones de captura están activas de forma simultánea, es posible que se ejecuten diferentes solicitudes de procesamiento previo en diferentes transmisiones.
Las implementaciones de HAL y del subsistema de audio deben permitir que se aplique un procesamiento previo diferente a diferentes transmisiones, incluso si comparten el mismo dispositivo de entrada. Es decir, el procesamiento previo se debe aplicar después de demuxar las transmisiones de la fuente de captura principal.
Si no es posible por motivos técnicos en un subsistema de audio determinado, el HAL de audio debe aplicar reglas de prioridad similares a las que se indican en Selección de dispositivos.
Llamada de voz y captura simultáneas desde el AP
La captura desde el AP puede ocurrir mientras hay una llamada de voz activa. Esta situación no es nueva en Android 10 y no se relaciona directamente con la función de captura simultánea, pero es útil mencionar los lineamientos para esta situación.
Se necesitan dos tipos diferentes de captura del AP durante una llamada.
- Captura de las rutas de RX y TX de las llamadas
- Captura desde un dispositivo de entrada (por ejemplo, un micrófono integrado)
Cómo capturar la recepción y transmisión de llamadas
La captura de RX y TX de llamadas se activa con el uso de la fuente de audio AudioSource.VOICE_UPLINK o AudioSource.VOICE_DOWNLINK, o el dispositivo AudioDevice.IN_TELEPHONY_RX.
Los HAL de audio deben exponerse en el perfil de entrada (mixPort del rol sink) 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 transmisión de captura activa desde el dispositivo AudioDevice.IN_TELEPHONY_RX.
Captura desde dispositivos de entrada cuando hay una llamada 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 simultánea de flujos de entrada de AP.
Sin embargo, la prioridad para la selección de dispositivos 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 de AP.
Captura simultánea de DSP y AP
Cuando el subsistema de audio contiene un DSP que admite funciones de detección de palabras clave o contexto de audio de baja potencia, la implementación debe admitir la captura simultánea del AP y el DSP de audio.
Esto incluye la captura por parte de la DSP durante la fase de detección inicial y la captura por parte del AP con AudioSource.HOTWORD después de que la DSP activa la detección.
Esto debería reflejarse en la marca de captura simultánea que informa el HAL del activador de sonido a través del descriptor de implementación: ISoundTriggerHw.Properties.concurrentCapture = true.
La HAL de audio también debe exponer y, luego, ingresar un perfil específico para la captura de palabras clave identificadas por la marca 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 puede cargar de forma simultánea el HAL del activador de sonido.
La captura desde este perfil de entrada debería ser posible mientras otros perfiles de entrada estén activos.
Implicaciones para las implementaciones de Asistente
Requisitos sobre el uso de datos y la notificación a los usuarios
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 apps precargadas con privilegios que soliciten 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 activa la palabra clave.
- Las aplicaciones que escuchan de forma simultánea deben proporcionar indicadores visuales al usuario después de que se detecte la palabra clave. Esto ayuda a los usuarios a comprender que las conversaciones adicionales se llevarán a cabo a través de una app diferente, como Asistente.
- Los usuarios deben poder desactivar el micrófono o los activadores de Asistente.
- Cuando se almacenan grabaciones de audio, los usuarios deben poder acceder a ellas, revisarlas y borrarlas 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 puede escuchar la palabra activa. Por lo tanto, era necesario cambiar entre los dos asistentes. En Android 10, el Asistente predeterminado puede escuchar de forma simultánea con el otro Asistente. Esto brinda una experiencia mucho más fluida para los usuarios que tienen ambos asistentes.
Apps que mantienen el micrófono abierto
Cuando apps como Shazam o Waze mantienen el micrófono abierto, el Asistente predeterminado puede seguir escuchando la palabra clave.
En el caso de las apps de Asistente que no son predeterminadas, no hay cambios en el comportamiento de Android 10.
Ejemplo de implementación de HAL de audio
En AOSP, puedes encontrar un ejemplo de una implementación de HAL de audio que cumple con los lineamientos de este documento.