Android の L リリースでは、一部のセンサー HAL バージョンのサポートを終了します。サポートされるバージョンは SENSORS_DEVICE_API_VERSION_1_0
と SENSORS_DEVICE_API_VERSION_1_3
のみになります。
次回のリリースでは 1_0 もサポート対象から外れる可能性があります。
1_0 にはバッチ処理の概念がありません。可能であれば、1_0 を使用しているすべてのデバイスを 1_3 にアップグレードするようおすすめします。
1_1 と 1_2 は、バッチ処理の概念の定義が不適切であるため、サポート対象ではありません。
現在 1_1 または 1_2 を使用しているデバイスはすべて、1_3 にアップグレードする必要があります。
1_3 では、バッチ処理の考え方を単純化し、ウェイクアップ センサーを導入しました。
1_3 にアップグレードするには、下記の変更を行ってください。
バッチ関数を実装する
バッチ処理を実装しない(ハードウェアに FIFO がない)場合でも、batch
関数を実装する必要があります。batch
は、特定のセンサーのサンプリング期間と最大レポート レイテンシを設定するために使用され、setDelay
の代わりとして機能します。setDelay
は呼び出されなくなります。
バッチ処理を実装しない場合は、指定された sampling_period_ns
パラメータを使用して既存の setDelay
関数を呼び出すだけで、batch
を実装できます。
フラッシュ関数を実装する
バッチ処理を実装しなくても、flush
関数を実装する必要があります。
バッチ処理を実装しない場合、flush
は 1 つの META_DATA_FLUSH_COMPLETE
イベントを生成して 0(成功)を返す必要があります。
sensor_poll_device_t.common.version を変更する
your_poll_device.common.version = SENSORS_DEVICE_API_VERSION_1_3
センサーの定義に新しいフィールドを追加する
各センサーを定義する際には、通常の sensor_t フィールドに加えて、次が必要になります。
.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,
1_0 から 1_3 までの間に定義された新しいフィールドも設定する必要があります。
.fifoReservedEventCount = 0, .fifoMaxEventCount = 0, .stringType = 0, .requiredPermission = 0, .maxDelay = 200000 .flags = SENSOR_FLAG_CONTINUOUS_MODE,
fifoReservedEventCount: バッチ処理を実装しない場合は、これを 0 に設定します。
fifoMaxEventCount: バッチ処理を実装しない場合は、これを 0 に設定します。
stringType: この値は、フレームワークによって上書きされるため、すべての公式 Android センサー(sensor.h で定義されているもの)について 0 に設定します。非公式センサーの設定に関する詳細については、sensor_t をご覧ください。
requiredPermission: これは、アプリがセンサーにアクセスするために必要とされる権限です。通常は、すべてのセンサーについて 0 に設定してかまいませんが、HEART_RATE
タイプのセンサーでは SENSOR_PERMISSION_BODY_SENSORS.
に設定する必要があります。
maxDelay: この値は重要です。この値はセンサーとそのドライバの機能に基づいて設定する必要があります。
この値は、連続センサーと変化時センサーに対してのみ定義されます。これは、このセンサーでサポートされる最低頻度に対応する 2 つのセンサー イベント間の遅延を表します。それよりも低い頻度を batch
関数でリクエストしても、代わりにこの頻度でイベントが生成されます。フレームワークまたはアプリが、バッチ FIFO がいっぱいになるタイミングを予測するために使用できます。この値が正しく設定されていないと、CTS は失敗します。ワンショットおよび特別レポートモード センサーの場合は、maxDelay
を 0 に設定します。
連続センサーの場合は、可能な最大サンプリング時間をマイクロ秒単位で設定します。
period_ns
、maxDelay
、minDelay
には以下が適用されます。
period_ns
はナノ秒単位で、maxDelay
/minDelay
はマイクロ秒単位です。maxDelay
は常に 32 ビット符号付き整数に収まる必要があります。64 ビット アーキテクチャでは、単にバイナリ互換性の理由から、64 ビットとして宣言されます。
flags: このフィールドでは、センサーのレポートモードと、センサーがウェイクアップ センサーであるかどうかが定義されます。
バッチ処理を実装せず 1.0 から 1.3 への移行のみを実施する場合は、これを次のように設定します。
ワンショット センサーの場合は SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ONE_SHOT_MODE
連続センサーの場合は SENSOR_FLAG_CONTINUOUS_MODE
、変化時センサー(ただし近接を除く)の場合は SENSOR_FLAG_ON_CHANGE_MODE
、特別レポートモードのセンサー(ただしチルト検出を除く)の場合は SENSOR_FLAG_SPECIAL_REPORTING_MODE
。
近接センサーと Android 公式チルト検出センサーの場合は SENSOR_FLAG_WAKE_UP | SENSOR_FLAG_ON_CHANGE_MODE
。
1_1 または 1_2 からのアップグレードに関する注意事項
- 現在、
batch
関数は、バッチ処理をサポートしていないセンサーであっても、タイムアウト引数の値に関係なくほぼ必ず成功するようになりました。batch
関数が失敗するケースがあるとすれば、内部エラー、不正なsensor_handle,
、負のsampling_period_ns
、負のmax_report_latency_ns
が生じた場合に限られます。 - センサーがバッチ処理をサポートするかどうかは、
fifoMaxEventCount
が 0 より大きいかどうかによって定義されます(以前のバージョンでは、batch()
の戻り値に基づいていました)。 - バッチ処理をサポートするセンサーは常に、以前のバージョンで「バッチモード」と呼ばれていたモードになります。
max_report_latency_ns
パラメータが 0 の場合でも、センサーはバッチ処理される必要があります。つまり、SoC が停止モードになったときにはイベントを FIFO に格納する必要があります。 -
batch
関数のflags
パラメータは、使用されなくなりました。DRY_RUN
とWAKE_UPON_FIFO_FULL
はどちらも非推奨になり、batch
関数に渡されません。 - バッチ タイムアウトの引数の名称は
max_report_latency
引数に変わりました。