สถาปัตยกรรม

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

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

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

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

เครื่องเสียง

ใน AAOS เสมือนจริง VM ของแขก Android สามารถใช้ virtio-snd เพื่อเข้าถึงเสียงได้ virtio-snd จัดเตรียมอุปกรณ์ PCM เสมือนจริงให้กับ Android VM เพื่อให้การใช้งาน Audio 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 (HFP) บน trout ข้อมูลจำเพาะของอุปกรณ์เสียง VirtIO ได้รับการขยายเพื่อรองรับการควบคุมเสียง ด้วยวิธีการนี้ อุปกรณ์เสียง VirtIO ที่ฝั่งโฮสต์/ไฮเปอร์ไวเซอร์จะมีการควบคุมเสียงสามส่วนที่เกี่ยวข้องกับ HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

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

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

สถาปัตยกรรมบลูทูธ
รูปที่ 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)

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

โหมดโรงรถ

สำหรับข้อมูลเพิ่มเติม โปรดดู ที่ โหมดโรงรถคืออะไร? .

การเข้าและออกจากโหมดโรงรถถูกทริกเกอร์โดยคุณสมบัติ AP_POWER_STATE_REQ ที่ส่งโดย HAL ของพาหนะ ในโหมดเวอร์ชวลไลเซชัน โหมดโรงรถจะเปิดใช้งานจากฝั่งโฮสต์ VM ของโฮสต์ควรเปิดอยู่เพื่อให้อุปกรณ์เสมือนสำหรับ Android VM จนกว่า Android จะปิด เซิร์ฟเวอร์ VHAL บนโฮสต์ VM ส่งสัญญาณการปิดระบบไปยัง AAOS guest VM เมื่อได้รับสัญญาณไคลเอ็นต์ VHAL แล้ว AAOS VM จะเข้าสู่โหมด Garage และเริ่มส่งสัญญาณฮาร์ตบีตเพื่อให้โฮสต์ 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 driver บน VM และอุปกรณ์ virtio-gpu ของ Android ได้ในการเข้าถึง GPU

บน 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 บน Android guest VM และอุปกรณ์ 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

การนำ 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 จริง