클러스터 UI는 일반적으로 핸들 뒤에 별도의 디스플레이로 배치되어 있습니다. OEM은 계기판과 IVI를 단일 디스플레이로 점차 결합하고 있습니다. 이 결합된 UI가 DriverUI입니다.
그림 1. DriverUI.
DriverUI는 전체 계기판 디스플레이를 렌더링하는 Android 시스템 앱입니다. 단, 고가용성 렌더러 (HAR)에서 렌더링하는 안전 관련 요소나 규제 요소는 제외됩니다. DriverUI는 미디어 재생, 전화 통화, 지도, 내비게이션 등과 관련된 정보를 표시하고 Automotive Design for Compose를 구현합니다.
DriverUI를 기본 클러스터 활동으로 사용
DriverUI는 Android에서 권한이 있는 클러스터 앱으로 실행되며 AAOS는 이를 자동으로 시작합니다.
AAOS는 Cluster2라고도 하는 ClusterHomeManager 클래스를 사용하여 계기판을 빌드합니다. 이 클래스는 계기판 구현을 식별하는 데 필요한 구성과 AAOS가 계기판과 상호작용하는 방식을 지정합니다. Google은 Cluster2 API의 참조 구현을 제공합니다.
플랫폼
SDV에서 디스플레이 안전을 빌드하고 실행할 수 있습니다. 소프트웨어 정의 차량 (SDV) 플랫폼:
- 게스트 VM 2개가 필요합니다.
- 게스트 VM의 SDV 미디어 (빠른 부팅 VM이라고도 함)에서 HAR을 실행합니다.
- 다른 게스트 SDV IVI VM에서 DriverUI를 실행합니다.
- SDV 미디어 VM에서 안전 모니터를 실행합니다.

그림 2. SDV 플랫폼 아키텍처
HAR 및 DriverUI 출력 혼합
HAR과 DriverUI는 별도의 디스플레이를 사용하여 UI를 렌더링합니다. 두 출력은 합성되어 DriverUI에 하나의 이미지로 표시됩니다.
이를 위해 HAR은 DriverUI의 하트비트 메시지를 기반으로 Android 출력이 표시되는 영역의 투명도를 제어합니다. DriverUI를 사용할 수 없는 경우 HAR은 하트비트가 없음을 감지하고 DriverUI 영역을 불투명하게 렌더링하고 자리표시자를 표시합니다. 하트비트가 수신되면 자리표시자가 삭제되고 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 채널을 통해 전송되는 데이터의 예이며 타임스탬프를 필드 중 하나로 포함합니다.
gRPC는 RPC에 사용됩니다. SDV에서 SDV 통신은 DriverUI에서 HAR로의 채널을 검색하고 설정하는 SDV 게이트웨이 클라이언트를 제공합니다. 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에 있는 디스플레이 안전 소스에 있습니다.
SDV 플랫폼에서 SDV 통신은 DriverUI에서 HAR로 gRPC 채널을 검색하고 설정하는 SDV 게이트웨이 클라이언트를 제공합니다.
IVI 터미널을 사용하여 이러한 명령어를 실행하면 SDV 미디어에 통신이 전송되어 전체 클러스터에서 테마 업데이트가 트리거됩니다.
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는 참조 클러스터 내에 미디어, 지도, 전화 통신 정보를 표시할 수 있습니다. 참조 구현에서 미디어가 기본 상태로 사용되지만 디스플레이는 다음 우선순위에 따라 활성 서비스를 기반으로 업데이트됩니다.
- 지도
- 전화 통신
- 미디어
시스템은 기본 미디어 상태보다 지도 내비게이션 또는 활성 전화 통신 서비스를 우선적으로 표시합니다.
다양한 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 Design 버전
- 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이 디자인 소스와 동기화된 상태로 유지됩니다.

그림 6. Figma에서 DriverUI 및 HAR로 디자인 문서 실시간 업데이트
gRPC 채널 보호
gRPC에는 SSL 및 TLS 통합이 있으며 SSL 및 TLS를 사용하여 서버를 인증하고 클라이언트와 서버 간에 교환되는 모든 데이터를 암호화합니다. 클라이언트가 상호 인증을 위해 인증서를 제공할 수 있는 선택적 메커니즘이 있습니다. gRPC 인증에 대한 자세한 내용은 인증을 참조하세요.