センサースタック

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

次の図は、Android センサー スタックを表しています。各コンポーネントは、そのすぐ上と下にあるコンポーネントとのみ通信しますが、一部のセンサーは、存在する場合にセンサー ハブをバイパスできます。アプリケーションからセンサーへの制御フローと、センサーからアプリケーションへのデータフローです。

Android センサー スタックのレイヤーと所有者

図 1. Android センサー スタックのレイヤーとそれぞれの所有者

SDK

アプリケーションは、センサー SDK (ソフトウェア開発キット) APIを介してセンサーにアクセスします。 SDK には、使用可能なセンサーを一覧表示し、センサーに登録する関数が含まれています。

センサーに登録するとき、アプリケーションは優先サンプリング周波数とレイテンシー要件を指定します。

  • たとえば、アプリケーションは既定の加速度計に登録し、100 Hz でイベントを要求し、1 秒の待機時間でイベントを報告できるようにする場合があります。
  • アプリケーションは、少なくとも 100 Hz の速度で加速度計からイベントを受信します。最大 1 秒遅れることもあります。

SDK の詳細については、開発者向けドキュメントを参照してください。

フレームワーク

フレームワークは、いくつかのアプリケーションをHALにリンクする役割を果たします。 HAL 自体はシングル クライアントです。フレームワーク レベルでこの多重化が行われないと、特定の時点で 1 つのアプリケーションのみが各センサーにアクセスできます。

  • 最初のアプリケーションがセンサーに登録されると、フレームワークは HAL に要求を送信してセンサーをアクティブにします。
  • 追加のアプリケーションが同じセンサーに登録されると、フレームワークは各アプリケーションからの要件を考慮し、更新された要求パラメーターを HAL に送信します。
    • サンプリング周波数は、要求されたサンプリング周波数の最大値になります。つまり、一部のアプリケーションは、要求した周波数よりも高い周波数でイベントを受信します。
    • 最大レポート レイテンシは、要求されたものの最小値になります。 1 つのアプリケーションが 0 の最大レポート レイテンシで 1 つのセンサーを要求した場合、すべてのアプリケーションは、ゼロ以外の最大レポート レイテンシでセンサーを要求した場合でも、このセンサーから連続モードでイベントを受信します。詳細については、バッチ処理を参照してください。
  • 1 つのセンサーに登録された最後のアプリケーションがそのセンサーから登録解除されると、フレームワークは HAL に要求を送信してセンサーを非アクティブ化し、電力が不必要に消費されないようにします。

多重化の影響

フレームワークに多重化レイヤーが必要であることは、いくつかの設計上の決定事項を説明しています。

  • アプリケーションが特定のサンプリング頻度を要求した場合、イベントがより速い速度で到着しないという保証はありません。別のアプリケーションが同じセンサーをより速い速度で要求した場合、最初のアプリケーションもそれらを高速で受け取ります。
  • 要求された最大レポート レイテンシーにも同じ保証の欠如が当てはまります。アプリケーションは、要求されたよりもはるかに短いレイテンシーでイベントを受信する可能性があります。
  • サンプリング頻度と最大レポート レイテンシ以外に、アプリケーションはセンサー パラメータを設定できません。
    • たとえば、「高精度」モードと「低電力」モードの両方で機能する物理センサーを想像してみてください。
    • Android デバイスで使用できるのは、これら 2 つのモードのうち 1 つだけです。それ以外の場合、アプリケーションは高精度モードを要求し、別のモードは低電力モードを要求する可能性があります。フレームワークが両方のアプリケーションを満たす方法はありません。フレームワークは常にすべてのクライアントを満足させることができる必要があるため、これはオプションではありません。
  • アプリケーションからセンサーまたはそのドライバーにデータを送信するメカニズムはありません。これにより、1 つのアプリケーションがセンサーの動作を変更して、他のアプリケーションを壊してしまうことがなくなります。

センサーフュージョン

Android フレームワークは、一部の複合センサーのデフォルト実装を提供します。ジャイロスコープ加速度計磁力計がデバイスに存在するが、回転ベクトル重力、および線形加速度センサーが存在しない場合、フレームワークはこれらのセンサーを実装するため、アプリケーションは引き続きそれらを使用できます。

デフォルトの実装は、他の実装がアクセスできるすべてのデータにアクセスできるわけではなく、SoC 上で実行する必要があるため、他の実装ほど正確でもなく、電力効率も高くありません。可能な限り、デバイス メーカーは、この既定の実装に依存するのではなく、独自の融合センサー (回転ベクトル、重力、線形加速度、およびゲームの回転ベクトルなどの新しい複合センサー) を定義する必要があります。デバイス メーカーは、センサー チップ ベンダーに実装を提供するよう要求することもできます。

デフォルトのセンサー フュージョンの実装は維持されていないため、それに依存するデバイスが CTS に失敗する可能性があります。

フードの下

このセクションは、Android オープン ソース プロジェクト (AOSP) フレームワーク コードの管理者向けの背景情報として提供されています。ハードウェア メーカーには関係ありません。

JNI

フレームワークは、 android.hardwareに関連付けられ、 frameworks/base/core/jni/ディレクトリにある Java Native Interface (JNI) を使用します。このコードは、下位レベルのネイティブ コードを呼び出して、センサー ハードウェアへのアクセスを取得します。

ネイティブ フレームワーク

ネイティブ フレームワークはframeworks/native/で定義され、 android.hardwareパッケージに相当するネイティブを提供します。ネイティブ フレームワークは、Binder IPC プロキシを呼び出して、センサー固有のサービスへのアクセスを取得します。

バインダーIPC

Binder IPC プロキシは、プロセス境界を越えた通信を容易にします。

ハル

Sensors Hardware Abstraction Layer (HAL) API は、ハードウェア ドライバーと Android フレームワーク間のインターフェイスです。これは、1 つの HAL インターフェイス sensors.h と、sensors.cpp と呼ばれる 1 つの HAL 実装で構成されています。

インターフェースは Android および AOSP の貢献者によって定義され、実装はデバイスの製造元によって提供されます。

センサー HAL インターフェースはhardware/libhardware/include/hardwareます。詳細については、 sensors.hを参照してください。

リリースサイクル

HAL 実装は、 your_poll_device.common.versionを設定して、実装する HAL インターフェースのバージョンを指定します。既存の HAL インターフェースのバージョンは、sensors.h で定義されており、機能はそれらのバージョンに関連付けられています。

Android フレームワークは現在、バージョン 1.0 と 1.3 をサポートしていますが、1.0 はまもなくサポートされなくなります。このドキュメントでは、すべてのデバイスをアップグレードする必要があるバージョン 1.3 の動作について説明します。 1.3 へのアップグレード方法の詳細については、 HAL バージョンの廃止を参照してください。

カーネルドライバー

センサー ドライバーは、物理デバイスと対話します。場合によっては、HAL 実装とドライバーが同じソフトウェア エンティティです。また、ハードウェア インテグレーターがセンサー チップ メーカーにドライバーの提供を要求する場合もありますが、HAL 実装を作成するのはセンサー チップ メーカーです。

いずれの場合も、HAL の実装とカーネル ドライバーはハードウェア メーカーの責任であり、Android はそれらを記述するための推奨される方法を提供していません。

センサーハブ

デバイスのセンサー スタックには、必要に応じてセンサー ハブを含めることができます。これは、SoC がサスペンド モードである場合に、低電力で低レベルの計算を実行するのに役立ちます。たとえば、これらのチップで歩数のカウントやセンサー フュージョンを実行できます。また、センサー イベント用のハードウェア FIFO を追加して、センサーのバッチ処理を実装するのにも適しています。詳細については、バッチ処理を参照してください。

注:新しいセンサーまたは LED を使用する新しい ContextHub 機能を開発するには、Hikey または Hikey960 開発ボードに接続されたNeonkey SensorHubを使用することもできます。

センサー ハブがどのように実現されるかは、アーキテクチャによって異なります。別のチップである場合もあれば、SoC と同じチップに含まれている場合もあります。センサー ハブの重要な特徴は、バッチ処理に十分なメモリが含まれている必要があり、低電力の Android センサーの実装を可能にするために電力をほとんど消費しないことです。一部のセンサー ハブには、一般的な計算用のマイクロコントローラーと、低電力センサーの超低電力計算を可能にするハードウェア アクセラレータが含まれています。

センサー ハブのアーキテクチャと、センサーおよび SoC (I2C バス、SPI バスなど) との通信方法は、Android では指定されていませんが、全体的な電力使用量を最小限に抑えることを目指す必要があります。

実装の簡素化に大きな影響を与えると思われるオプションの 1 つは、センサー ハブから SoC に 2 つの割り込みラインを接続することです。 (非ウェイクアップ センサーの場合)。

センサー

これらは、測定を行う物理MEMチップです。多くの場合、複数の物理センサーが同じチップ上に存在します。たとえば、一部のチップには、加速度計、ジャイロスコープ、磁力計が含まれています。 (このようなチップは、各センサーが 3 軸にわたってデータを提供するため、9 軸チップと呼ばれることがよくあります。)

これらのチップの一部には、モーション検出、ステップ検出、9 軸センサー フュージョンなどの通常の計算を実行するためのロジックも含まれています。

CDD の電力と精度の要件と推奨事項は、物理センサーではなく Android センサーを対象としていますが、これらの要件は物理センサーの選択に影響します。たとえば、ゲームの回転ベクトルの精度要件は、物理ジャイロスコープに必要な精度に影響します。物理センサーの要件を導き出すのは、デバイス メーカーの責任です。