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 proporcionados por un servicio de accesibilidad.
El framework de audio implementa la política que permite que solo ciertas apps privilegiadas capturen audio de forma simultánea con las apps normales.
La política de simultaneidad se implementa silenciando el audio capturado en lugar de impedir 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 activos, 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 desde el HAL de audio
Una situación de captura simultánea puede generar diferentes situaciones en términos de la cantidad de transmisiones de entrada activas, la selección del dispositivo de entrada o la configuración del preprocesamiento.
La simultaneidad puede ocurrir entre los siguientes elementos:
- Varias transmisiones de entrada del procesador de aplicaciones (AP)
- Transmisiones de entrada y una llamada de voz
- Transmisiones de entrada y un DSP de audio que implementa la detección de palabras clave de bajo consumo
Actividad simultánea de las transmisiones de entrada de AP
El archivo de configuración de la política de audio audio_policy_configuration.xml se usa en el framework de audio para determinar cuántos flujos de entrada se pueden abrir y estar activos 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 se adjuntan al mismo flujo de entrada del HAL, el framework selecciona el dispositivo adecuado para este flujo de entrada según la prioridad del caso de uso.
Cuando hay varios flujos de entrada activos, cada uno puede tener una selección de dispositivo diferente.
Si la tecnología es compatible, se recomienda que el HAL y el subsistema de audio permitan que diferentes transmisiones capturen desde diferentes dispositivos, como auriculares Bluetooth y micrófono integrado.
Si hay una incompatibilidad (por ejemplo, dos dispositivos comparten la misma interfaz de audio digital o el mismo 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, el flujo activo restante debe enrutarse al dispositivo solicitado inicialmente en este flujo.
Si el HAL de audio define un orden de prioridad entre los 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 del preprocesamiento
El framework de audio puede solicitar el preprocesamiento en un flujo de entrada con los métodos de HAL addEffect() o removeEffect().
Para el preprocesamiento 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 provoca 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 del 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 varios flujos de captura están activos de forma simultánea, es posible que se ejecuten diferentes solicitudes de preprocesamiento en diferentes flujos.
Las implementaciones de la HAL y el subsistema de audio deben permitir que se aplique un preprocesamiento diferente a diferentes transmisiones, incluso si comparten el mismo dispositivo de entrada. Es decir, el preprocesamiento se debe aplicar después de demultiplexar los flujos 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 enumeran en Selección de dispositivo.
Llamada de voz y captura simultáneas desde el 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 los lineamientos para este caso.
Durante una llamada, se necesitan dos tipos diferentes de captura del AP.
- Cómo capturar las rutas de RX y TX de las llamadas
- Captura desde un dispositivo de entrada (por ejemplo, micrófono integrado)
Captura la recepción y transmisión de llamadas
La captura de la recepción y la transmisión de llamadas se activa con el uso de la fuente de audio AudioSource.VOICE_UPLINK o AudioSource.VOICE_DOWNLINK, o bien el dispositivo AudioDevice.IN_TELEPHONY_RX.
Las 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 un flujo de captura activo 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 simultánea de flujos de entrada del AP.
Sin embargo, la prioridad para la selección de dispositivos y el preprocesamiento 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 la AP.
Captura simultánea desde el DSP y la AP
Cuando el subsistema de audio contiene un DSP que admite funciones de detección de palabras clave o contexto de audio de bajo consumo, la implementación debe admitir la captura simultánea desde el AP y el DSP de audio.
Esto incluye la captura por parte del DSP durante la fase de detección inicial y la captura por parte de la AP con AudioSource.HOTWORD después de que el DSP active la detección.
Esto se debe reflejar 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 proporcionar un perfil de entrada específico para la captura de palabras clave identificadas por la marca AudioInputFlag.HW_HOTWORD. La implementación debe admitir la apertura y la activación de una cantidad de transmisiones en este perfil que sea, al menos, igual a la cantidad de modelos de sonido que el HAL del activador de sonido puede cargar de forma simultánea.
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 al usuario
Dado 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 solicitan mantener 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 indicaciones visuales al usuario después de que se detecte la palabra clave. Esto ayuda a los usuarios a comprender que las conversaciones posteriores se realizarán a través de otra app, 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 su palabra de activación. 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 genera una experiencia mucho más fluida para los usuarios de 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 del Asistente que no son predeterminadas, no hay cambios en el comportamiento para Android 10.
Ejemplo de implementación del HAL de audio
En AOSP, se puede encontrar un ejemplo de una implementación de HAL de audio que cumple con los lineamientos de este documento.