Einstellung der HAL-Version

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ährend maxDelay/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 Funktion batch fehlschlagen kann, weil es sich um interne Fehler oder eine fehlerhafte sensor_handle, oder negativ sampling_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 von batch().)
  • 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 Funktion batch ist werden nicht mehr verwendet. DRY_RUN und WAKE_UPON_FIFO_FULL sind werden nicht mehr unterstützt und nie an die Funktion batch übergeben.
  • Das Batch-Zeitlimit-Argument wird jetzt als max_report_latency-Argument.