传统上，仪表盘界面位于方向盘后方的单独显示屏中。原始设备制造商 (OEM) 逐渐将集群和 IVI 合并到单个显示屏中。这种组合界面就是 DriverUI。
图 1. DriverUI。
DriverUI 是一款 Android 系统应用，用于呈现整个仪表盘显示，但不包括高可用性渲染器 (HAR) 呈现的安全相关元素或监管元素。DriverUI 会显示与媒体播放、电话通话、地图、导航等相关的信息，并实现 Automotive Design for Compose。
将 DriverUI 用作默认集群 activity
DriverUI 在 Android 中作为特权集群应用运行，AAOS 会自动启动它。
AAOS 使用 ClusterHomeManager 类（也称为 Cluster2）来构建仪表盘集群。此类指定了识别仪表盘实现所需的配置，以及 AAOS 与仪表盘的互动方式。Google 提供了 Cluster2 API 的参考实现。
平台
您可以在 SDV 上构建和运行 Display Safety。软件定义车辆 (SDV) 平台：
- 需要两个 guest 虚拟机。
- 在客机虚拟机中运行 SDV Media（也称为快速启动虚拟机）中的 HAR。
- 在另一个客机 SDV IVI 虚拟机中运行 DriverUI。
- 在 SDV 媒体虚拟机上运行安全监控器。
图 2. SDV 平台架构。
混合 HAR 和 DriverUI 输出
HAR 和 DriverUI 使用单独的显示屏来呈现其界面。这两个输出是复合输出，在 DriverUI 中显示为一张图片。
为实现此目的，HAR 会根据来自 DriverUI 的心跳消息控制 Android 输出显示区域的透明度。当 DriverUI 不可用时，HAR 会检测到没有心跳，并将 DriverUI 区域渲染为不透明并显示占位符。收到心跳后，系统会移除占位符，并将 DriverUI 区域设置为透明。
图 3. HAR 和 DriverUI 组成。
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
图 4. RPC 通信，用于更改 DriverUI 和 HAR 主题。
在集群上显示媒体、地图和电话信息
通过与 IVI 通信，DriverUI 可以在参考集群中显示媒体、地图和电话信息。虽然媒体在参考实现中充当默认状态，但显示会根据有效服务按以下优先级进行更新：
- 地图
- 电话
- 媒体
系统会自动优先显示地图导航或活跃的电话服务，而不是默认的媒体状态。
下图展示了各种 DriverUI 显示状态：
图 5. DriverUI 在完整仪表盘中展示媒体和电话部分。
适用于 Compose 集成的 Automotive 设计
DriverUI 实现了 Automotive Design for Compose，以便在 Android 应用中直接展示设计 (Figma) 并对其进行迭代。此集成通过在运行时环境中呈现设计文档，弥合了设计与开发之间的差距。
访问设计资源
DriverUI 的示例 Figma 文档是代码库的一部分。如需访问和修改这些设计，请执行以下操作：
- 使用
packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf中的本地 Automotive Design for Compose DCF 设计文件启动 DriverUI。 - 找到
packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig资源文件。 - 将此文件导入 Figma 以查看源设计或进行更改。
适用于 Compose 版本的 Automotive 设计
- Gradle 使用
packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml中为designcompose指定的 Automotive Design for Compose 版本。 - 您可以在版本页面上找到 Automotive Design for Compose 版本。
实时更新配置
适用于 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
双虚拟机设计文档同步
在双虚拟机设置中，设计更新必须跨边界传播，以保持一致性。
- DriverUI 会获取最新的 Figma 设计文档，并通过此页面上详述的 gRPC 通信渠道将其传输到 HAR。
- 这样一来，整个集群就会更新为最新的 Figma 设计迭代版本，从而使两个虚拟机都与设计源保持同步。
图 6. 从 Figma 到 DriverUI 和 HAR 的设计文档实时更新。
保护 gRPC 通道
gRPC 集成了 SSL 和 TLS，并提倡使用 SSL 和 TLS 来验证服务器身份，以及加密客户端和服务器之间交换的所有数据。客户端可选择使用一些机制来提供证书以进行双向身份验证。如需详细了解 gRPC 身份验证，请参阅身份验证。