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.

Sensores com várias HAL

"Sensors Multi-HAL" é um framework que permite que as HALs de sensores funcionem junto outras HALs do sensor. Os sensores com várias HALs carregam dinamicamente sub-HALs dos sensores. armazenadas como bibliotecas dinâmicas na partição do fornecedor e dá a elas um callback Objeto que pode manipular eventos de publicação e adquirir e liberar o wake lock. Uma sub-HAL de sensores é uma HAL de sensores integrada a um objeto compartilhado de fornecedor e é usada pelo framework multi-HAL. Essas sub-HALs não precisam dependem uns dos outros ou do código multi-HAL que contém a função principal para o processo.

Sensores Multi-HAL 2.1, disponíveis em dispositivos com Android 11 ou superior, é uma iteração de Sensores Multi-HAL 2.0 com suporte ao carregamento de sub-HALs que podem expor ângulo de dobradiça tipo de sensor. Para oferecer suporte a esse tipo de sensor, os sub-HALs precisam usar as APIs sub-HAL definido no 2.1 Cabeçalho SubHal.

Para dispositivos com o Android 13 ou mais recente que usam a HAL de sensores AIDL, poderá usar camada de paliativo multi-HAL para permitir a funcionalidade de multi-HAL. Para detalhes de implementação, ver Como usar a HAL de sensores multi-HAL com a HAL de sensores AIDL.

Diferença entre os sensores Multi-HAL 2 e os sensores HAL 2

Sensores Multi-HAL 2, disponíveis em dispositivos com Android 10 ou mais introduziu diversas abstrações sobre a HAL de sensores 2 para facilitar para interagir com as APIs HAL. Os Sensores Multi-HAL 2 apresentam a HalProxy (link em inglês) para lidar com a implementação da interface de HAL 2 de sensores e a V2_1/SubHal (ou V2_0/SubHal). interface para permitir que HalProxy interaja com sub-HALs.

A interface ISensorsSubHal é diferente da 2.1/ISensors.hal (ou 2.0/ISensors.hal). das seguintes maneiras:

O método de inicialização transmite um IHalProxyCallback. em vez de dois FMQs e ISensorsCallback.
Sub-HALs devem implementar uma função de depuração para fornecer depuração em relatórios de bugs.
As sub-HALs devem implementar uma função de nome para que a sub-HAL carregada possa ser diferentes de outras sub-HALs.

A principal diferença entre os sensores Multi-HAL 2 e os sensores HAL 2 está no inicializar funções. Em vez de fornecer FMQs, o IHalProxyCallback interface fornece dois métodos: um para postar eventos de sensor para os sensores e um método para criar wake locks. Em segundo plano, os sensores O Multi-HAL gerencia todas as interações com os FMQs para garantir a entrega oportuna de eventos de sensor para todas as sub-HALs. É altamente recomendável que sub-HALs usem a Método createScopedWakelock para delegar o trabalho de tempo limite de wake locks para os sensores multi-HAL e para centralizar o uso do wake lock em um wake lock comum para toda a HAL de sensores, o que minimiza o bloqueio e desbloqueio de chamadas.

Os sensores Multi-HAL 2 também têm alguns recursos de segurança integrados. Ele cuida situações em que a FMQ do sensor está cheia ou em que o framework do sensor do Android será reiniciado e o estado do sensor precisa ser redefinido. Além disso, quando os eventos são publicado para a classe HalProxy, mas o framework do sensor não consegue aceitar imediatamente, os Sensores Multi-HAL podem movê-los para um segundo plano para permitir que o trabalho continue em todas as sub-HALs enquanto aguarda o eventos a serem postados.

Código-fonte e implementação de referência

Todos os códigos multi-HAL de sensores estão disponíveis hardware/interfaces/sensors/common/default/2.X/multihal/ Aqui estão alguns indicadores para alguns recursos.

HalProxy.h: O objeto HalProxy é instanciado pelos sensores multi-HAL e processa o transmitir dados das sub-HALs para o framework do sensor.
HalProxy.cpp: A implementação de HalProxy contém toda a lógica necessária para comunicação multiplexada entre sub-HALs e o framework do sensor.
SubHal.h: A interface ISensorsSubHal define a interface que os sub-HALs devem seguem para serem compatíveis com HalProxy. A sub-HAL implementa a método de inicialização para que o objeto HalProxyCallback possa ser usado para postEvents e createScopedWakelock.

Para implementações multi-HAL 2.0, use a versão 2.0 do SubHal.h
hardware/interfaces/sensors/common/default/2.X/multihal/tests/: Esses testes de unidade verificam a implementação de HalProxy.
hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/: Este exemplo de implementação de sub-HAL usa sensores falsos para gerar dados. Útil para testar como várias sub-HALs interagem em um dispositivo.

Implementação

Esta seção descreve como implementar os sensores multi-HAL nas seguintes situações:

Como usar a HAL de sensores com a HAL de sensores AIDL
Como implementar sensores Multi-HAL 2.1
Portabilidade de sensores Multi-HAL 2.0 para Multi-HAL 2.1
Portabilidade a partir de sensores HAL 2.0
Portabilidade a partir de sensores HAL 1.0
Portabilidade de sensores Multi-HAL 1.0

Usar a HAL de sensores com a HAL de sensores AIDL

Para permitir a funcionalidade de várias HAL com a HAL de sensores AIDL, importe a AIDL Módulo de camada paliativa multi-HAL, encontrado na hardware/interfaces/sensors/aidl/default/multihal/ O módulo processa a conversão entre a definição de HAL dos sensores AIDL e HIDL e define um wrapper em torno da interface multi-HAL descrita em Como implementar sensores Multi-HAL 2.1 (em inglês). A interface multi-HAL da AIDL é compatível com dispositivos que implementam Sensores Multi-HAL 2.1.

A camada de paliativo AIDL multi-HAL permite expor o rastreador da cabeça e tipos de sensores de IMU de eixo limitado na HAL de sensores AIDL. Para usar esses sensores definidos pela interface HAL da AIDL, defina o campo type na struct SensorInfo na implementação de getSensorsList_2_1(). Isto é seguro porque os campos de tipo de sensor com base em um número inteiro da HAL dos sensores AIDL e HIDL não se sobreponham.

Implemente sensores Multi-HAL 2.1

Para implementar os Sensores Multi-HAL 2.1 em um novo dispositivo, siga estas etapas:

Implemente a interface ISensorsSubHal conforme descrito em SubHal.h.
Implementar o sensorsHalGetSubHal_2_1 em SubHal.h.
Adicione um destino cc_library_shared para criar a sub-HAL recém-implementada. Ao adicionar o destino:
1. Verifique se o destino é enviado para algum lugar no fornecedor do dispositivo.
2. No arquivo de configuração localizado em /vendor/etc/sensors/hals.conf, adicione o caminho para a biblioteca em uma nova linha. Se necessário, crie a hals.conf.
Para conferir um exemplo de entrada Android.bp para criar uma biblioteca sub-HAL, consulte hardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp.
Remova todas as android.hardware.sensors entradas da manifest.xml , que contém a lista de HALs compatíveis com o dispositivo.
Remova todos os android.hardware.sensors serviços e service.rc arquivos de o arquivo device.mk e adicionar android.hardware.sensors@2.1-service.multihal e android.hardware.sensors@2.1-service.multihal.rc para PRODUCT_PACKAGES.

Na inicialização, HalProxy é iniciado, procura a sub-HAL recém-implementada e o inicializa chamando sensorsHalGetSubHal_2_1.

Porta dos sensores Multi-HAL 2.0 para Multi-HAL 2.1

Para transferir de Multi-HAL 2.0 para Multi-HAL 2.1, implemente a SubHal e recompilar a sub-HAL.

Estas são as diferenças entre as interfaces SubHal 2.0 e 2.1:

IHalProxyCallback usa os tipos criados em a versão 2.1 da especificação ISensors.hal.
A função initialize() transmite uma nova IHalProxyCallback em vez daquele da interface 2.0 SubHal
As sub-HALs precisam implementar getSensorsList_2_1 e injectSensorData_2_1. em vez de getSensorsList e injectSensorData, já que esses métodos usam os novos tipos adicionados na versão 2.1 da especificação ISensors.hal.
As sub-HALs precisam expor sensorsHalGetSubHal_2_1 em vez de sensorsHalGetSubHal para que a Multi-HAL os trate como versão 2.1. sub-HALs.

Porta dos sensores HAL 2.0

Ao fazer upgrade da HAL de sensores para Sensores Multi-HAL 2.0 2.0, verifique se a HAL a implementação atende aos requisitos a seguir.

Inicializar a HAL

A HAL 2.0 de sensores tem uma função de inicialização que permite que o serviço de sensores transmitir FMQs e um callback de sensor dinâmico. Nos Sensores Multi-HAL 2.0, A função initialize() transmite um único callback que precisa ser usado para publicar eventos de sensor, obter wake locks e notificar sobre a conexão dinâmica do sensor e e desconexões.

Publicar eventos do sensor na implementação de várias HALs

Em vez de postar eventos do sensor pela FMQ, a sub-HAL precisa gravar aos eventos IHalProxyCallback quando eventos do sensor estiverem disponíveis.

Eventos WAKE_UP

Na HAL de sensores 2.0, a HAL pode gerenciar o wake lock para a implementação. Em Sensores Multi-HAL 2.0, os sub-HALs permitem que a implementação de Multi-HAL gerenciar wake locks e solicitar que um wake lock seja adquirido invocando createScopedWakelock Um wake lock de escopo bloqueado precisa ser adquirido e transmitido para postEvents quando postar eventos de ativação na implementação de Multi-HAL.

Sensores dinâmicos

Os sensores Multi-HAL 2.0 exigem que onDynamicSensorsConnected e onDynamicSensorsDisconnected pol. IHalProxyCallback são chamados sempre que as conexões do sensor dinâmico mudam. Esses callbacks são como parte do ponteiro IHalProxyCallback fornecido pelo a função initialize().

Porta dos sensores HAL 1.0

Ao fazer upgrade da HAL de sensores para Sensores Multi-HAL 2.0 1.0, verifique se a HAL a implementação atende aos requisitos a seguir.

Inicializar a HAL

A função initialize() precisa ser compatível para estabelecer o callback entre a implementação da sub-HAL e da Multi-HAL.

Expor os sensores disponíveis

Em Sensores Multi-HAL 2.0, a função getSensorsList() precisa retornar o mesmo durante a inicialização de um único dispositivo, mesmo entre as reinicializações da HAL dos sensores. Isso permite o framework 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.

Publicar eventos do sensor na implementação de várias HALs

Na HAL de sensores 2.0, em vez de esperar que poll() seja chamado, a sub-HAL precisa gravar proativamente eventos do sensor IHalProxyCallback sempre que eventos do sensor estiverem disponíveis.

Eventos WAKE_UP

Na HAL de sensores 1.0, a HAL pode gerenciar o wake lock para a implementação. Em Sensores Multi-HAL 2.0, os sub-HALs permitem que a implementação de Multi-HAL gerenciar wake locks e solicitar que um wake lock seja adquirido invocando createScopedWakelock Um wake lock de escopo bloqueado precisa ser adquirido e transmitido para postEvents quando postar eventos de ativação na implementação de Multi-HAL.

Sensores dinâmicos

Na HAL 1.0 de sensores, os sensores dinâmicos são retornados pela função poll(). Os sensores Multi-HAL 2.0 exigem que onDynamicSensorsConnected e onDynamicSensorsDisconnected pol. IHalProxyCallback são chamados sempre que as conexões do sensor dinâmico mudam. Esses callbacks são como parte do ponteiro IHalProxyCallback fornecido pelo a função initialize().

Porta dos sensores Multi-HAL 1.0

Para transferir uma implementação atual Sensores Multi-HAL 1.0, siga estas etapas.

Verifique se a configuração da HAL dos sensores está localizada em /vendor/etc/sensors/hals.conf: Isso pode envolver mover o arquivo às /system/etc/sensors/hals.conf.
Remova todas as referências a hardware/hardware.h e hardware/sensors.h já que não são compatíveis com a HAL 2.0.
Portas sub-HALs, conforme descrito em Portabilidade de sensores Hal 1.0.
Defina os sensores Multi-HAL 2.0 como a HAL designada seguindo as etapas 3 e 4 na seção Como implementar sensores Mutli-HAL 2.0.

Validação

Executar VTS

Ao integrar uma ou mais sub-HALs com os sensores Multi-Hal 2.1, use o conjunto de teste de fornecedor (VTS, na sigla em inglês) para garantir que a sub-HAL as implementações atendem a todos os requisitos definidos pela interface HAL de sensores.

Para executar apenas os testes do VTS de sensores quando ele estiver configurado em uma máquina host, faça o seguinte: execute os seguintes comandos:

vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_0Target && \
  vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_1Target

Se você estiver executando a camada de paliativo AIDL Multi-HAL, execute VtsAidlHalSensorsTargetTest.

vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsAidlHalSensorsTargetTest

Executar testes de unidade

Os testes de unidade em HalProxy_test.cpp testam HalProxy usando sub-HALs falsas que são instanciadas no teste de unidade e não são carregados dinamicamente. Ao criar um nova sub-HAL, esses testes devem servir como um guia sobre como adicionar testes de unidade que verificar se a nova sub-HAL está implementada corretamente.

Para executar os testes, execute os seguintes comandos:

cd $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests
atest

Testar com sub-HALs falsas

As sub-HALs falsas são implementações fictícias da interface ISensorsSubHal. As sub-HALs expõem diferentes listas de sensores. Quando os sensores são ativados, eles postam periodicamente eventos do sensor gerados automaticamente em HalProxy com base nos intervalos especificados em uma determinada solicitação do sensor.

As sub-HALs falsas podem ser usadas para testar como o código Multi-HAL completo funciona com outras sub-HALs carregadas no sistema e para estressar vários aspectos da Código multi-HAL dos sensores.

Duas sub-HALs falsas estão disponíveis em hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/

Para criar e enviar as sub-HALs falsas para um dispositivo, siga estas etapas:

Execute os comandos a seguir para criar e enviar os três tipos diferentes sub-HALs para o dispositivo:

$ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests/
mma
adb push \
  $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so \
  /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
adb push \
  $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so \
  /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
adb push \
  $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so \
  /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so

Atualize a configuração da HAL dos sensores em /vendor/etc/sensors/hals.conf com caminhos para as sub-HALs falsas.

/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so

Reinicie o HalProxy e carregue as novas sub-HALs listadas na configuração.
```
adb shell stop
adb shell start
```

Depuração

Os desenvolvedores podem depurar o framework usando o comando lshal. Para solicitar de depuração da HAL de sensores, execute o seguinte comando:

adb root
adb shell lshal debug android.hardware.sensors@2.1::ISensors/default

Informações sobre o estado atual da HalProxy e das sub-HALs são no terminal. Veja abaixo um exemplo da resposta ao comando para o Objeto HalProxy e sub-HALs falsas.

Internal values:
  Threads are running: true
  Wakelock timeout start time: 200 ms ago
  Wakelock timeout reset time: 73208 ms ago
  Wakelock ref count: 0
  # of events on pending write queue: 0
  # of non-dynamic sensors across all subhals: 8
  # of dynamic sensors across all subhals: 0
SubHals (2):
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2

Se o número especificado para # of events on pending write queue for um grande (1.000 ou mais), isso indica que há muitos eventos pendentes para gravação nos sensores de análise de dados em nuvem. Isso indica que o serviço do sensor está em um impasse ou falhou e não está processando eventos do sensor ou que um grande lote de eventos do sensor foi recentemente postados em uma sub-HAL.

Se a contagem de referência de wake lock for maior que 0, isso significa que HalProxy tem adquiriu um wake lock. Só precisa ser maior que 0 se um ScopedWakelock é realizado intencionalmente ou se eventos de despertar foram enviados para HalProxy e têm não foram processados pelo framework do sensor.

O descritor de arquivo transmitido ao método de depuração de HalProxy é transmitido a cada sub-HAL, de modo que os desenvolvedores devem implementar o método de depuração como parte da ISensorsSubHal.