สถาปัตยกรรม

การเปลี่ยนแปลงส่วนใหญ่ที่จำเป็นในการรองรับ VirtIO ใน AAOS เกี่ยวข้องกับการเปลี่ยนแปลงที่ระดับการใช้งาน HAL และระดับที่ต่ำกว่าใน Android Common Kernel เฟรมเวิร์ก Android จะสื่อสารกับ HAL ทั่วไปที่ไม่ขึ้นกับฮาร์ดแวร์โดยใช้ไดรเวอร์ VirtIO ในเคอร์เนล VM ของ AAOS ซึ่งจะสื่อสารกับอุปกรณ์ VirtIO ในฝั่งโฮสต์โดยใช้โปรโตคอล VirtIO อุปกรณ์ VirtIO ในฝั่งโฮสต์สามารถเข้าถึง HW จริงได้โดยใช้ไดรเวอร์อุปกรณ์ที่เฉพาะเจาะจงกับ SoC

การสื่อสารระหว่างไดรเวอร์ VirtIO กับอุปกรณ์ VirtIO จะเกิดขึ้นด้วย virtqueue ซึ่งเป็นบัฟเฟอร์แบบวงแหวนที่คล้าย DMA ของรายการการกระจายและการรวบรวม คุณสามารถใช้การรับส่งหลายรายการ เช่น MMIO หรือ PCI เพื่อแลกเปลี่ยนข้อความ VirtIO ระหว่าง VM

ในบางกรณี ระบบได้ใช้ vsock สำหรับการสื่อสารระหว่าง VM ระบบรองรับการสื่อสารของ HAL ยานพาหนะ, การควบคุมเสียง และ Dumpstate โดยใช้การเชื่อมต่อกับเอเจนต์เพียร์ใน VM แยกต่างหากผ่านอินเทอร์เฟซ vsock ระบบใช้ GRPC-vsock เพื่อเข้าถึงระบบย่อยที่ไม่เป็นมาตรฐานเหล่านี้ GRPC ในแผนผังแหล่งที่มาของ Android ได้รับการแก้ไขให้ทำงานกับ vsock ที่มีรูปแบบที่อยู่ เป็น vsock:CID:PORT_NUMBER

สถาปัตยกรรมระบบเสมือนจริง
รูปที่ 1 สถาปัตยกรรมระบบเสมือนจริง

เสียง

ใน AAOS ที่จำลองเสมือน VM ของ Android ที่เป็น Guest สามารถใช้ virtio-snd เพื่อเข้าถึงเสียงได้ virtio-snd จะจัดหาอุปกรณ์ PCM ที่จำลองเสมือนให้กับ VM ของ Android เพื่อให้การใช้งาน HAL ของเสียงโต้ตอบกับอุปกรณ์เสียงที่จำลองเสมือนได้ด้วยไลบรารี TinyALSA

การใช้งาน HAL ของเสียงเริ่มต้นจะอยู่ใน AOSP ที่ /device/google/trout/hal/audio/6.0 OEM สามารถแก้ไข ro.vendor.trout.audiohal.{in,out}_period_{ms,count} สำหรับแพลตฟอร์มของตนได้ นอกจากนี้ OEM ยังสามารถใช้งาน HAL ของเสียงเองได้โดยการลบล้างตัวแปรที่เกี่ยวข้องกับเสียงใน /device/google/trout/aosp_trout_common.mk.

HAL ของการควบคุมเสียงจะจัดการโฟกัสเสียงใน AAOS ตัวอย่างเช่น เมื่อระบบเล่นเสียงฉุกเฉิน อาจต้องปิดเสียงเพลงที่เล่นอยู่เบื้องหลัง HAL ของการควบคุมเสียงจะแจ้งให้แอปที่เล่นเพลงปิดเสียงในสถานการณ์นี้ ในระบบที่จำลองเสมือน เสียงอาจมาจาก VM อื่น ในการใช้งานอ้างอิง VM ของ AAOS ที่เป็น Guest จะมี Daemon เซิร์ฟเวอร์การควบคุมเสียงที่ทำงานอยู่ ซึ่งใช้ GRPC-vsock เพื่อรับคำขอโฟกัสเสียงจาก VM อื่น VM ของโฮสต์สามารถใช้ device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller เพื่อส่งคำขอการควบคุมเสียงไปยัง AAOS ขณะที่ libandroid_audio_controller มีโฟกัสเสียง ระบบจะส่งสัญญาณชีพจรไปยัง AAOS ต่อไปจนกว่าจะปล่อยโฟกัส

สถาปัตยกรรมเสียง
รูปที่ 5 สถาปัตยกรรมเสียง

บลูทูธ

การใช้งานบลูทูธอิงตามการออกแบบที่แสดงไว้ด้านล่าง

สถาปัตยกรรมบลูทูธ
รูปที่ 5 สถาปัตยกรรมบลูทูธ

โปรไฟล์แฮนด์ฟรีของบลูทูธ

หากต้องการเปิดใช้โปรไฟล์แฮนด์ฟรีของบลูทูธ (HFP) ใน trout ระบบได้ขยายข้อกำหนดของอุปกรณ์เสียง VirtIO เพื่อรองรับการควบคุมเสียง เมื่อใช้วิธีนี้ อุปกรณ์เสียง VirtIO ในฝั่งโฮสต์/ไฮเปอร์ไวเซอร์จะมีการควบคุมเสียง 3 รายการที่เกี่ยวข้องกับ HFP ดังนี้

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

เมื่อ AAOS ทำงานเป็น VM ของ Guest, AAOS จะใช้ TinyAlsa เพื่อตั้งค่าการควบคุมเสียงเหล่านี้ หากต้องการเปิดใช้กรณีการใช้งาน HFP โฮสต์/ไฮเปอร์ไวเซอร์จะทำการกำหนดเส้นทางและการปรับเทียบที่เฉพาะเจาะจงของผู้ให้บริการตามความเหมาะสม

การใช้งานบลูทูธอิงตามการออกแบบที่แสดงไว้ด้านล่าง

สถาปัตยกรรมบลูทูธ
รูปที่ 5 สถาปัตยกรรมบลูทูธ

Dumpstate

เมื่อสร้างรายงานข้อบกพร่องสำหรับ AAOS ที่จำลองเสมือน การรวมข้อมูล VM ของโฮสต์จะเป็นประโยชน์เพื่อให้ผู้พัฒนาเห็นภาพรวมของระบบได้มากขึ้น เพื่อให้บรรลุเป้าหมายนี้ การใช้งานอ้างอิง trout จะใช้ IDumpstateDevice HAL ซึ่งรวบรวมข้อมูล VM ของโฮสต์ผ่าน GRPC-vsock ข้อมูล VM ของโฮสต์ที่แพ็กเกจเป็น `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 ที่ส่งโดย HAL ยานพาหนะ ในโหมดการจำลองเสมือน โหมดโรงจอดจะทริกเกอร์จากฝั่งโฮสต์ VM ของโฮสต์ควรเปิดเครื่องไว้เพื่อจัดหาอุปกรณ์เสมือนสำหรับ VM ของ Android จนกว่า Android จะปิดเครื่อง เซิร์ฟเวอร์ VHAL ใน VM ของโฮสต์จะส่งสัญญาณปิดเครื่องไปยัง VM ของ AAOS ที่เป็น Guest เมื่อได้รับสัญญาณไคลเอ็นต์ VHAL, VM ของ AAOS จะเข้าสู่โหมดโรงจอดและเริ่มส่งสัญญาณชีพจรเพื่อให้ VM ของโฮสต์ทำงานอยู่

ระบบดาวเทียมนำร่องทั่วโลก (GNSS)

ใน trout 1.0 ระบบได้เพิ่มการรองรับการจำลองเสมือน GNSS ผ่าน virtio-console การใช้งานรองรับการแลกเปลี่ยนการวัดผลดิบและการแก้ไขตำแหน่งจากโฮสต์ไปยัง Guest

รูปแบบการแลกเปลี่ยนข้อมูลคือ CSV ที่แอป GnssLogger ใช้ ในการใช้งานอ้างอิง เนื่องจากไดรเวอร์ GNSS ดั้งเดิมไม่พร้อมใช้งาน ระบบจึงจัดเตรียมข้อมูลจำลองไว้ แต่คุณสามารถใช้งานไดรเวอร์ดั้งเดิมได้โดยไม่ต้องทำการเปลี่ยนแปลงใดๆ ในฝั่ง Guest ระบบจัดเตรียมเอเจนต์โฮสต์จำลองตัวอย่างไว้เป็นส่วนหนึ่งของซอร์สโค้ด trout

การใช้งานปัจจุบันคาดหวังให้สภาพแวดล้อมระบบปฏิบัติการโฮสต์จัดการการเริ่มต้น GNSS และ GNSS ที่ได้รับความช่วยเหลือ (AGNSS)

สถาปัตยกรรม GNSS
รูปที่ 2 สถาปัตยกรรม GNSS

กราฟิก

เมื่อ AAOS ทำงานเป็น VM ของ Guest ควบคู่ไปกับระบบปฏิบัติการยานยนต์อื่นๆ Android อาจไม่มีสิทธิ์เข้าถึง GPU หรือคอนโทรลเลอร์การแสดงผลโดยตรง ในกรณีนี้ Mesa หรือ goldfish-opengl และไดรเวอร์ virtio-gpu ใน VM ของ Android ที่เป็น Guest และอุปกรณ์ virtio-gpu สามารถใช้เพื่อเข้าถึง GPU ได้

ใน VM ของ Android ที่เป็น Guest, Mesa หรือ goldfish-opengl จะเข้ารหัสคำสั่ง OpenGLES เป็นสตรีม Gallium หรือสตรีม GLES ที่สร้างขึ้นโดยอัตโนมัติ ตามลำดับ ระบบใช้ไดรเวอร์เคอร์เนล virtio-gpu เป็นการรับส่ง ในฝั่งโฮสต์ virglrenderer (สำหรับ Mesa) และ vulkan-cereal (สำหรับ goldfish-opengl) จะเล่นสตรีมคำสั่งที่ถอดรหัสแล้วซ้ำบนไดรเวอร์ GPU ที่มีอยู่ แพลตฟอร์มอ้างอิง AAOS trout รองรับ OpenGL ES เท่านั้น โดยจะรองรับ Vulkan ในรุ่นที่จะเปิดตัวในอนาคต

สถาปัตยกรรมกราฟิก
รูปที่ 3 สถาปัตยกรรมกราฟิก

เซ็นเซอร์

เมื่อ AAOS ทำงานเป็น VM ของ Guest ควบคู่ไปกับระบบปฏิบัติการยานยนต์อื่นๆ Android อาจไม่มีสิทธิ์เข้าถึงเซ็นเซอร์โดยตรง ในกรณีนี้ ระบบจะใช้ไดรเวอร์ Virtio-SCMI ใน VM ของ Android ที่เป็น Guest และอุปกรณ์ VirtIO-SCMI ใน VM ของโฮสต์เพื่อเข้าถึงเซ็นเซอร์ แพลตฟอร์มการจำลองเสมือนอ้างอิง AAOS มี HAL ของเซ็นเซอร์ทั่วไปที่ไม่ขึ้นกับ HW ซึ่งใช้ได้กับ SoC ที่ใช้ ARM เพื่อเข้าถึงเซ็นเซอร์

HAL ของเซ็นเซอร์จะสื่อสารกับไดรเวอร์ IIO SCMI ในระบบย่อย IIO ของเคอร์เนล Linux ซึ่งใช้โปรโตคอลการจัดการเซ็นเซอร์ SCMI ที่ระบุไว้ใน ARM System Control and Management Interface (SCMI) ข้อกำหนดเพื่อค้นหาและกำหนดค่าเซ็นเซอร์ อ่านข้อมูลเซ็นเซอร์ และรับการแจ้งเตือนการเปลี่ยนแปลงค่าเซ็นเซอร์

ไดรเวอร์ IIO SCMI ใช้ไดรเวอร์ VirtIO SCMI ซึ่งใช้โปรโตคอลการรับส่ง VirtIO ตามที่ระบุไว้ในข้อกำหนด virtio-scmi เพื่อแลกเปลี่ยนข้อความ SCMI กับอุปกรณ์ VirtIO SCMI ใน VM ของโฮสต์ อุปกรณ์ VirtIO SCMI มีสิทธิ์เข้าถึงเซ็นเซอร์โดยตรงผ่านไดรเวอร์เซ็นเซอร์ที่เฉพาะเจาะจงกับ SoC

สถาปัตยกรรมเซ็นเซอร์
รูปที่ 4 สถาปัตยกรรมเซ็นเซอร์

ตำแหน่ง HAL ของเซ็นเซอร์

การใช้งานอ้างอิงของ HAL ของเซ็นเซอร์ซึ่งใช้ VirtIO SCMI จะอยู่ที่ device/google/trout/hal/sensors

การกำหนดค่า HAL ของเซ็นเซอร์

HAL ของเซ็นเซอร์อาจต้องแก้ไขข้อมูลเซ็นเซอร์ที่ได้รับจาก VM ของโฮสต์เพื่อให้เป็นไปตามระบบพิกัดเซ็นเซอร์ของรถยนต์ Android คุณดูสคีมาสำหรับการกำหนดค่าเซ็นเซอร์ได้ที่ device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd

OEM สามารถระบุการกำหนดค่าเซ็นเซอร์ เช่น การวางแนวและตำแหน่ง ใน 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>

HAL ยานพาหนะ

การใช้งาน Vehicle HAL ประกอบด้วย 2 คอมโพเนนต์ ได้แก่

  • ไคลเอ็นต์ มี API ที่ Android ใช้ใน AAOS ที่จำลองเสมือน
  • เซิร์ฟเวอร์ สื่อสารกับฮาร์ดแวร์โดยตรง เช่น บัสของยานพาหนะ (หรือโปรแกรมจำลอง)

ในการจำลองเสมือน เซิร์ฟเวอร์ VHAL จะทำงานใน VM ของโฮสต์ ไคลเอ็นต์และเซิร์ฟเวอร์ VHAL จะสื่อสารผ่าน GRPC-vsock (ดูข้อมูลเพิ่มเติมได้ที่ device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto) OEM สามารถใช้โปรโตคอลการรับส่งอื่นที่ไม่ใช่ GRPC ได้โดยการลบล้าง API การสื่อสาร ดูตัวอย่างได้ที่ device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp

ระบบย่อยอื่นๆ

VirtIO มีอินเทอร์เฟซที่กำหนดไว้อย่างดีสำหรับคอมโพเนนต์ต่างๆ เช่น พื้นที่เก็บข้อมูลแบบบล็อก, เครือข่าย, คอนโซล, อินพุต, ซ็อกเก็ต และเอนโทรปี สำหรับระบบย่อยเหล่านี้ AAOS จะใช้ไดรเวอร์ตามที่เป็นอยู่ เช่น virtio-blk, virtio-input, virtio-console และ virtio-net

ในแพลตฟอร์มอ้างอิง AAOS ที่จำลองเสมือน ระบบรองรับ Wi-Fi ด้วย mac80211_hwsim เพื่อเปิดใช้เครือข่ายไร้สาย VirtWifi ซึ่งจะใช้การเชื่อมต่อแบบอุโมงค์ข้อมูล virtio-net เพื่อส่งการจราจรของข้อมูลในเครือข่ายไปยัง VM ของโฮสต์ ซึ่งมีสิทธิ์เข้าถึงเครือข่าย Wi-Fi จริงโดยตรง