スマートフォンには多数のプロセッサが搭載されており、それぞれがさまざまなタスクを実行するために最適化されています。ただし、Androidは、アプリケーションプロセッサ（AP）という1つのプロセッサでのみ実行されます。 APは、ゲームなどの画面オンのユースケースで優れたパフォーマンスを提供するように調整されていますが、画面がオフの場合でも、頻繁に短時間の処理を必要とする機能をサポートするには電力が不足しています。小型のプロセッサは、これらのワークロードをより効率的に処理し、バッテリ寿命に大きな影響を与えることなくタスクを完了できます。ただし、これらの低電力プロセッサのソフトウェア環境はより制限されており、大きく異なる可能性があるため、クロスプラットフォーム開発が困難になります。
Context Hub Runtime Environment（CHRE）は、シンプルで標準化された組み込み対応のAPIを使用して、低電力プロセッサーでアプリを実行するための共通プラットフォームを提供します。 CHREを使用すると、デバイスOEMとその信頼できるパートナーは、APから処理をオフロードし、バッテリーを節約し、ユーザーエクスペリエンスのさまざまな領域を改善し、特にマシンのアプリケーションに関連する、常にオンのコンテキスト認識機能のクラスを有効にします。アンビエントセンシングを学ぶ。
重要な概念
CHREは、 nanoappsと呼ばれる小さなネイティブアプリケーションが低電力プロセッサで実行され、共通のCHREAPIを介して基盤となるシステムと対話するソフトウェア環境です。 CHRE APIの適切な実装を加速するために、CHREのクロスプラットフォームリファレンス実装がAOSPに含まれています。リファレンス実装には、一連のプラットフォーム抽象化レイヤー（PAL）を介した、基盤となるハードウェアおよびソフトウェアへの共通コードと抽象化が含まれます。 Nanoappsは、ほとんどの場合、Androidで実行されている1つ以上のクライアントアプリに関連付けられています。これらのクライアントアプリは、アクセスが制限されたContextHubManagerシステムAPIを介してCHREおよびnanoappsと対話します。
大まかに言えば、CHREのアーキテクチャとAndroid全体の間に類似点を描くことができます。ただし、いくつかの重要な違いがあります。
- CHREは、ネイティブコード（CまたはC ++）で開発されたnanoappのみの実行をサポートします。 Javaはサポートされていません。
- リソースの制約とセキュリティの制限により、CHREは任意のサードパーティのAndroidアプリで使用できません。システムが信頼するアプリのみがアクセスできます。
CHREの概念とセンサーハブの間には重要な違いもあります。同じハードウェアを使用してセンサーハブとCHREを実装するのが一般的ですが、CHRE自体はAndroidセンサーHALに必要なセンサー機能を提供しません。 CHREはContextHubHALに関連付けられており、APを使用せずにセンサーデータを受信するためのデバイス固有のセンサーフレームワークのクライアントとして機能します。
図1.CHREフレームワークアーキテクチャ
コンテキストハブHAL
Context Hubハードウェアアブストラクションレイヤー（HAL）は、AndroidフレームワークとデバイスのCHRE実装の間のインターフェイスであり、 hardware/interfaces/contexthubで定義されています。 Context Hub HALは、Androidフレームワークが利用可能なコンテキストハブとそのnanoappを検出し、メッセージパッシングを通じてそれらのnanoappと対話し、nanoappのロードとアンロードを可能にするAPIを定義します。 CHREのリファレンス実装と連携するContextHubHALのリファレンス実装は、 system/chre/hostで入手できます。
このドキュメントとHAL定義の間に矛盾がある場合は、HAL定義が優先されます。
初期化
Androidが起動すると、 ContextHubServiceはgetHubs() HAL関数を呼び出して、デバイスで使用可能なコンテキストハブがあるかどうかを判断します。これはブロッキングの1回限りの呼び出しであるため、起動の遅延を回避するために迅速に完了する必要があり、新しいコンテキストハブを後で導入できないため、正確な結果を返す必要があります。
nanoappsのロードとアンロード
コンテキストハブには、デバイスイメージに含まれ、CHREの開始時にロードされる一連のナノアプリを含めることができます。これらはプリロードされたnanoappsと呼ばれ、 queryApps()への最初の可能な応答に含める必要があります。
Context Hub HALは、 loadNanoApp()およびunloadNanoApp()関数を介して、実行時に動的にnanoappをロードおよびアンロードすることもサポートします。 Nanoappsは、デバイスのCHREハードウェアおよびソフトウェア実装に固有のバイナリ形式でHALに提供されます。
nanoappをロードするための実装に、CHREを実行するプロセッサに接続されたフラッシュストレージなどの不揮発性メモリへの書き込みが含まれる場合、CHRE実装は、これらの動的nanoappを無効状態で常に起動する必要があります。これは、 enableNanoapp()リクエストがHALを介して受信されるまで、nanoappのコードが実行されないことを意味します。プリロードされたnanoappは、有効な状態で初期化できます。
コンテキストハブが再起動します
CHREは通常の操作中に再起動することは想定されていませんが、マップされていないメモリアドレスにアクセスしようとするなど、予期しない状態から回復する必要がある場合があります。このような状況では、CHREはAndroidから独立して再起動します。 HALはRESTARTEDイベントを介してAndroidにこれを通知します。このイベントは、CHREがqueryApps()などの新しいリクエストを受け入れることができるように再初期化された後にのみ送信する必要があります。
CHREシステムの概要
CHREは、イベント駆動型アーキテクチャを中心に設計されており、計算の主要な単位は、nanoappのイベント処理エントリポイントに渡されるイベントです。 CHREフレームワークはマルチスレッド化できますが、特定のnanoappが複数のスレッドから並行して実行されることはありません。 CHREフレームワークは、3つのnanoappエントリポイント（ nanoappStart() 、 nanoappHandleEvent() 、 nanoappEnd() ）のいずれか、または以前のCHRE API呼び出しで提供されたコールバックを介して、特定のnanoappと対話し、nanoappはCHREフレームワークと対話します。 CHREAPIを介した基盤となるシステム。 CHRE APIは、センサー、GNSS、Wi-Fi、WWAN、オーディオなどのコンテキスト信号にアクセスするための一連の基本機能と機能を提供し、ベンダー固有のnanoappで使用するための追加のベンダー固有の機能で拡張できます。 。
ビルドシステム
Context Hub HALおよびその他の必要なAP側コンポーネントはAndroidと一緒にビルドされますが、CHRE内で実行されるコードには、専用のツールチェーンの必要性など、Androidビルドシステムとの互換性をなくす要件が含まれる場合があります。したがって、AOSPのCHREプロジェクトは、GNU Makeに基づいてnanoappsをコンパイルするための簡略化されたビルドシステムを提供し、オプションで、システムと統合できるライブラリにCHREフレームワークを提供します。 CHREのサポートを追加するデバイスメーカーは、ターゲットデバイスのビルドシステムサポートをAOSPに統合する必要があります。
CHRE APIはC99言語標準に基づいて記述されており、リファレンス実装では、リソースが制限されたアプリケーションに適したC++11の制限されたサブセットが使用されます。
CHRE API
CHRE APIは、nanoappとシステム間のソフトウェアインターフェイスを定義するCヘッダーファイルのコレクションです。これは、CHREをサポートするすべてのデバイス間でnanoappsコードの互換性を保つように設計されています。つまり、nanoappのソースコードを変更して新しいデバイスタイプをサポートする必要はありませんが、ターゲットデバイスのプロセッサ用に特別に再コンパイルする必要がある場合があります。命令セットまたはアプリケーションバイナリインターフェイス（ABI）。 CHREアーキテクチャとAPI設計により、nanoappはCHRE APIの異なるバージョン間でバイナリ互換性が確保されます。つまり、異なるバージョンのCHRE APIを実装するシステムで実行するために、nanoappを再コンパイルする必要はありません。 nanoappがコンパイルされるターゲットAPI。つまり、nanoappバイナリがCHRE API v1.3をサポートするデバイスで実行され、そのデバイスがCHRE API v1.4をサポートするようにアップグレードされた場合、同じnanoappバイナリは引き続き機能します。同様に、nanoappはCHRE API v1.2で実行でき、実行時にAPI v1.3の機能が必要かどうか、または機能が正常に低下する可能性があるかどうかを判断できます。
CHRE APIの新しいバージョンはAndroidと一緒にリリースされますが、CHREの実装はベンダーの実装の一部であるため、デバイスでサポートされているCHREAPIのバージョンは必ずしもAndroidのバージョンにリンクされているとは限りません。
バージョンの概要
Android HIDLバージョン管理スキームと同様に、CHREAPIはセマンティックバージョニングに従います。メジャーバージョンはバイナリ互換性を示しますが、マイナーバージョンは下位互換性のある機能が導入されると増分されます。 CHRE APIには、関数またはパラメーターを導入したバージョンを識別するためのソースコードアノテーションが含まれています（例@since v1.1 ）。
CHRE実装は、 chreGetVersion()を介してプラットフォーム固有のパッチバージョンも公開します。これは、実装でバグ修正またはマイナーアップデートが行われた時期を示します。
バージョン1.0（Android 7）
センサーのサポート、およびイベントやタイマーなどのコアnanoapp機能が含まれます。
バージョン1.1（Android 8）
GNSS位置と生の測定、Wi-Fiスキャン、セルラーネットワーク情報を介して位置機能を導入し、nanoappからnanoappへの通信を可能にする一般的な改良やその他の改善を行います。
バージョン1.2（Android 9）
低電力マイク、Wi-Fi RTTレンジング、APウェイク/スリープ通知、およびその他の改善からのデータのサポートを追加します。
バージョン1.3（Android 10）
センサーキャリブレーションデータに関連する機能を強化し、バッチ化されたセンサーデータをオンデマンドでフラッシュするためのサポートを追加し、ステップ検出センサータイプを定義し、追加の精度フィールドでGNSSロケーションイベントを拡張します。
バージョン1.4（Android 11）
5Gセル情報、nanoappデバッグダンプ、およびその他の改善のサポートを追加します。
必須のシステム機能
センサーなどのコンテキスト信号のソースはオプションの機能領域に分類されますが、すべてのCHRE実装でいくつかのコア機能が必要です。これには、タイマーの設定、アプリケーションプロセッサ上のクライアントとのメッセージの送受信、ロギングなどのコアシステムAPIが含まれます。詳細については、 APIヘッダーを参照してください。
CHRE APIで体系化されたコアシステム機能に加えて、ContextHubHALレベルで指定された必須のCHREシステムレベル機能もあります。これらの中で最も重要なのは、nanoappを動的にロードおよびアンロードする機能です。
C /C++標準ライブラリ
メモリ使用量とシステムの複雑さを最小限に抑えるために、CHREの実装では、標準のCおよびC ++ライブラリのサブセットと、ランタイムサポートを必要とする言語機能のみをサポートする必要があります。これらの原則に従って、一部の機能は、メモリや広範なOSレベルの依存関係のために明示的に除外され、その他の機能は、より適切なCHRE固有のAPIに取って代わられているためです。網羅的なリストを意図したものではありませんが、以下の機能をnanoappsで利用できるようにすることを意図したものではありません。
- C ++例外と実行時型情報（RTTI）
- C ++ 11ヘッダー
<thread>、<mutex>、<atomic>、<future>を含む標準ライブラリマルチスレッドのサポート - CおよびC++標準入出力ライブラリ
- C ++標準テンプレートライブラリ（STL）
- C++標準正規表現ライブラリ
- 標準関数（たとえば、
malloc、calloc、realloc、free、operator new）、およびstd::unique_ptrなどの動的割り当てを本質的に使用するその他の標準ライブラリ関数による動的メモリ割り当て - ローカリゼーションとUnicode文字のサポート
- 日付と時刻のライブラリ
<setjmp.h>、<signal.h>、abort、std::terminateなどの通常のプログラムフローを変更する関数system、getenvを含むホスト環境へのアクセス- C99またはC++11言語標準に含まれていないPOSIXおよびその他のライブラリ
多くの場合、同等の機能はCHREAPI関数やユーティリティライブラリから利用できます。たとえば、 chreLogは、Android logcatシステムを対象としたデバッグロギングに使用できます。従来のプログラムでは、 printfまたはstd::coutを使用する場合があります。
対照的に、いくつかの標準ライブラリ機能が必要です。 nanoappバイナリに含めるために静的ライブラリを介して、またはnanoappとシステム間の動的リンクによってこれらを公開するのは、プラットフォームの実装次第です。これには以下が含まれますが、これらに限定されません。
- 文字列/配列ユーティリティ：
memcmp、memcpy、memmove、memset、strlen 数学ライブラリ：一般的に使用される単精度浮動小数点関数：
- 基本操作：
ceilf、fabsf、floorf、fmaxf、fminf、fmodf、roundf、lroundf、remainderf - 指数/電力関数：
expf、log2f、powf、sqrtf - 三角関数/双曲線関数：
sinf、cosf、tanf、asinf、acosf、atan2f、tanhf
- 基本操作：
一部の基盤となるプラットフォームは追加機能をサポートしていますが、nanoappは、外部依存関係をCHRE API関数と承認された標準ライブラリ関数に制限しない限り、CHRE実装間で移植可能とは見なされません。
オプション機能
ハードウェアとソフトウェアを促進するために、CHRE APIは機能領域に分割されており、APIの観点からはオプションと見なされます。これらの機能は、互換性のあるCHRE実装をサポートするために必要ではない場合がありますが、特定のnanoappをサポートするために必要な場合があります。プラットフォームが特定のAPIセットをサポートしていない場合でも、それらの関数を参照するnanoappは、ビルドおよびロードできる必要があります。
センサー
CHRE APIは、加速度計、ジャイロスコープ、磁力計、環境光センサー、近接センサーなどのセンサーにデータを要求する機能を提供します。これらのAPIは、消費電力を削減するためのセンサーサンプルのバッチ処理のサポートなど、AndroidセンサーAPIと同様の機能セットを提供することを目的としています。 CHRE内でセンサーデータを処理すると、APで実行する場合と比較して、モーション信号の処理がはるかに低電力で低遅延になります。
GNSS
CHREは、GPSやその他の衛星コンステレーションを含むグローバルナビゲーション衛星システム（GNSS）からの位置データを要求するためのAPIを提供します。これには、定期的な位置修正の要求と生の測定データが含まれますが、どちらも独立した機能です。 CHREはGNSSサブシステムに直接リンクしているため、APはロケーションセッションのライフサイクル全体を通じてスリープ状態を維持できるため、APベースのGNSS要求と比較して電力が削減されます。
Wi-Fi
CHREは、主にロケーションの目的でWi-Fiチップと対話する機能を提供します。 GNSSは屋外の場所でうまく機能しますが、Wi-Fiスキャンの結果は、屋内および開発地域で正確な位置情報を提供できます。スキャンのためにAPをウェイクアップするコストを回避することに加えて、CHREは、接続の目的でWi-Fiファームウェアによって実行されたWi-Fiスキャンの結果をリッスンできます。これは通常、電力上の理由でAPに配信されません。コンテキスト目的で接続スキャンを活用すると、実行されるWi-Fiスキャンの総数を減らし、電力を節約できます。
Wi-FiのサポートがCHREAPIv1.1で追加されました。これには、スキャン結果を監視し、オンデマンドでスキャンをトリガーする機能が含まれます。これらの機能はv1.2で拡張され、この機能をサポートするアクセスポイントに対してラウンドトリップ時間（RTT）測定を実行する機能が追加され、正確な相対位置の決定が可能になりました。
WWAN
CHRE APIは、サービングセルとその隣接セルのセル識別情報を取得する機能を提供します。これは通常、大まかなロケーションの目的で使用されます。
オーディオ
CHREは、SoundTrigger HALの実装に使用されるハードウェアを通常利用する、低電力マイクからのオーディオデータのバッチを処理できます。 CHREでオーディオデータを処理すると、モーションセンサーなどの他のデータと融合させることができます。
リファレンス実装
CHREフレームワークの参照コードは、C++11で実装されたsystem/chreプロジェクトのAOSPに含まれています。厳密には必須ではありませんが、一貫性を確保し、新機能の採用を加速するために、すべてのCHRE実装をこのコードベースに基づくことをお勧めします。このコードは、アプリケーションが使用するAPIのオープンソース実装であり、互換性のベースラインおよび標準として機能するという点で、コアAndroidフレームワークに類似していると見なすことができます。ベンダー固有の機能を使用してカスタマイズおよび拡張できますが、共通コードを可能な限り参照に近づけることをお勧めします。 AndroidのHALと同様に、CHREリファレンス実装はさまざまなプラットフォームの抽象化を使用して、最小要件を満たす任意のデバイスに適応できるようにします。
技術的な詳細と移植ガイドについては、 system/chreプロジェクトに含まれているREADMEを参照してください。