ממשק המשתמש של לוח המחוונים ממוקם בדרך כלל מאחורי ההגה במסך נפרד. יצרני ציוד מקורי (OEM) משלבים בהדרגה את לוח המחוונים ואת מערכת המידע והבידור (IVI) במסך אחד. ממשק המשתמש המשולב הזה נקרא DriverUI.
איור 1. DriverUI.
ממשק המשתמש של הנהג הוא אפליקציית מערכת של Android שמציגה את כל לוח המכוונים, למעט רכיבים רלוונטיים לבטיחות או רגולטוריים שמוצגים על ידי רכיב הרינדור של זמינות גבוהה (HAR). ב-DriverUI מוצג מידע שקשור להפעלת מדיה, לשיחות טלפון, למפות, לניווט ועוד, והוא מבוסס על Automotive Design for Compose.
DriverUI כפעילות ברירת המחדל של האשכול
DriverUI פועל כאפליקציית אשכול עם הרשאות ב-Android, ו-AAOS מפעיל אותו באופן אוטומטי.
מערכת AAOS משתמשת במחלקה ClusterHomeManager, שנקראת גם Cluster2, כדי ליצור קבוצות מחוונים. המחלקות האלה מציינות את ההגדרה שנדרשת כדי לזהות הטמעה של לוח מחוונים, ואיך AAOS מקיים איתה אינטראקציה. Google מספקת הטמעות לדוגמה של ממשקי Cluster2 API.
פלטפורמות
אפשר ליצור ולהריץ את התכונה 'בטיחות ברשת המדיה' ב-SDV. פלטפורמת הרכב מוגדר התוכנה (SDV):
- נדרשות שתי מכונות וירטואליות של אורחים.
- מריץ HAR ב-SDV Media (שנקרא גם מכונת ה-VM לאתחול מהיר) במכונת VM אורחת.
- מריץ את DriverUI במכונה וירטואלית אחרת של SDV IVI.
- מריץ את 'המרכז לבקרת אבטחה' במכונה וירטואלית של SDV Media.

איור 2. ארכיטקטורת הפלטפורמה של SDV.
מיזוג של פלט HAR ו-DriverUI
ממשק המשתמש של HAR וממשק המשתמש של DriverUI מוצגים במסכים נפרדים. שתי התוצאות הן מורכבות ומופיעות כתמונה אחת בממשק המשתמש של הנהג.
כדי לעשות את זה, ה-HAR שולט בשקיפות של האזורים שבהם הפלט של Android מופיע על סמך הודעות פעימות לב מ-DriverUI. אם DriverUI לא זמין, ה-HAR מזהה את היעדר הפעימות ומציג את האזורים של DriverUI כאטומים, וגם מציג מצייני מיקום. כשמתקבלים אותות הפעימה, המערכת מסירה את ה-placeholder והאזורים בממשק המשתמש של הנהג מוגדרים כשקופים.

איור 3. הרכב של HAR ו-DriverUI.
תקשורת בין DriverUI ל-HAR
ה-DriverUI וה-HAR מתקשרים זה עם זה באמצעות קריאות לפרוצדורות מרוחקות (RPC). הודעת הדופק היא דוגמה לנתונים שנשלחים בערוץ ה-RPC, והיא כוללת חותמת זמן כאחד מהשדות שלה.
gRPC משמש לקריאות RPC. ב-SDV, תקשורת SDV מספקת את לקוח שער SDV כדי לגלות וליצור ערוץ מ-DriverUI ל-HAR. שירות gRPC מגדיר קובץ Protocol Buffer:
// 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 מספקת את לקוח שער SDV כדי לגלות ולהקים ערוץ 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.
הצגת מידע על רשת המדיה, מפות וטלפוניה באשכול
באמצעות תקשורת עם מערכת ה-IVI, ממשק המשתמש של הנהג יכול להציג מידע על מדיה, מפות וטלפוניה באשכול ההפניה. למרות שהמצב 'מדיה' הוא מצב ברירת המחדל בהטמעה לדוגמה, התצוגה מתעדכנת על סמך שירותים פעילים לפי סדר העדיפות הבא:
- מפות
- טלפוניה
- מדיה
המערכת נותנת עדיפות אוטומטית להצגת הניווט במפות Google או לשירותי טלפוניה פעילים על פני מצב המדיה שמוגדר כברירת מחדל.
באיור הבא מוצגים מצבי התצוגה השונים של DriverUI:

איור 5. ממשק המשתמש של הנהג שמציג את הקטע 'מדיה' ו'טלפוניה' בלוח המחוונים המלא.
עיצוב לרכב לשילוב עם Compose
ה-DriverUI מיישם את Automotive Design for Compose כדי לאפשר הצגה של עיצובים (Figma) וביצוע איטרציות עליהם ישירות באפליקציית Android. השילוב הזה מגשר על הפער בין עיצוב לפיתוח בכך שהוא מאפשר עיבוד של מסמכי עיצוב בסביבת זמן הריצה.
גישה לנכסי עיצוב
דוגמאות למסמכי Figma עבור DriverUI הן חלק מבסיס הקוד. כדי לגשת לעיצובים האלה ולשנות אותם:
- מפעילים את DriverUI באמצעות קובץ העיצוב המקומי של Automotive Design for Compose DCF מ-
packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf. - מאתרים את קובץ הנכס
packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig. - מייבאים את הקובץ הזה ל-Figma כדי לראות את עיצובי המקור או לבצע שינויים.
עיצוב לרכב בגרסת 'פיתוח נייטיב'
- Gradle משתמש בגרסה של Automotive Design for Compose שצוינה עבור
designcomposeב-packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml. - גרסאות של Automotive Design for Compose זמינות בדף releases.
הגדרת עדכונים בזמן אמת
התכונה 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
סנכרון מסמכי עיצוב של מכונות וירטואליות כפולות
בהגדרה של שני מכונות וירטואליות, העדכונים בעיצוב צריכים להתפשט מעבר לגבולות כדי לשמור על עקביות.
- הכלי DriverUI מאחזר את מסמך העיצוב העדכני ביותר של Figma ומשדר אותו אל HAR באמצעות ערוצי התקשורת של gRPC שמפורטים בדף הזה.
- כתוצאה מכך, כל האשכול מתעדכן עם האיטרציות האחרונות של עיצוב Figma, ושני המכונות הווירטואליות נשארות מסונכרנות עם מקור העיצוב.

איור 6. עדכון חי של מסמך העיצוב מ-Figma ל-DriverUI ול-HAR.
אבטחת ערוץ gRPC
ל-gRPC יש שילוב של SSL ו-TLS, והוא מעודד שימוש ב-SSL וב-TLS כדי לאמת את השרת ולהצפין את כל הנתונים שמועברים בין הלקוח לשרת. קיימים מנגנונים אופציונליים שמאפשרים ללקוחות לספק אישורים לאימות הדדי. מידע נוסף על אימות gRPC זמין במאמר בנושא אימות.