O Sensores Multi-HAL é um framework que permite que os HALs de sensores sejam executados com outros HALs de sensores. 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. Esses sub-HALs não dependem um do outro nem do código multi-HAL que contém a função principal do processo.
A Sensors Multi-HAL 2.1, disponível em dispositivos com o Android 11 ou versões mais recentes, é uma iteração da Sensors Multi-HAL 2.0 que oferece suporte ao carregamento de sub-HALs que podem expor o tipo de sensor de ângulo de dobradiça. Para oferecer suporte a esse tipo de sensor, os sub-HALs precisam usar as APIs sub-HAL definidas no cabeçalho SubHal 2.1.
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, consulte Como usar a Sensores Multi-HAL com a HAL de sensores AIDL.
Diferença entre Sensors Multi-HAL 2 e Sensors HAL 2
A Sensores Multi-HAL 2, disponível em dispositivos com o Android
10 ou versões mais recentes,
apresenta várias abstrações sobre a Sensors HAL
2 para facilitar
a interação com as APIs HAL. A Sensors Multi-HAL 2 introduz a classe
HalProxy
para processar a implementação da interface Sensors HAL 2 e a
V2_1/SubHal
(ou
V2_0/SubHal
)
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 eISensorsCallback
. - 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 o Sensors Multi-HAL 2 e o Sensors HAL 2 está nas
funções de inicialização. Em vez de fornecer FMQs, a interface IHalProxyCallback
oferece dois métodos: um para postar eventos do sensor no framework
de sensores e outro para criar bloqueios de ativação. Por trás dos panos, a Sensor
Multi-HAL gerencia todas as interações com as FMQs para garantir a entrega oportuna de
eventos do sensor para todas as sub-HALs. É altamente recomendável que as sub-HALs usem o
método createScopedWakelock
para delegar o ônus de esgotar os bloqueios de ativação para
o Sensores Multi-HAL e centralizar o uso de um bloqueio de ativação comum
para todo o Sensores Multi-HAL, o que minimiza as chamadas de bloqueio e desbloqueio.
O Sensors Multi-HAL 2 também tem 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
enviados para a classe HalProxy
, mas o framework do sensor não pode aceitar
os eventos imediatamente, o Sensores Multi-HAL pode mover os eventos para uma linha de execução
em segundo plano para permitir que o trabalho continue em todos os sub-HALs enquanto aguarda que
os eventos sejam 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/
Confira alguns recursos.
HalProxy.h
: O objetoHalProxy
é instanciado pelos sensores multi-HAL e processa o transmitir dados das sub-HALs para o framework do sensor.HalProxy.cpp
: A implementação deHalProxy
contém toda a lógica necessária para comunicação multiplexada entre sub-HALs e o framework do sensor.SubHal.h
: a interfaceISensorsSubHal
define a interface que as sub-HALs precisam seguir para serem compatíveis comHalProxy
. A sub-HAL implementa a método de inicialização para que o objetoHalProxyCallback
possa ser usado parapostEvents
ecreateScopedWakelock
.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 deHalProxy
.hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/
: neste exemplo de implementação de sub-HAL, sensores falsos são usados para gerar dados falsos. Útil para testar como vários sub-HALs interagem em um dispositivo.
Implementação
Esta seção descreve como implementar o Sensor Multi-HAL nas seguintes situações:
- Como usar a Sensors Multi-HAL com a Sensors AIDL HAL
- Como implementar sensores Multi-HAL 2.1
- Portabilidade de sensores Multi-HAL 2.0 para Multi-HAL 2.1
- Portabilidade da HAL 2.0 de sensores
- Portabilidade da HAL 1.0 de sensores
- Portabilidade da Sensors Multi-HAL 1.0
Usar a Sensores Multi-HAL com a HAL de sensores AIDL
Para permitir o recurso de várias HALs com a HAL de sensores AIDL, importe o módulo de camada de shim de várias HALs AIDL, que está em hardware/interfaces/sensors/aidl/default/multihal/. O módulo processa a conversão entre os tipos de definição de HAL de sensores AIDL e HIDL e define um wrapper em torno da interface multi-HAL descrita em Como implementar a Sensors Multi-HAL 2.1. A interface multi-HAL da AIDL é compatível com dispositivos que implementam Sensores Multi-HAL 2.1.
A camada de shim de vários HALs da AIDL permite expor o rastreador de cabeça e
os tipos de sensor de IMU de eixo limitado na HAL de sensores AIDL. Para usar esses tipos de sensor
definidos pela interface HAL da AIDL, defina o campo type
na
estrutura SensorInfo
na implementação 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.
Implementar a Sensores Multi-HAL 2.1
Para implementar o Sensors Multi-HAL 2.1 em um novo dispositivo, siga estas etapas:
- Implemente a interface
ISensorsSubHal
conforme descrito emSubHal.h
. - Implementar o
sensorsHalGetSubHal_2_1
emSubHal.h
. Adicione um destino
cc_library_shared
para criar o sub-HAL recém-implementado. Ao adicionar o destino:- Verifique se o destino foi enviado para algum lugar na partição do fornecedor do dispositivo.
- 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 ahals.conf
.
Para conferir um exemplo de entrada
Android.bp
para criar uma biblioteca sub-HAL, consultehardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp
.Remova todas as
android.hardware.sensors
entradas damanifest.xml
, que contém a lista de HALs compatíveis com o dispositivo.Remova todos os
android.hardware.sensors
serviços eservice.rc
arquivos de o arquivodevice.mk
e adicionarandroid.hardware.sensors@2.1-service.multihal
eandroid.hardware.sensors@2.1-service.multihal.rc
paraPRODUCT_PACKAGES
.
Na inicialização, HalProxy
é iniciada, procura o sub-HAL recém-implementado e
o inicializa chamando
sensorsHalGetSubHal_2_1
.
Migração da Sensors Multi-HAL 2.0 para a 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çãoISensors.hal
.- A função
initialize()
transmite uma novaIHalProxyCallback
em vez daquele da interface 2.0SubHal
- As sub-HALs precisam implementar
getSensorsList_2_1
einjectSensorData_2_1
. em vez degetSensorsList
einjectSensorData
, já que esses métodos usam os novos tipos adicionados na versão 2.1 da especificaçãoISensors.hal
. - As sub-HALs precisam expor
sensorsHalGetSubHal_2_1
em vez desensorsHalGetSubHal
para que a Multi-HAL os trate como versão 2.1. sub-HALs.
Porta dos sensores HAL 2.0
Ao fazer upgrade para o Sensors Multi-HAL 2.0 da HAL 2.0 de sensores, verifique se a implementação da HAL atende aos requisitos a seguir.
Inicializar o HAL
A Sensors HAL 2.0 tem uma função de inicialização que permite que o serviço de sensor
transmita FMQs e um callback dinâmico de sensor. Na Sensors Multi-HAL 2.0, a
função initialize()
transmite um único callback que precisa ser usado para postar
eventos do sensor, receber bloqueios de ativação e notificar conexões e
desconexões dinâmicas do sensor.
Publicar eventos do sensor na implementação de várias HALs
Em vez de postar eventos de sensor pela FMQ, a sub-HAL precisa gravar eventos
de sensor na
IHalProxyCallback
quando eles estiverem disponíveis.
Eventos WAKE_UP
Na HAL 2.0 de sensores, a HAL pode gerenciar o bloqueio de ativação 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 bloqueio de desbloqueio de escopo precisa ser adquirido e transmitido para postEvents
ao
publicar eventos de ativação para a implementação de vários HALs.
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 para o Sensors Multi-HAL 2.0 da HAL de sensores 1.0, verifique se a implementação da HAL atende aos requisitos a seguir.
Inicializar a HAL
A função initialize()
precisa ter suporte para estabelecer o callback entre
a sub-HAL e a implementação de várias HALs.
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
que o framework 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.
Publicar eventos do sensor na implementação Multi-HAL
Na HAL 2.0 de sensores, em vez de esperar que poll()
seja chamada, a sub-HAL
precisa gravar proativamente eventos do sensor em
IHalProxyCallback
sempre que os eventos do sensor estiverem disponíveis.
Eventos WAKE_UP
Na HAL 1.0 de sensores, a HAL pode gerenciar o bloqueio de ativação para a implementação. No
Sensors Multi-HAL 2.0, os sub-HALs permitem que a implementação de
Sensors Multi-HAL gerencie wake locks e pode solicitar que um wake lock seja adquirido
chamando createScopedWakelock
.
Uma trava de ativação de escopo bloqueada precisa ser adquirida e transmitida para postEvents
ao
publicar eventos de ativação para a implementação de vários HALs.
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 estão
disponíveis como parte do ponteiro IHalProxyCallback
fornecido pela
função initialize()
.
Porta de Sensores Multi-HAL 1.0
Para transferir uma implementação atual Sensores Multi-HAL 1.0, siga estas etapas.
- Verifique se a configuração do HAL de 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
ehardware/sensors.h
porque eles 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
Depois de integrar um ou mais sub-HALs com a Sensors Multi-HAL 2.1, use o pacote de testes do fornecedor (VTS, na sigla em inglês) para garantir que as implementações de sub-HAL atendam a todos os requisitos definidos pela interface HAL de sensores.
Para executar apenas os testes do VTS com 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 uma
nova sub-HAL, esses testes servem como um guia para adicionar testes de unidade que
verificam se a nova sub-HAL foi 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 falsos
Os sub-HALs falsos 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 completo de várias HALs funciona com outras sub-HALs carregadas no sistema e para enfatizar vários aspectos do código de várias HALs de 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 abaixo para criar e enviar os três sub-HALs falsos diferentes 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
Atualizamos a configuração do HAL de sensores em
/vendor/etc/sensors/hals.conf
com os 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
HalProxy
e carregue os novos sub-HALs listados 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. Confira abaixo um exemplo da saída do comando para o
objeto HalProxy
e sub-HALs falsos.
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
número grande (1.000 ou mais),
isso indica que há muitos eventos pendentes para serem gravados no framework
de sensores. Isso indica que o serviço de sensor está em deadlock ou travou e
não está processando eventos de sensor ou que um grande lote de eventos de sensor foi
enviado recentemente de um sub-HAL.
Se a contagem de referência do bloqueio de ativação for maior que 0
, isso significa que HalProxy
adquiriu um bloqueio de ativação. Esse valor só será maior que 0
se um ScopedWakelock
estiver sendo mantido intencionalmente ou se eventos de ativação tiverem sido enviados para HalProxy
e não
tiverem sido 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
.