In der Android-Version L wird die Unterstützung für einige Sensor-HAL eingestellt
Versionen. Die einzigen unterstützten Versionen sind SENSORS_DEVICE_API_VERSION_1_0
und SENSORS_DEVICE_API_VERSION_1_3
.
In den nächsten Versionen wird die Unterstützung für 1_0 voraussichtlich ebenfalls eingestellt.
1_0 hat kein Batching-Konzept. Wenn möglich, sollten alle Geräte, die 1_0 verwenden, Upgrade auf 1_3.
1_1 und 1_2 leiden unter einer schlechten Definition des Batching-Konzepts und sind nicht mehr unterstützt
Alle Geräte, die derzeit 1_1 oder 1_2 verwenden, MÜSSEN ein Upgrade auf 1_3 durchführen.
In 1:3 vereinfachten wir das Konzept der Batchverarbeitung und führten Sensoren.
Nehmen Sie die unten aufgeführten Änderungen vor, um ein Upgrade auf 1_3 durchzuführen.
Batchfunktion implementieren
Auch wenn Sie keine Batchverarbeitung implementieren (Ihre Hardware hat kein FIFO), müssen Sie
Implementieren Sie die Funktion batch
. Mit batch
wird Folgendes festgelegt:
Stichprobenzeitraum und maximale Berichtslatenz
für einen bestimmten Sensor. Es
ersetzt setDelay
. setDelay
wird nicht aufgerufen
nicht mehr weiter.
Wenn Sie keine Batchverarbeitung implementieren, können Sie batch
implementieren, indem Sie
einfach Ihre vorhandene setDelay
-Funktion mit dem bereitgestellten
sampling_period_ns
-Parameter.
Flush-Funktion implementieren
Auch wenn Sie keine Stapelverarbeitung implementieren, müssen Sie die Methode
flush
.
Wenn Sie keine Batchverarbeitung implementieren, muss flush
eine generieren.
META_DATA_FLUSH_COMPLETE
-Ereignis und gibt 0 zurück (erfolgreich).
Ändere deine sensoren_poll_device_t.common.version
your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3
Neue Felder zur Definition Ihrer Sensoren hinzufügen
Bei der Definition jedes Sensors zusätzlich zu dem üblichen sensor_t Felder:
.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,
müssen Sie 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,
fifoReserviertEventCount: Wenn keine Batchverarbeitung implementiert wird, setzen Sie diesen Wert auf 0.
fifoMaxEventCount: Wenn keine Batchverarbeitung implementiert wird, setzen Sie diesen Wert auf 0.
stringType: Legen Sie diesen Wert für alle offiziellen Android-Sensoren, die in sensor.h), da dieser Wert vom Framework überschrieben wird. Für nicht offizielle Sensoren finden Sie unter sensor_t wie diese eingerichtet wird.
requiredPermission: Dies ist die Berechtigung, die Anwendungen benötigen, um
auf den Sensor zugreifen können. Normalerweise können Sie diese Einstellung
für alle Sensoren auf 0 setzen,
Für Sensoren des Typs HEART_RATE
muss dieser Wert jedoch auf SENSOR_PERMISSION_BODY_SENSORS.
festgelegt werden.
maxDelay: Dieser Wert ist wichtig und muss gemäß dem Funktionen des Sensors und des Treibers.
Dieser Wert wird nur für kontinuierliche und wechselnde Sensoren definiert. Es handelt sich um die
Verzögerung zwischen zwei Sensorereignissen, die der niedrigsten Häufigkeit entsprechen,
Sensor unterstützt. Wenn niedrigere Frequenzen über die
batch
verwenden, werden die Ereignisse mit dieser Häufigkeit generiert.
. Er kann vom Framework oder von Anwendungen verwendet werden, um abzuschätzen, wann der
Batch-FIFO ist möglicherweise voll. Wenn dieser Wert nicht korrekt festgelegt ist, schlägt die CTS fehl.
Legen Sie für One-Shot- und spezielle Sensoren im Berichtsmodus maxDelay
auf 0 fest.
Für kontinuierliche Sensoren stellen Sie den Wert auf den maximalen Stichprobenzeitraum ein, der in Mikrosekunden.
Folgendes gilt für period_ns
, maxDelay
und minDelay
:
period_ns
wird in Nanosekunden angegeben, währendmaxDelay
/minDelay
werden in Mikrosekunden angegeben.maxDelay
muss immer in eine vorzeichenbehaftete 32-Bit-Ganzzahl passen. Es wird in 64-Bit-Architekturen nur aus Gründen der binären Kompatibilität als 64-Bit deklariert.
flags: In diesem Feld wird der Berichtsmodus des Sensors definiert und festgelegt, ob er einem Wecksensor.
Wenn Sie keine Batchverarbeitung implementieren und nur von 1.0 auf 1.3 umstellen, legen Sie Folgendes fest: in:
SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE
für One-Shot
Sensoren
SENSOR_FLAG_CONTINUOUS_MODE
für fortlaufend
Sensoren SENSOR_FLAG_ON_CHANGE_MODE
für Bei Wechsel
Sensoren außer Näherungssensoren
SENSOR_FLAG_SPECIAL_REPORTING_MODE
für Sensoren mit spezieller
Berichtsmodus mit Ausnahme der Neigung
Detektor.
SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ON_CHANGE_MODE
für den Näherungssensor und den offiziellen Neigungsdetektor von Android.
Hinweise zum Upgrade von 1_1 oder 1_2
- Die Funktion
batch
ist jetzt fast immer erfolgreich, auch bei Sensoren, die den Batchverarbeitung unabhängig vom Wert des Zeitüberschreitungsarguments. Die einzigen Fälle bei denen die Funktionbatch
fehlschlagen kann, weil es sich um interne Fehler oder eine fehlerhaftesensor_handle,
oder negativsampling_period_ns
oder negativ:max_report_latency_ns
. - Ob ein Sensor Batchverarbeitung unterstützt, hängt davon ab, ob ein Sensor
fifoMaxEventCount
größer als 0. (In früheren Versionen basierend auf dem Rückgabewert vonbatch()
.) - Sensoren, die Batchverarbeitung unterstützen, befinden sich immer in dem sogenannten
Modus“ in früheren Versionen: Auch wenn der Parameter
max_report_latency_ns
den Wert 0 hat, muss der Sensor dennoch in Batches zusammengefasst werden, d. h. die Ereignisse müssen die im FIFO gespeichert sind, wenn das SoC in den Ruhemodus wechselt. - Der Parameter
flags
der Funktionbatch
ist werden nicht mehr verwendet.DRY_RUN
undWAKE_UPON_FIFO_FULL
sind werden nicht mehr unterstützt und nie an die Funktionbatch
übergeben. - Das Batch-Zeitlimit-Argument wird jetzt als
max_report_latency
-Argument.