Gatilho de som

O recurso de gatilho de som oferece aos apps a capacidade de detectar determinados eventos acústicos, como palavras-chave, com baixo consumo de energia e sensibilidade à 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 Sound Trigger 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:

sound_trigger_stack

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 separadamente os recursos específicos do Google Assistente e dos apps genéricos.

A função da pilha do acionador de som é entregar eventos discretos que representam eventos acústicos e acionados. Na maioria dos casos, a pilha do acionador 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 do 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 de configuração de 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 específico da implementação (motor) usar, além dos 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 for carregado, o cliente HAL vai chamar startRecognition() para iniciar a detecção. O reconhecimento continua em execução em segundo plano até que um dos seguintes eventos ocorra:

    1. Uma stopRecognition() foi chamada 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 HAL ao carregar. 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.