تتضمن معظم التغييرات المطلوبة لدعم VirtIO في AAOS تغييرات على مستوى تنفيذ HAL وأدناه في Android Common Kernel. يتواصل إطار عمل Android مع HAL عام لا يعرف الأجهزة باستخدام برامج تشغيل VirtIO في نواة الضيف VM AAOS ، والتي تتصل بأجهزة VirtIO على جانب المضيف باستخدام بروتوكولات VirtIO. يمكن لأجهزة VirtIO الموجودة على الجانب المضيف الوصول إلى المخلفات المادية المادية باستخدام برامج تشغيل الأجهزة الخاصة بشركة نفط الجنوب.
يتم الاتصال بين مشغل VirtIO وجهاز Virtio بواسطة virtqueue ، وهي عبارة عن مخازن مؤقتة تشبه الحلقات DMA لقوائم تجميع مبعثر. يمكن استخدام العديد من وسائل النقل ، مثل MMIO أو PCI لتبادل رسائل VirtIO بين الأجهزة الافتراضية.
في بعض الحالات ، تم الاستفادة من vsock للتواصل بين الأجهزة الافتراضية. يتم دعم اتصالات HAL الخاصة بالمركبة والتحكم في الصوت و Dumpstate باستخدام اتصال بوكيل نظير على جهاز افتراضي منفصل عبر واجهة vsock . يتم استخدام GRPC-vsock للوصول إلى هذه الأنظمة الفرعية غير المعيارية. تم تعديل GRPC في شجرة مصدر Android للعمل مع vsock بتنسيق عنوان vsock:CID:PORT_NUMBER .
الرسومات
عند تشغيل AAOS كضيف VM جنبًا إلى جنب مع أنظمة تشغيل السيارات الأخرى ، قد لا يكون لدى Android وصول مباشر إلى وحدة معالجة الرسومات أو وحدة التحكم في الشاشة. في هذه الحالة ، يمكن استخدام Mesa وبرنامج تشغيل virtio-gpu على جهاز Android Guest VM وجهاز virtio-gpu للوصول إلى وحدة معالجة الرسومات.
على جهاز Android الضيف VM ، يستخدم Mesa إطار عمل Gallium3D لتجميع تظليل لتمثيل TGSI المتوسط وترجمة واجهة برمجة التطبيقات إلى كائنات حالة. ثم يرسل Gallium3D كائنات الحالة المترجمة واستدعاءات السحب إلى Mesa Virgl ، والتي تستخدم بعد ذلك virtio-gpu كبروتوكول نقل لإرسال الأوامر والتظليل إلى Host VM.
على الجانب المضيف ، يتلقى virglrenderer دفق أوامر virtio-gpu ويحول الدفق إلى أوامر OpenGL ES. كما أنه يترجم التظليل من تنسيق TGSI إلى تنسيق GLSL ثم يعيد تشغيلها أعلى برنامج تشغيل GPU الحالي.
يدعم trout النظام الأساسي المرجعي AAOS حاليًا OpenGL ES بدعم Vulkan ، المتوقع في إصدار مستقبلي.
مجسات
عند تشغيل AAOS كضيف VM جنبًا إلى جنب مع أنظمة تشغيل السيارات الأخرى ، قد لا يكون لدى Android وصول مباشر إلى المستشعرات. في هذه الحالة ، يتم استخدام برنامج تشغيل Virtio-SCMI على جهاز Android guest VM وجهاز VirtIO-SCMI على Host VM للوصول إلى المستشعرات. توفر المنصة المرجعية الافتراضية لـ AAOS مستشعر HAL عام وغير محدد HW يمكن استخدامه في SoCs المستندة إلى ARM للوصول إلى المستشعرات.
يتواصل Sensor HAL مع برنامج تشغيل IIO SCMI في النظام الفرعي Linux Kernel IIO ، والذي يستخدم بروتوكول إدارة مستشعر SCMI المقدم من مواصفات واجهة التحكم والتحكم في نظام ARM (SCMI) لاكتشاف المستشعرات وتكوينها ، وقراءة بيانات المستشعر ، وإخطار المستشعر تتغير القيمة. يستخدم برنامج تشغيل IIO SCMI برنامج VirtIO SCMI Driver ، والذي يستخدم بروتوكول نقل VirtIO كما هو محدد في مواصفات virtio-scmi لتبادل رسائل SCMI مع جهاز VirtIO SCMI على الجهاز الظاهري للمضيف. يتمتع جهاز VirtIO SCMI بوصول مباشر إلى المستشعرات من خلال برامج تشغيل أجهزة الاستشعار الخاصة بشركة نفط الجنوب.
موقع 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 .
يمكن أن توفر الشركات المصنعة للمعدات الأصلية تكوين المستشعر ، مثل الاتجاه والموقع ، في 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>
صوتي
في AAOS الافتراضي ، يمكن لجهاز Android VM الضيف استخدام virtio-snd للوصول إلى الصوت. يوفر virtio-snd أجهزة PCM الافتراضية لجهاز Android VM بحيث يمكن لتطبيق HAL الصوتي التفاعل مع أجهزة الصوت الافتراضية مع مكتبة TinyALSA.
يقع تطبيق HAL الصوتي الافتراضي في AOSP على /device/google/trout/hal/audio/6.0 . يمكن لمصنعي المعدات الأصلية تعديل ro.vendor.trout.audiohal.{in,out}_period_{ms,count} الأساسي. يمكن لمصنعي المعدات الأصلية أيضًا تنفيذ HAL الصوتي الخاص بهم عن طريق تجاوز المتغيرات المتعلقة بالصوت في /device/google/trout/aosp_trout_common.mk.
يدير التحكم في الصوت HAL تركيز الصوت في AAOS. على سبيل المثال ، عندما يقوم النظام بتشغيل أصوات طوارئ ، فقد يلزم كتم صوت الموسيقى التي يتم تشغيلها في الخلفية. سيُعلم التحكم في الصوت HAL تلك التطبيقات التي تقوم بتشغيل الموسيقى لكتم الصوت في هذه الحالة. في النظام الافتراضي ، قد تأتي الأصوات من أجهزة افتراضية أخرى. في التنفيذ المرجعي ، يحتوي الضيف VM الضيف AAOS على خادم التحكم الصوتي قيد التشغيل ، والذي يستخدم GRPC-vsock لتلقي طلبات التركيز الصوتي من أجهزة افتراضية أخرى. يمكن لجهاز VM المضيف استخدام device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller لإرسال طلبات التحكم في الصوت إلى AAOS. بينما يحتفظ libandroid_audio_controller بتركيز الصوت ، فإنه سيستمر في إرسال دقات القلب إلى AAOS حتى يتم تحرير التركيز.
بلوتوث
عند تشغيل AAOS كضيف VM جنبًا إلى جنب مع أنظمة تشغيل السيارات الأخرى ، قد لا يكون لدى Android وصول مباشر إلى وحدة تحكم Bluetooth. في هذه الحالة ، يمكن استخدام برنامج تشغيل VirtIO-Console على جهاز Android guest VM وجهاز VirtIO-Console الموجود على الجهاز الظاهري المضيف لفتح منفذ COM افتراضي وإرسال حزم HCI إلى وحدة تحكم Bluetooth واستقبال الأحداث. يسمح هذا التصميم باستخدام تقنية Bluetooth HAL العامة والحيادية حول HW بواسطة مكدس Android Bluetooth. يمكن لجهاز VM المضيف التعامل مع المهام الخاصة بالأجهزة ، مثل التهيئة وتنزيل البرامج الثابتة لوحدة تحكم Bluetooth.
يعتمد تطبيق Bluetooth على الرسم التوضيحي للتصميم أدناه.
السيارة HAL
يتكون تطبيق HAL للمركبة من عنصرين:
- عميل. يوفر واجهات برمجة التطبيقات التي يستخدمها Android في AAOS الافتراضي
- الخادم. يتصل مباشرة بالأجهزة ، مثل حافلات المركبات (أو المحاكي).
في الظاهرية ، يعمل خادم VHAL على الجهاز الظاهري المضيف. يتواصل عميل وخادم VHAL من خلال GRPC-vsock (لمزيد من المعلومات ، راجع device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). يمكن لمصنعي المعدات الأصلية استخدام بروتوكول نقل مختلف بخلاف GRPC من خلال تجاوز واجهات برمجة تطبيقات الاتصال. للحصول على أمثلة ، راجع device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .
نظام عرض ممتد
يستخدم نظام الرؤية الممتد (EVS) لعرض الفيديو الذي تم التقاطه بواسطة كاميرات الرؤية الخلفية والرؤية المحيطية. في AAOS الافتراضي ، يمكن لمكدس EVS الوصول إلى دفق الفيديو من جهاز دفق V4L2 الافتراضي الذي يستخدم برنامج تشغيل VirtIO-video.
وضع المرآب
لمزيد من المعلومات ، راجع ما هو وضع المرآب؟ .
يتم تشغيل الدخول إلى وضع Garage والخروج منه بواسطة خصائص AP_POWER_STATE_REQ المرسلة بواسطة HAL الخاص بالمركبة. في الوضع الافتراضي ، يتم تشغيل وضع المرآب من جانب المضيف. يجب أن يظل الجهاز المضيف VM قيد التشغيل لتوفير أجهزة افتراضية لنظام Android VM ، حتى يتم إيقاف تشغيل Android. يرسل خادم VHAL على المضيف VM إشارة إيقاف التشغيل إلى ضيف AAOS VM. عند استقبال عميل VHAL للإشارة ، يدخل AAOS VM في وضع Garage ويبدأ في إرسال إشارات دقات القلب للحفاظ على الجهاز الظاهري للمضيف نشطًا.
تفريغ
عند إنشاء تقرير الأخطاء لـ AAOS الافتراضي ، من المهم تضمين معلومات المضيف VM بحيث يكون للمطورين رؤية أكثر شمولاً للنظام. لتحقيق ذلك ، يقوم تنفيذ مرجع trout بتنفيذ IDumpstateDevice HAL ، الذي يجمع معلومات الجهاز الظاهري للمضيف من خلال GRPC-vsock . تتم تسمية معلومات الجهاز الظاهري لمضيف حزمة 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 الجديد إلى خادم dumpstate عند بدء التشغيل. على سبيل المثال:
--config_file my_config.xml
أنظمة فرعية أخرى
يوفر VirtIO بالفعل واجهة محددة جيدًا لمكونات مثل التخزين الكتلي والشبكة ووحدة التحكم والإدخال والمقبس والإنتروبيا. بالنسبة لهذه الأنظمة الفرعية ، تستخدم AAOS برنامج التشغيل كما هو ، مثل virtio-blk و virtio-input و virtio-console و virtio-net .
في النظام الأساسي المرجعي الافتراضي AAOS ، يتم دعم Wi-Fi مع mac80211_hwsim لتمكين شبكة VirtWifi اللاسلكية ، والتي تستخدم بعد ذلك نفق virtio-net لإرسال حركة مرور الشبكة إلى الجهاز الظاهري المضيف ، والذي لديه وصول مباشر إلى شبكة Wi-Fi الفعلية.