Le multi-HAL des capteurs est un framework qui permet aux HAL des capteurs de s'exécuter avec d'autres HAL de capteurs. Le multi-HAL des capteurs charge dynamiquement les sous-HAL des capteurs stockés en tant que bibliothèques dynamiques sur la partition du fournisseur et leur fournit un objet de rappel capable de gérer l'envoi d'événements, l'acquisition et la libération du verrouillage de réveil. Un sous-HAL pour les capteurs est un ensemble de capteurs HAL intégré dans un objet partagé la partition des fournisseurs et est utilisée par le framework multi-HAL. Ces sous-HAL ne dépendent pas les uns des autres ni du code multi-HAL qui contient la fonction principale du processus.
Capteurs Multi-HAL 2.1, disponible sur les appareils équipés d'Android 11 ou supérieure, est un de Sensors Multi-HAL 2.0, qui permet de charger des sous-HAL exposent angle de charnière le type de capteur. Pour prendre en charge ce type de capteur, les sous-HAL doivent utiliser les API de sous-HAL définies dans l'en-tête SubHal 2.1.
Pour les appareils équipés d'Android 13 ou version ultérieure qui utilisent le HAL AIDL Sensors, vous pouvez utiliser la couche shim multi-HAL pour autoriser la fonctionnalité multi-HAL. Pour en savoir plus sur l'implémentation, voir Utiliser le système Sensors Multi-HAL avec le HAL des capteurs AIDL
Différence entre les capteurs Multi-HAL 2 et HAL 2
Sensors Multi-HAL 2, disponible sur les appareils équipés d'Android 10 ou version ultérieure, introduit plusieurs abstractions au-dessus de Sensors HAL 2 pour faciliter l'interaction avec les API HAL. Sensors Multi-HAL 2 présente
HalProxy
pour gérer l'implémentation de l'interface HAL 2 des capteurs et
V2_1/SubHal
(ou
V2_0/SubHal
).
pour permettre à HalProxy
d'interagir avec les sous-HAL.
L'interface ISensorsSubHal
diffère de l'interface 2.1/ISensors.hal
(ou 2.0/ISensors.hal
) comme suit :
- La méthode d'initialisation transmet un
IHalProxyCallback
au lieu de deux FMQ etISensorsCallback
. - Les sous-HAL doivent implémenter une fonction de débogage pour fournir le débogage dans les rapports de bugs.
- Les sous-HAL doivent implémenter une fonction de nom afin que le sous-HAL chargé puisse être distingué des autres sous-HAL.
La principale différence entre Sensors Multi-HAL 2 et Sensors HAL 2 réside dans les fonctions d'initialisation. Au lieu de fournir des FMQ, l'interface IHalProxyCallback
fournit deux méthodes : une pour publier des événements de capteur dans le framework de capteurs et une pour créer des wake locks. Sous le capot, le multi-HAL des capteurs gère toutes les interactions avec les FMQ pour garantir la diffusion rapide des événements de capteur pour tous les sous-HAL. Il est fortement recommandé que les sous-HAL utilisent la méthode createScopedWakelock
pour déléguer la charge de la mise à expiration des wake locks au multi-HAL Sensors et pour centraliser l'utilisation des wake locks sur un seul wake lock commun pour l'ensemble du multi-HAL Sensors, ce qui réduit au minimum les appels de verrouillage et de déverrouillage.
Les capteurs Multi-HAL 2 intègrent également des fonctionnalités de sécurité. Il gère
dans les situations où le capteur FMQ est saturé ou lorsque le framework de capteur Android
redémarre et l'état du capteur doit être réinitialisé. De plus, lorsque des événements sont publiés dans la classe HalProxy
, mais que le framework de capteurs ne peut pas les accepter immédiatement, le multi-HAL des capteurs peut déplacer les événements vers un thread en arrière-plan pour permettre la poursuite des travaux sur tous les sous-HAL en attendant que les événements soient publiés.
Code source et implémentation de référence
Le code multi-HAL de tous les capteurs est disponible dans hardware/interfaces/sensors/common/default/2.X/multihal/
.
Voici des liens vers quelques ressources utiles.
HalProxy.h
: L'objetHalProxy
est instancié par la fonctionnalité Sensors Multi-HAL et gère les la transmission des données des sous-HAL à la structure du capteur.HalProxy.cpp
: L'implémentation deHalProxy
contient toute la logique nécessaire pour la communication multiplex entre les sous-HAL et la structure du capteur.SubHal.h
: L'interfaceISensorsSubHal
définit l'interface que les sous-HAL doivent suivre pour être compatible avecHalProxy
. La sous-HAL met en œuvre d'initialisation afin que l'objetHalProxyCallback
puisse être utilisé pourpostEvents
etcreateScopedWakelock
.Pour les implémentations Multi-HAL 2.0, utilisez la version 2.0 de
SubHal.h
.hardware/interfaces/sensors/common/default/2.X/multihal/tests/
: ces tests unitaires vérifient l'implémentation deHalProxy
.hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/
: cet exemple d'implémentation de sous-HAL utilise de faux capteurs pour générer de fausses données. Utile pour tester la manière dont plusieurs sous-HAL interagissent sur un appareil.
Implémentation
Cette section explique comment implémenter la fonctionnalité Sensors Multi-HAL dans situations suivantes:
- Utiliser le système Sensors Multi-HAL avec le HAL des capteurs AIDL
- Implémenter des capteurs Multi-HAL 2.1
- Transfert depuis Sensors Multi-HAL 2.0 vers Multi-HAL 2.1
- Portage à partir de Sensors HAL 2.0
- Transfert depuis Sensors HAL 1.0
- Transfert depuis Sensors Multi-HAL 1.0
Utiliser le système Sensors Multi-HAL avec le HAL des capteurs AIDL
Pour autoriser la fonctionnalité multiHAL avec le HAL des capteurs AIDL, importez l'AIDL le module de couche de shim multi-HAL, disponible dans hardware/interfaces/sensors/aidl/default/multihal/. Le module gère la conversion entre la définition HAL des capteurs AIDL et HIDL et définit un wrapper autour de l'interface multi-HAL décrite dans Implémenter des capteurs Multi-HAL 2.1 Le multi-HAL AIDL La couche shim est compatible avec les appareils qui implémentent les capteurs Multi-HAL 2.1.
La couche de shim multi-HAL AIDL vous permet d'exposer le head tracker et
Types de capteurs IMU à axe limité dans le HAL des capteurs AIDL. Pour utiliser ces types de capteurs définis par l'interface HAL AIDL, définissez le champ type
dans la structure SensorInfo
dans l'implémentation getSensorsList_2_1()
. C'est sans danger
car les champs de type de capteur reposant sur des entiers des capteurs AIDL et HIDL HAL
ne se chevauchent pas.
Implémenter des capteurs Multi-HAL 2.1
Pour implémenter Sensors Multi-HAL 2.1 sur un nouvel appareil, procédez comme suit:
- Implémentez l'interface
ISensorsSubHal
comme décrit dansSubHal.h
. - Implémentez le
sensorsHalGetSubHal_2_1
dansSubHal.h
. Ajoutez une cible
cc_library_shared
pour créer le sub-HAL que vous venez d'implémenter. Lorsque vous ajoutez la cible:- Assurez-vous que la cible est transmise à un emplacement de la partition du fournisseur de l'appareil.
- Dans le fichier de configuration situé à
/vendor/etc/sensors/hals.conf
, ajoutez le chemin d'accès à la bibliothèque sur une nouvelle ligne. Si nécessaire, créez la classehals.conf
.
Pour obtenir un exemple d'entrée
Android.bp
pour la création d'une bibliothèque secondaire, consultezhardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp
Supprimez toutes les entrées
android.hardware.sensors
du fichiermanifest.xml
, qui contient la liste des HAL compatibles sur l'appareil.Supprimer tout le service
android.hardware.sensors
etservice.rc
fichiers de le fichierdevice.mk
et ajoutezandroid.hardware.sensors@2.1-service.multihal
etandroid.hardware.sensors@2.1-service.multihal.rc
àPRODUCT_PACKAGES
Au démarrage, HalProxy
démarre, recherche le sous-HAL récemment implémenté, puis
l'initialise en appelant
sensorsHalGetSubHal_2_1
Port des capteurs Multi-HAL 2.0 vers Multi-HAL 2.1
Pour transférer des charges de travail multi-HAL 2.0 vers Multi-HAL 2.1, implémentez la
SubHal
et recompilez votre sous-HAL.
Voici les différences entre les interfaces SubHal
2.0 et 2.1:
IHalProxyCallback
utilise les types créés dans la version 2.1 de la spécificationISensors.hal
.- La fonction
initialize()
transmet un nouvel élémentIHalProxyCallback
au lieu de celui de l'interfaceSubHal
2.0. - Les sous-HAL doivent implémenter
getSensorsList_2_1
etinjectSensorData_2_1
au lieu degetSensorsList
etinjectSensorData
, car ces méthodes utilisent les nouveaux types ajoutés dans la version 2.1 de la spécificationISensors.hal
. - Les sous-HAL doivent exposer
sensorsHalGetSubHal_2_1
plutôt quesensorsHalGetSubHal
pour que le système Multi-HAL les traite comme la version 2.1 sous-HAL.
Port de Sensors HAL 2.0
Lorsque vous passez à Sensors Multi-HAL 2.0 à partir de Sensors HAL 2.0, assurez-vous que l'implémentation du HAL répond aux exigences suivantes.
Initialiser l'HAL
Sensors HAL 2.0 dispose d'une fonction d'initialisation qui permet au service de capteur de transmettre des FMQ et un rappel de capteur dynamique. Dans Sensors Multi-HAL 2.0, la
La fonction initialize()
transmet un seul rappel qui doit être utilisé pour publier
les événements des capteurs, obtenir des wakelocks et une notification en cas de connexion dynamique des capteurs,
les déconnexions.
Publier des événements de capteur dans l'implémentation multi-HAL
Au lieu de publier les événements liés aux capteurs via le FMQ, le sous-HAL doit écrire les données
les événements
IHalProxyCallback
lorsque des événements de capteurs sont disponibles.
Événements WAKE_UP
Dans Sensors HAL 2.0, le HAL peut gérer le verrouillage de réveil pour son implémentation. Dans Sensors Multi-HAL 2.0, les sous-HAL permettent à l'implémentation Multi-HAL de gérer les wakelocks et peuvent demander l'acquisition d'un wakelock en appelant createScopedWakelock
.
Un verrouillage de réveil de portée verrouillée doit être acquis et transmis à postEvents
lors de la publication d'événements de réveil dans l'implémentation multi-HAL.
Capteurs dynamiques
Sensors Multi-HAL 2.0 nécessite que onDynamicSensorsConnected
et
onDynamicSensorsDisconnected
po
IHalProxyCallback
sont appelés dès que les connexions dynamiques des capteurs changent. Ces rappels sont disponibles dans le pointeur IHalProxyCallback
fourni via la fonction initialize()
.
Port des capteurs HAL 1.0
Lorsque vous passez à Sensors Multi-HAL 2.0 à partir de Sensors HAL 1.0, assurez-vous que l'implémentation du HAL répond aux exigences suivantes.
Initialiser le HAL
La fonction initialize()
doit être compatible pour établir le rappel entre le sous-HAL et l'implémentation multi-HAL.
Exposer les capteurs disponibles
Dans Sensors Multi-HAL 2.0, la fonction getSensorsList()
doit renvoyer la même valeur
lors du démarrage d'un seul appareil, même entre les redémarrages du HAL des capteurs. Cela permet
le framework de tenter de rétablir les connexions des capteurs si le serveur système
redémarre automatiquement. La valeur renvoyée par getSensorsList()
peut changer après que l'appareil
effectue un redémarrage.
Publier des événements de capteurs dans l'implémentation multi-HAL
Dans Sensors HAL 2.0, au lieu d'attendre l'appel de poll()
, le sous-HAL doit écrire de manière proactive des événements de capteur dans IHalProxyCallback
chaque fois que des événements de capteur sont disponibles.
Événements WAKE_UP
Dans Sensors HAL 1.0, le HAL peut gérer le verrouillage de réveil pour son implémentation. Dans Sensors Multi-HAL 2.0, les sous-HAL permettent à l'implémentation Multi-HAL de gérer les wake locks et peuvent demander l'acquisition d'un wake lock en appelant createScopedWakelock
.
Un wakelock cloisonné verrouillé doit être acquis et transmis à postEvents
lorsque
publier des événements de wakeups dans l'implémentation multi-HAL.
Capteurs dynamiques
Dans Sensors HAL 1.0, les capteurs dynamiques sont renvoyés via la fonction poll()
.
Sensors Multi-HAL 2.0 exige que onDynamicSensorsConnected
et onDynamicSensorsDisconnected
dans IHalProxyCallback
soient appelés chaque fois que les connexions de capteurs dynamiques changent. Ces rappels sont disponibles dans le pointeur IHalProxyCallback
fourni via la fonction initialize()
.
Port de Sensors Multi-HAL 1.0
Pour porter une implémentation existante à partir de Sensors Multi-HAL 1.0, procédez comme suit.
- Assurez-vous que la configuration HAL des capteurs se trouve dans
/vendor/etc/sensors/hals.conf
Cela peut impliquer de déplacer le fichier situé dans/system/etc/sensors/hals.conf
. - Supprimez toute référence à
hardware/hardware.h
ethardware/sensors.h
car ils ne sont pas compatibles avec HAL 2.0. - Portez les sous-HAL comme décrit dans la section Portage à partir de Sensors HAL 1.0.
- Définissez Sensors Multi-HAL 2.0 comme HAL désigné en suivant les étapes 3 et 4 de la section Implémenter Sensors Multi-HAL 2.0.
Validation
Exécuter VTS
Une fois que vous avez intégré un ou plusieurs sous-HAL avec Sensors Multi-HAL 2.1, utilisez la suite de tests du fournisseur (VTS) pour vous assurer que vos implémentations de sous-HAL répondent à toutes les exigences définies par l'interface HAL des capteurs.
Pour exécuter uniquement les tests VTS des capteurs lorsque VTS est configuré sur une machine hôte, exécutez les commandes suivantes :
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
Si vous exécutez la couche de shim multi-HAL AIDL, exécutez VtsAidlHalSensorsTargetTest
.
vts-tradefed run commandAndExit vts \
--skip-all-system-status-check \
--primary-abi-only \
--skip-preconditions \
--module VtsAidlHalSensorsTargetTest
Exécuter des tests unitaires
Les tests unitaires de HalProxy_test.cpp
testent HalProxy
à l'aide de faux sous-HAL instanciés dans le test unitaire et qui ne sont pas chargés dynamiquement. Lorsque vous créez un sous-HAL, ces tests doivent vous servir de guide pour ajouter des tests unitaires qui vérifient que le nouveau sous-HAL est implémenté correctement.
Pour exécuter les tests, exécutez les commandes suivantes:
cd $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests
atest
Tester avec les faux sous-HAL
Les faux sous-HAL sont des implémentations factices de l'interface ISensorsSubHal
.
Les sous-HAL exposent différentes listes de capteurs. Lorsque les capteurs sont activés,
ils publient régulièrement des événements de capteurs générés automatiquement sur HalProxy
en fonction des intervalles spécifiés
dans une requête de capteur donnée.
Les faux sous-HAL peuvent être utilisés pour tester le fonctionnement du code Multi-HAL complet avec d'autres sous-HAL chargés dans le système et pour tester différents aspects du code Multi-HAL des capteurs.
Deux faux sous-HAL
sont disponibles à l'adresse
hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/
Pour créer des faux sub-HAL et les transférer vers un appareil, procédez comme suit:
Exécutez les commandes suivantes pour créer et transférer les trois instances aux sous-HAL de l'appareil:
$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
Mettez à jour la configuration du HAL des capteurs à
/vendor/etc/sensors/hals.conf
avec les chemins des faux sous-HAL./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
Redémarrez
HalProxy
et chargez les nouveaux sous-HAL listés dans la configuration.adb shell stop
adb shell start
Débogage
Les développeurs peuvent déboguer le framework à l'aide de la commande lshal
. Pour demander le
la sortie de débogage du HAL des capteurs, exécutez la commande suivante:
adb root
adb shell lshal debug android.hardware.sensors@2.1::ISensors/default
Les informations sur l'état actuel de HalProxy
et de ses sous-HAL sont ensuite affichées dans le terminal. Vous trouverez ci-dessous un exemple de résultat de la commande
Objet HalProxy
et faux sous-HAL.
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
Si le nombre spécifié pour # of events on pending write queue
est un
un grand nombre (1 000 ou plus),
cela indique que de nombreux événements sont en attente d'écriture sur les capteurs
d'infrastructure. Cela indique que le service des capteurs
est bloqué ou a planté.
ne traite pas les événements liés aux capteurs, ou qu'un grand nombre
ont récemment publié des posts depuis un sous-HAL.
Si le nombre de références de verrouillage de réveil est supérieur à 0
, cela signifie que HalProxy
a acquis un verrouillage de réveil. Cette valeur ne doit être supérieure à 0
que si un ScopedWakelock
est maintenu intentionnellement ou si des événements de réveil ont été envoyés à HalProxy
et n'ont pas été traités par le framework de capteurs.
Le descripteur de fichier transmis à la méthode de débogage de HalProxy
est transmis à chaque sous-HAL. Les développeurs doivent donc implémenter la méthode de débogage dans l'interface ISensorsSubHal
.