Diese Seite wurde von der Cloud Translation API übersetzt.

Sensoren Multi-HAL

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 und ISensorsCallback.
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: Das HalProxy-Objekt wird von Sensors Multi-HAL instanziiert und verarbeitet die von den untergeordneten HALs an das Sensor-Framework übergeben.
HalProxy.cpp: Die Implementierung von HalProxy enthält die gesamte Logik, die für Multiplex-Kommunikation zwischen Sub-HALs und dem Sensor-Framework.
SubHal.h: Die ISensorsSubHal-Schnittstelle definiert die Schnittstelle, die Sub-HALs benötigen folgen Sie, um mit HalProxy kompatibel zu sein. Der Sub-HAL implementiert die Initialisierung der Methode so, dass das HalProxyCallback-Objekt für postEvents und createScopedWakelock.

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 die HalProxy-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 unter SubHal.h
Implementieren Sie die sensorsHalGetSubHal_2_1 in SubHal.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:
1. Sicherstellen, dass das Ziel irgendwo innerhalb des Anbieters übertragen wird Partition des Geräts.
2. 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 die hals.conf-Datei.
Ein Beispiel für einen Android.bp-Eintrag zum Erstellen einer Sub-HAL-Bibliothek finden Sie unter hardware/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 und service.rc-Dateien entfernen aus die Datei device.mk und fügen Sie android.hardware.sensors@2.1-service.multihal hinzu und android.hardware.sensors@2.1-service.multihal.rc bis PRODUCT_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 Spezifikation ISensors.hal.
Die Funktion initialize() übergibt eine neue IHalProxyCallback anstelle der 2.0-Version der SubHal-Benutzeroberfläche
Sub-HALs müssen getSensorsList_2_1 und injectSensorData_2_1 implementieren anstelle von getSensorsList und injectSensorData, da diese Methoden die neuen Typen, die in Version 2.1 der ISensors.hal-Spezifikation hinzugefügt wurden.
Untergeordnete HALs müssen sensorsHalGetSubHal_2_1 verfügbar machen und nicht sensorsHalGetSubHal 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 und hardware/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.