تتضمّن معظم التغييرات اللازمة لتوفير توافق VirtIO في AAOS تغييرات على مستوى تنفيذ طبقة تجريد الأجهزة (HAL) وما دونه في نواة Android المشتركة. يتواصل إطار عمل Android مع طبقة HAL عامة مستقلة عن الأجهزة باستخدام برامج تشغيل VirtIO في نواة الجهاز الظاهري (VM) لنظام التشغيل AAOS، والتي تتواصل مع أجهزة VirtIO على جانب المضيف باستخدام بروتوكولات VirtIO. يمكن لأجهزة VirtIO على جانب المضيف الوصول إلى الأجهزة المادية باستخدام برامج تشغيل الأجهزة الخاصة بالمنظومة على الرقاقة (SoC).
يتم التواصل بين برنامج تشغيل VirtIO وجهاز VirtIO باستخدام
virtqueue، وهي مخازن مؤقتة حلقية تشبه الوصول المباشر إلى الذاكرة (DMA) لقوائم التجميع والتشتيت.
يمكن استخدام العديد من عمليات النقل، مثل
MMIO
أو
PCI
لتبادل رسائل VirtIO بين الأجهزة الافتراضية.
في بعض الحالات، تم استخدام vsock للتواصل بين الأجهزة الافتراضية.
يتم توفير إمكانية التواصل مع طبقة تجريد الأجهزة في المركبة، والتحكّم في الصوت، وDumpstate باستخدام اتصال ببرنامج وكيل على جهاز افتراضي منفصل عبر واجهة vsock.
يتم استخدام GRPC-vsock للوصول إلى هذه الأنظمة الفرعية غير الموحّدة.
تم تعديل GRPC في شجرة المصدر لنظام Android لتعمل مع vsock بتنسيق العنوان vsock:CID:PORT_NUMBER.
الصوت
في AAOS المحاكي، يمكن للجهاز الظاهري الضيف لنظام التشغيل Android استخدام virtio-snd للوصول إلى الصوت.
يوفر virtio-snd أجهزة PCM الافتراضية لجهاز Android الظاهري، ما يتيح تنفيذ HAL الصوتي التفاعل مع أجهزة الصوت الافتراضية باستخدام مكتبة TinyALSA.
يقع التنفيذ التلقائي لطبقة تجريد الأجهزة (HAL) الخاصة بالصوت في مشروع Android مفتوح المصدر (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 الخاص بعناصر التحكّم في الصوت إشعارًا إلى التطبيقات التي تشغّل الموسيقى لإيقاف الصوت في هذه الحالة. في النظام المحاكى، يمكن أن تأتي الأصوات من أجهزة افتراضية أخرى. في التصميم المرجعي، تتضمّن الآلة الافتراضية الخاصة بنظام التشغيل Android Automotive (AAOS) برنامجًا خفيًا لخادم التحكّم في الصوت يعمل، ويستخدم GRPC-vsock لتلقّي طلبات أولويّة الصوت من الآلات الافتراضية الأخرى.
يمكن للجهاز الافتراضي المضيف استخدام device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller
لإرسال طلبات التحكّم في الصوت إلى AAOS. أثناء احتفاظ libandroid_audio_controller بأولويّة الصوت، يستمر في إرسال إشارات دورية إلى نظام التشغيل Android Automotive (AAOS) إلى أن يتم تحرير الأولويّة.
بلوتوث
تستند عملية تنفيذ البلوتوث إلى التصميم الموضّح أدناه.
بروتوكول تنفيذ الإجراءات بدون لمس الجهاز عبر البلوتوث
لتفعيل ملف البلوتوث بدون لمس الجهاز (HFP) على trout، تم توسيع مواصفات جهاز الصوت VirtIO لتشمل عناصر التحكّم في الصوت. باستخدام هذا الأسلوب، يوفّر جهاز صوت VirtIO على جانب المضيف/مراقب الأجهزة الافتراضية عناصر التحكّم الثلاثة التالية في الصوت المرتبطة ببروتوكول HFP:
hfp_enablehfp_set_sampling_ratehfp_volume
عندما يتم تشغيل AAOS كآلة افتراضية للضيف، يستخدم AAOS TinyAlsa لضبط عناصر التحكّم في الصوت هذه. لتفعيل حالة استخدام HFP، ينفّذ المضيف/برنامج الإشراف التوجيه والمعايرة الخاصَّين بالمورّد وفقًا لذلك.
تستند عملية تنفيذ البلوتوث إلى رسم التصميم أدناه.
Dumpstate
عند إنشاء تقرير الأخطاء لنظام التشغيل Android Automotive OS المحاكى، من المفيد تضمين معلومات حول الجهاز الظاهري المضيف
ليتمكّن المطوّرون من الحصول على نظرة أكثر شمولاً على النظام. لتحقيق ذلك، ينفّذ التنفيذ المرجعي trout واجهة HAL IDumpstateDevice التي تجمع معلومات الجهاز الظاهري المضيف من خلال 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
نظام العرض الموسّع (EVS)
يُستخدَم نظام العرض الموسّع (EVS) لعرض الفيديو الذي تم التقاطه بواسطة كاميرات الرؤية الخلفية وكاميرات العرض المحيطي. في AAOS المحاكي، يمكن لمجموعة برامج EVS الوصول إلى بث الفيديو من جهاز البث V4L2 المحاكي الذي يستخدم برنامج تشغيل VirtIO-video.
وضع "المرآب"
لمزيد من المعلومات، اطّلِع على وضع "المرآب".
يتم تفعيل وضع "المرآب" وإيقافه من خلال خصائص AP_POWER_STATE_REQ التي يرسلها طبقة تجريد الأجهزة في المركبة. في وضع المحاكاة الافتراضية، يتم تفعيل "وضع المرآب" من جانب الجهاز المضيف.
يجب أن يظل الجهاز الافتراضي المضيف قيد التشغيل لتوفير أجهزة افتراضية لجهاز Android الافتراضي إلى أن يتم إيقاف Android. يرسل خادم VHAL على الجهاز الافتراضي المضيف إشارة الإيقاف إلى الجهاز الافتراضي الضيف AAOS.
عند تلقّي إشارة عميل VHAL، تنتقل الآلة الافتراضية AAOS إلى "وضع المرآب" وتبدأ في إرسال إشارات نبضات القلب
لإبقاء الآلة الافتراضية المضيفة نشطة.
النظام العالمي لتحديد المواقع عبر الأقمار الصناعية (GNSS)
في الإصدار 1.0 من trout، تمت إضافة إمكانية محاكاة نظام GNSS عبر virtio-console. يتيح التنفيذ تبادل القياسات الأولية وإصلاحات الموقع الجغرافي من المضيف إلى الجهاز الضيف.
تنسيق تبادل البيانات هو ملف CSV الذي يستخدمه تطبيق GnssLogger. في التنفيذ المرجعي،
بما أنّ برنامج تشغيل GNSS الأصلي غير متوفّر، يتم توفير بيانات وهمية، ولكن يمكن تنفيذ برنامج تشغيل أصلي
بدون أي تغييرات من جهة الضيف. يتم توفير عيّنة من وكيل المضيف الوهمي كجزء من رمز المصدر trout.
يتوقّع التنفيذ الحالي أن يتم التعامل مع تهيئة GNSS وAGNSS من خلال بيئة نظام التشغيل المضيف.
الرسومات
عند تشغيل AAOS كجهاز افتراضي ضيف إلى جانب أنظمة تشغيل أخرى خاصة بالسيارات، قد لا يتمكّن نظام التشغيل Android من الوصول مباشرةً إلى وحدة معالجة الرسومات أو وحدة التحكّم في الشاشة. في هذه الحالة، يمكن استخدام Mesa أو goldfish-opengl وبرنامج تشغيل virtio-gpu على الجهاز الافتراضي Android وvirtio-gpu للوصول إلى وحدة معالجة الرسومات.
على جهاز Android الظاهري للضيف، يشفّر Mesa أو goldfish-opengl أوامر OpenGLES إما
في بث Gallium أو بث GLES من إنشاء تلقائي، على التوالي. يتم استخدام برنامج تشغيل النواة virtio-gpu كوسيلة نقل. من جهة المضيف، يعيد virglrenderer (لـ Mesa) وvulkan-cereal (لـ goldfish-opengl) تشغيل دفق الأوامر الذي تم فك ترميزه فوق برنامج تشغيل وحدة معالجة الرسومات الحالي. تتوافق المنصة المرجعية لنظام التشغيل Android Automotive OS (AAOS) trout مع OpenGL ES
فقط، ومن المتوقّع أن تتوافق مع Vulkan في إصدار مستقبلي.
أجهزة الاستشعار
عند تشغيل AAOS كجهاز افتراضي للضيف إلى جانب أنظمة تشغيل أخرى خاصة بالسيارات، قد لا يتمكّن Android من الوصول مباشرةً إلى أجهزة الاستشعار. في هذه الحالة، يتم استخدام برنامج تشغيل Virtio-SCMI على الجهاز الافتراضي Android والوصول إلى أدوات الاستشعار باستخدام جهاز VirtIO-SCMI على الجهاز الافتراضي المضيف. توفر منصة AAOS المرجعية للمحاكاة الافتراضية Sensor HAL عامًا ومستقلاً عن الأجهزة يمكن استخدامه مع أنظمة على شرائح ARM للوصول إلى المستشعرات.
يتواصل Sensor HAL مع برنامج تشغيل IIO SCMI في نظام Linux الفرعي IIO، الذي يستخدم بروتوكول إدارة أجهزة الاستشعار SCMI الذي توفّره مواصفات ARM System Control and Management Interface (SCMI) لاكتشاف أجهزة الاستشعار وضبطها وقراءة بيانات جهاز الاستشعار وتلقّي إشعارات بشأن التغييرات في قيمها.
يستخدم برنامج تشغيل IIO SCMI برنامج تشغيل VirtIO SCMI، الذي يستخدم بروتوكول نقل VirtIO كما هو محدّد في مواصفات virtio-scmi لتبادل رسائل SCMI مع جهاز VirtIO SCMI على الجهاز الافتراضي المضيف. يمكن لجهاز VirtIO
SCMI الوصول مباشرةً إلى أدوات الاستشعار من خلال برامج تشغيل أدوات الاستشعار الخاصة بنظام التشغيل على الشريحة.
موقع طبقة تجريد الأجهزة للمستشعر
يقع التنفيذ المرجعي لطبقة تجريد الأجهزة (HAL) الخاصة بأجهزة الاستشعار، والتي تستخدم VirtIO SCMI، في
device/google/trout/hal/sensors.
إعدادات طبقة تجريد الأجهزة الخاصة بأجهزة الاستشعار
قد يحتاج Sensor HAL إلى تعديل بيانات جهاز الاستشعار التي تم تلقّيها من الجهاز الظاهري المضيف للامتثال لنظام إحداثيات مستشعر السيارة في 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>
طبقة تجريد الأجهزة في المركبة
يتألف تنفيذ طبقة تجريد الأجهزة في المركبة من مكوّنين:
- العميل: توفير واجهات برمجة التطبيقات التي يستخدمها Android في AAOS المحاكى
- الخادم: يتواصل مباشرةً مع الأجهزة، مثل ناقلات المركبات (أو المحاكي).
في المحاكاة الافتراضية، يتم تشغيل خادم VHAL على الجهاز الافتراضي المضيف. يتواصل كل من خادم 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.
الأنظمة الفرعية الأخرى
توفّر VirtIO حاليًا واجهة محدّدة جيدًا للمكوّنات، مثل Block Storage وNetwork وConsole وInput وSocket وEntropy. بالنسبة إلى الأنظمة الفرعية هذه، يستخدم نظام التشغيل Android Automotive (AAOS) برنامج التشغيل كما هو، مثل virtio-blk وvirtio-input وvirtio-console وvirtio-net.
في المنصة المرجعية AAOS المحاكية، تتوفّر شبكة Wi-Fi مع mac80211_hwsim لإتاحة شبكة VirtWifi لاسلكية، والتي تستخدم بعد ذلك اتصال نفَقي virtio-net لإرسال حركة بيانات الشبكة إلى الجهاز الظاهري المضيف الذي يمكنه الوصول مباشرةً إلى شبكة Wi-Fi الفعلية.