ארכיטקטורה

רוב השינויים הנדרשים כדי לתמוך ב-VirtIO ב-AAOS כוללים שינויים ברמת ההטמעה של HAL ומטה בליבה המשותפת של Android. מסגרת Android מתקשרת עם HAL גנרי ללא תלות בחומרה באמצעות מנהלי ה-VirtIO בליבה של המכונה הווירטואלית האורחית של AAOS, שמתקשרת עם מכשירי VirtIO בצד המארח באמצעות פרוטוקולי VirtIO. מכשירי VirtIO בצד המארח יכולים לגשת לחומרה הפיזית באמצעות מנהלי התקנים ספציפיים ל-SoC.

התקשורת בין מנהל ה-VirtIO לבין מכשיר ה-VirtIO מתבצעת באמצעות virtqueue, שהם מאגרי טבעת (ring buffer) דמויי DMA של רשימות פיזור ואיסוף (scatter gather). אפשר להשתמש בכמה אמצעי תעבורה, כמו MMIO או PCI, כדי להחליף את הודעות ה-VirtIO בין מכונות וירטואליות.

במקרים מסוימים, השתמשו ב-vsock לתקשורת בין מכונות וירטואליות. התקשורת של Vehicle HAL,‏ Audio Control ו-Dumpstate נתמכת באמצעות חיבור לסוכן עמית ב-VM נפרד דרך ממשק vsock. GRPC-vsock משמש לגישה לרכיבי המשנה הלא סטנדרטיים האלה. GRPC ב-Android source tree שונה כך שיעבוד עם vsock בפורמט הכתובת vsock:CID:PORT_NUMBER.

ארכיטקטורת וירטואליזציה
איור 1. ארכיטקטורת וירטואליזציה

אודיו

ב-AAOS וירטואלי, המכונה הווירטואלית האורחית של Android יכולה להשתמש ב-virtio-snd כדי לגשת לשמע. virtio-snd מספק את מכשירי ה-PCM הווירטואליים למכונה הווירטואלית של Android, כדי שההטמעה של HAL האודיו תוכל לקיים אינטראקציה עם מכשירי האודיו הווירטואליים באמצעות הספרייה TinyALSA.

הטמעת ברירת המחדל של HAL אודיו נמצאת ב-AOSP בכתובת /device/google/trout/hal/audio/6.0. יצרני ציוד מקורי יכולים לשנות את ro.vendor.trout.audiohal.{in,out}_period_{ms,count} עבור הפלטפורמה שלהם. יצרני ציוד מקורי יכולים גם להטמיע HAL אודיו משלהם על ידי שינוי של המשתנים הקשורים לאודיו בקובץ /device/google/trout/aosp_trout_common.mk.

HAL של בקרת האודיו מנהל את המיקוד של האודיו ב-AAOS. לדוגמה, כשהמערכת מפעילה צלילי חירום, יכול להיות שיהיה צורך להשתיק את המוזיקה שמתנגנת ברקע. במקרה כזה, HAL של בקרת האודיו יעדכן את האפליקציות שמפעילות מוזיקה להשתיק את האודיו. במערכת הווירטואלית, הצלילים יכולים להגיע ממכונות וירטואליות אחרות. בהטמעת העזר, במכונה הווירטואלית האורחית של AAOS פועל דימון של שרת בקרת אודיו, שמשתמש ב-GRPC-vsock כדי לקבל בקשות להעברת המיקוד של האודיו ממכונות וירטואליות אחרות. המכונה הווירטואלית המארחת יכולה להשתמש ב-device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller כדי לשלוח בקשות ל-AAOS לבקרת אודיו. בזמן ש-libandroid_audio_controller מחזיק את המיקוד האודיו, הוא ממשיך לשלוח פעימות לב ל-AAOS עד שהמיקוד משוחרר.

ארכיטקטורת אודיו
איור 5. ארכיטקטורת האודיו

Bluetooth

הטמעת ה-Bluetooth מבוססת על התכנון שמתואר בהמשך.

הארכיטקטורה של Bluetooth
איור 5. הארכיטקטורה של Bluetooth

פרופיל Bluetooth לשימוש בזמן נהיגה

כדי להפעיל את פרופיל Bluetooth Hands-Free (HFP) ב-trout, הורחבה המפרט של מכשיר האודיו VirtIO כדי לתמוך בפקדי אודיו. באמצעות הגישה הזו, מכשיר אודיו מסוג VirtIO בצד המארח/ההיפר-ווירטואלי מספק את שלושת פקדי האודיו האלה שקשורים ל-HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

כש-AAOS פועל כמכונה וירטואלית אורחת, מערכת AAOS משתמשת ב-TinyAlsa כדי להגדיר את אמצעי הבקרה על האודיו. כדי להפעיל את תרחיש השימוש של HFP, המארח/ההיפר-ווירטואלי מבצע את הניתוב והכיול הספציפיים לספק בהתאם.

הטמעת ה-Bluetooth מבוססת על איור העיצוב שבהמשך.

הארכיטקטורה של Bluetooth
איור 5. הארכיטקטורה של Bluetooth

Dumpstate

כשיוצרים את דוח הבאג ל-AAOS וירטואלי, כדאי לכלול מידע על המארח הווירטואלי כדי למסור למפתחים תמונה מקיפה יותר של המערכת. כדי לעשות זאת, ההטמעה של trout מבוססת על IDumpstateDevice HAL, שמאגד את המידע של המכונה הווירטואלית המארחת דרך GRPC-vsock. המידע על המכונה הווירטואלית המארחת באריזת tar נקרא dumpstate_board.bin בדוח הבאג, והדיווח על גרסת ה-dump של היומנים נמצא ב-dumpstate_board.txt.

כדי להגדיר את הפקודות לביצוע:

  1. מעתיקים את פרטי התצורה מהקובץ שלמטה לקובץ XML, למשל config.xml. 
    <dumpstateHalConfiguration version="1.0">
    <services>
        <service name="coqos-virtio-blk"        command="/bin/journalctl --no-pager -t coqos-virtio-blk"/>
        <service name="coqos-virtio-net"        command="/bin/journalctl --no-pager -t coqos-virtio-net"/>
        <service name="coqos-virtio-video"      command="/bin/journalctl --no-pager -t coqos-virtio-video"/>
        <service name="coqos-virtio-console"    command="/bin/journalctl --no-pager -t coqos-virtio-console"/>
        <service name="coqos-virtio-rng"        command="/bin/journalctl --no-pager -t coqos-virtio-rng"/>
        <service name="coqos-virtio-vsock"      command="/bin/journalctl --no-pager -t coqos-virtio-vsock"/>
        <service name="coqos-virtio-gpu-virgl"  command="/bin/journalctl --no-pager -t coqos-virtio-gpu-virgl"/>
        <service name="coqos-virtio-scmi"       command="/bin/journalctl --no-pager -t coqos-virtio-scmi"/>
        <service name="coqos-virtio-input"      command="/bin/journalctl --no-pager -t coqos-virtio-input"/>
        <service name="coqos-virtio-snd"        command="/bin/journalctl --no-pager -t coqos-virtio-snd"/>
        <service name="dumpstate_grpc_server"   command="/bin/journalctl --no-pager -t dumpstate_grpc_server"/>
        <service name="systemd"                 command="/bin/journalctl --no-pager -t systemd"/>
        <service name="systemctl"               command="/bin/systemctl status"/>
        <service name="vehicle_hal_grpc_server" command="/bin/journalctl --no-pager -t vehicle_hal_grpc_server"/>
    </services>
    <systemLogs>
        <service name="dmesg" command="/bin/dmesg -kuPT"/>
    </systemLogs>
</dumpstateHalConfiguration>
  2. מעבירים את הנתיב של קובץ ה-XML החדש לשרת dumpstate בזמן ההפעלה. לדוגמה: 
    --config_file my_config.xml

מערכת תצוגה מורחבת (EVS)

מערכת התצוגה החיצונית (EVS) משמשת להצגת סרטון שצולם על ידי המצלמה האחורית והמצלמה הקדמית הימנית. ב-AAOS וירטואלי, מחסנית ה-EVS יכולה לגשת לשידור הווידאו ממכשיר הסטרימינג הווירטואלי V4L2 שמשתמש במנהל הווידאו VirtIO.

מצב מוסך

מידע נוסף זמין במאמר מצב מוסך.

הכניסה למצב 'חניה' והיציאה ממנו מופעלות על ידי מאפייני AP_POWER_STATE_REQ שנשלחים על ידי Vehicle HAL. במצב וירטואליזציה, מצב Garage מופעל מצד המארח. המכונה הווירטואלית המארחת צריכה להישאר מופעלת כדי לספק מכשירי וירטואליים למכונה הווירטואלית של Android, עד שהמכשיר של Android יושבת. שרת VHAL במכונה הווירטואלית המארחת שולח את אות ההשבתה למכונה הווירטואלית האורחית של AAOS. לאחר קבלת האות מהלקוח VHAL, המכונה הווירטואלית של AAOS נכנסת למצב Garage ומתחילה לשלוח אותות של פעימות לב כדי לשמור על המכונה הווירטואלית המארחת פעילה.

מערכת לוויינים גלובלית לניווט (GNSS)

ב-trout 1.0 נוספה תמיכה בווירטואליזציה של GNSS דרך virtio-console. ההטמעה תומכת בחילופי מדידות גולמיות ותיקוני מיקום מהמארח לאורחים.

פורמט החלפת הנתונים הוא CSV שמשמש את אפליקציית GnssLogger. בהטמעת העזר, מאחר שמנהל ההתקן המקורי של GNSS לא זמין, נתוני דמה זמינים, אבל אפשר להטמיע מנהל התקן מקורי בלי שינויים בצד האורח. סוכן מארח לדוגמה מופיע כחלק מקוד המקור של trout.

בהטמעה הנוכחית, סביבת מערכת ההפעלה המארחת אמורה לטפל בהפעלה של GNSS וב-GNSS מסייע (AGNSS).

ארכיטקטורת GNSS
איור 2. ארכיטקטורת GNSS

גרפיקה

כשמערכת AAOS פועלת כמכונה וירטואלית אורחת לצד מערכות הפעלה אחרות לכלי רכב, יכול להיות של-Android לא תהיה גישה ישירה ל-GPU או לבקר המסך. במקרה כזה, אפשר להשתמש ב-Mesa או ב-goldfish-opengl ובדרייבר virtio-gpu במכונה הווירטואלית האורחית של Android ובמכשיר virtio-gpu כדי לגשת ל-GPU.

במכונה הווירטואלית האורחית של Android, Mesa או goldfish-opengl מקודדים פקודות OpenGLES לזרם Gallium או לזרם GLES שנוצר באופן אוטומטי, בהתאמה. מנהל הליבה virtio-gpu משמש ככלי להעברה. בצד המארח, virglrenderer (ל-Mesa) ו-vulkan-cereal (ל-goldfish-opengl) מפעילים מחדש את מקור הפקודות המקודד מעל מנהל ההתקן הקיים של ה-GPU. פלטפורמת העזר של AAOS‏ trout תומכת ב-OpenGL ES בלבד עם תמיכה ב-Vulkan, שצפויה להופיע בגרסה עתידית.

ארכיטקטורת גרפיקה
איור 3. ארכיטקטורת הגרפיקה

חיישנים

כשמערכת AAOS פועלת כמכונה וירטואלית אורחת לצד מערכות הפעלה אחרות לכלי רכב, יכול להיות של-Android לא תהיה גישה ישירה לחיישנים. במקרה כזה, נעשה שימוש בהתקן Virtio-SCMI במכונה הווירטואלית האורחית של Android ובהתקן VirtIO-SCMI במכונה הווירטואלית המארחת כדי לגשת לחיישנים. פלטפורמת העזר של AAOS לווירטואליזציה מספקת HAL של חיישנים שהוא גנרי ולא תלוי בחומרה, שאפשר להשתמש בו כדי לאפשר ל-SoCs מבוססי ARM לגשת לחיישנים.

‏HAL של החיישן מתקשר עם מנהל ה-SCMI של IIO בתת-מערכת IIO של Linux Kernel, שמשתמש בפרוטוקול ניהול החיישן של SCMI שמסופק על ידי המפרט של ממשק הבקרה והניהול של מערכת ARM‏ (SCMI) כדי לזהות ולקבוע הגדרות של חיישנים, לקרוא נתוני חיישנים ולקבל התראות על שינויים בערכי החיישנים.

מנהל ההתקן של IIO SCMI משתמש במנהל ההתקן של VirtIO SCMI, שמשתמש בפרוטוקול התעבורה של VirtIO כפי שמפורט במפרט virtio-scmi כדי להחליף הודעות SCMI עם מכשיר VirtIO SCMI במכונה הווירטואלית המארחת. למכשיר VirtIO-SCMI יש גישה ישירה לחיישנים דרך מנהלי חיישנים ספציפיים ל-SoC.

ארכיטקטורת חיישנים
איור 4. ארכיטקטורת חיישנים

מיקום ה-HAL של החיישן

ההטמעה לדוגמה של HAL החיישן, שמשתמשת ב-VirtIO SCMI, נמצאת בכתובת device/google/trout/hal/sensors.

הגדרת HAL של חיישן

יכול להיות ש-HAL של החיישן יצטרך לשנות את נתוני החיישן שהתקבלו מהמכונה הווירטואלית המארחת כדי לעמוד בדרישות של מערכת הקואורדינטות של חיישן הרכב ב-Android. הסכימה של הגדרת החיישן מופיעה בקובץ device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd.

יצרני ציוד מקורי יכולים לספק הגדרות חיישן, כמו כיוון ומיקום, בקובץ sensor_hal_configuration.xml ולהעתיק אותו לקובץ /odm/etc/sensors/ או לקובץ /vendor/etc/sensors/. בהמשך מופיעה הגדרה לדוגמה של חיישן:

<sensorHalConfiguration version="1.0" xmlns:xi="http://www.w3.org/2001/XInclude">
    <modules>
        <module halName="android.hardware.sensors@2.0-Google-IIO-Subhal" halVersion="2.0">
            <sensors>
                <sensor name="scmi.iio.accel" type="1">
                    <configuration>
<!-- Attribute rotate denotes if HAL needs to modify the sensor data to comply with //
        the Android car sensor coordinate system -->
                        <orientation rotate="true">
               <!-- Attribute map denotes the indexes of data in sensor data received -->
               <!-- Attribute negate denotes if data needs to be negated -->
                            <x map="0" negate="false"/>
                            <y map="1" negate="true"/>
                            <z map="2" negate="true"/>
                        </orientation>
                        <location>
               <!-- Attribute x, y, z denotes location of the sensor placement -->
                            <x>10</x>
                            <y>15</y>
                            <z>20</z>
                        </location>
                    </configuration>
                </sensor>
         </sensors>
        </module>
    </modules>
</sensorHalConfiguration>

Vehicle HAL

הטמעת Vehicle HAL מורכבת משני רכיבים:

  • לקוח רכיבי API ש-Android משתמשת בהם ב-AAOS וירטואלי
  • שרת מתקשר ישירות עם החומרה, כמו מערכי ה-bus של הרכב (או אמולטור).

בווירטואליזציה, שרת VHAL פועל במכונה הווירטואלית המארחת. הלקוח והשרת של VHAL מתקשרים דרך GRPC-vsock (מידע נוסף זמין במאמר device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto). יצרני ציוד מקורי יכולים להשתמש בפרוטוקול תעבורה אחר מלבד GRPC על ידי שינוי של ממשקי ה-API לתקשורת. דוגמאות מפורטות מופיעות במאמר device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp.

תת-מערכות אחרות

VirtIO כבר מספק ממשק מוגדר היטב לרכיבים כמו Block Storage,‏ Network,‏ Console,‏ Input,‏ Socket ו-Entropy. ברכיבי המשנה האלה, מערכת AAOS משתמשת במנהל כפי שהוא, למשל virtio-blk,‏ virtio-input,‏ virtio-console ו-virtio-net.

בפלטפורמת העזרה הווירטואלית של AAOS, יש תמיכה ב-Wi-Fi באמצעות mac80211_hwsim כדי להפעיל רשת אלחוטית VirtWifi, שמשתמשת לאחר מכן במנהרה virtio-net כדי לשלוח את תעבורת הרשת למכונה הווירטואלית המארחת, שיש לה גישה ישירה לרשת ה-Wi-Fi בפועל.