Die Hardware-Abstraktionsschicht (Sensors Hardware Abstraktionsschicht, HAL) ist die Schnittstelle zwischen der Ein Android-Sensor-Framework und die Sensoren eines Geräts, z. B. ein Beschleunigungsmesser oder Gyroskop. Der HAL für die Sensoren definiert die Funktionen, die implementiert werden müssen, um damit das Framework die Sensoren steuern kann.
Die Sensors AIDL HAL ist für Android 13 und für neue und aktualisierte Geräte. Die Sensoren-AIDL HAL, die auf Für die Sensoren HAL 2.1 werden die AIDL HAL-Schnittstelle und zeigt den Kopf-Tracker und die IMU-Sensoren mit begrenzter Achse an.
AIDL HAL-Schnittstelle
Die Hauptdokumentation für die Sensoren AIDL HAL befindet sich im HAL. Definition bei hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.
Die Sensoren AIDL HAL implementieren
Zur Implementierung von Sensors AIDL HAL muss ein Objekt den ISensors erweitern.
und alle Funktionen implementieren, die in den
hardware/interfaces/sensors/aidl/android/hardware/sensors/ISensors.aidl.
HAL initialisieren
Der Sensoren-HAL muss vorher vom Android-Sensor-Framework initialisiert werden.
verwendet werden können. Das Framework ruft die Funktion initialize() auf, um drei
HAL: zwei FMQ-Deskriptoren und ein Zeiger auf einen
ISensorsCallback-Objekt.
Der HAL verwendet den ersten Deskriptor, um die Ereignis-FMQ zu erstellen, die zum Schreiben des Sensors verwendet wird
mit dem Framework. Der HAL verwendet den zweiten Deskriptor, um den Wake-
FMQ-Sperre, die zum Synchronisieren verwendet wird, wenn der HAL seinen Wakelock für WAKE_UP freigibt
Sensorereignisse verwenden. Der HAL muss einen Zeiger auf das ISensorsCallback-Objekt speichern, damit
damit alle erforderlichen Callback-Funktionen aufgerufen werden können.
Die Funktion initialize() muss bei der Initialisierung als erste Funktion aufgerufen werden
die Sensoren-HAL.
Verfügbare Sensoren freigeben
Um eine Liste aller im Gerät verfügbaren statischen Sensoren aufzurufen, verwende die
getSensorsList(). Diese Funktion gibt eine Liste von Sensoren zurück,
eindeutig durch seinen Handle identifiziert wird. Der Alias eines Sensors darf sich nicht ändern.
wenn der Hosting-Prozess des HAL für die Sensoren neu gestartet wird. Aliasse können sich in
und bei Systemserver-Neustarts.
Wenn mehrere Sensoren denselben Sensortyp und dieselbe Aufwacheigenschaft haben,
Der erste Sensor in der Liste wird als Standardsensor bezeichnet und an den
Apps, die den getDefaultSensor(int sensorType, bool wakeUp) verwenden
.
Liste der Sensorenstabilität
Wenn die von getSensorsList() zurückgegebenen Daten nach einem Neustart des Sensors HAL
weist auf eine wesentliche Änderung gegenüber der Sensorliste hin, die vor dem
löst das Framework einen Neustart des
Android-Laufzeit Zu den wesentlichen Änderungen an der Sensorliste gehören Fälle, in denen
mit einem bestimmten Ziehpunkt fehlt oder die Attribute geändert wurden
kommen neue Sensoren hinzu. Obwohl ein Neustart der Android-Laufzeit störend ist
ist erforderlich, da das Android-Framework die
Gemäß der Android API-Vereinbarung ändern sich statische (nicht dynamische) Sensoren während der
der Lebensdauer einer App. Dies kann auch verhindern, dass das Framework
aktive Sensoranfragen von Apps. Daher wird HAL-Anbietern empfohlen,
vermeidbare Änderungen an der Sensorliste verhindern.
Um stabile Sensor-Handles zu gewährleisten, muss der HAL einen bestimmten physischen Sensor des Geräts am Griff. Obwohl keine spezifische Implementierung durch die HAL-Schnittstelle der Sensoren vorgeschrieben wird, haben Entwickler um diese Anforderung zu erfüllen.
Beispielsweise lässt sich die Sensorliste mithilfe der
feste Attribute wie Anbieter, Modell und Sensortyp. Eine andere Option ist
dass die statischen Sensoren des Geräts in der Hardware unveränderlich sind, sodass der
HAL muss wissen, wann alle erwarteten Sensoren die Initialisierung abgeschlossen haben,
Rückflug von getSensorsList(). Diese Liste mit
erwartete Sensoren können in die HAL-Binärdatei kompiliert oder in einem
Konfigurationsdatei im Dateisystem und
die Reihenfolge der Darstellung kann verwendet werden,
um stabile Aliasse abzuleiten. Obwohl die beste Lösung von Ihrem HAL abhängig ist,
Implementierungsdetails erforderlich sind, müssen Sensorsensoren
ändern sich bei HAL-Neustarts nicht.
Sensoren konfigurieren
Bevor ein Sensor aktiviert wird, muss er mit einer Stichprobenerhebung konfiguriert werden
und maximale Berichtslatenz mithilfe der Funktion batch().
Ein Sensor muss mit batch() jederzeit neu konfiguriert werden können, ohne das
Sensordaten verloren gehen.
Stichprobenzeitraum
Der Stichprobenzeitraum hat je nach Sensortyp, konfiguriert werden:
- Kontinuierlich: Sensorereignisse werden kontinuierlich generiert.
- Bei Änderung: Ereignisse werden nicht schneller als der Stichprobenzeitraum generiert und können langsamer als der Stichprobenzeitraum generiert wird, wenn der gemessene Wert ändert sich nichts.
- One-Shot: Der Stichprobenzeitraum wird ignoriert.
- Specials: Weitere Informationen finden Sie unter Sensortypen
Um mehr über die Interaktion zwischen einem Stichprobenzeitraum und dem Berichtsmodi
Maximale Latenz für die Berichterstellung
Die maximale Berichtslatenz legt die maximale Zeit in Nanosekunden fest, Ereignisse können verzögert und im Hardware-FIFO gespeichert werden, bevor sie in das Ereignis-FMQ über den HAL, während das SoC aktiv ist.
Der Wert „0“ bedeutet, dass Ereignisse gemeldet werden müssen, sobald sie gemessen, wobei entweder der FIFO komplett übersprungen wird oder der FIFO geleert wird, sobald Im FIFO liegt ein Ereignis vom Sensor vor.
Beispiel: Ein Beschleunigungsmesser, der bei 50 Hz mit einer maximalen Berichterstellung aktiviert ist. Latenz von null Triggern wird 50 Mal pro Sekunde unterbrochen, wenn der SoC aktiv ist.
Ist die maximale Berichtslatenz größer null, werden Sensorereignisse müssen gemeldet werden, sobald sie erkannt werden. Termine können vorübergehend die im Hardware-FIFO gespeichert und in Batches gemeldet werden, um mehr als die maximale Berichtslatenz verzögert ist. Alle Ereignisse seit dem werden die vorherigen Batches aufgezeichnet und sofort zurückgegeben. Dadurch wird die Anzahl der Unterbrechungen, die an das SoC gesendet werden, und ermöglicht es dem SoC, in einen Modus mit geringerem Energieverbrauch zu wechseln während der Sensor Daten erfasst und in Batches aufnimmt.
Jedem Ereignis ist ein Zeitstempel zugeordnet. Die Verzögerung verzögern, zu der ein gemeldet wird, darf sich nicht auf den Ereigniszeitstempel auswirken. Der Zeitstempel muss genau sind und dem Zeitpunkt entsprechen, zu dem das Ereignis physisch stattfand, und nicht Zeitpunkt der Meldung.
Weitere Informationen und Anforderungen zum Melden von Sensorereignissen mit die maximale Berichtslatenz ungleich null haben, siehe Batching.
Sensoren aktivieren
Das Framework aktiviert und deaktiviert Sensoren mithilfe der Funktion activate().
Bevor ein Sensor aktiviert werden kann, muss das Framework den Sensor konfigurieren
mit batch().
Nachdem ein Sensor deaktiviert wurde, dürfen weitere Sensorereignisse von diesem Sensor nicht mehr in das Ereignis-FMQ geschrieben werden.
Spülsensoren
Wenn ein Sensor für die Batch-Verarbeitung von Sensordaten konfiguriert ist, kann das Framework die
eine sofortige Löschung zusammengefasster Sensorereignisse durch Aufrufen von flush(). Das führt dazu, dass
Die zusammengefassten Sensorereignisse für das angegebene Sensor-Handle werden sofort angezeigt
in Event-FMQ geschrieben. Der Sensoren-HAL muss ein Ereignis zum abgeschlossenen Leeren anhängen.
an das Ende der Sensorereignisse an, die als Ergebnis eines Aufrufs von
flush()
Das Leeren erfolgt asynchron (d. h. diese Funktion muss sofort). Wenn die Implementierung einen einzelnen FIFO für mehrere Sensoren verwendet, ist dieser FIFO geleert und das Ereignis „Leeren abgeschlossen“ wird nur für den angegebenen Sensor hinzugefügt.
Wenn der angegebene Sensor keinen FIFO hat (keine Pufferung möglich) oder wenn der FIFO
zum Zeitpunkt des Aufrufs leer ist, muss flush() trotzdem erfolgreich sein und einen Leerungsvorgang senden.
abgeschlossen ist. Dies gilt für alle Sensoren mit Ausnahme von Einzelaufnahmen
Sensoren.
Wenn flush() für einen One-Shot-Sensor aufgerufen wird, muss flush() zurückgeben
BAD_VALUE und generieren kein Leerungsabschluss-Ereignis.
Sensorereignisse in FMQ schreiben
Die Ereignis-FMQ wird vom Sensors-HAL verwendet, um Sensorereignisse an Android zu übertragen Sensor-Framework.
Das Ereignis-FMQ ist ein synchronisierter FMQ, was bedeutet, dass jeder Versuch, mehr an die FMQ senden, als der verfügbare Speicherplatz zulässt, eine fehlgeschlagene Schreiben. In diesem Fall sollte der HAL bestimmen, ob der aktuelle Satz geschrieben werden soll. als zwei kleinere Ereignisgruppen oder zum Schreiben aller Ereignisse wenn genügend Platz verfügbar ist.
Wenn der Sensoren-HAL die gewünschte Anzahl von Sensorereignissen
Event-FMQ muss der Sensoren-HAL das Framework benachrichtigen, dass Ereignisse bereit sind, indem
Schreiben des EventQueueFlagBits::READ_AND_PROCESS-Bits in die Ereignis-FMQs
EventFlag::wake. Das EventFlag kann aus dem Ereignis-FMQ erstellt werden.
mit EventFlag::createEventFlag und getEventFlagWord() der Ereignis-FMQs
.
AIDL HAL von Sensors unterstützt sowohl write als auch writeBlocking in Ereignis-FMQ.
Die Standardimplementierung bietet eine Referenz zur Verwendung von write. Wenn die
writeBlocking-Funktion verwendet wird, muss das Flag readNotification auf
EventQueueFlagBits::EVENTS_READ, der vom Framework festgelegt wird, wenn es liest
aus Ereignis-FMQ. Das Flag für Schreibbenachrichtigungen muss auf
EventQueueFlagBits::READ_AND_PROCESS, die das Framework benachrichtigt, dass Ereignisse
in Event FMQ geschrieben.
WAKE_UP-Ereignisse
WAKE_UP-Ereignisse sind Sensorereignisse, die dazu führen, dass der Anwendungsprozessor (AP)
und das Ereignis sofort abwickeln. Immer wenn ein WAKE_UP-Ereignis geschrieben wird
an Ereignis-FMQ muss der Sensoren-HAL einen Wakelock sichern, um sicherzustellen, dass der
bleibt aktiv, bis das Framework das Ereignis verarbeiten kann. Nach Erhalt einer
WAKE_UP-Ereignis handelt, sichert das Framework seinen eigenen Wakelock,
Sensoren HAL, um seinen Wakelock freizugeben. Um zu synchronisieren, wenn die Sensoren die HAL
gibt seinen Wakelock frei und verwendet die Wake Lock FMQ.
Der HAL der Sensoren muss die Wakelock-FMQ-Funktion lesen, um die Anzahl der WAKE_UP zu bestimmen
Ereignisse, die das Framework verarbeitet hat. Der HAL sollte nur seinen Wakelock freigeben
für WAKE_UP-Ereignisse, wenn die Gesamtzahl der nicht verarbeiteten WAKE_UP-Ereignisse null ist.
Nach der Verarbeitung von Sensorereignissen zählt das Framework die Anzahl der Ereignisse,
als WAKE_UP-Ereignisse markiert und schreibt diese Nummer in die Wake Lock FMQ.
Das Framework legt den WakeLockQueueFlagBits::DATA_WRITTEN-Schreibvorgang fest.
in Wake Lock FMQ erhalten, wenn Daten in die Wake Lock FMQ geschrieben werden.
Dynamische Sensoren
Dynamische Sensoren sind Sensoren, die zwar nicht Teil des Geräts sind, die als Eingabe für das Gerät verwendet werden, z. B. ein Gamepad mit Beschleunigungsmesser.
Wenn ein dynamischer Sensor verbunden ist, wird die Funktion onDynamicSensorConnected in
ISensorsCallback muss vom Sensoren-HAL aufgerufen werden. Dadurch wird der
des neuen dynamischen Sensors und ermöglicht die Steuerung des Sensors
um die Ereignisse des Sensors
von Kunden verarbeiten zu lassen.
Wenn ein dynamischer Sensor getrennt wird,
Die Funktion onDynamicSensorDisconnected in ISensorsCallback muss aufgerufen werden, damit
dass das Framework jeden
Sensor entfernen kann, der nicht mehr verfügbar ist.
Direkter Kanal
Der direkte Kanal ist eine Betriebsmethode, bei der Sensorereignisse in
einen bestimmten Arbeitsspeicher statt des Event-FMQ, das die Android-Sensoren umgeht
Framework. Ein Client, der einen direkten Kanal registriert, muss die Sensorereignisse lesen
aus dem Arbeitsspeicher, mit dem der direkte Kanal erstellt wurde,
die Sensorereignisse über das Framework empfangen. Das configDirectReport()
ähnelt batch() für den normalen Betrieb und konfiguriert die direkte
Channel melden.
Die Funktionen registerDirectChannel() und unregisterDirectChannel() erstellen
oder einen neuen direkten Channel löschen.
Betriebsmodi
Mit der Funktion setOperationMode() kann das Framework einen Sensor konfigurieren
damit das Framework Sensordaten
in den Sensor einfügen kann. Dies ist nützlich für
insbesondere für Algorithmen
unter dem Framework.
Die Funktion injectSensorData() wird normalerweise verwendet, um den Betrieb in Betrieb zu nehmen.
in den Sensoren-HAL. Die Funktion kann auch verwendet werden, um Sensor
in einen bestimmten Sensor übertragen.
Zertifizierungsstufe
Um die Implementierung der Sensoren-HAL zu überprüfen, führe die CTS- und VTS-Sensoren für den Sensor aus Tests durchführen.
CTS-Tests
CTS-Sensortests sind sowohl in automatisierten als auch in manuellen CTS-Tests vorhanden
Die automatisierten Tests befinden sich cts/tests/sensor/src/android/hardware/cts Mit diesen Tests wird die Standardfunktionalität von Sensoren überprüft, z. B. Sensoren, Batchverarbeitung und Sensorereignisraten.
Die CTS Verifier-Tests befinden sich in cts/apps/CtsVerifier/src/com/android/cts/verifier/sensors Diese Tests erfordern manuelle Eingaben durch die Testpersonen und stellen sicher, dass die Sensoren korrekte Werte melden.
Das Bestehen der CTS-Tests ist entscheidend, um sicherzustellen, dass das zu testende Gerät die alle CDD-Anforderungen erfüllt.
VTS-Tests
Die VTS-Tests für die Sensoren AIDL HAL befinden sich in
hardware/interfaces/sensors/aidl/vts/.
Mit diesen Tests wird sichergestellt, dass der HAL für die Sensoren ordnungsgemäß implementiert ist und dass alle
Anforderungen innerhalb der ISensors.aidl und ISensorsCallback.aidl ordnungsgemäß erfüllt sind.
HAL initialisieren
Die Funktion initialize() muss unterstützt werden, um FMQs zwischen den
Framework und HAL.
Verfügbare Sensoren freigeben
In Sensors AIDL HAL muss die Funktion getSensorsList() denselben Wert zurückgeben
während eines einzelnen Gerätestarts auch
über HAL-Neustarts der Sensoren hinweg. Neue Anforderung
der Funktion getSensorsList() besteht darin, dass sie während
ein einziges Gerät starten, auch über HAL-Neustarts der Sensoren hinweg. So können die
um 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 in FMQ schreiben
Anstatt darauf zu warten, dass poll() aufgerufen wird, werden in der AIDL HAL der Sensoren
HAL muss proaktiv Sensorereignisse in die Ereignis-FMQ schreiben, wenn Sensorereignisse
verfügbar sind. Der HAL ist auch
für das Schreiben der richtigen Bits
EventFlag, um einen FMQ-Lesevorgang im Framework auszulösen.
WAKE_UP-Ereignisse
In den Sensoren HAL 1.0 konnte der HAL seinen Wakelock für jeden WAKE_UP freigeben
Termin bei jedem nachfolgenden Aufruf von poll(), nachdem ein WAKE_UP gepostet wurde an
poll(), da dies darauf hinweist, dass das Framework den gesamten Sensor
und ggf. einen Wakelock erhalten hatten. Denn in der Sensors-AIDL
HAL wird der HAL nicht mehr benachrichtigt, wenn das Framework Ereignisse verarbeitet hat.
Wake Lock FMQ ermöglicht dem Framework die Kommunikation mit dem
HAL, wenn WAKE_UP-Ereignisse verarbeitet wurden.
Im Sensors AIDL HAL, der vom Sensoren-HAL für WAKE_UP gesicherte Wakelock
Ereignisse müssen mit SensorsHAL_WAKEUP beginnen.
Dynamische Sensoren
Dynamische Sensoren wurden mit der Funktion poll() in Sensoren HAL 1.0 zurückgegeben.
Für die Sensoren-AIDL HAL müssen onDynamicSensorsConnected und
onDynamicSensorsDisconnected in ISensorsCallback wird immer dann aufgerufen, wenn ein dynamischer
Sensorverbindungen ändern sich. Diese Callbacks sind im Rahmen des
Der Zeiger ISensorsCallback, der durch die Funktion initialize() bereitgestellt wird.
Betriebsmodi
Der DATA_INJECTION-Modus für WAKE_UP-Sensoren muss unterstützt werden.
Multi-HAL-Unterstützung
Die Sensoren AIDL HAL unterstützen Multi-HAL mithilfe der Sensors-Multi-HAL-Framework. Für Implementierungsdetails, siehe Portierung von Sensoren HAL 2.1.