DriverUI

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

DriverUI

図 1. DriverUI。

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

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

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

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

プラットフォーム

SDV で Display Safety をビルドして実行できます。ソフトウェア定義自動車（SDV）プラットフォーム:

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

SDV プラットフォーム アーキテクチャ

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

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

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

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

HAR と DriverUI の構成

図 3. HAR と DriverUI の構成。

アルファ合成とパンチスルーのトラブルシューティング

HAR は安全性に不可欠であるため、そのハードウェア ディスプレイ プレーンは Android IVI ディスプレイ プレーンの上に配置されます。HAR でカスタムビューまたは外部 OpenGL ES サーフェスをビルドまたはデバッグする場合は、アルファ値の設定方法を確認します。

  • HAR プレーンの下に DriverUI 出力がない: HAR は DriverUI から有効な HeartbeatRequest メッセージを受信しますが、HAR は DriverUI ビューポート領域を透明（alpha = 0.0）にクリアして、基盤となる Android クラスタ UI が表示されるようにする必要があります。カスタム HAR レイヤまたは背景が DriverUI 領域に不透明なピクセル（alpha = 1.0）を描画すると、その下にある Android の出力がブロックされます。
  • カスタム 3D または OpenGL サーフェスに意図しない透明な穴がある: 外部の OpenGL ES または 3D サーフェスを HAR ノードにレンダリングする場合（未使用のアルファバイトを 0x00 に残したまま RGB ピクセルを書き込むカスタム 3D ゲージやシーンなど）、不透明なピクセルのアルファ チャンネルを明示的に 0xFF（alpha = 1.0）に設定します。アルファバイトを 0x00 のままにすると、コンポジタはそれらのピクセルを透明（alpha = 0.0）として扱い、HAR レイヤを貫通して基盤となる Android IVI プレーンに穴を開けます。
  • クロス VM ディスプレイ診断: HAR（sdv_media_har_cf）と Android IVI（sdv_ivi_cf_ds）は別々のゲスト VM で実行されるため、Android IVI VM で adb shell dumpsys SurfaceFlinger を実行すると、Android レイヤのみが検査され、上位の HAR プレーンは表示されません。

DriverUI と HAR の通信

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

gRPC は RPC に使用されます。SDV では、SDV 通信が SDV ゲートウェイ クライアントを提供し、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 通信が SDV ゲートウェイ クライアントを提供し、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

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

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

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

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

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

システムは、デフォルトのメディア状態よりも、マップ ナビゲーションまたはアクティブなテレフォニー サービスの表示を自動的に優先します。

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

フルクラスタのメディア セクションと電話セクションを表示する DriverUI。

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

Compose 統合のための Automotive Design

DriverUI は Automotive Design for 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 にインポートして、ソースデザインを表示したり、変更を加えたりします。

Automotive Design for Compose のバージョン

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

ライブ情報の設定

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 がデザインソースと同期されます。

Figma から DriverUI と HAR への設計ドキュメントのライブ アップデート。

図 6. Figma から DriverUI と HAR への設計ドキュメントのライブ アップデート。

gRPC チャネルを保護する

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