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 フレームワークの enum インスタンスと struct インスタンス。通常、プラットフォーム関連の実装から HAR フレームワークに情報を渡すために使用されます。

エラーとエラー処理

提案された 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 搭載デバイスまたはエミュレータにテストをデプロイして実行します。