Gatilho de som

O recurso Acionador de som oferece aos apps a capacidade de detectar determinados eventos acústicos, como hotwords, com baixo consumo de energia e que respeitam a privacidade. Exemplos de casos de uso do Acionador de som são o Google Assistente e o Agora tocando.

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

Pilha de gatilho de som

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

pilha_acionador_de_som

Figura 1. Pilha de gatilho de som

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 de gatilho de som (STHAL).

  • O SoundTriggerMiddleware (em amarelo) fica acima da interface HAL. Ele se comunica com o HAL e é responsável por funcionalidades como compartilhar o HAL entre diferentes clientes, gerar registros, aplicar permissões e processar a compatibilidade com versões mais antigas do HAL.

  • O sistema SoundTriggerService (em azul) fica 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 pilha (em marrom) processa recursos específicos do Google Assistente e de apps genéricos separadamente.

A função da pilha de acionadores de som é enviar eventos discretos que representam eventos acionadores acústicos. Na maioria dos casos, a pilha de acionadores de som não lida com áudio. Após o recebimento dos eventos de gatilho, os apps recebem acesso ao stream de áudio real, em torno do horário dos eventos, abrindo um objeto AudioRecord pelo framework de áudio. As APIs HAL de gatilho de som fornecem um identificador com o evento acionado que é usado com o framework de áudio. Portanto, como o HAL do gatilho de som e o HAL de áudio estão conectados, eles normalmente compartilham um processo.

Interface HAL do gatilho de som

A interface HAL de gatilho de som (STHAL, na sigla em inglês) é a parte específica do fornecedor da pilha de gatilho de som e processa o reconhecimento de hardware de palavras de ativação 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 oferece suporte a uma ou mais sessões de detecção em execução em um determinado momento e a 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 para configurar uma sessão é explicado da seguinte forma na Figura 2:

sthal_state

Figura 2. Diagrama de estado da 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 de detecção (mecanismo) específico de implementação usar, bem como os parâmetros aplicáveis a esse algoritmo. Se bem-sucedidos, esses métodos retornam um identificador que é usado para referenciar esse modelo em chamadas subsequentes.

  2. Depois que o modelo é carregado, o cliente da 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 neste modelo.
    2. Uma detecção ocorreu.
    3. A detecção é abortada devido a restrições de recursos, por exemplo, quando um caso de uso de prioridade mais alta foi iniciado.

    Nos dois últimos casos, um evento de reconhecimento é enviado pela interface de callback, registrada pelo cliente da HAL no carregamento. Em todos os casos, depois que um desses eventos ocorre, a detecção fica inativa e nenhum outro callback de reconhecimento é permitido.

    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 é removido pelo cliente HAL por unloadModel().

Processar erros do HAL

Para garantir um comportamento confiável e consistente entre as implementações de drivers, no Android 11, todos os códigos de erro que não indicam sucesso retornados pelo HAL são tratados como erros de programação. A recuperação deles requer a reinicialização do processo HAL. Essa é uma estratégia de recuperação de último recurso, e a expectativa é que esses casos não ocorram em um sistema que funcione corretamente.