สถาปัตยกรรม

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

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

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

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

เสียง

ใน AAOS เสมือน Android VM สำหรับผู้มาเยือนจะใช้ 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 มีดีมอนเซิร์ฟเวอร์ควบคุมเสียงที่ทำงานอยู่ ซึ่งใช้ 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 ของผู้เข้าร่วม AAOS จะใช้ TinyAlsa ในการตั้งค่าการควบคุมเสียงเหล่านี้ วิธีเปิดใช้ HFP โฮสต์/Hypervisor จะดำเนินการกำหนดเส้นทางเฉพาะผู้ให้บริการและปรับเทียบให้สอดคล้องกัน

การใช้งานบลูทูธจะอิงตามภาพการออกแบบด้านล่าง

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

ดัมพ์สเตท

เมื่อสร้างรายงานข้อบกพร่องสำหรับ 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 ใหม่ไปยังเซิร์ฟเวอร์ดัมพ์สเตทเมื่อเปิดใช้ ดังตัวอย่างต่อไปนี้
    --config_file my_config.xml
    

ระบบมุมมองขยาย (EVS)

ระบบมุมมองขยาย (Extended View System หรือ EVS) ใช้เพื่อแสดงวิดีโอที่ถ่ายด้วยมุมมองด้านหลังและ กล้องมุมมองเซอร์ราวด์ ใน AAOS เสมือน สแต็ก EVS จะเข้าถึงสตรีมวิดีโอได้จาก อุปกรณ์สตรีมมิง V4L2 เสมือนจริงที่ใช้ไดรเวอร์วิดีโอ VirtIO

โหมดโรงรถ

สำหรับข้อมูลเพิ่มเติม โปรดดู โหมดโรงรถ

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

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

ใน trout 1.0 การรองรับระบบเสมือนจริงของ GNSS ผ่าน virtio-console ถูกเพิ่มแล้ว การใช้งานจะสนับสนุนการแลกเปลี่ยนการวัดดิบและการแก้ไขสถานที่จาก กับแขกรับเชิญ

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

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

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

กราฟิก

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

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

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

เซ็นเซอร์

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

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

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

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

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

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

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

Sensor 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 ยานพาหนะ

การติดตั้งใช้งาน 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 มีอินเทอร์เฟซที่กำหนดไว้ชัดเจนสำหรับคอมโพเนนต์ต่างๆ เช่น Block Storage, Network, Console, Input, Socket และ Entropy สําหรับระบบย่อยเหล่านี้ AAOS จะใช้ คนขับตามที่เป็นอยู่ เช่น virtio-blk, virtio-input virtio-console และ virtio-net

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