Einstellung 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 Batch-Konzept. Wenn möglich, SOLLTEN alle Geräte, die 1_0 verwenden, auf 1_3 aktualisiert werden.

1_1 und 1_2 weisen eine schlechte Definition des Batch-Konzepts auf 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 kein Batch implementieren (Ihre Hardware verfügt über kein FIFO), müssen Sie die batch Funktion implementieren. batch wird verwendet, um den Abtastzeitraum und die maximale Meldelatenz für einen bestimmten Sensor festzulegen. Es ersetzt setDelay . setDelay wird nicht mehr aufgerufen.

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

Implementieren Sie die Flush-Funktion

Auch wenn Sie keine Stapelverarbeitung implementieren, müssen Sie die flush Funktion implementieren.

Wenn Sie keine Stapelverarbeitung 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

Beim Definieren 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 diesen Wert auf 0.

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

stringType : Für alle offiziellen Android-Sensoren (die in sensor.h definiert sind) auf 0 gesetzt, da dieser Wert vom Framework überschrieben wird. Informationen zu nicht offiziellen Sensoren finden Sie unter sensor_t für Einzelheiten zur Einstellung.

requirePermission : Dies ist die Berechtigung, die Anwendungen benötigen, um Zugriff auf Ihren Sensor zu erhalten. Normalerweise können Sie dies 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 wechselnde Sensoren definiert. Es handelt sich um die Verzögerung zwischen zwei Sensorereignissen, die der niedrigsten Frequenz entspricht, die dieser Sensor unterstützt. Wenn über die batch Funktion 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 eingestellt ist, schlägt CTS fehl. Für One-Shot- und spezielle Meldemodus-Sensoren setzen Sie maxDelay auf 0.

Stellen Sie bei kontinuierlichen Sensoren den maximal zulässigen Abtastzeitraum in Mikrosekunden ein.

Folgendes gilt für period_ns , maxDelay und minDelay :

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

Flags : Dieses Feld definiert den Berichtsmodus des Sensors und ob es sich bei dem Sensor um einen Wecksensor handelt.

Wenn Sie keine Stapelverarbeitung implementieren und nur von 1.0 auf 1.3 wechseln, 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 Sensoren SENSOR_FLAG_ON_CHANGE_MODE für On-Change- Sensoren außer Näherungssensoren SENSOR_FLAG_SPECIAL_REPORTING_MODE für Sensoren mit speziellem Meldemodus außer dem Neigungsdetektor .

SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ON_CHANGE_MODE für den Näherungssensor und den offiziellen Android- Neigungsdetektorsensor .

Hinweise beim Upgrade von 1_1 oder 1_2

  • Die batch Funktion ist nun fast immer erfolgreich, selbst bei Sensoren, die Batch-Funktion 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 ein negativer sampling_period_ns oder ein negativer max_report_latency_ns .
  • Ob ein Sensor die Stapelverarbeitung unterstützt, wird dadurch definiert, ob er einen fifoMaxEventCount größer als 0 hat. (In früheren Versionen basierte dies auf dem Rückgabewert von batch() .)
  • Sensoren, die die Stapelverarbeitung unterstützen, befinden sich immer in dem, was wir in früheren Versionen als „Batch-Modus“ bezeichnet haben: Auch wenn der Parameter max_report_latency_ns 0 ist, muss der Sensor weiterhin stapelweise verarbeitet werden, was bedeutet, dass die Ereignisse im FIFO gespeichert werden müssen, wenn der 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 Funktion übergeben.
  • Das Batch-Timeout-Argument wird jetzt als max_report_latency Argument bezeichnet.