Das Sensors Multi-HAL ist ein Framework, das es ermöglicht, neben HALs von Sensoren HALs anderer Sensor-HALs. Sensors Multi-HAL lädt dynamisch Sensoren, die untergeordnete HALs enthalten. die als dynamische Bibliotheken in der Anbieterpartition gespeichert werden, -Objekt, das das Posten von Ereignissen verarbeiten und den Wakelock abrufen und freigeben kann. Ein untergeordneter HAL ist ein Sensoren-HAL, der in ein gemeinsam genutztes Objekt auf der Anbieterpartition und wird vom Multi-HAL-Framework verwendet. Diese Sub-HALs voneinander oder vom Multi-HAL-Code abhängen, der die Hauptfunktion enthält, für den Prozess.
Sensoren Multi-HAL 2.1, verfügbar auf Geräten mit Android 11 oder höher ist, der Sensors Multi-HAL 2.0, die das Laden von untergeordneten HALs unterstützt, enthüllen die Scharnierwinkel des Sensortyps. Zur Unterstützung dieses Sensortyps müssen Unter-HAL-APIs die Sub-HAL-APIs verwenden definiert in den 2.1 SubHal-Header
Für Geräte mit Android 13 oder höher, die AIDL HAL-Sensor verwenden, können Sie Multi-HAL-Shim Layer, um Multi-HAL-Funktionen zu ermöglichen. Details zur Implementierung Siehe Verwendung des Sensors Multi-HAL mit den Sensoren AIDL HAL.
Unterschied zwischen Sensoren Multi-HAL 2 und Sensoren HAL 2
Sensoren Multi-HAL 2, verfügbar auf Geräten mit Android
10 oder höher,
mehrere Abstraktionen über Sensoren HAL
2, damit es einfacher ist,
um mit HAL APIs zu interagieren. Die Sensoren Multi-HAL 2 führen die Funktion
HalProxy
Implementierung der HAL 2-Schnittstelle für Sensoren und der
V2_1/SubHal
(oder
V2_0/SubHal
)
verwenden, damit HalProxy
mit Unter-HALs interagieren kann.
Die ISensorsSubHal
-Schnittstelle unterscheidet sich von der
2.1/ISensors.hal
(oder
2.0/ISensors.hal
)
wie folgt aussehen:
- Die Methode "initialisieren" übergibt eine
IHalProxyCallback
. statt zwei FMQs undISensorsCallback
. - Untergeordnete HALs müssen eine Debugging-Funktion implementieren, um das Debugging zu ermöglichen Informationen in Fehlerberichten.
- Sub-HALs müssen eine Namensfunktion implementieren, damit der geladene untergeordnete HAL von anderen untergeordneten HALs unterschieden werden kann.
Der Hauptunterschied zwischen den Sensoren Multi-HAL 2 und den Sensoren HAL 2 liegt in der
Funktionen zu initialisieren. Anstelle der Bereitstellung von FMQs wird der IHalProxyCallback
bietet zwei Methoden: eine Methode,
um Sensorereignisse an die Sensoren zu senden,
und eine Methode
zum Erstellen von Wakelocks. Unter der Haube
Multi-HAL verwaltet alle Interaktionen mit den FMQs, um die pünktliche Lieferung von
Sensorereignisse für alle Unter-HALs. Es wird dringend empfohlen, Sub-HALs
createScopedWakelock
-Methode zum Delegieren der Last für das Zeitlimit von Wakelocks an
Multi-HAL von Sensoren und zur Zentralisierung der Wakelock-Nutzung auf einen gemeinsamen Wakelock
für den gesamten Sensors Multi-HAL, wodurch das Ver- und Entriegeln von Anrufen minimiert wird.
Die Sensoren Multi-HAL 2 haben außerdem einige integrierte Sicherheitsfunktionen. Sie übernimmt die
Situationen, in denen der Sensor-FMQ voll oder das Android-Sensor-Framework
und der Sensorstatus muss zurückgesetzt werden. Wenn Ereignisse
in der Klasse HalProxy
veröffentlicht, aber das Sensor-Framework kann diese nicht akzeptieren
Ereignisse sofort erkennen, kann das Sensors Multi-HAL sie in einen Hintergrund verschieben.
-Thread, damit die Arbeit auf allen untergeordneten HALs fortgesetzt werden kann, während auf den
zu postende Veranstaltungen.
Implementierung von Quellcode und Referenz
Der Multi-HAL-Code aller Sensoren ist in folgenden Farben verfügbar:
hardware/interfaces/sensors/common/default/2.X/multihal/
Hier sind einige Ressourcen, die Sie interessieren könnten.
HalProxy.h
: DasHalProxy
-Objekt wird von Sensors Multi-HAL instanziiert und verarbeitet die von den untergeordneten HALs an das Sensor-Framework übergeben.HalProxy.cpp
: Die Implementierung vonHalProxy
enthält die gesamte Logik, die für Multiplex-Kommunikation zwischen Sub-HALs und dem Sensor-Framework.SubHal.h
: DieISensorsSubHal
-Schnittstelle definiert die Schnittstelle, die Sub-HALs benötigen folgen Sie, um mitHalProxy
kompatibel zu sein. Der Sub-HAL implementiert die Initialisierung der Methode so, dass dasHalProxyCallback
-Objekt fürpostEvents
undcreateScopedWakelock
.Verwenden Sie für Implementierungen mit mehreren HAL 2.0 Version 2.0 der
SubHal.h
hardware/interfaces/sensors/common/default/2.X/multihal/tests/
: Mit diesen Unittests wird dieHalProxy
-Implementierung überprüft.hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/
: In diesem Beispiel für die Sub-HAL-Implementierung werden künstliche Sensoren verwendet, Daten. Nützlich zum Testen der Interaktion mehrerer untergeordneter HALs auf einem Gerät.
Implementierung
In diesem Abschnitt wird beschrieben, wie Sie Sensors Multi-HAL in den folgenden Situationen:
- Sensoren Multi-HAL mit den Sensoren AIDL HAL verwenden
- Sensoren Multi-HAL 2.1 implementieren
- Porting von Sensoren Multi-HAL 2.0 zu Multi-HAL 2.1
- Porting von Sensoren HAL 2.0
- Porting von Sensoren HAL 1.0
- Porting von Sensoren Multi-HAL 1.0
Sensoren Multi-HAL mit den Sensoren AIDL HAL verwenden
Um Multi-HAL-Funktionen mit den Sensoren AIDL HAL zuzulassen, importieren Sie die AIDL Multi-HAL-Shimschichtmodul, das sich hardware/interfaces/sensors/aidl/default/multihal/. Das Modul übernimmt die Konvertierung zwischen der HAL-Definition von AIDL- und HIDL-Sensoren. gibt einen Typ ein und definiert einen Wrapper um die Multi-HAL-Schnittstelle, die unter Sensoren Multi-HAL 2.1 implementieren AIDL Multi-HAL Die Shim-Ebene ist mit Geräten kompatibel, die Sensors Multi-HAL 2.1 implementieren.
Mit der AIDL-Multi-HAL-Shimschicht können Sie den Kopf-Tracker freilegen
IMU-Sensortypen mit begrenzter Achse in den Sensoren AIDL HAL. So verwenden Sie diesen Sensor:
über die AIDL HAL-Schnittstelle definiert haben, legen Sie das Feld type
in der
SensorInfo
-Struktur in der getSensorsList_2_1()
-Implementierung. Das ist sicher
da die Sensortypfelder der AIDL- und HIDL-Sensoren HAL
sich nicht überschneiden.
Sensoren implementieren Multi-HAL 2.1
So implementieren Sie die Sensoren Multi-HAL 2.1 auf einem neuen Gerät:
- Implementieren Sie die
ISensorsSubHal
-Schnittstelle wie unterSubHal.h
- Implementieren Sie die
sensorsHalGetSubHal_2_1
inSubHal.h
. Fügen Sie ein
cc_library_shared
-Ziel hinzu, um die neu implementierte Unter-HAL zu erstellen. Gehen Sie beim Hinzufügen des Ziels so vor:- Sicherstellen, dass das Ziel irgendwo innerhalb des Anbieters übertragen wird Partition des Geräts.
- In der Konfigurationsdatei unter
/vendor/etc/sensors/hals.conf
fügen Sie den Pfad zur Bibliothek in einer neuen Zeile ein. Erstellen Sie bei Bedarf diehals.conf
-Datei.
Ein Beispiel für einen
Android.bp
-Eintrag zum Erstellen einer Sub-HAL-Bibliothek finden Sie unterhardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp
Alle
android.hardware.sensors
Einträge entfernen aus:manifest.xml
-Datei mit der Liste der unterstützten HALs auf dem Gerät.Alle
android.hardware.sensors
-Dienste undservice.rc
-Dateien entfernen aus die Dateidevice.mk
und fügen Sieandroid.hardware.sensors@2.1-service.multihal
hinzu undandroid.hardware.sensors@2.1-service.multihal.rc
bisPRODUCT_PACKAGES
Beim Booten startet HalProxy
, sucht nach dem neu implementierten untergeordneten HAL und
initialisiert sie mit dem Aufruf
sensorsHalGetSubHal_2_1
Anschluss von Sensoren Multi-HAL 2.0 zu Multi-HAL 2.1
Für die Portierung von Multi-HAL 2.0 zu Multi-HAL 2.1 implementieren Sie die Methode
SubHal
und die Sub-HAL neu kompilieren.
Das sind die Unterschiede zwischen den SubHal
-Oberflächen in Version 2.0 und 2.1:
IHalProxyCallback
verwendet die Typen, die erstellt wurden in Version 2.1 der SpezifikationISensors.hal
.- Die Funktion
initialize()
übergibt eine neueIHalProxyCallback
anstelle der 2.0-Version derSubHal
-Benutzeroberfläche - Sub-HALs müssen
getSensorsList_2_1
undinjectSensorData_2_1
implementieren anstelle vongetSensorsList
undinjectSensorData
, da diese Methoden die neuen Typen, die in Version 2.1 derISensors.hal
-Spezifikation hinzugefügt wurden. - Untergeordnete HALs müssen
sensorsHalGetSubHal_2_1
verfügbar machen und nichtsensorsHalGetSubHal
für den Multi-HAL, damit sie als Version 2.1 behandelt werden Sub-HALs.
Anschluss von Sensoren HAL 2.0
Beim Upgrade auf Sensoren Multi-HAL 2.0 von Sensoren HAL 2.0 und achten Sie darauf, dass der HAL die folgenden Anforderungen erfüllt.
HAL initialisieren
Die Sensoren HAL 2.0 verfügen über eine Initialisierungsfunktion, mit der der Sensordienst
FMQs und einen dynamischen Sensor-Callback übergeben. In Sensors Multi-HAL 2.0
Die initialize()
-Funktion gibt einen einzelnen Callback weiter, der zum Senden von
Sensorereignisse, Erhalt von Wakelocks, Benachrichtigungen über dynamische Sensorverbindungen und
Verbindungsabbrüche.
Sensorereignisse an die Multi-HAL-Implementierung senden
Anstatt Sensorereignisse über das FMQ zu senden, muss der Sub-HAL Sensorereignisse
zu den
IHalProxyCallback
wenn Sensorereignisse verfügbar sind.
WAKE_UP-Ereignisse
In HAL 2.0 der Sensoren kann der HAL den Wakelock für seine Implementierung verwalten. In
Sensoren Multi-HAL 2.0 ermöglicht die Multi-HAL-Implementierung
Wakelocks verwalten und den Erwerb eines Wakelocks durch Aufrufen
createScopedWakelock
Ein gesperrter Wakelock muss abgerufen und an postEvents
übergeben werden, wenn
Posten von Wake-Ereignissen an die Multi-HAL-Implementierung
Dynamische Sensoren
Für Sensoren von Multi-HAL 2.0 müssen onDynamicSensorsConnected
und
onDynamicSensorsDisconnected
Zoll
IHalProxyCallback
werden aufgerufen, wenn sich dynamische Sensorverbindungen ändern. Diese Callbacks sind
verfügbar als Teil des IHalProxyCallback
-Zeigers, der über
die Funktion initialize()
.
Anschluss von Sensoren HAL 1.0
Beim Upgrade auf Sensoren Multi-HAL 2.0 von Sensoren HAL 1.0, achten Sie darauf, dass der HAL die folgenden Anforderungen erfüllt.
HAL initialisieren
Die Funktion initialize()
muss unterstützt werden, um den Callback zwischen
die Sub-HAL- und die Multi-HAL-Implementierung.
Verfügbare Sensoren freigeben
In „Sensors Multi-HAL 2.0“ muss die getSensorsList()
-Funktion die gleiche
HAL-Neustarts über mehrere Sensoren hinweg. Dadurch können Sie
das Framework, um die Sensorverbindungen wiederherzustellen, wenn der Systemserver
neu gestartet. Der von getSensorsList()
zurückgegebene Wert kann sich nach dem Gerät ändern
führt einen Neustart aus.
Sensorereignisse an die Multi-HAL-Implementierung senden
In den Sensoren HAL 2.0 wartet der Sub-HAL nicht darauf, dass poll()
aufgerufen wird.
Sensorereignisse proaktiv in
IHalProxyCallback
wenn Sensorereignisse verfügbar sind.
WAKE_UP-Ereignisse
In HAL 1.0 der Sensoren kann der HAL den Wakelock für seine Implementierung verwalten. In
Sensoren Multi-HAL 2.0 ermöglicht die Multi-HAL-Implementierung
Wakelocks verwalten und den Erwerb eines Wakelocks durch Aufrufen
createScopedWakelock
Ein gesperrter Wakelock muss abgerufen und an postEvents
übergeben werden, wenn
Posten von Wake-Ereignissen an die Multi-HAL-Implementierung
Dynamische Sensoren
In Sensoren HAL 1.0 werden dynamische Sensoren über die Funktion poll()
zurückgegeben.
Für Sensoren von Multi-HAL 2.0 müssen onDynamicSensorsConnected
und
onDynamicSensorsDisconnected
Zoll
IHalProxyCallback
werden aufgerufen, wenn sich dynamische Sensorverbindungen ändern. Diese Callbacks sind
verfügbar als Teil des IHalProxyCallback
-Zeigers, der über
die Funktion initialize()
.
Anschluss von Sensoren Multi-HAL 1.0
Um eine vorhandene Implementierung von Sensoren Multi-HAL 1.0, führen Sie die folgenden Schritte aus.
- Die HAL-Konfiguration der Sensoren muss sich an der
/vendor/etc/sensors/hals.conf
Dies kann bedeuten, dass die Datei um/system/etc/sensors/hals.conf
. - Entfernen Sie alle Verweise auf
hardware/hardware.h
undhardware/sensors.h
da diese für HAL 2.0 nicht unterstützt werden. - Port-Sub-HALs, wie in Porting from Sensors HAL: beschrieben 1.0.
- Legen Sie die Sensoren Multi-HAL 2.0 als bezeichneten HAL fest, indem Sie die Schritte 3 und 4 ausführen. 4 im Abschnitt Sensoren Mutli-HAL 2.0 implementieren.
Zertifizierungsstufe
VTS ausführen
Wenn Sie ein oder mehrere untergeordnete HALs mit Sensoren Multi-Hal 2.1 integriert haben, Verwenden Sie die Vendor Test Suite (VTS), um sicherzustellen, dass Ihr Sub-HAL -Implementierungen alle Anforderungen der HAL-Schnittstelle von Sensors erfüllen.
Um nur die VTS-Tests der Sensoren auszuführen, wenn VTS auf einem Hostcomputer eingerichtet ist, führen Sie die folgenden Befehle aus:
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
Wenn Sie die AIDL Multi-HAL-Shim-Ebene ausführen, führen Sie VtsAidlHalSensorsTargetTest
aus.
vts-tradefed run commandAndExit vts \
--skip-all-system-status-check \
--primary-abi-only \
--skip-preconditions \
--module VtsAidlHalSensorsTargetTest
Einheitentests ausführen
Die Einheitentests in HalProxy_test.cpp
testen HalProxy
mit falschen Unter-HALs, die
werden im Einheitentest instanziiert und nicht dynamisch geladen. Beim Erstellen einer
sollten diese Tests als Leitfaden zum Hinzufügen von Einheitentests dienen,
Überprüfen Sie, ob der neue untergeordnete HAL ordnungsgemäß implementiert wurde.
Führen Sie die folgenden Befehle aus, um die Tests auszuführen:
cd $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests
atest
Mit falschen Sub-HALs testen
Die fiktiven Sub-HALs sind Dummy-Implementierungen der ISensorsSubHal
-Schnittstelle.
Die untergeordneten HALs bieten unterschiedliche Listen von Sensoren. Wenn die Sensoren aktiviert sind,
Sie posten regelmäßig automatisch generierte Sensorereignisse an HalProxy
basierend auf den Intervallen, die in einer bestimmten Sensoranfrage angegeben wurden.
Mit den fiktiven Sub-HALs kann getestet werden, wie der vollständige Multi-HAL-Code funktioniert andere in das System geladene Unter-HALs und um verschiedene Aspekte des Multi-HAL-Code der Sensoren
Zwei gefälschte Sub-HALs sind verfügbar unter
hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/
Führen Sie die folgenden Schritte aus, um falsche untergeordnete HALs zu erstellen und per Push auf ein Gerät zu übertragen:
Führen Sie die folgenden Befehle aus, um die drei verschiedenen Fake-Objekte zu erstellen und per Push zu übertragen. Sub-HALs zum Gerät hinzufügen:
$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
Aktualisieren Sie die HAL-Konfiguration für die Sensoren unter
/vendor/etc/sensors/hals.conf
mit die Pfade für die fiktiven Sub-HALs./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
Starten Sie
HalProxy
neu und laden Sie die neuen untergeordneten HALs, die in der Konfiguration aufgeführt sind.adb shell stop
adb shell start
Fehlerbehebung
Entwickler können das Framework mit dem Befehl lshal
debuggen. So fordern Sie die
Debug-Ausgabe des Sensors-HAL, führen Sie den folgenden Befehl aus:
adb root
adb shell lshal debug android.hardware.sensors@2.1::ISensors/default
Informationen zum aktuellen Status von HalProxy
und seinen untergeordneten HALs werden dann
an das Terminal aus. Unten sehen Sie ein Beispiel für die Befehlsausgabe für die
HalProxy
-Objekt und falsche Unter-HALs.
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
Wenn die für # of events on pending write queue
angegebene Zahl ein
große Zahl (1.000 oder mehr)
bedeutet dies, dass viele Ereignisse noch in die Sensoren geschrieben werden müssen.
Framework. Dies weist darauf hin, dass der Sensordienst blockiert oder abgestürzt ist.
keine Sensorereignisse verarbeitet oder dass ein großer Batch von Sensorereignissen
die kürzlich von einem untergeordneten HAL gepostet wurden.
Wenn die Anzahl der Wakelock-Referenzen größer als 0
ist, bedeutet dies, dass HalProxy
hat einen Wakelock erhalten. Dieser Wert sollte nur größer als 0
sein, wenn ein ScopedWakelock
bewusst angehalten wird oder wenn Aufwachereignisse an HalProxy
gesendet wurden und
nicht vom Sensorsystem verarbeitet.
Der an die Debug-Methode von HalProxy
übergebene Dateideskriptor wird an alle
Sub-HAL, sodass Entwickler die Debug-Methode als Teil der
ISensorsSubHal
-Schnittstelle.