Gatilho de som

O recurso de ativação por som permite que os apps detectem determinados eventos acústicos, como palavras-chave de ativação, de maneira eficiente e com foco na privacidade. Exemplos de casos de uso do gatilho por som são o Google Assistente e o recurso "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).

Pilha de ativação por som

O subsistema de ativação por som é criado em camadas, conforme mostrado na Figura 1:

sound_trigger_stack

Figura 1:pilha do Sound Trigger.

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

  • A camada HAL (em verde) contém o código específico do fornecedor que implementa a interface HAL de ativação por som (STHAL, na sigla em inglês).

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

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

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

A função da pilha de gatilho de som é fornecer eventos discretos que representam eventos acústicos e de acionamento. Na maioria dos casos, a pilha do gatilho por som não lida com áudio. Ao receber os eventos de acionamento, os apps acessam o stream de áudio real, que envolve o horário dos eventos, abrindo um objeto AudioRecord usando o framework de áudio. As APIs HAL de ativação por som fornecem um identificador com o evento acionado que é usado com o framework de áudio. Portanto, como o HAL de gatilho de som e o HAL de áudio estão conectados nos bastidores, eles geralmente compartilham um processo.

Interface HAL do Sound Trigger

A interface HAL de gatilho de som (STHAL) é a parte específica do fornecedor da pilha de gatilho de som e processa o reconhecimento de hardware de hotwords e outros sons. O STHAL fornece um ou mais mecanismos, cada um executando um algoritmo diferente projetado para detectar uma classe específica de sons. Quando o STHAL detecta um gatilho, ele envia um evento para o framework e interrompe a detecção.

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

A interface ISoundTriggerHw permite ter uma ou mais sessões de detecção em execução ao mesmo tempo e 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 forma na Figura 2:

sthal_state

Figura 2:diagrama de estado do STHAL.

As etapas a seguir descrevem cada estado em mais detalhes:

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

  2. Depois que o modelo for carregado, o cliente HAL vai chamar 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 neste 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 ao carregar. Em todos os casos, depois que um desses eventos ocorre, a detecção fica inativa e não são permitidas 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 via unloadModel().

Processar erros de 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.