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ährendmaxDelay
/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 diebatch
Funktion möglicherweise fehlschlägt, sind interne Fehler oder ein fehlerhaftessensor_handle,
oder ein negativersampling_period_ns
oder ein negativermax_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 vonbatch()
.) - 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 derbatch
Funktion wird nicht mehr verwendet.DRY_RUN
undWAKE_UPON_FIFO_FULL
sind beide veraltet und werden niemals an diebatch
Funktion übergeben. - Das Batch-Timeout-Argument wird jetzt als
max_report_latency
Argument bezeichnet.