Sensoren – Multi-HAL

Die Sensors Multi-HAL ist ein Framework, mit dem Sensor-HALs neben anderen Sensor-HALs ausgeführt werden können. Sensors Multi-HAL lädt dynamisch Sensoren, die untergeordnete HALs enthalten. die als dynamische Bibliotheken in der Anbieterpartition gespeichert sind, -Objekt, das das Posten von Ereignissen verarbeiten und den Wakelock abrufen und freigeben kann. Eine Sensor-Sub-HAL ist eine Sensor-HAL, die in ein freigegebenes Objekt auf der Anbieterpartition eingebunden ist und vom Multi-HAL-Framework verwendet wird. Diese untergeordneten HALs sind weder voneinander noch vom Multi-HAL-Code abhängig, der die Hauptfunktion für den Prozess enthält.

Sensors Multi-HAL 2.1 ist auf Geräten mit Android 11 oder höher verfügbar und eine Iteration von Sensors Multi-HAL 2.0, die das Laden von untergeordneten HALs unterstützt, die den Sensortyp Scharnierwinkel freigeben können. Zur Unterstützung dieses Sensortyps müssen Sub-HALs die im 2.1 SubHal-Header definierten Sub-HAL-APIs verwenden.

Auf Geräten mit Android 13 oder höher, die die Sensors AIDL HAL verwenden, können Sie die Multi-HAL-Shimsschicht verwenden, um Multi-HAL-Funktionen zu ermöglichen. Implementierungsdetails finden Sie unter Sensors Multi-HAL mit der Sensors AIDL HAL verwenden.

Unterschied zwischen Sensoren Multi-HAL 2 und Sensoren HAL 2

Sensors Multi-HAL 2 ist auf Geräten mit Android 10 oder höher verfügbar und bietet mehrere Abstraktionsschichten zusätzlich zu Sensors HAL 2, um die Interaktion mit HAL APIs zu vereinfachen. In Sensors Multi-HAL 2 wird die Klasse HalProxy eingeführt, die die Implementierung der Sensors HAL 2-Schnittstelle und der V2_1/SubHal- (oder V2_0/SubHal-)Schnittstelle übernimmt, damit HalProxy mit untergeordneten 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.
  • Untergeordnete HALs müssen eine Namensfunktion implementieren, damit die 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. Anstatt FMQs bietet die IHalProxyCallback-Schnittstelle zwei Methoden: eine Methode zum Posten von Sensorereignissen an das Sensor Framework und eine Methode zum Erstellen von Wakelocks. Unter der Motorhaube werden die Sensoren Multi-HAL verwaltet alle Interaktionen mit den FMQs, um die pünktliche Lieferung von Sensorereignisse für alle Unter-HALs. Es wird dringend empfohlen, dass untergeordnete HALs die Methode createScopedWakelock verwenden, um die Zeitüberschreitung von Wakelocks an die Sensors Multi-HAL zu delegieren und die Verwendung von Wakelocks auf eine gemeinsame Wakelock für die gesamte Sensors Multi-HAL zu zentralisieren. Dadurch werden Sperr- und Entsperraufrufe minimiert.

Sensors Multi-HAL 2 bietet 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 an die HalProxy-Klasse gepostet werden, das Sensor-Framework sie aber nicht sofort akzeptieren kann, kann die Multi-HAL von Google Pixel die Ereignisse in einen Hintergrund-Thread verschieben, damit die Arbeit in allen untergeordneten HALs fortgesetzt werden kann, während auf das Posten der Ereignisse gewartet wird.

Quellcode und Referenzimplementierung

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 Multi-HAL 2.0-Implementierungen Version 2.0 von 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

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 Umwandlung zwischen HAL-Definitionen von AIDL- und HIDL-Sensoren und definiert einen Wrapper für die Multi-HAL-Schnittstelle, die in Implementing Sensors Multi-HAL 2.1 beschrieben wird. Die AIDL-Multi-HAL-Shimsschicht 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 sich die Felder für den Sensortyp der AIDL- und HIDL-Sensoren HAL nicht überschneiden.

Sensoren implementieren Multi-HAL 2.1

So implementieren Sie die Sensoren Multi-HAL 2.1 auf einem neuen Gerät:

  1. Implementieren Sie die ISensorsSubHal-Schnittstelle wie unter SubHal.h
  2. Implementieren Sie die sensorsHalGetSubHal_2_1 in SubHal.h.

  3. Fügen Sie ein cc_library_shared-Ziel hinzu, um die neu implementierte Unter-HAL zu erstellen. Beachten Sie beim Hinzufügen des Ziels Folgendes:

    1. Achten Sie darauf, dass das Ziel an eine Stelle auf der Anbieterpartition des Geräts gesendet wird.
    2. Fügen Sie in der Konfigurationsdatei unter /vendor/etc/sensors/hals.conf den Pfad zur Bibliothek in einer neuen Zeile hinzu. 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.

  4. Entfernen Sie alle android.hardware.sensors-Einträge aus der Datei manifest.xml, die die Liste der unterstützten HALs auf dem Gerät enthält.

  5. 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 Starten wird HalProxy gestartet, nach der neu implementierten Sub-HAL gesucht und diese durch Aufrufen von sensorsHalGetSubHal_2_1 initialisiert.

Port von Sensors Multi-HAL 2.0 zu Multi-HAL 2.1

Wenn Sie von Multi-HAL 2.0 zu Multi-HAL 2.1 wechseln möchten, implementieren Sie die Schnittstelle SubHal und kompilieren Sie die untergeordnete HAL neu.

Das sind die Unterschiede zwischen den SubHal-Benutzeroberflächen 2.0 und 2.1:

  • IHalProxyCallback verwendet die Typen, die in Version 2.1 der ISensors.hal-Spezifikation erstellt wurden.
  • Die Funktion initialize() übergibt eine neue IHalProxyCallback anstelle der 2.0-Version der SubHal-Benutzeroberfläche
  • Untergeordnete HALs müssen getSensorsList_2_1 und injectSensorData_2_1 anstelle von getSensorsList und injectSensorData implementieren, da diese Methoden die neuen Typen verwenden, 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

Sensors HAL 2.0 hat eine Initialisierungsfunktion, mit der der Sensordienst FMQs und einen dynamischen Sensor-Callback übergeben kann. 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 posten

Anstatt Sensorereignisse über die FMQ zu posten, muss die untergeordnete HAL Sensorereignisse in die IHalProxyCallback schreiben, wenn Sensorereignisse verfügbar sind.

WAKE_UP-Ereignisse

In Sensors HAL 2.0 kann die HAL die Wake-Lock für die Implementierung verwalten. In Sensoren Multi-HAL 2.0 ermöglicht die Multi-HAL-Implementierung Wakelocks verwalten und den Erwerb eines Wakelocks durch Aufrufen createScopedWakelock Wenn Weck-Ereignisse an die Multi-HAL-Implementierung gesendet werden, muss eine gesperrte Wecksperre abgerufen und an postEvents übergeben werden.

Dynamische Sensoren

Bei Sensors Multi-HAL 2.0 müssen onDynamicSensorsConnected und onDynamicSensorsDisconnected in IHalProxyCallback aufgerufen werden, wenn sich dynamische Sensorverbindungen ändern. Diese Callbacks sind als Teil des IHalProxyCallback-Zeigers verfügbar, der über die initialize()-Funktion bereitgestellt wird.

Port von Sensors HAL 1.0

Wenn Sie von Sensors HAL 1.0 auf Sensors Multi-HAL 2.0 umstellen, muss die HAL-Implementierung die folgenden Anforderungen erfüllen.

HAL initialisieren

Die Funktion initialize() muss unterstützt werden, um den Rückruf zwischen der untergeordneten HAL und der Multi-HAL-Implementierung herzustellen.

Verfügbare Sensoren freigeben

In Sensors Multi-HAL 2.0 muss die Funktion getSensorsList() bei einem einzelnen Gerätestart denselben Wert zurückgeben, auch bei Neustarts der HAL der Sensoren. So kann das Framework versuchen, Sensorverbindungen wiederherzustellen, wenn der Systemserver neu gestartet wird. Der von getSensorsList() zurückgegebene Wert kann sich nach einem Neustart des Geräts ändern.

Sensorereignisse an die Multi-HAL-Implementierung senden

In Sensors HAL 2.0 muss die untergeordnete HAL nicht darauf warten, dass poll() aufgerufen wird, sondern Sensorereignisse proaktiv in IHalProxyCallback schreiben, sobald 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 Wenn Weck-Ereignisse an die Multi-HAL-Implementierung gesendet werden, muss eine gesperrte Wecksperre abgerufen und an postEvents übergeben werden.

Dynamische Sensoren

In Sensors 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 als Teil des IHalProxyCallback-Zeigers verfügbar, der über die initialize()-Funktion bereitgestellt wird.

Anschluss von Sensoren Multi-HAL 1.0

So portieren Sie eine vorhandene Implementierung von Sensors Multi-HAL 1.0:

  1. Die HAL-Konfiguration der Sensoren muss sich unter /vendor/etc/sensors/hals.conf befinden. Dazu muss möglicherweise die Datei unter /system/etc/sensors/hals.conf verschoben werden.
  2. Entfernen Sie alle Verweise auf hardware/hardware.h und hardware/sensors.h, da diese für HAL 2.0 nicht unterstützt werden.
  3. Portieren Sie untergeordnete HALs wie unter Porting from Sensors Hal 1.0 beschrieben.
  4. 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 eine oder mehrere untergeordnete HALs in Sensors Multi-HAL 2.1 eingebunden haben, verwenden Sie die Vendor Test Suite (VTS), um sicherzustellen, dass Ihre untergeordneten HAL-Implementierungen alle Anforderungen der Sensors HAL-Schnittstelle 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

Unittests 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 neuen untergeordneten HAL sollten diese Tests als Leitfaden dienen, um Unit-Tests hinzuzufügen, die überprüfen, ob die neue untergeordnete HAL richtig implementiert ist.

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, senden sie basierend auf den in einer bestimmten Sensoranfrage angegebenen Intervallen regelmäßig automatisch generierte Sensorereignisse an HalProxy.

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

Unter hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/ sind zwei gefälschte untergeordnete HALs verfügbar.

Führen Sie die folgenden Schritte aus, um gefälschte untergeordnete HALs zu erstellen und per Push auf ein Gerät zu übertragen:

  1. Führen Sie die folgenden Befehle aus, um die drei verschiedenen gefälschten Sub-HALs zu erstellen und auf das Gerät zu übertragen:

    $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

  2. Aktualisieren Sie die HAL-Konfiguration für Sensoren unter /vendor/etc/sensors/hals.conf mit den Pfaden zu den gefälschten untergeordneten 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

  3. 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. Führen Sie den folgenden Befehl aus, um die Debugausgabe der Sensors HAL anzufordern:

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 im Terminal ausgegeben. Unten sehen Sie ein Beispiel für die Befehlsausgabe für das HalProxy-Objekt und die gefälschten untergeordneten 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 sehr hoch ist (1.000 oder mehr), gibt es viele Ereignisse, die noch in das Sensor-Framework geschrieben werden müssen. 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, hat HalProxy ein Wakelock erworben. Dieser Wert sollte nur dann größer als 0 sein, wenn eine ScopedWakelock absichtlich gehalten wird oder wenn Weck-Ereignisse an HalProxy gesendet und nicht vom Sensor-Framework verarbeitet wurden.

Der an die Debug-Methode von HalProxy übergebene Dateideskriptor wird an alle Sub-HAL, sodass Entwickler die Debug-Methode als Teil der ISensorsSubHal-Schnittstelle.