HAL バージョンのサポート終了

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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_nsmaxDelayminDelay には以下が適用されます。

  • 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_RUNWAKE_UPON_FIFO_FULL はどちらもサポートが終了しており、batch 関数に渡されなくなります。
  • バッチ タイムアウトの引数の名称は max_report_latency 引数に変わりました。