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.
Para implementar la política de simultaneidad, se silencia el audio capturado en lugar de evitar que una aplicación comience la captura. 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 inicie la captura 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.
Cómo capturar situaciones de la 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 de dispositivos de entrada o la configuración de procesamiento previo.
La simultaneidad puede ocurrir entre los siguientes tipos de eventos:
- 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 transmisiones de entrada del PA
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, la HAL de audio debe admitir al menos una instancia de cada perfil de entrada (mixPort de la función sink) que se menciona en el archivo de configuración abierto y activo.
Selección de dispositivos
Cuando se conectan varios clientes activos a la misma transmisión de entrada de HAL, el framework selecciona el dispositivo apropiado para esta transmisión de entrada en función de 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, el flujo activo restante se debe enrutar al dispositivo solicitado inicialmente en este flujo.
Si la 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 preprocesamiento en una transmisión de entrada determinada, el framework de audio solo habilita la configuración correspondiente al caso de uso activo de mayor prioridad en la transmisión de entrada. Sin embargo, puede haber cierta superposición durante la activación y desactivación de casos de uso, lo que provoca que se ejecuten dos procesos activos simultáneos (por ejemplo, dos instancias de cancelador de eco) en la misma transmisión de entrada. En este caso, la implementación del HAL elige qué solicitud se aceptará: realiza un seguimiento de las solicitudes activas y restablece el estado correcto cuando se inhabilita alguno de los procesos.
Cuando varias transmisiones de captura están activas de forma simultánea, diferentes solicitudes de procesamiento previo pueden ejecutarse en transmisiones distintas.
Las implementaciones del subsistema de audio y HAL 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 demuxear 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 PA 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 la llamada 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 del AP.
Sin embargo, la llamada de voz siempre debe controlar la prioridad para la selección y el procesamiento previo del dispositivo en caso de que exista un conflicto con las solicitudes de las transmisiones de entrada del PA.
Captura simultánea de DSP y AP
Cuando el subsistema de audio contiene un DSP compatible con 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 que identifica 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 pistas visuales al usuario después de que se detecta la palabra clave. Esto ayuda a los usuarios a comprender que las conversaciones posteriores 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 en 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. De esta manera, se brinda una experiencia mucho más fluida para los usuarios que usan ambos Asistentes.
Apps con 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.