DriverUI

傳統上，儀表板 UI 會放在方向盤後方的獨立螢幕上。原始設備製造商 (OEM) 逐漸將儀表板和 IVI 整合至單一螢幕。這個整合式 UI 稱為 DriverUI。

DriverUI

圖 1. DriverUI。

DriverUI 是 Android 系統應用程式，可轉譯整個儀表板螢幕，但不包括由高可用性轉譯器 (HAR) 轉譯的安全相關或法規元素。DriverUI 會顯示與媒體播放、電話、地圖、導航等相關的資訊，並實作 Automotive Design for Compose。

DriverUI 做為預設叢集活動

DriverUI 會在 Android 中以具特殊權限的叢集應用程式執行，且 AAOS 會自動啟動。

AAOS 會使用 ClusterHomeManager 類別 (也稱為 Cluster2) 建構儀表板。這個類別會指定識別儀表板實作所需的設定，以及 AAOS 與儀表板的互動方式。Google 提供 Cluster2 API 的參考實作。

平台

您可以在 SDV 上建構及執行 Display Safety。軟體定義車輛 (SDV) 平台：

  • 需要兩個訪客 VM。
  • 在訪客 VM 中，於 SDV Media (也稱為快速啟動 VM) 執行 HAR。
  • 在另一個客體 SDV IVI VM 中執行 DriverUI。
  • 在 SDV Media VM 上執行 Safety Monitor。

SDV 平台架構

圖 2. SDV 平台架構。

混合 HAR 和 DriverUI 輸出內容

HAR 和 DriverUI 會使用不同的螢幕顯示 UI。這兩個輸出內容會合成，並在 DriverUI 中顯示為一張圖片。

為此，HAR 會根據 DriverUI 的心跳訊息，控制 Android 輸出內容顯示區域的透明度。如果 DriverUI 無法使用，HAR 會偵測到缺少心跳訊號，並將 DriverUI 區域轉為不透明，並顯示預留位置。收到心跳訊號後，系統會移除預留位置，並將 DriverUI 區域設為透明。

HAR 和 DriverUI 組合

圖 3. HAR 和 DriverUI 組合。

排解 Alpha 組合和穿透問題

由於 HAR 對安全至關重要，因此其硬體顯示平面位於 Android IVI 顯示平面上方。在 HAR 中建構或偵錯自訂檢視畫面或外部 OpenGL ES 介面時，請確認 Alpha 值的設定方式：

  • HAR 平面下方缺少 DriverUI 輸出：雖然 HAR 會從 DriverUI 接收有效的 HeartbeatRequest 訊息，但 HAR 必須將 DriverUI 檢視區區域清除為透明 (alpha = 0.0)，以便顯示底層的 Android 儀表板 UI。如果自訂 HAR 圖層或背景在 DriverUI 區域繪製不透明像素 (alpha = 1.0)，就會遮蓋下方的 Android 輸出內容。
  • 自訂 3D 或 OpenGL 介面中出現非預期的透明孔洞：將外部 OpenGL ES 或 3D 介面算繪至 HAR 節點時 (例如自訂 3D 儀表或場景，寫入 RGB 像素，並將未使用的 Alpha 位元組保留在 0x00)，請明確將不透明像素的 Alpha 管道設為 0xFF (alpha = 1.0)。如果將 Alpha 位元組保留在 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 管道傳送的資料範例，其中一個欄位包含時間戳記。

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

RPC 通訊，可同時變更 DriverUI 和 HAR 主題。

圖 4. 透過 RPC 通訊變更 DriverUI 和 HAR 主題。

在儀表板上顯示媒體、地圖和電話資訊

透過與 IVI 通訊，DriverUI 可以在參考叢集中顯示媒體、地圖和電話的資訊。雖然在參考實作中，媒體是預設狀態，但螢幕會根據下列優先順序，依據使用中的服務更新：

  1. 地圖
  2. 電話通訊系統
  3. 媒體

系統會自動優先顯示地圖導航或使用中的電話服務，而非預設的媒體狀態。

下圖說明各種 DriverUI 顯示狀態：

DriverUI 完整顯示媒體和電話通訊區塊。

圖 5. DriverUI 顯示完整叢集中的媒體和電話區段。

Compose 整合的 Automotive 設計

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 驗證，請參閱「驗證」。