O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

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 HAL de Sensores 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. Sensors HAL 2.0 é baseado em Sensors HAL 1.0, mas tem várias diferenças importantes, que o impedem de ser compatível com versões anteriores. Sensores O HAL 2.0 usa Filas de Mensagens Rápidas (FMQs) para enviar eventos de sensor do HAL para a estrutura de sensor do 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 tipo de sensor HINGE_ANGLE e atualiza vários métodos para aceitar o tipo HINGE_ANGLE .

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 , use o requisito em ISensors.hal .

Interface HAL 2.0

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

Implementando Sensores HAL 2.0 e HAL 2.1

Para implementar Sensors HAL 2.0 ou 2.1, um objeto deve estender a interface ISensors 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 Android antes de poder ser usado. A estrutura chama a função initialize() para HAL 2.0 e a função initialize_2_1() para HAL 2.1 para fornecer três parâmetros ao HAL de sensores: dois descritores FMQ e um ponteiro para um objeto ISensorsCallback .

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 Lock FMQ usado para sincronizar quando o HAL libera seu wake lock para eventos do sensor WAKE_UP . O HAL deve salvar um ponteiro para o objeto ISensorsCallback para que qualquer função de retorno de chamada necessária possa ser chamada.

A função initialize() ou initialize_2_1() deve ser a primeira função chamada ao inicializar o HAL de sensores.

Exposição dos sensores disponíveis

Para obter uma lista de todos os sensores estáticos disponíveis no dispositivo, use a função getSensorsList() no HAL 2.0 e a função getSensorsList_2_1() 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 de ativação, o primeiro sensor da lista é chamado de sensor padrão e é retornado aos aplicativos que utilizam a função getDefaultSensor(int sensorType, bool wakeUp) .

Estabilidade da lista de sensores

Após uma reinicialização do Sensors HAL, se os dados retornados por getSensorsList() ou getSensorsList_2_1() indicarem uma mudança significativa em comparação com a lista de sensores recuperada antes da reinicialização, a estrutura acionará uma reinicialização do tempo 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 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 uma série de opções disponíveis para atender a esse requisito.

Por exemplo, a lista de sensores pode ser classificada usando uma combinação dos atributos fixos de cada sensor, como fornecedor, modelo e tipo de sensor. Outra opção se baseia no fato de que o conjunto de sensores estáticos do dispositivo é fixo no hardware, portanto, o HAL precisa saber quando todos os sensores esperados concluíram a inicialização antes de retornar de 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 ser ativado, ele deve ser configurado com um período de amostragem e latência máxima de relatório usando a função batch() .

Um sensor deve ser capaz de ser reconfigurado a qualquer momento usando 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 obter mais detalhes, consulte Tipos de sensores .

Para saber mais sobre a interação entre um período de amostragem e os modos de relatório de um sensor, consulte Modos de relatório .

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 por completo ou esvaziando o FIFO assim que um evento do sensor estiver presente no FIFO.

Por exemplo, um acelerômetro ativado em 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 os 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 obter informações e requisitos adicionais sobre eventos de sensor de relatório com latência de relatório máxima diferente de zero, consulte Lote .

Ativando sensores

A estrutura habilita e desabilita sensores usando a função activate() . Antes de ativar um sensor, a estrutura deve primeiro configurar o sensor usando 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 for configurado para dados do sensor em lote, a estrutura pode forçar uma descarga imediata de eventos do sensor 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. O HAL de sensores deve anexar um evento de conclusão de liberação ao final dos eventos de sensor que são gravados 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 (nenhum buffer é possível), ou se o FIFO estava vazio no momento da chamada, flush() ainda deve ter sucesso e enviar um evento flush complete para esse sensor. Isso se aplica a todos os sensores, exceto sensores de disparo único.

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

Gravando eventos do sensor no FMQ

O Event FMQ é usado pelo Sensors HAL para enviar eventos de sensor para a estrutura de sensor 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 o HAL de sensores grava o número desejado de eventos de sensor no FMQ de eventos, o HAL de sensores deve notificar a estrutura de que os eventos estão prontos, gravando o bit EventQueueFlagBits::READ_AND_PROCESS na função EventFlag::wake do FMQ de EventFlag::wake . O EventFlag pode ser criado a partir do Event FMQ usando EventFlag::createEventFlag e a função getEventFlagWord() do Event FMQ.

Sensores HAL 2.0 / 2.1 suporta write e writeBlocking no Event FMQ. A implementação padrão fornece uma referência para o uso de write . Se a função writeBlocking for usada, o sinalizador readNotification deve ser definido como EventQueueFlagBits::EVENTS_READ , que é definido pela estrutura ao ler eventos do Event FMQ. O sinalizador de notificação de gravação deve ser definido como EventQueueFlagBits::READ_AND_PROCESS , que notifica a estrutura de que os eventos foram gravados no FMQ do Evento.

WAKE_UP eventos

WAKE_UP eventos WAKE_UP são eventos de sensor que fazem com que o processador de aplicativos (AP) desperte e manipule o evento imediatamente. Sempre que um evento WAKE_UP é gravado no FMQ do evento, o HAL dos sensores deve proteger um wake lock para garantir que o sistema permaneça ativo até que a estrutura possa lidar com o evento. Ao receber um evento WAKE_UP , a estrutura protege seu próprio wake lock, permitindo que o HAL de sensores libere seu wake lock. Para sincronizar quando o Sensors HAL libera seu wake lock, use o Wake Lock FMQ.

O Sensors HAL deve ler o Wake Lock FMQ para determinar o número de eventos WAKE_UP que a estrutura manipulou. O HAL só deve liberar seu wake lock para eventos WAKE_UP se o número total de eventos WAKE_UP não manipulados for zero. Depois de manipular eventos de sensor, a estrutura conta o número de eventos marcados como eventos WAKE_UP e grava esse número de volta no Wake Lock FMQ.

A estrutura define a notificação de gravação WakeLockQueueFlagBits::DATA_WRITTEN no Wake Lock FMQ sempre que grava dados no Wake Lock 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 através da estrutura 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 deve ser chamada para que a estrutura possa remover qualquer sensor que não esteja mais disponível.

Canal direto

Canal direto é um método de operação em que eventos de 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. A função configDirectReport() é semelhante a batch() para operação normal e configura o canal de relatório direto.

As funções registerDirectChannel() e unregisterDirectChannel() criam ou destroem um novo canal direto.

Modos de operação

A função setOperationMode() permite que a estrutura configure um sensor para que a estrutura possa injetar dados do sensor no sensor. Isso é útil para teste, especialmente para algoritmos que existem abaixo da estrutura.

A função injectSensorData() no HAL 2.0 e a função injectSensorsData_2_1() no HAL 2.0 é normalmente usada para enviar parâmetros operacionais para o HAL dos sensores. 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 / tests / sensor / src / android / hardware / cts . Esses testes verificam a funcionalidade padrão dos sensores, como sensores de ativação, lote e taxas de eventos do sensor.

Os testes do CTS Verifier estão localizados em cts / apps / CtsVerifier / src / com / android / cts / verifier / 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

Os testes de VTS para Sensores HAL 2.0 estão localizados em hardware / interfaces / sensores / 2.0 / vts . Os testes VTS para sensores HAL 2.1 estão localizados em hardware / interfaces / sensores / 2.1 / vts . Esses testes garantem que o Sensors HAL seja implementado corretamente e que todos os requisitos em ISensors.hal e ISensorsCallback.hal sejam atendidos de forma adequada.

Atualizando para Sensores HAL 2.1 de 2.0

Ao atualizar para Sensors HAL 2.1 a partir de 2.0, sua implementação de HAL deve incluir os métodos initialize_2_1() , getSensorsList_2_1() e injectSensorsData_2_1() , junto 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 obter um exemplo de como implementar seus próprios Sensors 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 requisitos a seguir.

Inicializando o HAL

A função initialize() deve ser suportada para estabelecer FMQs entre a estrutura e o HAL.

Exposição dos sensores disponíveis

No Sensors HAL 2.0, a função getSensorsList() deve retornar o mesmo valor durante uma única inicialização do dispositivo, mesmo nas reinicializações do Sensors HAL. Um novo requisito da função getSensorsList() é que ela deve retornar o mesmo valor durante uma única inicialização do dispositivo, mesmo nas reinicializações do HAL dos sensores. Isso permite que a estrutura tente restabelecer as conexões do sensor se o servidor do sistema for reiniciado. O valor retornado por getSensorsList() pode mudar depois que o dispositivo executa uma reinicialização.

Gravando eventos do sensor no FMQ

Em vez de esperar que poll() seja chamado, no Sensors HAL 2.0, o Sensors HAL deve gravar eventos de sensor proativamente no FMQ de eventos sempre que houver eventos de sensor disponíveis. O HAL também é responsável por gravar os bits corretos no EventFlag para causar uma leitura de FMQ dentro da estrutura.

Eventos WAKE_UP

No Sensors HAL 1.0, o HAL foi capaz de liberar seu wake lock para qualquer evento WAKE_UP em qualquer chamada subsequente para poll() depois que um WAKE_UP foi postado para poll() porque isso indicava que o framework havia processado todos os eventos de sensor e obtido um wake lock, se necessário. Como no Sensors HAL 2.0, o HAL não sabe mais quando o framework processou eventos gravados no FMQ, o Wake Lock FMQ permite que o framework se comunique com o HAL quando ele tiver manipulado eventos WAKE_UP .

No Sensors HAL 2.0, o wake lock protegido pelo Sensors HAL para eventos WAKE_UP deve começar com SensorsHAL_WAKEUP .

Sensores dinâmicos

Sensores dinâmicos foram retornados usando a função poll() em Sensors HAL 1.0. Sensors HAL 2.0 requer que onDynamicSensorsConnected e onDynamicSensorsDisconnected em ISensorsCallback sejam chamados sempre que as conexões dinâmicas do sensor mudarem. Esses retornos de chamada estão disponíveis como parte do ponteiro ISensorsCallback que é fornecido por meio da função initialize() .

Modos de operação

O modo DATA_INJECTION para sensores WAKE_UP deve ser compatível com Sensors HAL 2.0.

Suporte multi-HAL

Os sensores HAL 2.0 e 2.1 oferecem suporte a multi-HAL usando a estrutura de sensores Multi-HAL . Para obter detalhes de implementação, consulte Porting from Sensors HAL 1.0 .