DriverUI

Giao diện người dùng của cụm đồng hồ thường được đặt phía sau vô lăng trong một màn hình riêng. Các nhà sản xuất thiết bị gốc (OEM) dần kết hợp cụm đồng hồ và IVI thành một màn hình duy nhất. Giao diện người dùng kết hợp này là DriverUI.

DriverUI

Hình 1. DriverUI.

DriverUI là một ứng dụng hệ thống Android kết xuất toàn bộ màn hình cụm đồng hồ, ngoại trừ các thành phần liên quan đến an toàn hoặc quy định do trình kết xuất có độ sẵn sàng cao (HAR) kết xuất. DriverUI hiển thị thông tin liên quan đến việc phát nội dung nghe nhìn, cuộc gọi điện thoại, bản đồ, tính năng chỉ đường, v.v. và triển khai Automotive Design cho Compose.

DriverUI làm hoạt động mặc định của cụm

DriverUI chạy dưới dạng một ứng dụng cụm đặc quyền trong Android và AAOS sẽ tự động khởi động ứng dụng này.

AAOS sử dụng lớp ClusterHomeManager (còn gọi là Cluster2) để tạo cụm đồng hồ. Lớp này chỉ định cấu hình cần thiết để xác định cách triển khai cụm đồng hồ và cách AAOS tương tác với cụm đồng hồ đó. Google cung cấp các phương án triển khai tham khảo cho API Cluster2.

Nền tảng

Bạn có thể tạo và chạy tính năng An toàn cho màn hình trên SDV. Nền tảng xe được xác định bằng phần mềm (SDV):

  • Cần có hai máy ảo khách.
  • Chạy HAR trong SDV Media (còn gọi là máy ảo khởi động nhanh) trong máy ảo khách.
  • Chạy DriverUI trong một máy ảo IVI SDV khách khác.
  • Chạy Trình giám sát an toàn trên Máy ảo SDV Media.

Kiến trúc nền tảng SDV

Hình 2. Kiến trúc nền tảng SDV.

Kết hợp kết quả của HAR và DriverUI

HAR và DriverUI sử dụng các màn hình riêng biệt để hiển thị giao diện người dùng. Hai kết quả đầu ra được kết hợp và xuất hiện dưới dạng một hình ảnh cho DriverUI.

Để đạt được điều này, HAR kiểm soát độ trong suốt của các khu vực mà kết quả đầu ra của Android xuất hiện dựa trên thông báo nhịp tim từ DriverUI. Khi DriverUI không hoạt động, HAR sẽ phát hiện thấy thiếu nhịp tim và hiển thị các vùng DriverUI mờ đục cũng như hiển thị phần giữ chỗ. Khi nhận được tín hiệu nhịp tim, các phần giữ chỗ sẽ bị xoá và các khu vực DriverUI được đặt ở chế độ trong suốt.

Cấu trúc HAR và DriverUI

Hình 3. Cấu trúc HAR và DriverUI.

Khắc phục sự cố về thành phần alpha và hiệu ứng đục lỗ

Vì HAR là thành phần quan trọng về an toàn, nên mặt phẳng hiển thị phần cứng của HAR nằm trên mặt phẳng hiển thị IVI của Android. Khi bạn tạo hoặc gỡ lỗi các khung hiển thị tuỳ chỉnh hoặc nền tảng OpenGL ES bên ngoài trong HAR, hãy xác minh cách đặt giá trị alpha:

  • Thiếu kết quả DriverUI trong mặt phẳng HAR: Mặc dù HAR nhận được thông báo HeartbeatRequest hợp lệ từ DriverUI, nhưng HAR phải xoá vùng khung nhìn DriverUI thành trong suốt (alpha = 0.0) để giao diện người dùng cụm Android cơ bản hiển thị. Nếu một lớp hoặc nền HAR tuỳ chỉnh vẽ các pixel mờ (alpha = 1.0) trên khu vực DriverUI, thì lớp hoặc nền đó sẽ chặn đầu ra Android bên dưới.
  • Lỗ hổng trong suốt ngoài ý muốn trong các nền tảng 3D hoặc OpenGL tuỳ chỉnh: Khi bạn kết xuất một nền tảng OpenGL ES hoặc 3D bên ngoài vào một nút HAR (chẳng hạn như một thước đo hoặc cảnh 3D tuỳ chỉnh ghi các pixel RGB bằng một byte alpha không dùng đến còn lại ở 0x00), hãy đặt rõ ràng kênh alpha của các pixel mờ thành 0xFF (alpha = 1.0). Việc để byte alpha ở 0x00 sẽ khiến trình kết hợp coi các pixel đó là trong suốt (alpha = 0.0) và tạo một lỗ hổng xuyên thẳng qua lớp HAR đến mặt phẳng IVI Android bên dưới.
  • Chẩn đoán màn hình trên nhiều máy ảo: Vì HAR (sdv_media_har_cf) và IVI Android (sdv_ivi_cf_ds) chạy trong các máy ảo khách riêng biệt, nên việc chạy adb shell dumpsys SurfaceFlinger trên máy ảo IVI Android chỉ kiểm tra các lớp Android và không có chế độ hiển thị vào mặt phẳng HAR nằm trên.

Giao tiếp giữa DriverUI và HAR

DriverUI và HAR giao tiếp với nhau bằng lệnh gọi quy trình từ xa (RPC). Thông báo nhịp tim là một ví dụ về dữ liệu được gửi qua kênh RPC và bao gồm dấu thời gian là một trong các trường của thông báo.

gRPC được dùng cho RPC. Trên SDV, SDV comms cung cấp SDV Gateway Client để khám phá và thiết lập kênh từ DriverUI đến HAR. Dịch vụ gRPC xác định một tệp vùng đệm giao thức:


// 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) {}

Thông tin chi tiết về yêu cầu và phản hồi nằm trong nguồn Display Safety tại packages/apps/Car/DriverUI/proto/driverui.proto trong kho lưu trữ mã nguồn ub-automotive.

Trên nền tảng SDV, SDV comms cung cấp SDV Gateway Client để khám phá và thiết lập kênh gRPC từ DriverUI đến HAR.

Việc thực thi các lệnh này bằng thiết bị đầu cuối IVI sẽ gửi thông tin liên lạc đến SDV Media, kích hoạt các bản cập nhật giao diện trên toàn bộ cụm.

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

Giao tiếp RPC để thay đổi cả giao diện DriverUI và HAR.

Hình 4. Giao tiếp RPC để thay đổi cả giao diện DriverUI và HAR.

Hiển thị thông tin về nội dung nghe nhìn, bản đồ và điện thoại trên cụm đồng hồ

Thông qua việc giao tiếp với IVI, DriverUI có thể hiển thị thông tin cho Nội dung nghe nhìn, Maps và Điện thoại trong cụm tham chiếu. Mặc dù nội dung nghe nhìn đóng vai trò là trạng thái mặc định trong bản triển khai tham chiếu, nhưng màn hình sẽ cập nhật dựa trên các dịch vụ đang hoạt động theo mức độ ưu tiên sau:

  1. Maps
  2. Điện thoại
  3. Nội dung nghe nhìn

Hệ thống sẽ tự động ưu tiên hiển thị thông tin chỉ đường trên Maps hoặc các dịch vụ Điện thoại đang hoạt động thay vì trạng thái Nội dung nghe nhìn mặc định.

Các trạng thái hiển thị khác nhau của DriverUI được minh hoạ trong hình sau:

DriverUI giới thiệu đầy đủ phần Nội dung nghe nhìn và Điện thoại trong cụm.

Hình 5. DriverUI cho thấy phần Nội dung nghe nhìn và Điện thoại trong toàn bộ bảng điều khiển.

Thiết kế cho ô tô để tích hợp Compose

DriverUI triển khai Automotive Design for Compose để cho phép các thiết kế (Figma) giới thiệu và lặp lại trực tiếp trong ứng dụng Android. Việc tích hợp này thu hẹp khoảng cách giữa thiết kế và phát triển bằng cách cho phép kết xuất tài liệu thiết kế trong môi trường thời gian chạy.

Sử dụng thành phần thiết kế

Tài liệu Figma mẫu cho DriverUI là một phần của cơ sở mã. Cách truy cập và sửa đổi các thiết kế này:

  1. Chạy DriverUI bằng tệp thiết kế DCF của Automotive Design for Compose tại địa phương từ packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf.
  2. Tìm tệp tài sản packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig.
  3. Nhập tệp này vào Figma để xem thiết kế nguồn hoặc thực hiện thay đổi.

Phiên bản Automotive Design for Compose

  • Gradle sử dụng phiên bản Automotive Design for Compose được chỉ định cho designcompose trong packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml.
  • Các bản phát hành Automotive Design cho Compose có trên trang bản phát hành.

Cấu hình thông tin cập nhật trực tiếp

Automotive Design for Compose hỗ trợ thông tin cập nhật trực tiếp ở chế độ phát triển, cho phép các thay đổi được thực hiện trong Figma được kết xuất ngay lập tức trong DriverUI. Điều này tạo điều kiện cho việc thử nghiệm nhanh và chu kỳ lặp lại thiết kế nhanh hơn.

Chạy lệnh sau để đặt mã thông báo Figma cho DriverUI:

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

Đồng bộ hoá tài liệu thiết kế máy ảo kép

Trong chế độ thiết lập máy ảo kép, các bản cập nhật thiết kế phải được truyền tải qua các ranh giới để duy trì tính nhất quán.

  • DriverUI tìm nạp tài liệu thiết kế Figma mới nhất và truyền đến HAR bằng các kênh giao tiếp gRPC được trình bày chi tiết trên trang này.
  • Do đó, toàn bộ cụm sẽ cập nhật các phiên bản thiết kế Figma mới nhất, giúp cả hai máy ảo luôn đồng bộ với nguồn thiết kế.

Cập nhật trực tiếp tài liệu thiết kế từ Figma lên DriverUI và HAR.

Hình 6. Cập nhật trực tiếp tài liệu thiết kế từ Figma lên DriverUI và HAR.

Bảo mật kênh gRPC

gRPC có tích hợp SSL và TLS, đồng thời khuyến khích sử dụng SSL và TLS để xác thực máy chủ và mã hoá tất cả dữ liệu được trao đổi giữa máy khách và máy chủ. Ứng dụng có thể sử dụng các cơ chế không bắt buộc để cung cấp chứng chỉ cho việc xác thực lẫn nhau. Để biết thêm thông tin về quy trình xác thực gRPC, hãy xem phần Xác thực.