DriverUI

クラスタ UI は、従来はハンドル背後の別のディスプレイに配置されていました。OEM は、クラスタと IVI を徐々に 1 つのディスプレイに統合します。この統合された UI が DriverUI です。

図 1. DriverUI。

DriverUI は、高可用性レンダラ（HAR）によってレンダリングされる安全性関連要素または規制関連要素を除き、インストルメント クラスタのディスプレイ全体をレンダリングする Android システムアプリです。DriverUI は、メディア再生、電話、地図、ナビゲーションなどに関連する情報を表示し、Compose 向け Automotive デザインを実装します。

デフォルトのクラスタ アクティビティとしての DriverUI

DriverUI は Android で特権クラスタアプリとして実行され、AAOS が自動的に起動します。

AAOS は、ClusterHomeManager クラス（Cluster2 とも呼ばれます）を使用して、インストルメント クラスタを構築します。このクラスは、インストルメント クラスタの実装を特定するために必要な構成と、AAOS がインストルメント クラスタとやり取りする方法を指定します。Google は、Cluster2 API のリファレンス実装を提供します。

プラットフォーム

SDV でディスプレイの安全性を構築して実行できます。ソフトウェア定義自動車（SDV）プラットフォーム:

• 2 つのゲスト VM が必要です。
• ゲスト VM の SDV Media（高速ブート VM とも呼ばれます）で HAR を実行します。
• 別のゲスト SDV IVI VM で DriverUI を実行します。
• SDV Media VM で Safety Monitor を実行します。

図 2. SDV プラットフォームのアーキテクチャ。

HAR と DriverUI の出力をブレンドする

HAR と DriverUI は、別々のディスプレイを使用して UI をレンダリングします。2 つの出力は合成され、DriverUI に 1 つの画像として表示されます。

これを実現するため、HAR は DriverUI からのハートビート メッセージに基づいて、Android 出力が表示される領域の透明度を制御します。DriverUI が利用できない場合、HAR はハートビートがないことを検出し、DriverUI 領域を不透明にしてプレースホルダを表示します。ハートビートを受信すると、プレースホルダが削除され、DriverUI 領域が透明に設定されます。

図 3. HAR と DriverUI のコンポジション。

DriverUI と HAR の通信

DriverUI と HAR は、リモート プロシージャ コール（RPC）を使用して相互に通信します。ハートビート メッセージは、RPC チャネルで送信されるデータの例で、フィールドの 1 つとしてタイムスタンプが含まれています。

RPC には gRPC が使用されます。SDV では、SDV comms が SDV Gateway Client を提供し、DriverUI から HAR へのチャネルを検出して確立します。gRPC サービスはプロトコル バッファ ファイルを定義します。

// Heartbeat.
rpc Heartbeat(HeartbeatRequest) returns (HeartbeatResponse) {}

// Document switched in the DriverUI.
rpc DocumentSwitched(DocumentSwitchedRequest) returns (DocumentSwitchedResponse) {}

// Document updated in the DriverUI. Unary RPC.
rpc DocumentUpdated(DocumentUpdatedRequest) returns (DocumentUpdatedResponse) {}

// Document updated in the DriverUI. Requests are streamed with each request
// containing a part of the document and the entire document is assembled from these
// chunks by the server.
rpc DocumentUpdatedStreaming(stream DocumentUpdatedRequest) returns (DocumentUpdatedResponse) {}

/// Request for HAR to change design tokens.
rpc DesignTokenUpdate(DesignTokenUpdateRequest) returns (DesignTokenUpdateResponse) {}

// Request to change the current locale used in HAR.
rpc LocaleUpdate(LocaleUpdateRequest) returns (LocaleUpdateResponse) {}

// Requests to swap a certain variant at a Figma node.
rpc ChangeVariant(ChangeVariantRequest) returns (ChangeVariantResponse) {}

// Requests to change the container (display/root node) configuration (dpi, size) in HAR.
rpc ChangeContainerConfiguration(ChangeContainerConfigurationRequest) returns (ChangeContainerConfigurationResponse) {}

リクエストとレスポンスの詳細は、ub-automotive ソースコード リポジトリの packages/apps/Car/DriverUI/proto/driverui.proto にある Display Safety ソースにあります。

SDV プラットフォームでは、SDV comms が SDV Gateway Client を提供し、DriverUI から HAR への gRPC チャネルを検出して確立します。

IVI ターミナルを使用してこれらのコマンドを実行すると、SDV Media に通信が送信され、クラスタ全体でテーマの更新がトリガーされます。

adb shell cmd car_service inject-key -d 1 9 # Purple Theme
adb shell cmd car_service inject-key -d 1 8 # Blue Theme

図 4. DriverUI と HAR の両方のテーマを変更する RPC 通信。

クラスタにメディア、地図、電話の情報を表示

IVI との通信を通じて、DriverUI はリファレンス クラスタ内にメディア、マップ、電話の情報を表示できます。リファレンス実装では Media がデフォルトの状態ですが、ディスプレイはアクティブなサービスに基づいて次の優先度で更新されます。

1. マップ
2. 電話
3. メディア

システムは、デフォルトのメディア状態よりも、マップのナビゲーションやアクティブな電話サービスを優先して表示します。

さまざまな DriverUI 表示状態を次の図に示します。

図 5. クラスタ全体でメディアと電話セクションを表示する DriverUI。

Compose 統合のための Automotive Design

DriverUI は Compose 向け自動車デザインを実装し、デザイン（Figma）を Android アプリ内で直接表示して反復処理できるようにします。この統合により、ランタイム環境でデザイン ドキュメントをレンダリングできるようになり、デザインと開発のギャップを埋めることができます。

デザイン アセットにアクセスする

DriverUI の Figma ドキュメントのサンプルは、コードベースの一部です。これらのデザインにアクセスして変更するには:

1. packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf のローカル Automotive Design for Compose DCF デザイン ファイルを使用して DriverUI を起動します。
2. packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig アセット ファイルを見つけます。
3. このファイルを Figma にインポートして、ソースデザインを表示したり、変更を加えたりします。

Compose 版の Automotive Design

• Gradle は、packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml の designcompose に指定された Automotive Design for Compose のバージョンを使用します。
• Compose 向け Automotive Design のリリースは、リリースページで確認できます。

ライブ アップデートの設定

Automotive Design for Compose は、開発モードでのライブ更新をサポートしています。これにより、Figma で行った変更を DriverUI に即座にレンダリングできます。これにより、迅速なテストと設計の迅速なイテレーションのサイクルが容易になります。

DriverUI の Figma トークンを設定するには、次のコマンドを実行します。

adb shell am startservice \
  -n "com.android.car.driverui/com.android.designcompose.ApiKeyService" \
  -a setApiKey \
  -e ApiKey $FIGMA_ACCESS_TOKEN \
  --user 0

デュアル VM 設計ドキュメントの同期

デュアル VM 設定では、設計の更新は境界を越えて伝播し、一貫性を維持する必要があります。

• DriverUI は、最新の Figma デザイン ドキュメントを取得し、このページで説明する gRPC 通信チャネルを使用して HAR に送信します。
• これにより、クラスタ全体が最新の Figma デザイン イテレーションで更新され、両方の VM がデザイン ソースと同期されます。

図 6. Figma から DriverUI と HAR への設計ドキュメントのライブ更新。

gRPC チャネルを保護する

gRPC には SSL と TLS の統合機能があり、SSL と TLS を使用してサーバーを認証し、クライアントとサーバー間で交換されるすべてのデータを暗号化することを推奨しています。クライアントが相互認証用の証明書を提供するためのオプションのメカニズムが用意されています。gRPC 認証の詳細については、認証をご覧ください。