DriverUI

ממשק המשתמש של לוח המחוונים ממוקם בדרך כלל מאחורי ההגה במסך נפרד. יצרני ציוד מקורי משלבים בהדרגה את לוח המחוונים ואת ה-IVI בתצוגה אחת. ממשק המשתמש המשולב הזה הוא DriverUI.

איור 1. DriverUI.

‫DriverUI היא אפליקציית מערכת ל-Android שמעבדת את כל התצוגה של לוח המחוונים, חוץ מרכיבים שקשורים לבטיחות או לתקנות, שמעובדים על ידי ה-HAR (רכיב עיבוד עם זמינות גבוהה). ב-DriverUI מוצג מידע שקשור להפעלת מדיה, לשיחות טלפון, למפות, לניווט ועוד, והוא מיישם את Automotive Design for Compose.

‫DriverUI כפעילות ברירת המחדל של האשכול

‫DriverUI פועלת כאפליקציית אשכול עם הרשאות ב-Android, ו-AAOS מפעילה אותה באופן אוטומטי.

ב-AAOS משתמשים במחלקה ClusterHomeManager, שנקראת גם Cluster2, כדי ליצור לוחות מחוונים. המחלקה הזו מציינת את ההגדרות הנדרשות כדי לזהות הטמעה של לוח מחוונים, ואת האופן שבו AAOS יוצר איתה אינטראקציה. ‫Google מספקת הטמעות לדוגמה של ממשקי ה-API של Cluster2.

פלטפורמות

אתם יכולים ליצור ולהריץ את Display Safety ב-SDV. פלטפורמת הרכב מוגדר התוכנה (SDV):

• נדרשות שתי מכונות וירטואליות אורחות.
• מריץ את HAR במדיה של SDV (שנקראת גם VM לאתחול מהיר) במכונה וירטואלית אורחת.
• מריץ את DriverUI במכונה וירטואלית אחרת של IVI ב-SDV אורח.
• מריץ את Safety Monitor ב-SDV Media VM.

איור 2. ארכיטקטורת פלטפורמת SDV.

שילוב של פלט HAR ו-DriverUI

ב-HAR וב-DriverUI יש מסכים נפרדים לעיבוד של ממשק המשתמש. שני הפלטים משולבים ומופיעים כתמונה אחת ב-DriverUI.

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

איור 3. הרכב של HAR ו-DriverUI.

פתרון בעיות שקשורות לקומפוזיציית אלפא ול-punch-through

מכיוון שה-HAR הוא קריטי לבטיחות, מישור התצוגה של החומרה שלו נמצא מעל מישור התצוגה של ה-IVI ב-Android. כשאתם יוצרים או מנפים באגים בתצוגות בהתאמה אישית או במשטחי OpenGL ES חיצוניים ב-HAR, חשוב לוודא איך מוגדרים ערכי האלפא:

• פלט DriverUI חסר במישור ה-HAR: בזמן שה-HAR מקבל הודעות HeartbeatRequest תקינות מה-DriverUI, ה-HAR צריך לנקות את אזור התצוגה של DriverUI לשקוף (alpha = 0.0) כדי שממשק המשתמש של אשכול Android שמתחתיו יוצג. אם שכבת HAR או רקע בהתאמה אישית משרטטים פיקסלים אטומים (alpha = 1.0) מעל אזור DriverUI, הם חוסמים את הפלט של Android שמתחת.
• חורים שקופים לא מכוונים במשטחי תלת-ממד או OpenGL מותאמים אישית: כשמעבדים משטח OpenGL ES או תלת-ממד חיצוני לצומת HAR (כמו מד או סצנה תלת-ממדיים מותאמים אישית שכותבים פיקסלים של RGB עם בייט אלפא לא בשימוש שנותר ב-0x00), מגדירים במפורש את ערוץ האלפא של פיקסלים אטומים ל-0xFF (alpha = 1.0). אם משאירים את בייט האלפא ב-0x00, המלחין מתייחס לפיקסלים האלה כשקופים (alpha = 0.0) ויוצר חור ישירות דרך שכבת ה-HAR למישור ה-IVI הבסיסי של Android.
• אבחון של תצוגה בין מכונות וירטואליות: מכיוון שה-HAR (sdv_media_har_cf) וה-IVI של Android (sdv_ivi_cf_ds) פועלים במכונות וירטואליות נפרדות של אורחים, הפעלת adb shell dumpsys SurfaceFlinger במכונה הווירטואלית של ה-IVI של Android בודקת רק את השכבות של Android, ואין לה גישה למישור ה-HAR שמעליה.

תקשורת בין DriverUI ל-HAR

ה-DriverUI וה-HAR מתקשרים זה עם זה באמצעות קריאות לשירות מרוחק (RPC). הודעת ה-heartbeat היא דוגמה לנתונים שנשלחים בערוץ ה-RPC, ואחד מהשדות שלה הוא חותמת זמן.

‫gRPC משמש לקריאות RPC. ב-SDV, תקשורת SDV מספקת את לקוח השער של SDV כדי לגלות וליצור ערוץ מ-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 מספקת את 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.

הצגת מידע על מדיה, מפות וטלפוניה בלוח המחוונים

באמצעות תקשורת עם ה-IVI, ממשק המשתמש לנהג יכול להציג מידע על מדיה, מפות וטלפוניה בתוך לוח המחוונים לדוגמה. למרות שהמדיה משמשת כמצב ברירת המחדל בהטמעה לדוגמה, התצוגה מתעדכנת על סמך השירותים הפעילים לפי סדר העדיפויות הבא:

1. מפות
2. טלפוניה
3. מדיה

המערכת נותנת עדיפות אוטומטית להצגת הניווט במפות Google או שירותי טלפוניה פעילים על פני מצב המדיה שמוגדר כברירת מחדל.

מצבי התצוגה השונים של DriverUI מוצגים באיור הבא:

איור 5. ממשק המשתמש של הנהג, שבו מוצג הקטע "מדיה וטלפוניה" בלוח המחוונים המלא.

שילוב של Automotive Design ב-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 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 תומך בעדכונים בזמן אמת במצב פיתוח, וכך מאפשר להציג באופן מיידי ב-DriverUI שינויים שבוצעו ב-Figma. כך אפשר לבצע בדיקות מהירות ולשפר את העיצוב מהר יותר.

מריצים את הפקודה הבאה כדי להגדיר את האסימון של 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, קראו את המאמר אימות.