HAR プラットフォーム抽象化レイヤ

高可用性レンダラ（HAR）を使用して、Android で表示できない車両情報を表示します。これは、起動、可用性、安全性、規制などの問題が原因で発生する可能性があります。HAR は、Rust で記述されたポータブルな組み込みアプリです。

HAR（HAR フレームワークとも呼ばれます）には、アプリのビルドに使用するコードが含まれています。HAR で構築されたアプリは HAR ベースのアプリです。HAR フレームワークには、さまざまなプラットフォーム用のコード セクションがあります。たとえば、Linux システムでは、サウンドに tinyalsa などのライブラリを使用します。QNX には独自のオーディオ ライブラリがあります。

プラットフォームには、ハードウェア、オペレーティング システム、システム ライブラリなどの要素が含まれます。プラットフォーム固有のコードには、サブシステムと呼ばれる部分があります。各サブシステムは、音声、EVS カメラ、車両データなどのプラットフォーム機能を 1 つ処理します。プラットフォームをサポートするには、HAR フレームワークのすべてのサブシステムが実装されている必要があります。

プラットフォーム固有のサブシステム コードは、HAR ベースのアプリと同じプロセスで実行されることも、別のプロセスで実行されることもあります。分離されている場合、このコードはプロセス間通信（IPC）を処理して、プラットフォームがアプリをサポートしているかどうかを確認します。複雑な IPC メカニズムは、プラットフォーム固有のコードの一部でなければなりません。

HAR テストスイートは、プラットフォーム用に実装されたすべてのサブシステムでテストを実行します。このスイートを使用して、プラットフォームが HAR 要件を満たしているかどうかを確認し、新しい問題を見つけます。

用語

このページでは以下の用語を使用します。

HAR ベースのアプリ

HAR フレームワークで構築された OEM または機能固有のアプリ。アプリは、アプリの状態やその他のカスタマイズ可能な側面によって異なります。

HAR フレームワーク

アプリのビルドに使用されるコアツールセットを提供します。

HAR プラットフォームの抽象化

すべてのターゲット プラットフォームが実装する必要がある既知の API を提供する HAR フレームワークの一部。

HAR テストスイート

プラットフォーム実装に関する一連の既知のテスト。プラットフォーム実装が特定のプラットフォームで HAR フレームワークをサポートしていることを確認するのに役立ちます。

適用対象外

HAR では次のことはできません。

• すべてのプラットフォーム ターゲットの個々の実装: ターゲット プラットフォームの実装。このページでは、プラットフォーム実装が満たす必要のあるインターフェースと、テストスイートが満たす必要のあるインターフェースについて説明します。

• テストケース: すべてのインターフェースの具体的なテストケース。このページでは、引数、戻り値、想定される動作、想定される副作用など、インターフェースの個々の関数について説明します。このページでは、テストケースを実装して実行できるテストスイートについて説明します。

プラットフォーム抽象化の上位レベルのクレート構造

Rust プロジェクトはクレートで構成されます。図 1 は、HAR プラットフォーム抽象化レイヤのクレート構造を示しています。プラットフォーム抽象化レイヤは、2 つ以上の Rust クレートに影響します。

• 抽象化（Rust trait の説明）は HAR フレームワーク クレートにあります。

• プラットフォームの実装は、別の har-platform-x クレートによって行われます。たとえば、har-platform-linux や har-platform-android です。

プラットフォーム実装を指定しないと、HAR クレートをビルドまたはテストできません。HAR フレームワークはフレームワークであるため、これは意図的なものです。

プラットフォームを指定するアプリは、このフレームワークでビルドして、機能させ、テストする必要があります。HAR フレームワークとプラットフォーム間の接続は、次の図のとおりです。

図 1. HAR クレート。

display-safety 内の一般的な構造

この設計では、図 2 に示すように、display_safety リポジトリに一連の新しいクレートを追加します。

図 2. 抽象化モジュール。

テストスイートは構造的にはアプリに似ていますが、特定のプラットフォーム実装クレートのみに依存します。テストスイートは HAR フレームワークで定義されたトレイトと構造を参照する必要がありますが、より複雑な実装を参照してはなりません。

プラットフォーム抽象化レイヤの概要

次の表に、HAR プラットフォーム抽象化レイヤによって定義されるプラットフォーム固有のサブシステムを示します。

命名規則とフレームワーク構造

次の表に、これらの名前と構造を示します。

• HAR フレームワークによって提供される、想定されるサブシステム trait インスタンス。各 trait は、実装する必要があるプラットフォーム固有のサブシステムを表します。

• プラットフォーム クレート内のプラットフォーム固有のサブシステム実装の想定される名前。HAR ベースのアプリは、これらの特定の名前が実装されることを想定しています。

• プラットフォーム関連の実装から HAR フレームワークに情報を渡すために通常使用される、関連する HAR フレームワーク enum インスタンスと struct インスタンス。

エラーとエラー処理

提案された API は Rust の Result<> 型を使用します。Rust では、エラーを伝播する Result 型をチェックする必要があります。そうでない場合、コンパイラは警告またはエラーを生成します。ビルド時のチェックにより、プラットフォーム固有のコードからのエラーチェックが強制されます。

プラットフォーム実装から返されるエラーは harry::error::Error 型です。プラットフォーム エラータイプがアプリコードに漏洩しないことを確認するには、HAR フレームワークが提供する標準エラータイプを使用します。

harry::error::Error 型は、すべてのサブシステムに固有のエラーを含むように拡張されます。

// This is Rust
pub enum Error {
  Msg(String), // A generic message string
  // Legacy error type, likely to be removed or merged into Msg
  Audio(String),
}

回復不能なエラーは、主に定義されたインターフェースとコールバックを通じて返されます。

テストスイートの詳細設計

このセクションでは、抽象化のプラットフォーム固有の実装を検証するテストスイートの設計について説明します。

テストスイートのテストをビルドする

Soong ビルド（Android.bp ファイルで定義）の場合、テストは Android プラットフォーム ビルドシステムの一部としてコンパイルされ、実行は atest によって管理されます。

テストスイートを実行する

個々のプラットフォームをテストするには:

関連するテスト ターゲット（atest <module_name> など）を指定して atest コマンドを使用します。このコマンドは、Android デバイスまたはエミュレータにテストをデプロイして実行します。