O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Sensores HAL 2

O Sensors Hardware Abstraction Layer (HAL) é a interface entre a estrutura do sensor Android e os sensores de um dispositivo, como um acelerômetro ou giroscópio. O Sensors HAL define as funções que devem ser implementadas para permitir que a estrutura controle os sensores.

Sensores HAL 2.0 está disponível no Android 10 e superior para dispositivos novos e atualizados. Sensores HAL 2,0 baseia-se em sensores de HAL 1.0 mas tem várias diferenças importantes, o que impede que ela seja compatível. Utiliza sensores HAL 2.0 Fast Message Queues (FMQs) para enviar eventos do sensor do HAL no quadro sensor de Android.

Sensores HAL 2.1 está disponível no Android 11 e superior para dispositivos novos e atualizados. Sensores HAL 2.1 é uma iteração de sensores HAL 2.0 que expõe o HINGE_ANGLE tipo de sensor e actualiza vários métodos para aceitar o HINGE_ANGLE tipo.

Interface HAL 2.1

A principal fonte de documentação para Sensores HAL 2.1 está dentro da definição HAL em hardware / interfaces / sensores / 2.1 / ISensors.hal . Se houver um conflito de requisitos entre esta página e ISensors.hal , utilize o requisito do ISensors.hal .

Interface HAL 2.0

A principal fonte de documentação para sensores de HAL 2.0 está dentro da definição de HAL em hardware / interfaces de sensores / / 2,0 / ISensors.hal . Se houver um conflito de requisitos entre esta página e ISensors.hal , utilize o requisito do ISensors.hal .

Implementando Sensores HAL 2.0 e HAL 2.1

Para implementar Sensores HAL 2,0 ou 2,1, um objecto tem de estender o ISensors interface e implementar todas as funções definidas em 2.0/ISensors.hal ou 2.1/ISensors.hal .

Inicializando o HAL

O Sensors HAL deve ser inicializado pela estrutura de sensores do Android antes de poder ser usado. A estrutura apela a initialize() função para HAL 2.0 e o initialize_2_1() função para HAL 2.1 para fornecer três parâmetros para os sensores HAL: dois FMQ descritores e um ponteiro para uma ISensorsCallback objecto.

O HAL usa o primeiro descritor para criar o Event FMQ usado para gravar eventos de sensor na estrutura. O HAL usa o segundo descritor para criar o Wake Bloqueio FMQ usado para sincronizar quando o HAL libera seu bloqueio esteira para WAKE_UP eventos sensor. O HAL deve guardar um ponteiro para o ISensorsCallback objecto de modo a que todas as funções de chamada de retorno necessários pode ser invocado.

O initialize() ou initialize_2_1() função deve ser a primeira função chamada quando inicializar o Sensores HAL.

Exposição dos sensores disponíveis

Para obter uma lista de todos os sensores estáticos disponíveis no dispositivo, use o getSensorsList() função no HAL 2.0 e getSensorsList_2_1() função no HAL 2.1. Esta função retorna uma lista de sensores, cada um identificado exclusivamente por seu identificador. O identificador de um determinado sensor não deve ser alterado quando o processo que hospeda o HAL dos sensores for reiniciado. Os identificadores podem mudar nas reinicializações do dispositivo e nas reinicializações do servidor do sistema.

Se vários sensores compartilham o mesmo tipo de sensor e propriedade wake-up, em seguida, o primeiro sensor na lista é chamado o sensor padrão e é devolvido para aplicativos que utilizam o getDefaultSensor(int sensorType, bool wakeUp) função.

Estabilidade da lista de sensores

Após uma reinicialização Sensores HAL, se os dados retornados por getSensorsList() ou getSensorsList_2_1() indica uma mudança significativa em comparação com a lista de sensores recuperado antes do reinício, o quadro provoca um reinício do tempo de execução 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 onde novos sensores são introduzidos. Embora reiniciar o tempo de execução do Android seja prejudicial para o usuário, é necessário porque a estrutura do Android não pode mais cumprir o contrato de API do Android de que os sensores estáticos (não dinâmicos) não mudam durante a vida útil de um aplicativo. Isso também pode impedir que a estrutura restabeleça solicitações de sensores ativos feitas por aplicativos. Portanto, os fornecedores de HAL são aconselhados a evitar alterações evitáveis ​​na lista de sensores.

Para garantir alças de sensor estáveis, o HAL deve mapear deterministicamente um determinado sensor físico no dispositivo para sua alça. Embora nenhuma implementação específica seja exigida pela interface Sensors HAL, 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 de atributos fixos de cada sensor, como fornecedor, modelo e tipo de sensor. Outra opção se baseia no fato de que conjunto de sensores estáticos do dispositivo é fixado no hardware, de modo que o HAL precisa saber quando todos os sensores esperados ter concluído a inicialização antes de retornar da getSensorsList() ou getSensorsList_2_1() . Esta lista de sensores esperados pode ser compilada no binário HAL ou armazenada em um arquivo de configuração no sistema de arquivos, e a ordem de aparecimento pode ser usada para derivar identificadores estáveis. Embora a melhor solução dependa dos detalhes de implementação específicos do seu HAL, o principal requisito é que os identificadores do sensor não mudem nas reinicializações do HAL.

Configurando sensores

Antes de um sensor é activado, o sensor tem de ser configurado com um período de amostragem e máxima informando latência usando o batch() função.

Um sensor deve ser capaz de ser reconfigurados a qualquer altura utilizando batch() sem a perda dos dados do sensor.

Período de amostragem

O período de amostragem tem um significado diferente com base no tipo de sensor que está sendo configurado:

  • Contínuo: os eventos do sensor são gerados em uma taxa contínua.
  • Em mudança: Os eventos não são gerados mais rápido do que o período de amostragem e podem ser gerados a uma taxa mais lenta do que o período de amostragem se o valor medido não mudar.
  • One-shot: O período de amostragem é ignorado.
  • Especial: Para mais detalhes, consulte tipos de sensores .

Para saber mais sobre a interação entre um período de amostragem e modos de comunicação de um sensor, vide Relatórios Modos .

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 hardware FIFO antes de serem gravados no Event FMQ por meio do HAL enquanto o SoC está ativo.

Um valor zero significa que os eventos devem ser relatados assim que forem medidos, ignorando o FIFO completamente ou esvaziando o FIFO assim que um evento do sensor estiver presente no FIFO.

Por exemplo, um acelerômetro ativado a 50 Hz com uma latência máxima de relatório de zero dispara interrupções 50 vezes por segundo quando o SoC está ativo.

Quando a latência máxima do relatório é maior que zero, os eventos do sensor não precisam ser relatados assim que forem detectados. Os eventos podem ser armazenados temporariamente no FIFO de hardware e relatados em lotes, desde que nenhum evento seja atrasado mais do que a latência máxima de relatório. Todos os eventos desde o lote anterior são registrados e retornados de uma vez. Isso reduz o número de interrupções enviadas ao SoC e permite que o SoC mude para um modo de energia mais baixa enquanto o sensor está capturando e agrupando dados.

Cada evento possui um carimbo de data / hora associado a ele. Atrasar a hora em que um evento é relatado não deve impactar o registro de data e hora do evento. O carimbo de data / hora deve ser preciso e corresponder à hora em que o evento ocorreu fisicamente, não à hora em que foi relatado.

Para informações e requisitos para a comunicação de eventos de sensores com latência máxima diferente de zero relatórios adicionais, consulte dosagem .

Ativando sensores

A estrutura permite que os sensores e desactiva usando o activate() função. Antes da ativação de um sensor, o quadro deve primeiro configurar o sensor utilizando batch() .

Depois que um sensor é desativado, eventos de sensor adicionais desse sensor não devem ser gravados no FMQ de eventos.

Sensores de descarga

Se um sensor está configurado para dados do sensor lote, o quadro pode forçar um rubor imediata de eventos de sensores em lote chamando flush() . Isso faz com que os eventos de sensor em lote para o identificador de sensor especificado sejam imediatamente gravados no FMQ de eventos. Os sensores HAL deve anexar um evento completo flush para o fim dos eventos de sensores que são escritos como resultado de uma chamada para flush() .

A liberação ocorre de forma assíncrona (ou seja, esta função deve retornar imediatamente). Se a implementação usa um único FIFO para vários sensores, esse FIFO é liberado e o evento de liberação completa é adicionado apenas para o sensor especificado.

Se o sensor especificado não tem FIFO (sem buffer possível), ou se a FIFO estava vazio no momento da chamada, flush() ainda deve ter sucesso e enviar um evento completo nivelado para esse sensor. Isso se aplica a todos os sensores, exceto sensores de disparo único.

Se flush() é chamado para um sensor de one-shot, então flush() deve retornar BAD_VALUE e não gerar um evento completo flush.

Gravando eventos de sensor no FMQ

O Event FMQ é usado pelo Sensors HAL para enviar eventos de sensor para a estrutura de sensor do Android.

O Event FMQ é um FMQ sincronizado, o que significa que qualquer tentativa de gravar mais eventos no FMQ do que o espaço disponível permite resulta em uma gravação com falha. Nesse caso, o HAL deve determinar se deve gravar o conjunto atual de eventos como dois grupos menores de eventos ou gravar todos os eventos juntos quando houver espaço suficiente disponível.

Quando os sensores HAL tem escrito o número desejado de eventos de sensores para a FMQ Evento, os sensores HAL deve notificar o quadro que os eventos estão prontos escrevendo o EventQueueFlagBits::READ_AND_PROCESS pouco para o FMQ Evento EventFlag::wake função. O EventFlag pode ser criado a partir da FMQ Evento usando EventFlag::createEventFlag da FMQ Evento e getEventFlagWord() função.

Sensores HAL 2.0 / 2.1 suporta tanto write e writeBlocking na FMQ Evento. A implementação padrão fornece uma referência para o uso de write . Se o writeBlocking função é usada, o readNotification bandeira deve ser definido como EventQueueFlagBits::EVENTS_READ , que é definido pela estrutura quando ele lê eventos do FMQ Evento. A bandeira de notificação escrita deve ser definido como EventQueueFlagBits::READ_AND_PROCESS , que notifica o quadro que os eventos foram escritos à FMQ Evento.

Eventos WAKE_UP

WAKE_UP eventos são eventos de sensores que fazem com que o processador de aplicação (AP) para acordar e manipular o evento imediatamente. Sempre que um WAKE_UP evento é gravado no FMQ Evento, os sensores HAL deve garantir um bloqueio esteira para garantir que as estadias do sistema acordado até que o quadro pode manipular o evento. Ao receber uma WAKE_UP evento, o quadro assegura a sua própria fechadura esteira, permitindo a Sensores HAL para liberar seu bloqueio esteira. Para sincronizar quando o Sensors HAL libera seu wake lock, use o Wake Lock FMQ.

Os sensores HAL deve ler o Wake Bloqueio FMQ para determinar o número de WAKE_UP eventos que o quadro tem tratado. O HAL só deve liberar seu bloqueio esteira para WAKE_UP eventos se o número total de não tratadas WAKE_UP eventos é zero. Depois de manipulação de eventos do sensor, o quadro conta o número de eventos que são marcados como WAKE_UP eventos e escreve esse número de volta para a Wake Bloqueio FMQ.

O quadro define o WakeLockQueueFlagBits::DATA_WRITTEN notificação escrita no Wake Bloqueio FMQ sempre que grava dados no Wake Bloqueio FMQ.

Sensores dinâmicos

Sensores dinâmicos são sensores que não fazem parte fisicamente do dispositivo, mas podem ser usados ​​como entrada para o dispositivo, como um gamepad com um acelerômetro.

Quando um sensor dinâmico está ligado, o onDynamicSensorConnected função em ISensorsCallback deve ser chamado a partir dos sensores HAL. Isso notifica a estrutura do novo sensor dinâmico e permite que o sensor seja controlado por meio da estrutura e que os eventos do sensor sejam consumidos pelos clientes.

Da mesma forma, quando um sensor dinâmica é desligado, o onDynamicSensorDisconnected função em ISensorsCallback deve ser chamado assim que o quadro pode remover qualquer sensor que não está mais disponível.

Canal direto

O canal direto é um método de operação em que os eventos do sensor são gravados em uma memória específica em vez de no FMQ de eventos, ignorando o Android Sensors Framework. Um cliente que registra um canal direto deve ler os eventos do sensor diretamente da memória que foi usada para criar o canal direto e não receberá os eventos do sensor através da estrutura. O configDirectReport() a função é semelhante à batch() para o funcionamento normal e configura o canal relatório directa.

Os registerDirectChannel() e unregisterDirectChannel() funções de criar ou destruir um novo canal directo.

Modos de operação

O setOperationMode() função permite para o quadro para configurar um sensor, de modo que o quadro pode injectar dados do sensor para o sensor. Isso é útil para teste, especialmente para algoritmos que existem abaixo da estrutura.

O injectSensorData() função em HAL 2,0 e injectSensorsData_2_1() função em HAL 2.0 é normalmente usada para empurrar parâmetros operacionais no Sensores HAL. A função também pode ser usada para injetar eventos de sensor em um sensor específico.

Validação

Para validar sua implementação do Sensors HAL, execute os testes de sensor CTS e VTS.

Testes CTS

Os testes de CTS do sensor existem em testes CTS automatizados e no aplicativo CTS Verifier manual.

Os testes automatizados estão localizados em CTS / testes / sensor / src / android / hardware / CTS . Esses testes verificam a funcionalidade padrão dos sensores, como sensores de ativação, dosagem e taxas de eventos do sensor.

Os testes CTS Verificador estão localizados em cts / aplicativos / CtsVerifier / src / com / android / CTS / verificador / sensores . Esses testes exigem entrada manual do operador de teste e garantem que os sensores relatem valores precisos.

Passar nos testes CTS é fundamental para garantir que o dispositivo em teste atenda a todos os requisitos de CDD.

Testes VTS

Testes VTS para sensores HAL 2,0 estão localizados em hardware / interfaces / sensores / 2,0 / vts . Testes VTS para sensores HAL 2,1 estão localizados em hardware / interfaces / sensores / 2.1 / vts . Estes testes garantir que os sensores HAL é implementado adequadamente e que todos os requisitos dentro ISensors.hal e ISensorsCallback.hal são devidamente atendidas.

Atualizando para Sensores HAL 2.1 de 2.0

Ao atualizar para Sensores HAL 2.1 de 2.0, a implementação HAL deve incluir o initialize_2_1() , getSensorsList_2_1() , e injectSensorsData_2_1() métodos, juntamente com os tipos HAL 2.1. Esses métodos devem atender aos mesmos requisitos descritos para HAL 2.0 acima.

Como os HALs de versão secundária devem oferecer suporte a todas as funções dos HALs anteriores, os HALs 2.1 devem ser inicializados como HALs 2.0. Para evitar a complexidade de suportar ambas as versões HAL, é altamente recomendável usar Multi-HAL 2.1.

Para um exemplo de como implementar os seus próprios sensores 2.1 HAL, consulte Sensors.h .

Atualizando para Sensores HAL 2.0 de 1.0

Ao atualizar para Sensores HAL 2.0 de 1.0, certifique-se de que sua implementação HAL atenda aos seguintes requisitos.

Inicializando o HAL

O initialize() função deve ser apoiada para estabelecer FMQs entre o quadro e HAL.

Exposição dos sensores disponíveis

Em Sensores HAL 2.0, o getSensorsList() função deve retornar o mesmo valor durante um único dispositivo de arranque, mesmo através de sensores de HAL é reiniciado. A nova exigência do getSensorsList() função é que ele deve retornar o mesmo valor durante uma única inicialização do dispositivo, mesmo através de sensores de HAL é reiniciado. Isso permite que a estrutura tente restabelecer as conexões do sensor se o servidor do sistema for reiniciado. O valor devolvido por getSensorsList() pode mudar depois os dispositivos executa uma reinicialização.

Gravando eventos de sensor no FMQ

Em vez de esperar para poll() a ser chamado, em Sensores HAL 2.0, os sensores HAL deve eventos de sensores de forma proativa gravação para a FMQ Evento sempre que eventos de sensores estão disponíveis. O HAL é também responsável por escrever os bits corretos para EventFlag para causar uma FMQ leia no quadro.

Eventos WAKE_UP

Em Sensores HAL 1.0, o HAL foi capaz de liberar seu bloqueio esteira para qualquer WAKE_UP evento em qualquer chamada subsequente para poll() depois de um WAKE_UP foi enviada para poll() porque esta indicou que o quadro tinha processou todos os eventos do sensor e tinha obtido uma wake lock, se necessário. Porque, na Sensores HAL 2.0, o HAL não sabe quando o quadro já processou os eventos gravados no FMQ, o Wake Bloqueio FMQ permite que a estrutura para se comunicar com o HAL quando se tem tratado WAKE_UP eventos.

Em Sensores HAL 2.0, o bloqueio esteira garantido pelos sensores HAL para WAKE_UP eventos deve começar com SensorsHAL_WAKEUP .

Sensores dinâmicos

Sensores dinâmicos foram devolvidos utilizando o poll() a função de sensores de HAL 1,0. Sensores HAL 2.0 requer que onDynamicSensorsConnected e onDynamicSensorsDisconnected em ISensorsCallback ser chamado sempre dinâmico mudança ligações dos sensores. Essas chamadas de retorno são disponíveis como parte do ISensorsCallback ponteiro que é fornecido através da initialize() função.

Modos de operação

O DATA_INJECTION modo para WAKE_UP sensores devem ser suportadas em Sensores HAL 2.0.

Suporte multi-HAL

Sensores HAL 2.0 e 2.1 suporta multi-HAL usando o quadro Sensores Multi-HAL . Para detalhes de implementação, consulte Portando de Sensores HAL 1.0 .