สถาปัตยกรรม

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

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

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

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

เสียง

ใน AAOS เสมือนจริงนั้น Guest VM ของ Android สามารถใช้ virtio-snd เพื่อเข้าถึงเสียงได้ virtio-snd จัดเตรียมอุปกรณ์ PCM เสมือนจริงให้กับ Android VM เพื่อให้การใช้งาน 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 อื่นๆ ในการใช้งานอ้างอิง AAOS guest VM มี daemon เซิร์ฟเวอร์ควบคุมเสียงทำงานอยู่ ซึ่งใช้ GRPC-vsock เพื่อรับคำขอโฟกัสเสียงจาก VM อื่นๆ โฮสต์ VM สามารถใช้ device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller เพื่อส่งคำขอควบคุมเสียงไปยัง AAOS แม้ว่า libandroid_audio_controller จะเก็บโฟกัสของเสียงไว้ แต่ก็ยังคงส่งฮาร์ตบีตไปยัง AAOS ต่อไปจนกว่าจะปล่อยโฟกัส

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

บลูทู ธ

การใช้งาน Bluetooth ขึ้นอยู่กับการออกแบบที่แสดงด้านล่าง

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

โปรไฟล์แฮนด์ฟรี Bluetooth

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

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

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

การใช้งาน Bluetooth ขึ้นอยู่กับภาพประกอบการออกแบบด้านล่าง

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

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

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

โหมดโรงรถ

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

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

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

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

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

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

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

กราฟิก

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

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

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

เซนเซอร์

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

เซ็นเซอร์ HAL สื่อสารกับไดรเวอร์ IIO SCMI ในระบบย่อย Linux Kernel IIO ซึ่งใช้ SCMI Sensor Management Protocol ที่ได้รับจากข้อกำหนด 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 อาจจำเป็นต้องแก้ไขข้อมูลเซ็นเซอร์ที่ได้รับจาก Host 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 ประกอบด้วยสององค์ประกอบ:

  • ลูกค้า. จัดเตรียม 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

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