هندسة معمارية

تتضمّن معظم التغييرات اللازمة لدعم VirtIO في AAOS تغييرات على مستوى تنفيذ HAL وما دونه في Android Common Kernel. يتواصل إطار عمل Android مع HAL عام لا يعتمد على الأجهزة باستخدام برامج تشغيل VirtIO في النواة الخاصة بالجهاز الافتراضي المستضاف على AAOS، والتي تتواصل مع أجهزة VirtIO على جانب المضيف باستخدام بروتوكولات VirtIO. يمكن لأجهزة VirtIO على جانب المضيف الوصول إلى الأجهزة المادية باستخدام برامج تشغيل الأجهزة الخاصة بنظام SoC.

يتم التواصل بين برنامج تشغيل VirtIO وجهاز VirtIO باستخدام virtqueue، وهي مخازن مؤقتة حلقية تشبه الوصول المباشر إلى الذاكرة (DMA) لقوائم التجميع والتشتيت. يمكن استخدام العديد من عمليات النقل، مثل MMIO أو PCI ، لتبادل رسائل VirtIO بين الأجهزة الافتراضية.

في بعض الحالات، يتم استخدام vsock للتواصل بين الأجهزة الافتراضية. يتم دعم الاتصالات بين Vehicle HAL (VHAL) وAudio Control وDumpstate باستخدام اتصال بعميل نظير على جهاز افتراضي منفصل عبر واجهة vsock. ويتم استخدام gRPC عبر vsock للوصول إلى هذه الأنظمة الفرعية غير الموحّدة. يتم تعديل gRPC في شجرة مصدر Android للعمل مع vsock بتنسيق العنوان vsock:CID:PORT_NUMBER.

بنية المحاكاة الافتراضية

الشكل 1: بنية المحاكاة الافتراضية

الصوت

في AAOS المحاكى افتراضيًا، يمكن للجهاز الافتراضي المستضاف على Android استخدام virtio-snd للوصول إلى الصوت. توفّر virtio-snd أجهزة PCM المحاكية افتراضيًا لجهاز Android الافتراضي حتى يتمكّن تنفيذ 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 الخاص بالتحكّم في الصوت التطبيقات التي تشغّل الموسيقى بكتم الصوت في هذه الحالة. في النظام المحاكى افتراضيًا، يمكن أن تأتي الأصوات من أجهزة افتراضية أخرى. في التنفيذ المرجعي، يتضمّن الجهاز الافتراضي المستضاف على نظام التشغيل Android Automotive ‏(AAOS) برنامجًا خفيًا لخادم التحكّم في الصوت، والذي يستخدم gRPC عبر vsock لتلقّي طلبات أولويّة الصوت من الأجهزة الافتراضية الأخرى. يمكن للجهاز الافتراضي المضيف استخدام device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller لإرسال طلبات التحكّم في الصوت إلى AAOS. طالما أنّ libandroid_audio_controller يحافظ على أولويّة الصوت، فإنّه يواصل إرسال إشارات دورية إلى نظام التشغيل Android Automotive ‏(AAOS) إلى أن يتم تحرير التركيز.

بنية الصوت

الشكل 2: بنية الصوت

بلوتوث

يوضّح الشكل التالي تنفيذ البلوتوث:

بنية البلوتوث

الشكل 3: بنية البلوتوث

ملف البلوتوث بدون لمس الجهاز

لتفعيل ملف البلوتوث بدون لمس الجهاز (HFP) على trout، تم توسيع مواصفات جهاز الصوت VirtIO لدعم عناصر التحكّم في الصوت. باستخدام هذا النهج، يوفّر جهاز الصوت VirtIO على جانب المضيف/مراقب الأجهزة الافتراضية ثلاثة عناصر تحكّم في الصوت ذات صلة بملف البلوتوث بدون لمس الجهاز:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

عند تشغيل AAOS كجهاز افتراضي مستضاف، يستخدم AAOS مكتبة TinyALSA لضبط عناصر التحكّم في الصوت هذه. لتفعيل حالة استخدام HFP، ينفّذ المضيف/مراقب الأجهزة الافتراضية التوجيه والمعايرة الخاصين بمورّد الجهاز وفقًا لذلك.

يستند تنفيذ البلوتوث إلى الرسم التوضيحي للتصميم التالي:

بنية البلوتوث

الشكل 4: بنية البلوتوث

Dumpstate

عند إنشاء تقرير الأخطاء لـ AAOS المحاكى افتراضيًا، من المفيد تضمين معلومات الجهاز الافتراضي المضيف حتى يتمكّن المطوّرون من الحصول على عرض أكثر شمولاً للنظام. لتحقيق ذلك، ينفّذ التنفيذ المرجعي لـ trout واجهة IDumpstateDevice HAL، التي تجمع معلومات الجهاز الافتراضي المضيف من خلال gRPC عبر vsock. يُطلق على معلومات الجهاز الافتراضي المضيف المجمّعة بتنسيق 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) الفيديو الذي تلتقطه الكاميرات الخلفية وكاميرات العرض الشامل. في AAOS المحاكى افتراضيًا، يمكن لمجموعة EVS الوصول إلى بث الفيديو من جهاز البث المحاكى افتراضيًا V4L2 الذي يستخدم برنامج تشغيل VirtIO-video.

وضع المرآب

يتم تفعيل وضع المرآب والخروج منه من خلال خصائص AP_POWER_STATE_REQ التي يرسلها VHAL. في وضع المحاكاة الافتراضية، يتم تفعيل وضع المرآب من جانب المضيف. يجب أن يظل الجهاز الافتراضي المضيف قيد التشغيل لتوفير أجهزة افتراضية لجهاز Android الافتراضي إلى أن يتم إيقاف تشغيل Android. يرسل خادم VHAL على الجهاز الافتراضي المضيف إشارة الإيقاف إلى الجهاز الافتراضي المستضاف على AAOS. عند تلقّي إشارة عميل VHAL، يدخل جهاز AAOS الافتراضي وضع المرآب ويبدأ في إرسال إشارات نبض للحفاظ على نشاط الجهاز الافتراضي المضيف. لمزيد من المعلومات، يُرجى الاطّلاع على وضع المرآب.

النظام العالمي للملاحة عبر الأقمار الصناعية (GNSS)

في trout 1.0، يتم تضمين دعم المحاكاة الافتراضية لنظام GNSS عبر virtio-console. يتيح التنفيذ تبادل القياسات الأولية وإصلاحات الموقع الجغرافي من المضيف إلى الجهاز المستضاف.

تنسيق تبادل البيانات هو ملف CSV الذي يستخدمه تطبيق GNSSLogger. في التنفيذ المرجعي، لا يتوفّر برنامج تشغيل GNSS الأصلي، لذا تتوفّر بيانات وهمية. يمكنك تنفيذ برنامج تشغيل أصلي بدون إجراء أي تغييرات على جانب الجهاز المستضاف. يتم توفير نموذج لعميل مضيف وهمي كجزء من شفرة مصدر trout.

يتوقّع التنفيذ أن يتولّى نظام التشغيل المضيف عملية تهيئة نظام GNSS وGNSS المعزّز (AGNSS).

بنية GNSS

الشكل 5: بنية نظام GNSS

الرسومات

عند تشغيل 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) تشغيل بث الأوامر الذي تم فك تشفيره فوق برنامج تشغيل وحدة معالجة الرسومات الحالية. تتوافق منصة trout المرجعية لـ AAOS مع OpenGL ES فقط، ومن المتوقّع أن يتم توفير دعم Vulkan في إصدار مستقبلي.

بنية الرسومات

الشكل 6: بنية الرسومات

أجهزة الاستشعار

عند تشغيل AAOS كجهاز افتراضي مستضاف إلى جانب أنظمة تشغيل أخرى للسيارات، قد لا يتمكّن Android من الوصول مباشرةً إلى أجهزة الاستشعار. في هذه الحالة، يمكنك الوصول إلى أجهزة الاستشعار باستخدام برنامج تشغيل Virtio-SCMI على جهاز Android الافتراضي المستضاف وجهاز VirtIO-SCMI على الجهاز الافتراضي المضيف. توفّر منصة المحاكاة الافتراضية المرجعية لـ AAOS واجهة HAL عامة لأجهزة الاستشعار لا تعتمد على الأجهزة، ويمكنك استخدامها لأنظمة SoC المستندة إلى ARM للوصول إلى أجهزة الاستشعار.

يتواصل HAL الخاص بأجهزة الاستشعار مع برنامج تشغيل IIO SCMI في نظام Linux Kernel IIO الفرعي، الذي يستخدم بروتوكول إدارة أجهزة استشعار SCMI الذي توفّره مواصفات ARM System Control and Management Interface (SCMI) لاكتشاف أجهزة الاستشعار وضبطها وقراءة بيانات أجهزة الاستشعار وتلقّي إشعارات بشأن تغييرات قيم أجهزة الاستشعار.

يستخدم برنامج تشغيل IIO SCMI برنامج تشغيل VirtIO SCMI، الذي يستخدم بروتوكول نقل VirtIO في مواصفات virtio-scmi لتبادل رسائل SCMI مع جهاز VirtIO SCMI على الجهاز الافتراضي المضيف. يمكن لجهاز VirtIO SCMI الوصول مباشرةً إلى أجهزة الاستشعار من خلال برامج تشغيل أجهزة الاستشعار الخاصة بنظام SoC.

بنية أداة الاستشعار

الشكل 7: بنية أجهزة الاستشعار

موقع HAL الخاص بأجهزة الاستشعار

يقع التنفيذ المرجعي لـ HAL الخاص بأجهزة الاستشعار، الذي يستخدم VirtIO SCMI، في device/google/trout/hal/sensors.

إعداد HAL الخاص بأجهزة الاستشعار

قد يحتاج 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>

Vehicle HAL

يتألف تنفيذ طبقة تجريد الأجهزة في المركبة (VHAL) من مكوّنين:

  • العميل يوفّر واجهات برمجة التطبيقات التي يستخدمها 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.

الأنظمة الفرعية الأخرى

توفّر VirtIO حاليًا واجهة محدّدة جيدًا للمكوّنات، مثل مساحة التخزين على مستوى الكتلة والشبكة ووحدة التحكّم والإدخال والمقبس والإنتروبيا. بالنسبة إلى هذه الأنظمة الفرعية، يستخدم AAOS برنامج التشغيل كما هو، مثل virtio-blk وvirtio-input وvirtio-console وvirtio-net.

في المنصة المرجعية لـ AAOS المحاكى افتراضيًا، يتم دعم شبكة Wi-Fi باستخدام mac80211_hwsim لتفعيل شبكة لاسلكية VirtWifi، التي تستخدم بعد ذلك نفق virtio-net لإرسال حركة بيانات الشبكة إلى الجهاز الافتراضي المضيف، الذي يمكنه الوصول مباشرةً إلى شبكة Wi-Fi الفعلية.