Android 10 mejora la experiencia del usuario que requiere más de una. que la captura de audio activa se realice de forma simultánea, por ejemplo, si el usuario quiere controlar una Llamada VoIP o grabadora de video con comandos por voz proporcionados por un servicio de accesibilidad
El framework de audio implementa la política, lo que permite que solo ciertas apps con privilegios capturen al mismo tiempo que 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 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 la HAL de audio y el subsistema de audio es que deben admitir varias entradas activas a la vez, aunque en algunos casos solo una transmisión proporcione audio no silencioso a un cliente activo.
Requisitos de CDD
Consulta CDD para ver las requisitos para la 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)
- Transmisiones de entrada y una llamada de voz
- Transmisiones de entrada y DSP de audio que implementan una detección de palabra clave de bajo consumo
Actividad simultánea de transmisiones de entrada del PA
El audio usa el archivo de configuración de la 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 rol sink) que se indique 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 transmisión puede tener un dispositivo diferente selección.
Si la tecnología es compatible, se recomienda que la HAL de audio y un subsistema permiten capturar diferentes transmisiones desde distintos 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 si se repite el siguiente escenario.
- Cuando finaliza el estado de simultaneidad, la transmisión activa restante se debe enrutar al dispositivo solicitado 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 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 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 del HAL elige qué solicitud aceptada; realiza un seguimiento de las solicitudes activas y restablece el estado correcto cuando proceso está inhabilitado.
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 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 demuxar las transmisiones desde la fuente de captura principal.
Si no es posible por motivos técnicos en un subsistema de audio determinado, se debe aplicar la HAL de audio. reglas de prioridad similares a las que se enumeran 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)
Capturar 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.
Las HAL de audio se deben exponer en el perfil de entrada (mixPort de la función 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 audio es AudioMode.IN_CALL), debería ser posible
abrir y activar flujos de entrada desde el PA como se especifica en la sección
Actividad simultánea de transmisiones de entrada de PA
Sin embargo, la prioridad para la selección y el procesamiento previo de dispositivos siempre debe ser la prioridad de la voz en caso de conflicto con las solicitudes de los flujos 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
activar una cantidad de transmisiones en este perfil que sea, al menos, igual a la cantidad de modelos de sonido que
pueden cargarse simultáneamente a través de la 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 posteriores pasarían por un cambio 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 funciones siempre activas Asistentes en el dispositivo (solo uno de ellos) podría estar escuchando su palabra clave. Por lo tanto, era necesario alternar 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 para 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
Un ejemplo de implementación de HAL de audio que cumple con los lineamientos de este documento puede ser que se encuentran en el AOSP.