Sensoren Multi-HAL

Der Sensors Multi-HAL ist ein Framework, das es ermöglicht, Sensor-HALs neben anderen Sensor-HALs auszuführen. Die Sensors Multi-HAL lädt dynamisch die Sub-HALs der Sensoren, die als dynamische Bibliotheken auf der Herstellerpartition gespeichert sind, und gibt ihnen ein Callback-Objekt, das das Posten von Ereignissen und das Erfassen und Freigeben der Wakelock verarbeiten kann. Eine Sensor-Sub-HAL ist eine Sensor-HAL, die in ein gemeinsam genutztes Objekt auf der Anbieterpartition integriert ist und vom Multi-HAL-Framework verwendet wird. Diese Sub-HALs hängen nicht voneinander oder vom Multi-HAL-Code ab, der die Hauptfunktion für den Prozess enthält.

Sensoren Multi-HAL 2.1, verfügbar auf Geräte mit Android 11 oder höher, ist eine Iteration der Sensoren Multi-HAL 2.0 , die unterstützt das Laden Unter HALs, die den belichten können Scharnier Winkelsensortyp. Um diesen Sensortyp zu unterstützen, Unter HALs muß den Sub-HAL - APIs in dem definierten verwenden 2.1 SubHal Header .

Unterschied zwischen Sensoren Multi-HAL 2 und Sensoren HAL 2

Sensoren Multi-HAL 2, auf Geräte mit Android 10 oder höher, mehrere Abstraktionen einleiten oben auf Sensoren HAL 2 zu erleichtern , mit HAL - APIs zu interagieren. Sensoren Multi-HAL 2 stellt die HalProxy Klasse zu handhaben, den Sensoren HAL 2 - Schnittstelle implementiert und das V2_1/SubHal (oder V2_0/SubHal ) Schnittstelle zu ermöglichen HalProxy mit Sub-HALs zu interagieren.

Die ISensorsSubHal Schnittstelle unterscheidet sich von der 2.1/ISensors.hal (oder 2.0/ISensors.hal ) Schnittstelle auf folgende Weise:

  • Die initialize - Methode übergibt eine IHalProxyCallback Klasse statt zwei FMQs und ISensorsCallback .
  • Sub-HALs müssen eine Debug-Funktion implementieren, um Debug-Informationen in Fehlerberichten bereitzustellen.
  • Sub-HALs müssen eine Namensfunktion implementieren, damit die geladene Sub-HAL von anderen Sub-HALs unterschieden werden kann.

Der Hauptunterschied zwischen Sensoren Multi-HAL 2 und Sensoren HAL 2 liegt in den Initialisierungsfunktionen. Anstelle des Vorsehens FMQs die IHalProxyCallback bietet Schnittstelle zwei Verfahren, eine Methode zur postSensorEreignisse an die Sensoren Rahmen und ein Verfahren zum Sperren wake zu erstellen. Unter der Haube verwaltet der Sensors Multi-HAL alle Interaktionen mit den FMQs, um die rechtzeitige Bereitstellung von Sensorereignissen für alle Sub-HALs sicherzustellen. Es wird dringend empfohlen , dass Unter HALs die Verwendung createScopedWakelock Methode , um die Last der Ablaufen wake Schlösser an den Sensoren Multi-HAL und zu zentralisieren Wake Lock Benutzung auf eine gemeinsame wake Sperre für den gesamten Sensoren Multi-HAL, die minimiert Verriegeln und Entriegeln zu delegieren Anrufe.

Sensoren Multi-HAL 2 hat auch einige eingebaute Sicherheitsfunktionen. Es behandelt Situationen, in denen die Sensor-FMQ voll ist oder das Android-Sensor-Framework neu gestartet wird und der Sensorstatus zurückgesetzt werden muss. Zusätzlich wird , wenn Ereignisse an denen gebucht werden HalProxy Klasse , aber die Sensor - Framework ist nicht in der Lage , die Ereignisse sofort zu akzeptieren, kann die Sensoren Multi-HAL , die Ereignisse zu einem Hintergrund - Thread bewegt Arbeit zu ermöglichen , über alle Unter HALs fortzusetzen , während für die Ereignisse warten gepostet werden.

Quellcode- und Referenzimplementierung

Alle Sensoren Multi-HAL - Code ist verfügbar in hardware/interfaces/sensors/common/default/2.X/multihal/ . Hier sind Hinweise auf einige Ressourcen.

  • HalProxy.h : Die HalProxy Aufgabe wird durch Sensoren Mehr HAL und Griffe die Weitergabe von Daten aus dem Unter HALs zum Sensor Rahmen instanziiert.
  • HalProxy.cpp : Die Implementierung von HalProxy enthält alle zur Multiplexkommunikation zwischen dem Unter HALs und den Sensorrahmen benötigte Logik.
  • SubHal.h : Die ISensorsSubHal - Schnittstelle definiert die Schnittstelle , die Sub-HALs müssen kompatibel sein folgen HalProxy . Die Unter HAL implementiert das Initialisierungssignal Methode , so dass der HalProxyCallback Objekt kann verwendet werden für postEvents und createScopedWakelock .

    Für Multi-HAL 2.0 - Implementierungen, die Verwendung der Version 2.0 von SubHal.h .

  • hardware/interfaces/sensors/common/default/2.X/multihal/tests/ : Diese Unit - Tests überprüfen Sie die HalProxy Implementierung.

  • hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/ : Dieses Beispiel Unter HAL Implementierung verwendet gefälschte Sensoren gefälschte Daten zu erzeugen. Nützlich, um zu testen, wie mehrere Sub-HALs auf einem Gerät interagieren.

Implementierung

In diesem Abschnitt wird beschrieben, wie Sie Sensors Multi-HAL in den folgenden Situationen implementieren:

Implementieren von Sensoren Multi-HAL 2.1

Um Sensoren Multi-HAL 2.1 auf einem neuen Gerät zu implementieren, gehen Sie folgendermaßen vor:

  1. Implementieren Sie die ISensorsSubHal Schnittstelle , wie beschrieben in SubHal.h .
  2. Umsetzung der sensorsHalGetSubHal_2_1 Methode in SubHal.h .
  3. Fügen Sie ein cc_library_shared Ziel der neu implementierten Unter HAL zu bauen. Beim Hinzufügen des Ziels:

    1. Stellen Sie sicher, dass das Ziel irgendwo auf der Herstellerpartition des Geräts verschoben wird.
    2. In der Konfigurationsdatei an sich /vendor/etc/sensors/hals.conf , fügen Sie den Pfad zu der Bibliothek auf einer neuen Zeile. Erstellen Sie bei Bedarf die hals.conf Datei.

    Ein Beispiel Android.bp Eintrag für den Aufbau einer Unter HAL Bibliothek finden Sie hardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp .

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

  5. Entfernen Sie alle android.hardware.sensors Service und service.rc Dateien aus der device.mk Datei und fügen Sie android.hardware.sensors@2.1-service.multihal und android.hardware.sensors@2.1-service.multihal.rc zu PRODUCT_PACKAGES .

Beim Booten, HalProxy beginnt, sieht für den neu Sub-HAL implementiert und initialisiert sie durch den Aufruf sensorsHalGetSubHal_2_1 .

Portierung von Sensoren Multi-HAL 2.0 auf Multi-HAL 2.1

Zum Anschluss von Multi-HAL 2.0 Multi-HAL 2.1, implementieren die SubHal Schnittstelle und neu kompilieren Ihre Sub-HAL.

Dies sind die Unterschiede zwischen dem 2.0 und 2.1 SubHal Schnittstellen:

  • IHalProxyCallback verwendet die in der Version erstellt Typen 2.1 des ISensors.hal specifcation.
  • Die initialize() Funktion gibt einen neuen IHalProxyCallback anstelle der einen aus der 2,0 SubHal Schnittstelle
  • Sub-HALs implementieren muss getSensorsList_2_1 und injectSensorData_2_1 statt getSensorsList und injectSensorData wie diese Methoden die neuen Typen verwenden hinzugefügt in Version 2.1 der ISensors.hal Spezifikation.
  • Sub-HALs muss aussetzen sensorsHalGetSubHal_2_1 statt sensorsHalGetSubHal für die Multi-HAL sie als Version 2.1 Unter HALs zu behandeln.

Portierung von Sensoren HAL 2.0

Wenn ein Upgrade auf Sensoren Multi-HAL 2.0 von Sensoren HAL 2.0 sorgen die HAL Implementierung die folgenden Anforderungen erfüllt.

Initialisieren des HAL

Sensoren HAL 2.0 verfügt über eine Initialisierungsfunktion, die es dem Sensordienst ermöglicht, FMQs und einen dynamischen Sensorrückruf zu übergeben. In Sensoren Multi-HAL 2.0, die initialize() übergibt Funktion einen Rückruf, die Postsensorereignisse verwendet werden müssen, wake Sperren erhalten, und teilt der dynamischen Sensoranschluss und Abschaltungen.

Senden von Sensorereignissen an die Multi-HAL-Implementierung

Anstelle der Sensorereignisse durch die FMQ veröffentlichen, die Sub-HAL müssen Sensorereignisse an den Schreib IHalProxyCallback wenn Sensorereignisse zur Verfügung stehen.

WAKE_UP-Ereignisse

In Sensors HAL 2.0 kann die HAL den Wakelock für seine Implementierung verwalten. In Sensoren Multi-HAL 2.0 ermöglicht der Unter HALs der Multi-HAL Implementierung wake Sperren zu verwalten und kann eine Wake Sperre anfordern unter Berufung erworben werden createScopedWakelock . Ein gesperrtes scoped wake Sperre muss erworben und weitergegeben werden postEvents wenn aufwachen , um die Multi-HAL Implementierung Veranstaltungen veröffentlichen.

Dynamische Sensoren

Sensoren Multi-HAL 2.0 erfordert , dass onDynamicSensorsConnected und onDynamicSensorsDisconnected in IHalProxyCallback werden aufgerufen , wenn dynamische Sensoranschlüsse ändern. Diese Rückrufe sind als Teil des IHalProxyCallback Zeiger, der durch die zur Verfügung gestellt wird initialize() Funktion.

Portierung von Sensoren HAL 1.0

Wenn ein Upgrade auf Sensoren Multi-HAL 2.0 von Sensoren HAL 1.0 sorgen die HAL Implementierung die folgenden Anforderungen erfüllt.

Initialisieren des HAL

Die initialize() Funktion muss den Rückruf zwischen dem Unter HAL und die Multi-HAL Implementierung aufzubauen unterstützt werden.

Verfügbare Sensoren freilegen

In Sensoren Multi-HAL 2.0, die getSensorsList() muss Funktion den gleichen Wert während eines einzigen Geräts Boots zurückkehren, auch über Sensoren Neustarts HAL. Dadurch kann das Framework versuchen, Sensorverbindungen wiederherzustellen, wenn der Systemserver neu gestartet wird. Der zurückgegebene Wert von getSensorsList() kann nach der Gerät führt einen Neustart ändern.

Senden von Sensorereignissen an die Multi-HAL-Implementierung

In Sensoren HAL 2.0, statt für Warte poll() aufgerufen wird, muss der Unter HAL proaktiv Schreibsensorereignisse an IHalProxyCallback , wenn Sensorereignisse zur Verfügung stehen.

WAKE_UP-Ereignisse

In Sensors HAL 1.0 kann die HAL den Wakelock für seine Implementierung verwalten. In Sensoren Multi-HAL 2.0 ermöglicht der Unter HALs der Multi-HAL Implementierung wake Sperren zu verwalten und kann eine Wake Sperre anfordern unter Berufung erworben werden createScopedWakelock . Ein gesperrtes scoped wake Sperre muss erworben und weitergegeben werden postEvents wenn aufwachen , um die Multi-HAL Implementierung Veranstaltungen veröffentlichen.

Dynamische Sensoren

In Sensoren HAL 1.0 dynamische Sensoren werden durch die zurück poll() Funktion. Sensoren Multi-HAL 2.0 erfordert , dass onDynamicSensorsConnected und onDynamicSensorsDisconnected in IHalProxyCallback werden aufgerufen , wenn dynamische Sensoranschlüsse ändern. Diese Rückrufe sind als Teil des IHalProxyCallback Zeiger, der durch die zur Verfügung gestellt wird initialize() Funktion.

Portierung von Sensoren Multi-HAL 1.0

Um den Port eine bestehende Implementierung von Sensoren Multi-HAL 1.0 folgendermaßen vor.

  1. Stellen Sie sicher , dass die Sensoren HAL Config befindet sich unter /vendor/etc/sensors/hals.conf. Das können Sie die Datei an sich bewegenden /system/etc/sensors/hals.conf .
  2. Entfernen Sie alle Verweise auf hardware/hardware.h und hardware/sensors.h da diese nicht für HAL 2.0 unterstützt.
  3. Port Unter HALs wie beschrieben in Portieren von Sensoren Hal 1.0 .
  4. Set Sensoren Multi-HAL 2.0 als designierter HAL durch folgende Schritte 3 und 4 in dem Ausführungs Sensor Mutli-HAL 2,0 Abschnitt.

Validierung

Ausführen von VTS

Wenn Sie einen oder mehrere Sub-HALs mit Sensoren Multi-Hal 2.1 integriert haben, verwenden Sie die Vendor Test Suite (VTS) Ihre Unter HAL Implementierungen erfüllen alle Anforderungen durch die Sensoren HAL - Schnittstelle eingestellt , um sicherzustellen.

Führen Sie die folgenden Befehle aus, um nur die VTS-Tests der Sensoren auszuführen, wenn VTS auf einem Hostcomputer eingerichtet ist:

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

Ausführen von Komponententests

Die Komponententests in HalProxy_test.cpp Test HalProxy mit gefälschtem Unter HALs , die in der Testeinheit instantiiert werden und nicht dynamisch geladen. Beim Erstellen einer neuen Sub-HAL sollten diese Tests als Leitfaden für das Hinzufügen von Komponententests dienen, die überprüfen, ob die neue Sub-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

Testen mit den gefälschten Sub-HALs

Der gefälschte Unter HALs sind Dummy - Implementierungen der ISensorsSubHal Schnittstelle. Die Sub-HALs legen verschiedene Listen von Sensoren offen. Wenn die Sensoren aktiviert sind, schreiben sie in regelmäßigen Abständen automatisch generierten Sensorereignisse zu HalProxy basierend auf den Abständen in einer gegebenen Sensoranforderung angegeben.

Die gefälschten Sub-HALs können verwendet werden, um zu testen, wie der vollständige Multi-HAL-Code mit anderen in das System geladenen Sub-HALs funktioniert, und um verschiedene Aspekte des Sensors-Multi-HAL-Codes zu betonen.

Zwei gefälschte Unter HALs sind erhältlich bei hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/ .

Führen Sie die folgenden Schritte aus, um die gefälschten Sub-HALs zu erstellen und 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 Sensoren HAL Config an /vendor/etc/sensors/hals.conf mit den Pfaden für die gefälschten Unter 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. Restart HalProxy und laden Sie die neue Unter HALs in der Config aufgeführt.

    adb shell stop
    adb shell start
    

Debuggen

Entwickler können den Rahmen debuggen , indem die Verwendung von lshal Befehl. Um die Debug-Ausgabe der Sensors HAL anzufordern, führen Sie den folgenden Befehl aus:

adb root
adb shell lshal debug android.hardware.sensors@2.1::ISensors/default

Informationen über den aktuellen Zustand der HalProxy und dessen Unter HALS dann an das Terminal. Gezeigt ist unten ein Beispiel für die Befehlsausgabe für den HalProxy Objekt und gefälschten 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 Zahl für festgelegte # of events on pending write queue eine große Anzahl (1000 oder mehr) ist, zeigt dies , dass es viele Ereignisse anstehen , an die Sensoren Rahmen geschrieben werden. Dies zeigt an, dass der Sensordienst blockiert ist oder abgestürzt ist und keine Sensorereignisse verarbeitet, oder dass kürzlich ein großer Batch von Sensorereignissen von einer untergeordneten HAL gepostet wurde.

Wenn die Wake Lock ref Zahl größer ist , als 0 bedeutet dies HalProxy ein Wake Lock erworben hat. Dies sollte nur größer als 0 , wenn ein ScopedWakelock absichtlich gehalten wird oder wenn Wake - up - Ereignisse wurden gesendet HalProxy und sind nicht von dem Sensor Rahmen verarbeitet worden ist .

Der Dateideskriptor auf die Debug - Methode übergeben HalProxy wird jedem Sub-HAL geführt , so müssen die Entwickler die Debug - Methode als Teil der Umsetzung ISensorsSubHal Schnittstelle.