Captura simultânea

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

O framework de áudio implementa a política que permite que apenas determinados apps privilegiados capturem simultaneamente com apps normais.

A política de simultaneidade é implementada silenciando o áudio capturado em vez de impedir que um aplicativo inicie a captura. Isso permite que o framework lide dinamicamente com mudanças no número e nos tipos de casos de uso de captura ativa, sem impedir que um app inicie a captura em um caso em que ele possa 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 a um cliente ativo.

Requisitos do CDD

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

Capturar situações com a HAL de áudio

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

A simultaneidade pode acontecer entre:

  • Vários streams de entrada do processador de aplicativos (AP, na sigla em inglês)
  • Streams de entrada e uma ligação
  • Entradas de stream e um DSP de áudio que implementa uma detecção de hotword de baixo consumo de energia

Atividade simultânea de streams 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 quantos streams de entrada podem ser abertos e ativados simultaneamente.

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

Seleção de dispositivo

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

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

Se a tecnologia for compatível, é recomendável que o HAL de áudio e o subsistema permitam que diferentes streams sejam capturados 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), a 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 dispositivos quando o mesmo cenário se repete.
  • Quando o estado de simultaneidade termina, o fluxo ativo restante precisa ser roteado 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

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

Para o pré-processamento em um determinado stream de entrada, o framework de áudio só ativa 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 de cancelamento de eco) sejam executados no mesmo fluxo de entrada. Nesse caso, a implementação da HAL escolhe qual solicitação é aceita. Ela monitora as solicitações ativas e restaura o estado correto quando um processo é desativado.

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

As implementações do HAL e do subsistema de áudio precisam permitir que diferentes pré-processamentos sejam aplicados a streams diferentes, mesmo que compartilhem o mesmo dispositivo de entrada. Ou seja, o pré-processamento precisa ser aplicado após a multiplexação dos streams da fonte de captura principal.

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

Ligação de voz e captura simultâneas do AP

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 AP 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 no perfil de entrada (mixPort do papel 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 stream de captura ativo do dispositivo AudioDevice.IN_TELEPHONY_RX.

Capturar em dispositivos de entrada quando uma chamada estiver ativa

Quando uma chamada está ativa (o modo áudio é AudioMode.IN_CALL), pode ser 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 a seleção de dispositivos e o pré-processamento sempre precisa ser orientado pela chamada de voz, caso haja um conflito com as solicitações dos fluxos de entrada do AP.

Captura simultânea de DSP e AP

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

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

A HAL de áudio também precisa expor e inserir um perfil específico para a captura de palavra-chave identificada pela flag AudioInputFlag.HW_HOTWORD. A implementação precisa oferecer suporte para abrir e ativar um número de streams nesse perfil pelo menos igual ao número de modelos de som que podem ser carregados simultaneamente pelo HAL do gatilho de som.

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

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

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

Como o uso simultâneo do microfone pode vazar dados particulares do usuário, precisamos que as condições e garantias abaixo sejam aplicadas aos apps pré-carregados privilegiados que solicitam a função de Assistente.

  • Os dados coletados pelo microfone não podem sair do dispositivo, a menos que o usuário esteja interagendo com o Google Assistente. Por exemplo, depois que o comando de ativação é acionado.
  • Os aplicativos que estão ouvindo em paralelo precisam fornecer dicas visuais ao usuário depois que o comando de ativação for detectado. Isso ajuda os usuários a entender que outras conversas serão feitas em um app diferente, como o Google Assistente.
  • Os usuários precisam ter a opção de desativar o microfone ou os acionadores do Google Assistente.
  • Quando as gravações de áudio forem armazenadas, os usuários poderão acessar, revisar e excluir as gravações a qualquer momento.

Melhorias funcionais para o Android 10

Os assistentes não estão bloqueando um ao outro

No Android 9 ou versões anteriores, quando há dois Google Assistentes sempre ativos no dispositivo, apenas um deles pode detectar a palavra de ativação. Por isso, era necessário alternar entre os dois Assistentes. No Android 10, o Google Assistente padrão pode ouvir em paralelo com o outro. 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 o Shazam ou o Waze mantêm o microfone aberto, o Google Assistente padrão ainda pode ouvir a hotword.

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

Exemplo de implementação de HAL de áudio

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