Einstellung der HAL-Version

Mit der L-Version von Android wird die Unterstützung für einige HAL-Versionen von Sensoren eingestellt. Die einzigen unterstützten Versionen sind SENSORS_DEVICE_API_VERSION_1_0 und SENSORS_DEVICE_API_VERSION_1_3.

In den nächsten Releases wird die Unterstützung für 1_0 wahrscheinlich ebenfalls eingestellt.

1_0 unterstützt kein Batching. Nach Möglichkeit sollten alle Geräte, auf denen 1_0 verwendet wird, auf 1_3 umgestellt werden.

1_1 und 1_2 haben eine schlechte Definition des Batching-Konzepts und werden nicht mehr unterstützt.

Alle Geräte, auf denen derzeit 1_1 oder 1_2 verwendet wird, MÜSSEN auf 1_3 umgestellt werden.

In 1_3 haben wir das Batching vereinfacht und Wecksensoren eingeführt.

Wenn Sie auf Version 1_3 umstellen möchten, führen Sie die unten aufgeführten Änderungen aus.

Batchfunktion implementieren

Auch wenn Sie kein Batching implementieren (Ihre Hardware hat keinen FIFO), müssen Sie die Funktion batch implementieren. Mit batch wird der Messzeitraum und die maximale Berichtslatenz für einen bestimmten Sensor festgelegt. Er ersetzt setDelay. setDelay wird nicht mehr aufgerufen.

Wenn Sie kein Batching implementieren, können Sie batch implementieren, indem Sie einfach Ihre vorhandene setDelay-Funktion mit dem bereitgestellten sampling_period_ns-Parameter aufrufen.

Flush-Funktion implementieren

Auch wenn Sie kein Batching implementieren, müssen Sie die Funktion flush implementieren.

Wenn Sie das Batching nicht implementieren, muss flush ein META_DATA_FLUSH_COMPLETE-Ereignis generieren und 0 (Erfolg) zurückgeben.

Ändern Sie „sensors_poll_device_t.common.version“.

your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3

Fügen Sie die neuen Felder der Definition Ihrer Sensoren hinzu.

Geben Sie bei der Definition der einzelnen Sensoren zusätzlich zu den üblichen sensor_t-Feldern Folgendes an:

.name =       "My magnetic field Sensor",
.vendor =     "My company",
.version
=    1,
.handle =     mag_handle,
.type =       SENSOR_TYPE_MAGNETIC_FIELD,
.maxRange =   200.0f,
.resolution = CONVERT_M,
.power =      5.0f,
.minDelay =
 16667,

Außerdem müssen Sie die neuen Felder zwischen 1_0 und 1_3 festlegen:

.fifoReservedEventCount = 0,
.fifoMaxEventCount =   0,
.stringType =         0,
.requiredPermission = 0,
.maxDelay =      200000
.flags =
SENSOR_FLAG_CONTINUOUS_MODE,

fifoReservedEventCount: Wenn Sie die Batchverarbeitung nicht implementieren, setzen Sie diesen Wert auf 0.

fifoMaxEventCount: Wenn Sie die Batchverarbeitung nicht implementieren, setzen Sie diesen Wert auf 0.

stringType: Legen Sie für alle offiziellen Android-Sensoren (die in sensors.h definiert sind) den Wert „0“ fest, da dieser Wert vom Framework überschrieben wird. Informationen zur Einrichtung von nicht offiziellen Sensoren finden Sie unter sensor_t.

requiredPermission: Diese Berechtigung müssen Apps haben, um auf Ihren Sensor zugreifen zu können. Normalerweise können Sie diesen Wert für alle Sensoren auf „0“ festlegen. Bei Sensoren vom Typ HEART_RATE muss er jedoch auf „SENSOR_PERMISSION_BODY_SENSORS.“ festgelegt werden.

maxDelay: Dieser Wert ist wichtig und muss entsprechend den Funktionen des Sensors und seines Treibers festgelegt werden.

Dieser Wert wird nur für kontinuierliche und bei Änderung erfassende Sensoren definiert. Das ist die Verzögerung zwischen zwei Sensorereignissen, die der niedrigsten Frequenz entspricht, die dieser Sensor unterstützt. Wenn über die Funktion batch niedrigere Frequenzen angefordert werden, werden die Ereignisse stattdessen mit dieser Frequenz generiert. Es kann vom Framework oder von Anwendungen verwendet werden, um abzuschätzen, wann der Batch-FIFO voll sein könnte. Wenn dieser Wert nicht richtig festgelegt ist, schlägt CTS fehl. Legen Sie für Sensoren im Modus „Einzelmessung“ und im speziellen Berichtsmodus maxDelay auf „0“ fest.

Legen Sie für kontinuierliche Sensoren die maximal zulässige Abtastzeit in Mikrosekunden fest.

Für period_ns, maxDelay und minDelay gilt Folgendes:

• period_ns ist in Nanosekunden, während maxDelay/minDelay in Mikrosekunden angegeben sind.
• maxDelay sollte immer in eine vorzeichenbehaftete 32‑Bit-Ganzzahl passen. Sie wird nur aus Gründen der binären Kompatibilität auf 64‑Bit-Architekturen als 64‑Bit deklariert.

flags: Dieses Feld definiert den Berichtsmodus des Sensors und ob es sich um einen Wecksensor handelt.

Wenn Sie keine Batchverarbeitung implementieren und nur von 1.0 auf 1.3 umstellen, legen Sie Folgendes fest:

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE für One-Shot-Sensoren

SENSOR_FLAG_CONTINUOUS_MODE für kontinuierliche SensorenSENSOR_FLAG_ON_CHANGE_MODE für bei Änderung Sensoren mit Ausnahme des Näherungssensors SENSOR_FLAG_SPECIAL_REPORTING_MODE für Sensoren mit besonderem Berichtsmodus mit Ausnahme des Neigungssensors

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ON_CHANGE_MODE für den Näherungssensor und den offiziellen Neigungssensor von Android.

Hinweise beim Upgrade von 1_1 oder 1_2

• Die Funktion batch funktioniert jetzt fast immer, auch bei Sensoren, die das Batching nicht unterstützen, unabhängig vom Wert des Timeout-Arguments. Die batch -Funktion kann nur bei internen Fehlern oder bei einem falschen sensor_handle,, einer negativen sampling_period_ns oder einer negativen max_report_latency_ns fehlschlagen.
• Ob ein Sensor Batching unterstützt, wird dadurch bestimmt, ob fifoMaxEventCount größer als 0 ist. In früheren Versionen basierte sie auf dem Rückgabewert von batch().
• Sensoren, die Batching unterstützen, befinden sich immer in dem in früheren Versionen als „Batch-Modus“ bezeichneten Modus: Auch wenn der Parameter max_report_latency_ns 0 ist, muss der Sensor weiterhin in Batches verarbeitet werden. Das bedeutet, dass die Ereignisse im FIFO gespeichert werden müssen, wenn das SoC in den Ruhemodus wechselt.
• Der Parameter flags der Funktion batch wird nicht mehr verwendet. DRY_RUN und WAKE_UPON_FIFO_FULL sind eingestellt und werden nie an die batch-Funktion übergeben.
• Das Argument für die Batch-Zeitüberschreitung wird jetzt als max_report_latency-Argument bezeichnet.