Captura simultânea

O Android 10 melhora a experiência do usuário que exige mais de uma captura de áudio ativa simultânea. Por exemplo, se o usuário quiser controlar uma chamada VoIP ou um gravador de vídeo com comandos de voz fornecidos por um serviço de acessibilidade.

A estrutura de áudio implementa a política, permitindo que apenas determinados apps privilegiados capturem simultaneamente com apps comuns.

A política de simultaneidade é implementada silenciando o áudio capturado em vez de impedir que um aplicativo comece a capturar. Isso permite que a estrutura processe dinamicamente mudanças no número e nos tipos de casos de uso de captura ativa, sem impedir que um app comece a capturar em um caso em que ele pode recuperar o acesso total ao microfone depois que outro app terminar a captura.

A consequência para a HAL de áudio e o subsistema de áudio é que eles precisam oferecer suporte a vários streams de entrada ativos simultaneamente, mesmo que, em alguns casos, apenas um stream esteja fornecendo áudio não silencioso para um cliente ativo.

Requisitos do CDD

Consulte o CDD para os requisitos de suporte à captura simultânea.

Capturar situações da HAL de áudio

Um cenário de captura simultânea pode resultar em diferentes situações em termos de número de fluxos de entrada ativos, seleção de dispositivos de entrada ou configuração de pré-processamento.

A simultaneidade pode ocorrer entre:

  • Vários fluxos de entrada do processador de aplicativos (AP)
  • Fluxos de entrada e uma chamada de voz
  • Streams de entrada e um DSP de áudio que implementa uma detecção de hotword de baixa potência

Atividade simultânea de fluxos de entrada de AP

O arquivo de configuração da política de áudio audio_policy_configuration.xml é usado pelo framework de áudio para determinar quantas transmissões de entrada podem ser abertas e ativas simultaneamente.

No mínimo, o HAL de áudio precisa oferecer suporte a pelo menos uma instância de cada perfil de entrada (mixPort da função sink) listada no arquivo de configuração aberto e ativo.

Seleção de dispositivo

Quando vários clientes ativos estão conectados ao mesmo fluxo de entrada da HAL, o framework seleciona o dispositivo adequado para esse fluxo de entrada com base na prioridade do caso de uso.

Quando vários fluxos de entrada estão ativos, cada um pode ter uma seleção de dispositivo diferente.

Se a tecnologia for compatível, é recomendável que a HAL de áudio e o subsistema permitam que diferentes streams capturem de dispositivos diferentes, como um fone de ouvido Bluetooth e um microfone integrado.

Se houver uma incompatibilidade (por exemplo, dois dispositivos compartilham a mesma interface de áudio digital ou back-end), o HAL de áudio precisará escolher qual stream controla a seleção do dispositivo.

Neste caso:

  • O estado resultante precisa ser consistente e oferecer a mesma seleção de dispositivo quando o mesmo cenário é repetido.
  • Quando o estado de simultaneidade termina, o fluxo ativo restante precisa ser encaminhado para o dispositivo inicialmente solicitado nesse fluxo.

Se uma ordem de prioridade for definida pelo HAL de áudio entre casos de uso ativos, siga a mesma ordem encontrada em source_priority() em frameworks/av/services/audiopolicy/common/include/policy.h.

Seleção de pré-processamento

A estrutura de áudio pode solicitar o pré-processamento em um fluxo de entrada usando os métodos addEffect() ou removeEffect() HAL.

Para pré-processamento em um determinado stream de entrada, o framework de áudio ativa apenas a configuração correspondente ao caso de uso ativo de maior prioridade no stream de entrada. No entanto, pode haver alguma sobreposição durante a ativação e desativação do caso de uso, fazendo com que dois processos ativos simultâneos (por exemplo, duas instâncias do cancelador de eco) sejam executados no mesmo fluxo de entrada. Nesse caso, a implementação da HAL escolhe qual solicitação é aceita, acompanha as solicitações ativas e restaura o estado correto quando um dos processos é desativado.

Quando vários fluxos de captura estão ativos simultaneamente, diferentes solicitações de pré-processamento podem ser executadas em fluxos diferentes.

As implementações de HAL e subsistema de áudio precisam permitir que pré-processamentos diferentes sejam aplicados a streams diferentes, mesmo que eles compartilhem o mesmo dispositivo de entrada. Ou seja, o pré-processamento deve ser aplicado depois da demuxagem dos fluxos da fonte de captura principal.

Se não for possível por motivos técnicos em um determinado subsistema de áudio, a HAL de áudio vai aplicar regras de prioridade semelhantes às listadas em Seleção de dispositivo.

Chamada de voz e captura simultâneas do PA

A captura do AP pode acontecer enquanto uma chamada de voz está ativa. Essa situação não é nova no Android 10 e não está diretamente relacionada ao recurso de captura simultânea, mas é útil mencionar as diretrizes para esse cenário.

Dois tipos diferentes de captura do PA são necessários durante uma chamada.

Capturar RX e TX de chamadas

A captura de RX e TX de chamadas é acionada pelo uso da fonte de áudio AudioSource.VOICE_UPLINK ou AudioSource.VOICE_DOWNLINK e/ou do dispositivo AudioDevice.IN_TELEPHONY_RX.

As HALs de áudio precisam ser expostas em um perfil de entrada (mixPort da função sink) com uma rota disponível do dispositivo AudioDevice.IN_TELEPHONY_RX.

Quando uma chamada é conectada (o modo de áudio é AudioMode.IN_CALL), é possível ter pelo menos um fluxo de captura ativo do dispositivo AudioDevice.IN_TELEPHONY_RX.

Capturar de dispositivos de entrada quando uma chamada está ativa

Quando uma chamada está ativa (o modo de áudio é AudioMode.IN_CALL), é possível abrir e ativar fluxos de entrada do AP conforme especificado na seção Atividade simultânea de fluxos de entrada do AP.

No entanto, a prioridade para seleção de dispositivos e pré-processamento sempre deve ser determinada pela chamada de voz em caso de conflito com as solicitações dos fluxos de entrada de AP.

Captura simultânea de DSP e AP

Quando o subsistema de áudio contém um DSP que oferece suporte a contexto de áudio de baixa potência ou funções de detecção de palavra-chave ativação, a implementação precisa oferecer suporte à captura simultânea do AP e do DSP de áudio. Isso inclui a captura pelo DSP durante a fase inicial de detecção e a captura pelo AP com AudioSource.HOTWORD depois que a detecção é acionada pelo DSP.

Isso precisa ser refletido pela flag de captura simultânea informada pelo HAL de gatilho por som via o descritor de implementação: ISoundTriggerHw.Properties.concurrentCapture = true.

O HAL de áudio também precisa expor e inserir um perfil específico para captura de palavra-chave de ativação identificado pela flag AudioInputFlag.HW_HOTWORD. A implementação precisa oferecer suporte à abertura e ativação de um número de fluxos nesse perfil pelo menos igual ao número de modelos de som que podem ser carregados simultaneamente pelo HAL de gatilho por som.

A captura desse perfil de entrada deve ser possível enquanto outros perfis de entrada estão ativos.

Implicação para implementações do Google Assistente

Requisitos sobre uso de dados e notificação do usuário

Como o uso simultâneo do microfone, se abusado, pode vazar dados particulares do usuário, precisamos que as seguintes condições e garantias sejam aplicadas aos apps privilegiados pré-carregados que pedem para manter a função do Google Assistente.

  • Os dados coletados pelo microfone não devem sair do dispositivo, a menos que o usuário esteja interagindo com o Google Assistente. Por exemplo, depois que a palavra-chave de ativação é acionada.
  • Os aplicativos que estão ouvindo simultaneamente precisam fornecer indicadores visuais ao usuário depois que a palavra de ativação é detectada. Isso ajuda os usuários a entender que outras conversas seriam feitas por um app diferente, como o Google Assistente.
  • Os usuários precisam ter a opção de desativar o microfone ou os gatilhos do Google Assistente.
  • Quando as gravações de áudio são armazenadas, os usuários precisam ter a capacidade de acessar, analisar e excluir as gravações a qualquer momento.

Melhorias funcionais para o Android 10

Os assistentes não se bloqueiam

No Android 9 ou versões anteriores, quando há dois Assistentes sempre ativos no dispositivo, apenas um deles pode estar ouvindo a palavra de ativação. Por isso, era necessário alternar entre os dois assistentes. No Android 10, o Assistente padrão pode ouvir ao mesmo tempo que o outro Assistente. Isso resulta em uma experiência muito mais tranquila para os usuários com os dois assistentes.

Apps que mantêm o microfone aberto

Quando apps como Shazam ou Waze mantêm o microfone aberto, o Google Assistente padrão ainda pode estar ouvindo a hotword.

Para apps não padrão do Google Assistente, não há mudança no comportamento do Android 10.

Exemplo de implementação da HAL de áudio

Um exemplo de implementação de HAL de áudio em conformidade com as diretrizes deste documento pode ser encontrado no AOSP.