Veraltung der HAL-Version

In der L-Version von Android stellen wir die Unterstützung für einige Sensor-HAL-Versionen ein. Die einzigen unterstützten Versionen sind SENSORS_DEVICE_API_VERSION_1_0 und SENSORS_DEVICE_API_VERSION_1_3 .

In den nächsten Versionen werden wir wahrscheinlich auch die Unterstützung für 1_0 einstellen.

1_0 hat kein Batching-Konzept. Wenn möglich, sollten alle Geräte, die 1_0 verwenden, auf 1_3 aktualisieren.

1_1 und 1_2 leiden unter einer schlechten Definition des Stapelkonzepts und werden nicht mehr unterstützt

Alle Geräte, die derzeit 1_1 oder 1_2 verwenden, MÜSSEN auf 1_3 aktualisiert werden.

In 1_3 haben wir das Konzept der Stapelverarbeitung vereinfacht und Wecksensoren eingeführt.

Um auf 1_3 zu aktualisieren, befolgen Sie die unten aufgeführten Änderungen.

Implementieren Sie die Batch-Funktion

Auch wenn Sie Batching nicht implementieren (Ihre Hardware hat kein FIFO), müssen Sie die batch Funktion implementieren. batch wird verwendet, um den Abtastzeitraum und die maximale Berichtslatenz für einen bestimmten Sensor festzulegen. Es ersetzt setDelay . setDelay wird nicht mehr aufgerufen.

Wenn Sie keine Stapelverarbeitung implementieren, können Sie die batch implementieren, indem Sie einfach Ihre vorhandene setDelay Funktion mit dem bereitgestellten Parameter „ sampling_period_ns “ aufrufen.

Implementieren Sie die Spülfunktion

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

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

Ändern Sie Ihre sensors_poll_device_t.common.version

your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3

Fügen Sie die neuen Felder zur Definition Ihrer Sensoren hinzu

Bei der Definition jedes Sensors zusätzlich zu den üblichen sensor_t- Feldern:

.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,

Sie müssen auch die neuen Felder festlegen, die zwischen 1_0 und 1_3 definiert sind:

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

fifoReservedEventCount : Wenn keine Stapelverarbeitung implementiert wird, setzen Sie diese auf 0.

fifoMaxEventCount : Wenn keine Stapelverarbeitung implementiert wird, setzen Sie diese auf 0

stringType : Für alle offiziellen Android-Sensoren (die in sensors.h definiert sind) auf 0 setzen, da dieser Wert vom Framework überschrieben wird. Für nicht offizielle Sensoren siehe sensor_t für Details zum Einstellen.

requiredPermission : Dies ist die Berechtigung, die Anwendungen benötigen, um Zugriff auf Ihren Sensor zu erhalten. Sie können dies normalerweise für alle Ihre Sensoren auf 0 setzen, aber Sensoren mit dem Typ HEART_RATE müssen dies auf SENSOR_PERMISSION_BODY_SENSORS.

maxDelay : Dieser Wert ist wichtig und Sie müssen ihn entsprechend den Fähigkeiten des Sensors und seines Treibers einstellen.

Dieser Wert ist nur für kontinuierliche und On-Change-Sensoren definiert. Es ist die Verzögerung zwischen zwei Sensorereignissen, die der niedrigsten Frequenz entspricht, die dieser Sensor unterstützt. Wenn niedrigere Frequenzen über die batch angefordert werden, werden die Ereignisse stattdessen mit dieser Frequenz generiert. Es kann vom Framework oder von Anwendungen verwendet werden, um abzuschätzen, wann das Stapel-FIFO voll sein kann. Wenn dieser Wert nicht richtig eingestellt ist, schlägt CTS fehl. Setzen Sie für One-Shot- und spezielle maxDelay auf 0.

Stellen Sie ihn für kontinuierliche Sensoren auf die maximal zulässige Abtastperiode in Mikrosekunden ein.

Folgendes gilt für period_ns , maxDelay und minDelay :

  • period_ns ist in Nanosekunden angegeben, während maxDelay / minDelay in Mikrosekunden angegeben sind.
  • maxDelay sollte immer in eine 32-Bit-Ganzzahl mit Vorzeichen passen. Es wird nur aus Gründen der Binärkompatibilität auf 64-Bit-Architekturen als 64-Bit deklariert.

flags : Dieses Feld definiert den Meldemodus des Sensors und ob der Sensor ein Wecksensor ist.

Wenn Sie Batching nicht implementieren und nur von 1.0 auf 1.3 wechseln, setzen Sie dies auf:

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE für One-Shot- Sensoren

SENSOR_FLAG_CONTINUOUS_MODE für kontinuierliche Sensoren SENSOR_FLAG_ON_CHANGE_MODE für On-Change- Sensoren außer Näherungssensor SENSOR_FLAG_SPECIAL_REPORTING_MODE für Sensoren mit speziellem Meldemodus außer Neigungsdetektor .

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 batch -Funktion ist jetzt fast immer erfolgreich, sogar für Sensoren, die Batching nicht unterstützen, unabhängig vom Wert des Timeout-Arguments. Die einzigen Fälle, in denen die batch Funktion möglicherweise fehlschlägt, sind interne Fehler oder ein fehlerhaftes sensor_handle, oder negatives sampling_period_ns oder negatives max_report_latency_ns .
  • Ob ein Sensor Batching unterstützt, wird dadurch definiert, ob er einen fifoMaxEventCount größer als 0 hat. (In früheren Versionen basierte er auf dem Rückgabewert von batch() .)
  • Sensoren, die Batching unterstützen, befinden sich in früheren Versionen immer im sogenannten „Batch-Modus“: Selbst wenn der Parameter max_report_latency_ns 0 ist, muss der Sensor dennoch gebatcht werden, was bedeutet, dass die Ereignisse im FIFO gespeichert werden müssen, wenn das SoC in den Suspend-Modus wechselt .
  • Der flags -Parameter der batch Funktion wird nicht mehr verwendet. DRY_RUN und WAKE_UPON_FIFO_FULL sind beide veraltet und werden niemals an die batch übergeben.
  • Das Batch-Timeout-Argument wird jetzt als max_report_latency Argument bezeichnet.