Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Captura concurrente

Android 10 mejora la experiencia del usuario que requiere que ocurra 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 capturen simultáneamente con aplicaciones normales.

La política de concurrencia se implementa silenciando el audio capturado en lugar de evitar que una aplicación comience a capturar. Esto permite que el marco aborde dinámicamente los cambios en el número y los tipos de casos de uso de captura activa, sin evitar 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 CDD

Ver CDD para las necesidades de apoyo de captura simultánea.

Capture situaciones de audio HAL

Un escenario de captura concurrente puede resultar en diferentes situaciones en términos de la cantidad de flujos de entrada activos, selección de dispositivo de entrada o configuración de preprocesamiento.

La simultaneidad puede ocurrir entre lo siguiente:

  • Varias secuencias de entrada del procesador de aplicaciones (AP)
  • Flujos de entrada y una llamada de voz
  • Flujos de entrada y un DSP de audio que implementan una detección de palabras clave de bajo consumo

Actividad concurrente de flujos de entrada AP

La política de audio fichero de configuración audio_policy_configuration.xml es utilizado por el marco de audio para determinar cómo se pueden abrir muchos flujos de entrada y activa al mismo tiempo.

Como mínimo, la HAL audio debe ser compatible con al menos una instancia de cada perfil de entrada ( mixPort de papel sink ) que aparece en el archivo de configuración abierta y activa.

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 la captura de diferentes transmisiones desde diferentes dispositivos, como un auricular Bluetooth y un micrófono integrado.

Si hay una incompatibilidad (por ejemplo, dos dispositivos comparten la misma interfaz de audio digital o back-end), la HAL de audio debe elegir qué flujo controla la selección del dispositivo.

En este caso:

  • El estado resultante debe ser coherente y ofrecer la misma selección de dispositivo 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 una orden de prioridad se define por la HAL audio entre casos de uso activo, siga el mismo orden como se encuentran en source_priority() en frameworks/av/services/audiopolicy/common/include/policy.h

Selección previa al procesamiento

El marco de audio puede solicitar preprocesamiento en un flujo de entrada utilizando los addEffect() o removeEffect() métodos de HAL.

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 hace 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 de 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 del subsistema de audio y HAL deben permitir la aplicación de diferentes preprocesos a diferentes flujos, incluso si comparten el mismo dispositivo de entrada. Es decir, el preprocesamiento debe aplicarse después de la demultipulación de los flujos desde la fuente de captura primaria.

Si no es posible por razones técnicas en un subsistema de audio dada, la HAL de audio debe aplicarse reglas de prioridad similares a los que figuran en la selección de dispositivos .

Llamada de voz concurrente 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.

Se necesitan dos tipos diferentes de captura del AP durante una llamada.

Captura de llamadas RX y TX

La captura de llamada de RX y TX se desencadenan por el uso de la fuente de audio AudioSource.VOICE_UPLINK o AudioSource.VOICE_DOWNLINK , y / o dispositivo AudioDevice.IN_TELEPHONY_RX .

HAL de audio deben exponerse en el perfil de entrada ( mixPort de papel sink ) con una ruta disponible desde el dispositivo AudioDevice.IN_TELEPHONY_RX .

Cuando se conecta una llamada (modo de audio es AudioMode.IN_CALL ), debería ser posible tener al menos una corriente de captura activo desde el dispositivo AudioDevice.IN_TELEPHONY_RX .

Captura de dispositivos de entrada cuando una llamada está activa

Cuando una llamada está activa (modo de audio es AudioMode.IN_CALL ), debe ser posible abrir y activar flujos de entrada de la AP como se especifica en la sección de la actividad simultánea de flujos de entrada de AP .

Sin embargo, la prioridad para la selección del dispositivo y el preprocesamiento siempre debe ser impulsada por la llamada de voz en caso de que haya un conflicto con las solicitudes de los flujos de entrada del AP.

Captura concurrente 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 desde el AP y el DSP de audio. Esto incluye tanto la captura por el DSP durante la fase inicial de detección y captura por el AP con AudioSource.HOTWORD después de la detección se activa por el DSP.

Esto debe reflejarse por la bandera de captura simultánea reportados por la HAL gatillo sonido a través del descriptor de aplicación: ISoundTriggerHw.Properties.concurrentCapture = true .

El HAL audio también debe exponer y específica perfil de entrada para la captura de palabra activa identificada por bandera AudioInputFlag.HW_HOTWORD . La implementación debe admitir la apertura y activación de un número de transmisiones en este perfil al menos igual al número de modelos de sonido que pueden cargarse simultáneamente con el disparador de sonido HAL.

La captura desde este perfil de entrada debería ser posible mientras otros perfiles de entrada están activos.

Implicación para las implementaciones del Asistente

Requisitos sobre el uso de datos y la notificación al usuario

Debido a que el uso simultáneo del micrófono, si se abusa, puede filtrar datos privados del usuario, necesitamos que se apliquen las siguientes condiciones y garantías a las aplicaciones precargadas privilegiadas que solicitan tener 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 activa.
  • Las aplicaciones que escuchan al mismo tiempo deben proporcionar señales visuales al usuario después de que se detecte la palabra activa. Esto ayuda a los usuarios a comprender que las conversaciones posteriores se realizarían a través de una aplicación diferente, como Assistant.
  • Los usuarios deben tener la capacidad de 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

Asistentes que 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 cambiar entre los dos asistentes. En Android 10, el Asistente predeterminado puede estar escuchando al mismo tiempo que 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 de Asistente no predeterminadas, no hay ningún cambio en el comportamiento de Android 10.

Ejemplo de implementación de audio HAL

Un ejemplo de una aplicación de audio HAL cumplir con las directrices de este documento se puede encontrar en AOSP .