Gatilho de som

O recurso Sound Trigger oferece aos apps a capacidade de detectar determinados eventos acústicos, como palavras-chave, de maneira discreta e com foco na privacidade. Exemplos de casos de uso do Sound Trigger são o Google Assistente e o Tocando agora.

Esta página oferece uma visão geral da arquitetura do Sound Trigger e da interface HAL (camada de abstração de hardware).

Stack do Sound Trigger

O subsistema Sound Trigger é criado em camadas, conforme mostrado na Figura 1:

sound_trigger_stack

Figura 1:stack do Sound Trigger

A lista a seguir descreve cada camada mostrada na Figura 1 com mais detalhes:

  • A camada HAL (em verde) contém o código específico do fornecedor que implementa a interface HAL do Sound Trigger (STHAL).

  • O SoundTriggerMiddleware (em amarelo) reside acima da interface HAL. Ele se comunica com a HAL e é responsável por funcionalidades como o compartilhamento da HAL entre diferentes clientes, registro, aplicação de permissões e tratamento de compatibilidade com versões mais antigas da HAL.

  • O sistema SoundTriggerService (em azul) reside acima do middleware. Ele facilita a integração com outros recursos do sistema, como eventos de telefonia e bateria. Ele também mantém um banco de dados de modelos de som, indexados por IDs exclusivos.

  • Acima da camada SoundTriggerService, a stack (em marrom) processa recursos específicos do Google Assistente e apps genéricos separadamente.

A função da stack do Sound Trigger é fornecer eventos discretos que representam eventos acústicos de acionamento. Na maioria dos casos, a stack do Sound Trigger não lida com áudio. Ao receber os eventos de acionamento, os apps acessam o fluxo de áudio real, que envolve o tempo dos eventos, abrindo um objeto AudioRecord pela estrutura de áudio. As APIs HAL do Sound Trigger fornecem um identificador com o evento acionado que é usado com a estrutura de áudio. Portanto, como a HAL do Sound Trigger e a HAL de áudio estão conectadas nos bastidores, elas normalmente compartilham um processo.

Interface HAL do Sound Trigger

A interface HAL do Sound Trigger (STHAL) é a parte específica do fornecedor da stack do Sound Trigger e processa o reconhecimento de hardware de palavras-chave e outros sons. A STHAL fornece um ou mais mecanismos, cada um executando um algoritmo diferente projetado para detectar uma classe específica de sons. Quando a STHAL detecta um acionador, ela envia um evento para a estrutura e interrompe a detecção.

A interface STHAL é especificada em /hardware/interfaces/soundtrigger/.

A interface ISoundTriggerHw oferece suporte à capacidade de ter uma ou mais sessões de detecção em execução em um determinado momento e de detectar eventos acústicos. Uma chamada para ISoundTriggerHw.getProperties() retorna uma estrutura Properties que contém a descrição e os recursos da implementação.

O fluxo básico de configuração de uma sessão é explicado da seguinte maneira na Figura 2:

sthal_state

Figura 2:diagrama de estado da STHAL

As etapas a seguir descrevem cada estado com mais detalhes:

  1. O cliente HAL carrega um modelo usando loadSoundModel() ou loadPhraseSoundModel(). O objeto de modelo fornecido indica qual algoritmo de detecção específico da implementação (mecanismo) usar, bem como os parâmetros aplicáveis a esse algoritmo. Quando bem-sucedidos, esses métodos retornam um identificador usado para referenciar esse modelo em chamadas subsequentes.

  2. Depois que o modelo é carregado, o cliente HAL chama startRecognition() para iniciar a detecção. O reconhecimento continua sendo executado em segundo plano até que um dos seguintes eventos ocorra:

    1. Um stopRecognition() foi chamado nesse modelo.
    2. Uma detecção ocorreu.
    3. A detecção é interrompida devido a restrições de recursos, por exemplo, quando um caso de uso de maior prioridade é iniciado.

    Nos dois últimos casos, um evento de reconhecimento é enviado pela interface de callback registrada pelo cliente HAL após o carregamento. Em todos os casos, depois que um desses eventos ocorre, a detecção fica inativa e não são permitidos mais callbacks de reconhecimento.

    O mesmo modelo pode ser iniciado novamente mais tarde, e esse processo pode ser repetido quantas vezes forem necessárias.

  3. Por fim, um modelo inativo que não é mais necessário é descarregado pelo cliente HAL usando unloadModel().

Tratar erros da HAL

Para garantir um comportamento confiável e consistente entre as implementações de driver, no Android 11, todos os códigos de erro não bem-sucedidos retornados da HAL são tratados como erros de programação, cuja recuperação exige a reinicialização do processo da HAL. Essa é uma estratégia de recuperação de último recurso, e a expectativa é que esses casos não ocorram em um sistema funcionando corretamente.