การเปลี่ยนแปลงส่วนใหญ่ที่จำเป็นสำหรับการรองรับ 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
เสียง
ใน 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 ต่อไปจนกว่าจะมีการปล่อยโฟกัส
บลูทูธ
การใช้งานบลูทูธจะเป็นไปตามการออกแบบที่แสดงไว้ด้านล่าง
โปรไฟล์แฮนด์ฟรีของบลูทูธ
วิธีเปิดใช้โปรไฟล์แฮนด์ฟรีบลูทูธ (HFP) ใน trout
อุปกรณ์เสียง VirtIO
ได้ขยายข้อกำหนดให้รองรับการควบคุมเสียงแล้ว เมื่อใช้แนวทางนี้ ระบบเสียง VirtIO
อุปกรณ์ในฝั่งโฮสต์/ไฮเปอร์ไวเซอร์จะมีการควบคุมเสียง 3 รายการต่อไปนี้ที่เกี่ยวข้องกับ HFP
hfp_enable
hfp_set_sampling_rate
hfp_volume
เมื่อ AAOS ทำงานเป็น VM ของผู้เข้าร่วม AAOS จะใช้ TinyAlsa ในการตั้งค่าการควบคุมเสียงเหล่านี้ วิธีเปิดใช้ HFP โฮสต์/Hypervisor จะดำเนินการกำหนดเส้นทางเฉพาะผู้ให้บริการและปรับเทียบให้สอดคล้องกัน
การใช้งานบลูทูธจะอิงตามภาพการออกแบบด้านล่าง
ดัมพ์สเตท
เมื่อสร้างรายงานข้อบกพร่องสำหรับ AAOS เสมือน คุณควรรวมข้อมูล VM ของโฮสต์
เพื่อให้นักพัฒนาซอฟต์แวร์เห็นภาพระบบได้ครอบคลุมมากขึ้น เพื่อให้บรรลุเป้าหมายนี้ ฟิลด์
การใช้การอ้างอิง trout
จะใช้ IDumpstateDevice
HAL ซึ่ง
รวบรวมข้อมูล VM ของโฮสต์ผ่าน GRPC-vsock
VM ของโฮสต์แพ็กเกจ "tar"
ข้อมูลมีชื่อว่า dumpstate_board.bin
ในรายงานข้อบกพร่องขณะบันทึกข้อมูลการดัมพ์
dumpstate_board.txt
หากต้องการกำหนดค่าคำสั่งให้ดำเนินการ:
- คัดลอกรายละเอียดการกำหนดค่าจากไฟล์ด้านล่างลงในไฟล์ 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>
- ส่งเส้นทางของไฟล์ 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) จะได้รับการจัดการ ตามสภาพแวดล้อมของระบบปฏิบัติการของโฮสต์
กราฟิก
เมื่อ 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 โดยคาดว่าจะเปิดตัวในอนาคต
เซ็นเซอร์
เมื่อ 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
ตำแหน่งเซ็นเซอร์ 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 จริงโดยตรง