ארכיטקטורה

‫

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

התקשורת בין מנהל ההתקן של VirtIO לבין מכשיר VirtIO מתבצעת באמצעות virtqueue, שהם מאגרי טבעות דומים ל-DMA של רשימות scatter gather. אפשר להשתמש בכמה פרוטוקולי העברה, כמו MMIO או PCI, כדי להעביר את הודעות VirtIO בין מכונות וירטואליות.

במקרים מסוימים, נעשה שימוש ב-vsock לתקשורת בין מכונות וירטואליות. יש תמיכה בתקשורת של שכבת הפשטת חומרה לרכב, בבקרה על האודיו וב-Dumpstate באמצעות חיבור לסוכן עמית במכונה וירטואלית נפרדת דרך ממשק vsock. ‫GRPC-vsock משמש לגישה למערכות משנה לא סטנדרטיות. ‫GRPC בעץ המקור של Android שונה כדי לעבוד עם vsock בפורמט הכתובת של vsock:CID:PORT_NUMBER.

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

אודיו

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

ההטמעה של ברירת המחדל של Audio 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

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

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

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

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

ארכיטקטורת Bluetooth
איור 5. ארכיטקטורת Bluetooth

Dumpstate

כשיוצרים את דוח הבאגים עבור AAOS וירטואלי, כדאי לכלול מידע על המכונה הווירטואלית של המארח, כדי שהמפתחים יוכלו לקבל תמונה מקיפה יותר של המערכת. לשם כך, הטמעת ההפניה trout מטמיעה את IDumpstateDevice HAL, שאוסף את פרטי מכונת ה-VM המארחת דרך GRPC-vsock. המידע על המכונה הווירטואלית של המארח, שנארז ב-tar, נקרא dumpstate_board.bin בדוח הבאגים, והיומנים נמצאים ב-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-video.

מצב מוסך

מידע נוסף מופיע במאמר בנושא מצב מוסך.

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

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

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

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

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

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

גרפיקה

כש-AAOS פועלת כמכונה וירטואלית (VM) אורחת לצד מערכות הפעלה אחרות לרכב, יכול להיות שלא תהיה ל-Android גישה ישירה ל-GPU או לבקר התצוגה. במקרה כזה, אפשר להשתמש ב-Mesa או ב-goldfish-opengl ובדרייבר virtio-gpu במכונת ה-VM של אורח 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 פועלת כ-VM אורח לצד מערכות הפעלה אחרות לרכב, יכול להיות שלאנדרואיד לא תהיה גישה ישירה לחיישנים. במקרה הזה, נעשה שימוש במנהל ההתקן Virtio-SCMI במכונה הווירטואלית של אורח Android ובמכשיר VirtIO-SCMI במכונה הווירטואלית של המארח כדי לגשת לחיישנים. פלטפורמת ההפניה של AAOS לווירטואליזציה מספקת Sensor HAL גנרי שלא תלוי בחומרה, שאפשר להשתמש בו ב-SoC מבוסס-ARM כדי לגשת לחיישנים.

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

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

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

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

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

הגדרת Sensor HAL

יכול להיות ש-Sensor 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>

שכבת הפשטת חומרה לרכב

ההטמעה של שכבת הפשטת חומרה לרכב מורכבת משני רכיבים:

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

בווירטואליזציה, שרת ה-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, רשת, מסוף, קלט, Socket ואנטרופיה. במערכות המשנה האלה, AAOS משתמש במנהל ההתקן כמו שהוא, למשל virtio-blk,‏ virtio-input,‏ virtio-console ו-virtio-net.

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