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

แพลตฟอร์ม

คุณสามารถสร้างและเรียกใช้ Display Safety ใน SDV ได้ แพลตฟอร์ม Software Defined Vehicle (SDV) มีลักษณะดังนี้

  • ต้องใช้ VM ของผู้ใช้ชั่วคราว 2 รายการ
  • เรียกใช้ HAR ใน SDV Media (หรือที่เรียกว่า VM สำหรับการบูตอย่างรวดเร็ว) ใน VM ของผู้ใช้ชั่วคราว
  • เรียกใช้ DriverUI ใน VM ของผู้ใช้ชั่วคราว SDV IVI อีกรายการ
  • เรียกใช้ Safety Monitor ใน SDV Media VM

สถาปัตยกรรมแพลตฟอร์ม SDV

รูปที่ 2 สถาปัตยกรรมแพลตฟอร์ม SDV

รวมเอาต์พุต HAR และ DriverUI

HAR และ DriverUI ใช้จอแสดงผลแยกกันเพื่อแสดงผล UI โดยเอาต์พุตทั้ง 2 รายการจะรวมกันและปรากฏเป็นรูปภาพเดียวใน DriverUI

HAR จะควบคุมความโปร่งใสของพื้นที่ที่เอาต์พุต Android ปรากฏขึ้นตามข้อความ Heartbeat จาก DriverUI เมื่อ DriverUI ไม่พร้อมใช้งาน HAR จะตรวจพบว่าไม่มี Heartbeat และแสดงผลพื้นที่ DriverUI เป็นแบบทึบแสงและแสดงตัวยึดตำแหน่ง เมื่อได้รับ Heartbeat แล้ว ระบบจะนำตัวยึดตำแหน่งออกและตั้งค่าพื้นที่ DriverUI ให้โปร่งใส

องค์ประกอบ HAR และ DriverUI

รูปที่ 3 การรวม HAR และ DriverUI

การสื่อสารระหว่าง DriverUI และ HAR

DriverUI และ HAR สื่อสารกันโดยใช้การเรียกกระบวนการระยะไกล (RPC) ข้อความ Heartbeat เป็นตัวอย่างของข้อมูลที่ส่งผ่านช่อง RPC และประกอบด้วยการประทับเวลาเป็นหนึ่งในช่อง

gRPC ใช้สำหรับการเรียกกระบวนการระยะไกล ใน SDV นั้น SDV Comms จะมี SDV Gateway Client เพื่อค้นหาและสร้างช่องจาก 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) {}

รายละเอียดคำขอและการตอบกลับอยู่ในแหล่งที่มาของ Display Safety ที่ packages/apps/Car/DriverUI/proto/driverui.proto ในที่เก็บซอร์สโค้ด ub-automotive

ในแพลตฟอร์ม SDV นั้น SDV Comms จะมี SDV Gateway Client เพื่อค้นหา และสร้างช่อง gRPC จาก DriverUI ไปยัง HAR

การเรียกใช้คำสั่งเหล่านี้โดยใช้เทอร์มินัล 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

แสดงข้อมูลสื่อ แผนที่ และโทรศัพท์ในคลัสเตอร์

DriverUI สามารถแสดงข้อมูลสำหรับสื่อ แผนที่ และโทรศัพท์ภายในคลัสเตอร์อ้างอิงผ่านการสื่อสารกับ IVI แม้ว่าสื่อจะทำหน้าที่เป็นสถานะเริ่มต้นในการใช้งานอ้างอิง แต่จอแสดงผลจะอัปเดตตามบริการที่ใช้งานอยู่ตามลำดับความสำคัญต่อไปนี้

  1. Maps
  2. โทรศัพท์
  3. สื่อ

ระบบจะจัดลำดับความสำคัญในการแสดงการนำทาง Maps หรือบริการโทรศัพท์ที่ใช้งานอยู่เหนือสถานะสื่อเริ่มต้นโดยอัตโนมัติ

สถานะการแสดงผลต่างๆ ของ DriverUI แสดงอยู่ในรูปต่อไปนี้

DriverUI แสดงส่วนสื่อและการโทรในคลัสเตอร์เต็ม

รูปที่ 5 DriverUI แสดงส่วนสื่อและโทรศัพท์ในคลัสเตอร์ทั้งหมด

การผสานรวม Automotive Design for Compose

DriverUI ใช้ Automotive Design for Compose เพื่อให้การออกแบบ (Figma) สามารถแสดงและทำซ้ำได้โดยตรงภายในแอป Android การ ผสานรวมนี้จะช่วยลดช่องว่างระหว่างการออกแบบและการพัฒนาด้วยการเปิดใช้การ แสดงผลเอกสารการออกแบบในสภาพแวดล้อมรันไทม์

เข้าถึงชิ้นงานการออกแบบ

เอกสาร Figma ตัวอย่างสำหรับ DriverUI เป็นส่วนหนึ่งของฐานของโค้ด วิธีเข้าถึงและแก้ไขการออกแบบเหล่านี้

  1. เปิดใช้ DriverUI ด้วยไฟล์การออกแบบ DCF ของ Automotive Design for Compose ในเครื่องจาก packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf
  2. ค้นหาไฟล์ชิ้นงาน packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig
  3. นำเข้าไฟล์นี้ลงใน Figma เพื่อดูการออกแบบต้นฉบับหรือทำการเปลี่ยนแปลง

เวอร์ชัน Automotive Design for Compose

  • Gradle ใช้ Automotive Design for Compose เวอร์ชันที่ระบุไว้สำหรับ designcompose ใน packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml
  • Automotive Design for Compose เวอร์ชันที่เผยแพร่แล้วมีอยู่ในหน้าเวอร์ชันที่เผยแพร่

การกำหนดค่าการอัปเดตแบบเรียลไทม์

Automotive Design for Compose รองรับการอัปเดตแบบเรียลไทม์ในโหมดการพัฒนา ซึ่งช่วยให้การเปลี่ยนแปลงที่ทำใน Figma แสดงผลใน DriverUI ได้ทันที ซึ่งจะช่วยให้การทดสอบทำได้รวดเร็วขึ้นและรอบการทำซ้ำการออกแบบเร็วขึ้น

เรียกใช้คำสั่งต่อไปนี้เพื่อตั้งค่าโทเค็น Figma สำหรับ DriverUI

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 ล่าสุดและส่งไปยัง HAR โดยใช้ช่องทางการสื่อสาร gRPC ที่ระบุไว้ในหน้านี้
  • ด้วยเหตุนี้ คลัสเตอร์ทั้งหมดจึงอัปเดตด้วยการทำซ้ำการออกแบบ Figma ล่าสุด ซึ่งจะทำให้ VM ทั้ง 2 รายการซิงค์กับแหล่งที่มาของการออกแบบ

อัปเดตเอกสารการออกแบบจาก Figma ไปยัง DriverUI และ
HAR แบบเรียลไทม์

รูปที่ 6 การอัปเดตเอกสารการออกแบบแบบเรียลไทม์จาก Figma ไปยัง DriverUI และ HAR

รักษาความปลอดภัยช่อง gRPC

gRPC มีการผสานรวม SSL และ TLS และส่งเสริมให้ใช้ SSL และ TLS เพื่อตรวจสอบสิทธิ์เซิร์ฟเวอร์และเข้ารหัสข้อมูลทั้งหมดที่แลกเปลี่ยนระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ ไคลเอ็นต์สามารถใช้กลไกที่ไม่บังคับเพื่อระบุใบรับรองสำหรับการตรวจสอบสิทธิ์ร่วมกัน ดูข้อมูลเพิ่มเติมเกี่ยวกับการตรวจสอบสิทธิ์ gRPC ได้ที่การตรวจสอบสิทธิ์