A HAL (Camada de abstração de hardware de sensores) é a interface entre Framework de sensores do Android e os sensores de um dispositivo, como um acelerômetro ou giroscópio A HAL de sensores define as funções que precisam ser implementadas para permitem que o framework controle os sensores.
A HAL de sensores AIDL está disponível no Android 13 e para dispositivos novos e atualizados. A HAL de sensores AIDL, que é baseada HAL 2.1 de sensores, usa o a HAL de interface AIDL e expõe o rastreador principal e os tipos de sensor de IMU de eixo limitado.
Interface HAL da AIDL
A principal fonte de documentação para a HAL de sensores AIDL está dentro da HAL em hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.
Implementar a HAL de sensores AIDL
Para implementar a HAL de sensores AIDL, um objeto precisa estender a ISensors.
e implementar todas as funções definidas
hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.
Inicializar a HAL
A HAL de sensores precisa ser inicializada pelo framework de sensores do Android antes
podem ser usadas. O framework chama a função initialize() para fornecer três
para a HAL de sensores: dois descritores FMQ e um ponteiro para um
objeto ISensorsCallback.
A HAL usa o primeiro descritor para criar o evento FMQ do evento usado para gravar o sensor
eventos ao framework. A HAL usa o segundo descritor para criar a função
FMQ de bloqueio usado para sincronizar quando a HAL libera o wake lock para WAKE_UP
eventos de sensor. A HAL precisa salvar um ponteiro para o objeto ISensorsCallback para que
que qualquer função de callback necessária possa ser invocada.
A função initialize() precisa ser a primeira chamada ao inicializar
a HAL de sensores.
Expor os sensores disponíveis
Para obter uma lista de todos os sensores estáticos disponíveis no dispositivo, use o método
função getSensorsList(). Essa função retorna uma lista de sensores, cada
identificados exclusivamente pelo identificador. A alça de um determinado sensor não pode mudar
quando o processo que hospeda a HAL de sensores é reiniciado. Os identificadores podem mudar
o dispositivo é reinicializado e após
as reinicializações do servidor do sistema.
Se vários sensores compartilharem o mesmo tipo de sensor e propriedades de ativação, o
o primeiro sensor da lista é chamado de sensor default e é retornado ao
apps que usam o getDefaultSensor(int sensorType, bool wakeUp)
função.
Lista de estabilidades da lista de sensores
Após a reinicialização da HAL de sensores, se os dados retornados por getSensorsList()
indica uma alteração significativa em comparação com a lista de sensores recuperada antes que o
reiniciar, o framework vai acionar o reinício da
ambiente de execução do Android. Mudanças significativas na lista de sensores incluem casos em que um
sensor com um determinado identificador está ausente ou mudou de atributos, ou quando novos atributos
são introduzidos. Embora reiniciar o ambiente de execução do Android seja prejudicial
para o usuário, ela é necessária porque o framework do Android não atende mais
A API do Android estabelece que os sensores estáticos (não dinâmicos) não mudam durante a
de um app. Isso também pode impedir que a estrutura restabeleça a
solicitações de sensor ativas feitas pelos aplicativos. Portanto, os fornecedores de HAL são aconselhados a
evitar alterações evitáveis na lista de sensores.
Para garantir identificadores estáveis, a HAL precisa mapear de forma determinista uma determinada sensor físico do dispositivo à alça. Embora não haja uma implementação específica é determinado pela interface HAL de sensores, os desenvolvedores têm várias opções disponíveis para atender a esse requisito.
Por exemplo, a lista de sensores pode ser classificada usando uma combinação das configurações
atributos fixos, como fornecedor, modelo e tipo de sensor. Outra opção depende
de que o conjunto de sensores estáticos do dispositivo está fixado no hardware,
A HAL precisa saber quando todos os sensores esperados concluíram a inicialização antes de terminar
retornando de getSensorsList(). Esta lista de
os sensores esperados podem ser compilados no binário da HAL ou armazenados
de configuração original no sistema de arquivos, e a ordem de aparência pode ser usada
para gerar identificadores estáveis. Embora a melhor solução dependa do sistema
detalhes específicos da implementação, o principal requisito é que o sensor processe
não mudam durante as reinicializações da HAL.
Configurar sensores
Antes de um sensor ser ativado, ele precisa ser configurado com um
e latência máxima de relatórios usando a função batch().
Um sensor precisa ser reconfigurado a qualquer momento usando batch() sem a
perda de dados do sensor.
Período de amostragem
O período de amostragem tem um significado diferente com base no tipo de sensor que é que está sendo configurado:
- Contínuo: os eventos do sensor são gerados em uma taxa contínua.
- Ao alterar: os eventos são gerados antes do período de amostragem e podem ser gerados em uma taxa mais lenta do que o período de amostragem se o valor medido não muda.
- One-shot: o período de amostragem é ignorado.
- Especial: para mais detalhes, consulte Tipos de sensor.
Para aprender sobre a interação entre um período de amostragem e o sensor modos de relatório, consulte Modos de relatórios.
Latência máxima de relatórios
A latência máxima de relatório define o tempo máximo, em nanossegundos, que os eventos podem ser atrasados e armazenados no FIFO do hardware antes de serem gravados no o evento FMQ pela HAL enquanto o SoC está ativado.
O valor zero significa que os eventos precisam ser informados medido, pulando o FIFO completamente ou esvaziando o FIFO assim que um evento do sensor está presente no FIFO.
Por exemplo, um acelerômetro ativado a 50 Hz com valor máximo de geração de relatórios. latência de zero gatilhos interrompe 50 vezes por segundo quando o SoC está ativo.
Quando a latência máxima de geração de relatórios é maior que zero, os eventos do sensor não precisam ser informadas assim que são detectadas. Os eventos podem ser temporariamente armazenadas no FIFO de hardware e relatadas em lotes, desde que nenhum evento seja atrasado por mais do que a latência máxima do relatório. Todos os eventos desde a para o lote anterior são registrados e retornados de uma vez. Isso reduz o número de interrompe enviadas ao SoC e permite que o SoC mude para um modo de energia mais baixo enquanto o sensor captura e agrupa dados em lotes.
Cada evento tem um carimbo de data/hora associado a ele. Atrasar o horário evento for informado não devem afetar o carimbo de data/hora do evento. O carimbo de data/hora precisa ser precisas e correspondem à hora em que o evento aconteceu fisicamente, não do horário em que foi reportado.
Para mais informações e requisitos sobre como informar eventos de sensores com o latência máxima de relatórios diferente de zero, consulte Agrupamento em lotes.
Ativar sensores
O framework ativa e desativa os sensores usando a função activate().
Antes de ativar um sensor, o framework precisa configurar o sensor
usando batch().
Depois que um sensor é desativado, os eventos adicionais desse sensor não podem gravadas no FMQ do evento.
Sensores de limpeza
Se um sensor estiver configurado para agrupar dados, o framework pode forçar
uma liberação imediata de eventos de sensor reunidos chamando flush(). Isso faz com que
que os eventos agrupados na alça do sensor especificado sejam abertos imediatamente
gravados no FMQ do evento. A HAL de sensores precisa anexar um evento de limpeza completa
ao final dos eventos do sensor gravados como resultado de uma chamada para
flush():
A limpeza ocorre de forma assíncrona (ou seja, esta função deve retornar imediatamente). Se a implementação usar um único FIFO para vários sensores, esse FIFO será limpa e o evento de limpeza completa é adicionado apenas para o sensor especificado.
Se o sensor especificado não tem FIFO (nenhum armazenamento em buffer possível) ou se o FIFO foi
vazio no momento da chamada, flush() ainda precisa ter êxito e enviar uma limpeza
evento completo desse sensor. Isso se aplica a todos os sensores, exceto os únicos
ou sensores.
Se flush() for chamado para um sensor único, flush() precisará retornar
BAD_VALUE e não gerar um evento de limpeza completa.
Gravar eventos do sensor no FMQ
O Event FMQ é usado pela HAL de sensores para enviar eventos do sensor ao Android framework de sensor.
A FMQ do evento é sincronizada, o que significa que qualquer tentativa de gravar mais para a FMQ do que o espaço disponível permite resultados em um ambiente gravação. Nesse caso, a HAL deve determinar se deve gravar o conjunto atual como dois grupos menores de eventos ou para escrever todos os eventos juntos quando há espaço suficiente disponível.
Quando a HAL de sensores gravar o número desejado de eventos do sensor no
FMQ de evento, a HAL de sensores precisa notificar o framework de que os eventos estão prontos
gravar o bit EventQueueFlagBits::READ_AND_PROCESS no evento FMQ do evento
função EventFlag::wake. A EventFlag pode ser criada no evento FMQ
usando EventFlag::createEventFlag e o getEventFlagWord() do evento FMQ
função.
A HAL de sensores AIDL é compatível com write e writeBlocking no FMQ de eventos.
A implementação padrão fornece uma referência para usar write. Se o
a função writeBlocking for usada, a sinalização readNotification precisa ser definida como
EventQueueFlagBits::EVENTS_READ, que é definido pelo framework quando ele lê
do Event FMQ. O flag de notificação de gravação precisa ser definido como
EventQueueFlagBits::READ_AND_PROCESS, que notifica o framework de que os eventos
foram gravadas no FMQ do evento.
Eventos WAKE_UP
Eventos WAKE_UP são eventos do sensor que fazem com que o processador do aplicativo (AP)
acordar e lidar com o evento imediatamente. Sempre que um evento WAKE_UP é gravado
à FMQ do evento, a HAL de sensores precisa proteger um wake lock para garantir que o
o sistema permanece ativo até que o framework consiga lidar com o evento. Ao receber uma
WAKE_UP, o framework protege o próprio wake lock, permitindo que
A HAL de sensores é usada para liberar o wake lock. Para sincronizar quando a HAL de sensores
liberar o wake lock, use o FMQ do Wake Lock.
A HAL de sensores precisa ler o FMQ do Wake Lock para determinar o número de WAKE_UP
eventos que o framework processou. A HAL só deve liberar o wake lock
para eventos WAKE_UP se o número total de eventos WAKE_UP não processados for zero.
Depois de lidar com eventos do sensor, o framework conta o número de eventos
marcado como eventos WAKE_UP e grava esse número de volta no FMQ do Wake Lock.
O framework define a gravação WakeLockQueueFlagBits::DATA_WRITTEN
notificação no FMQ do Wake Lock sempre que ele grava dados nesse FMQ.
Sensores dinâmicos
Sensores dinâmicos são aqueles que não fazem parte fisicamente do dispositivo, mas podem ser usada como entrada para o dispositivo, como um gamepad com acelerômetro.
Quando um sensor dinâmico é conectado, a função onDynamicSensorConnected
É preciso chamar ISensorsCallback na HAL de sensores. Isso notifica o
do novo sensor dinâmico e permite que ele seja controlado
pelo framework e que os eventos do sensor sejam consumidos pelos clientes.
Da mesma forma, quando um sensor dinâmico é desconectado,
A função onDynamicSensorDisconnected em ISensorsCallback precisa ser chamada
que o framework possa remover qualquer sensor que não esteja mais disponível.
Canal direto
O canal direto é um método de operação em que os eventos do sensor são gravados
memória específica, em vez de a FMQ de eventos ignorando os sensores do Android.
de machine learning. Um cliente que registra um canal direto precisa ler os eventos do sensor
diretamente da memória usada para criar o canal direto e não
e receber os eventos do sensor pelo framework. O configDirectReport()
é semelhante a batch() para operação normal e configura a função
canal de denúncia.
As funções registerDirectChannel() e unregisterDirectChannel() criam
ou destruir um novo canal direto.
Modos de operação
A função setOperationMode() permite que o framework configure um sensor
para que o framework possa injetar dados do sensor no sensor. Isso é útil para
de testes, especialmente para algoritmos que existem abaixo do framework.
A função injectSensorData() normalmente é usada para enviar comandos
para a HAL de sensores. A função também pode ser usada para injetar
em um sensor específico.
Validação
Para validar sua implementação da HAL de sensores, execute os sensores CTS e VTS provas.
Testes CTS
Os testes CTS de sensor estão disponíveis tanto em testes de CTS quanto no verificador manual de CTS app.
Os testes automatizados estão localizados em cts/tests/sensor/src/android/hardware/cts Esses testes verificam a funcionalidade padrão dos sensores, como ativar como sensores, lotes e taxas de eventos do sensor.
Os testes do CTS Verifier estão localizados em cts/apps/CtsVerifier/src/com/android/cts/verifier/sensors Esses testes exigem entrada manual do operador e garantem que os sensores informar valores precisos.
A aprovação nos testes de CTS é essencial para garantir que o dispositivo em teste atenda todos os requisitos do CDD.
Testes VTS
Os testes VTS para a HAL de sensores AIDL estão localizados em
hardware/interfaces/sensors/aidl/vts/.
Esses testes garantem que a HAL de sensores seja implementada corretamente e que todos
requisitos em ISensors.aidl e ISensorsCallback.aidl sejam atendidos adequadamente.
Inicializar a HAL
A função initialize() precisa ser compatível para estabelecer FMQs entre os
e HAL.
Expor os sensores disponíveis
Na HAL de sensores AIDL, a função getSensorsList() precisa retornar o mesmo valor.
durante a inicialização de um único dispositivo, mesmo entre reinicializações da HAL de sensores. Um novo requisito
da função getSensorsList() é que ela precisa retornar o mesmo valor durante
inicialização de um único dispositivo, mesmo durante as reinicializações da HAL de sensores. Isso permite que
para tentar restabelecer as conexões do sensor se o servidor do sistema
reinicializações. O valor retornado por getSensorsList() pode mudar depois que o dispositivo
executa uma reinicialização.
Gravar eventos do sensor no FMQ
Em vez de esperar que poll() seja chamado, na HAL de sensores AIDL, os sensores
A HAL precisa gravar proativamente eventos do sensor no evento FMQ do evento sempre que esses eventos
estão disponíveis. A HAL também é responsável por gravar os bits corretos para
EventFlag para gerar uma leitura de FMQ no framework.
Eventos WAKE_UP
Na HAL de sensores 1.0, a HAL liberava o wake lock para qualquer WAKE_UP
evento em qualquer chamada subsequente para poll() depois que um WAKE_UP for postado para
poll() porque isso indicou que o framework processou todos os sensores
eventos de segurança e obtivesse um wake lock, se necessário. Porque, na AIDL de sensores
HAL, a HAL não é mais notificada quando o framework processa eventos
gravados no FMQ, o FMQ do Wake Lock permite que o framework se comunique com o
HAL quando processam eventos WAKE_UP.
Na HAL de sensores AIDL, o wake lock protegido pela HAL de sensores para WAKE_UP
os eventos precisam começar com SensorsHAL_WAKEUP.
Sensores dinâmicos
Os sensores dinâmicos foram retornados usando a função poll() na HAL 1.0 de sensores.
A HAL de sensores AIDL exige que onDynamicSensorsConnected e
onDynamicSensorsDisconnected em ISensorsCallback será chamado sempre que
nas conexões do sensor. Esses callbacks estão disponíveis como parte
Ponteiro ISensorsCallback fornecido pela função initialize().
Modos de operação
O modo DATA_INJECTION para sensores WAKE_UP precisa ser compatível.
Suporte a várias HAL
A HAL de sensores AIDL oferece suporte a várias HAL usando a Framework de vários HAL de sensores. Para detalhes de implementação, consulte Portabilidade a partir de sensores HAL 2.1