DriverUI

โดยปกติแล้ว UI ของแผงหน้าปัดจะอยู่ด้านหลังพวงมาลัยในจอแสดงผลแยกต่างหาก OEM ค่อยๆ รวมแผงหน้าปัดและ IVI เข้าเป็นจอแสดงผลเดียว UI แบบรวมนี้คือ DriverUI

รูปที่ 1 DriverUI

DriverUI เป็นแอประบบ Android ที่แสดงผลหน้าจอแผงหน้าปัดทั้งหมด ยกเว้นองค์ประกอบด้านความปลอดภัยหรือกฎระเบียบที่แสดงผลโดยโปรแกรมแสดงผลที่มีความพร้อมใช้งานสูง (HAR) DriverUI จะแสดงข้อมูลที่เกี่ยวข้องกับการเล่นสื่อ การโทร แผนที่ การนำทาง และอื่นๆ รวมถึงใช้การออกแบบ Automotive สำหรับ 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 ใน SDV IVI VM ของผู้ใช้ชั่วคราวอีกราย
• เรียกใช้การตรวจสอบความปลอดภัยใน SDV Media VM

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

ผสมผสานเอาต์พุต HAR และ DriverUI

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

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

รูปที่ 3 องค์ประกอบของ HAR และ DriverUI

แก้ปัญหาการจัดองค์ประกอบอัลฟ่าและการเจาะทะลุ

เนื่องจาก HAR มีความสำคัญต่อความปลอดภัย ระนาบการแสดงผลฮาร์ดแวร์จึงอยู่ด้านบนของระนาบการแสดงผล IVI ของ Android เมื่อคุณสร้างหรือแก้ไขข้อบกพร่องของมุมมองที่กำหนดเองหรือแพลตฟอร์ม OpenGL ES ภายนอกใน HAR ให้ตรวจสอบวิธีตั้งค่าอัลฟ่าดังนี้

• ไม่มีเอาต์พุต DriverUI ใต้ระนาบ HAR: แม้ว่า HAR จะได้รับข้อความ HeartbeatRequest ที่ถูกต้องจาก DriverUI แต่ HAR ต้องล้างขอบเขตวิวพอร์ต DriverUI ให้โปร่งใส (alpha = 0.0) เพื่อให้ UI คลัสเตอร์ Android ที่อยู่ด้านล่างแสดงผ่านได้ หากเลเยอร์หรือพื้นหลัง HAR ที่กำหนดเองวาดพิกเซลทึบแสง (alpha = 1.0) เหนือพื้นที่ DriverUI จะเป็นการบล็อกเอาต์พุต Android ที่อยู่ด้านล่าง
• รูโปร่งใสที่ไม่ได้ตั้งใจในพื้นผิว 3 มิติหรือ OpenGL ที่กำหนดเอง: เมื่อคุณแสดงผลพื้นผิว OpenGL ES หรือ 3 มิติภายนอกลงในโหนด HAR (เช่น มาตรวัดหรือฉาก 3 มิติที่กำหนดเองซึ่งเขียนพิกเซล RGB โดยมีไบต์อัลฟาที่ไม่ได้ใช้เหลืออยู่ที่ 0x00) ให้ตั้งค่าแชแนลอัลฟาของพิกเซลทึบแสงเป็น 0xFF (alpha = 1.0) อย่างชัดเจน การปล่อยไบต์อัลฟาไว้ที่ 0x00 จะทำให้คอมโพสิเตอร์ถือว่าพิกเซลเหล่านั้นโปร่งใส (alpha = 0.0) และเจาะรูผ่านเลเยอร์ HAR ไปยังระนาบ IVI ของ Android ที่อยู่ด้านล่างโดยตรง
• การวินิจฉัยการแสดงผลข้าม VM: เนื่องจาก HAR (sdv_media_har_cf) และ IVI ของ Android (sdv_ivi_cf_ds) ทำงานใน VM ของผู้มาเยือนแยกกัน การเรียกใช้ adb shell dumpsys SurfaceFlinger ใน VM ของ IVI ของ Android จะตรวจสอบเฉพาะเลเยอร์ Android และไม่สามารถมองเห็นระนาบ HAR ที่อยู่ด้านบน

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

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

gRPC ใช้สำหรับ RPC ใน SDV การสื่อสาร SDV จะมี 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

รูปที่ 4 การสื่อสาร RPC เพื่อเปลี่ยนทั้งธีม DriverUI และ HAR

แสดงข้อมูลสื่อ, Maps และโทรศัพท์บนแผงหน้าปัด

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

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

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

สถานะการแสดงผล DriverUI ต่างๆ จะแสดงในภาพต่อไปนี้

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

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

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

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

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

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

Automotive Design สำหรับ 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 ล่าสุด ทำให้ทั้ง 2 VM ซิงค์กับแหล่งที่มาของการออกแบบ

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

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

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