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

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

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

في بعض الحالات، تم الاستفادة من vsock للاتصال بين الأجهزة الافتراضية. يتم دعم اتصالات HAL للمركبة والتحكم في الصوت وDumpstate باستخدام اتصال بوكيل نظير على جهاز افتراضي منفصل عبر واجهة vsock . يتم استخدام GRPC-vsock للوصول إلى هذه الأنظمة الفرعية غير القياسية. تم تعديل GRPC في شجرة مصدر Android للعمل مع vsock بتنسيق عنوان vsock:CID:PORT_NUMBER .

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

صوتي

في 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 حتى يتم تحرير التركيز.

الهندسة الصوتية
الشكل 5. هندسة الصوت

بلوتوث

يعتمد تطبيق Bluetooth على التصميم الموضح أدناه.

بنية البلوتوث
الشكل 5. بنية البلوتوث

ملف تعريف بلوتوث بدون استخدام اليدين

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

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

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

يعتمد تطبيق Bluetooth على الرسم التوضيحي للتصميم أدناه.

بنية البلوتوث
الشكل 5. بنية البلوتوث

حالة تفريغ

عند إنشاء تقرير الأخطاء لـ AAOS الافتراضي، من المفيد تضمين معلومات الجهاز الظاهري المضيف حتى يكون لدى المطورين رؤية أكثر شمولاً للنظام. ولتحقيق ذلك، يطبق تطبيق مرجع trout IDumpstateDevice HAL، الذي يجمع معلومات VM المضيف من خلال 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)

يتم استخدام نظام العرض الممتد (EVS) لعرض الفيديو الذي تم التقاطه بواسطة كاميرات الرؤية الخلفية وكاميرات الرؤية المحيطية. في AAOS الافتراضي، يمكن لمكدس EVS الوصول إلى دفق الفيديو من جهاز البث V4L2 الافتراضي الذي يستخدم برنامج تشغيل الفيديو VirtIO.

وضع المرآب

لمزيد من المعلومات، راجع وضع المرآب .

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

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

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

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

يتوقع التنفيذ الحالي أن تتم معالجة تهيئة GNSS ومساعدة GNSS (AGNSS) بواسطة بيئة نظام التشغيل المضيف.

بنية الشبكات العالمية لسواتل الملاحة
الشكل 2. بنية GNSS

الرسومات

عندما يتم تشغيل AAOS كجهاز افتراضي ضيف جنبًا إلى جنب مع أنظمة تشغيل السيارات الأخرى، فقد لا يتمتع Android بإمكانية الوصول المباشر إلى وحدة معالجة الرسومات أو وحدة التحكم في العرض. في هذه الحالة، يمكن استخدام Mesa أو goldfish-opengl وبرنامج تشغيل virtio-gpu على جهاز Android VM الضيف وجهاز virtio-gpu للوصول إلى وحدة معالجة الرسومات.

على جهاز Android VM الضيف، يقوم Mesa أو goldfish-opengl بتشفير أوامر OpenGLES إما في تدفق Gallium أو تدفق GLES تم إنشاؤه تلقائيًا، على التوالي. يتم استخدام برنامج تشغيل kernel virtio-gpu نقل. على الجانب المضيف، يقوم virglrenderer (لـ Mesa) و vulkan-cereal (لـ goldfish-opengl ) بإعادة تشغيل دفق الأوامر التي تم فك تشفيرها أعلى برنامج تشغيل GPU الموجود. يدعم النظام الأساسي المرجعي trout AAOS برنامج OpenGL ES فقط مع دعم Vulkan، المتوقع في إصدار مستقبلي.

الهندسة المعمارية الرسومية
الشكل 3. بنية الرسومات

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

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

يتواصل مستشعر HAL مع برنامج تشغيل IIO SCMI في النظام الفرعي Linux Kernel IIO، والذي يستخدم بروتوكول إدارة مستشعر SCMI الذي توفره مواصفات واجهة التحكم والإدارة لنظام ARM (SCMI) لاكتشاف المستشعرات وتكوينها، وقراءة بيانات المستشعر، وإخطار المستشعر تغييرات القيمة.

يستخدم برنامج تشغيل IIO SCMI برنامج تشغيل VirtIO SCMI، الذي يستخدم بروتوكول نقل VirtIO كما هو محدد في مواصفات virtio-scmi لتبادل رسائل SCMI مع جهاز VirtIO SCMI على الجهاز الظاهري المضيف. يتمتع جهاز 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 .

يمكن لمصنعي المعدات الأصلية توفير تكوينات المستشعر، مثل الاتجاه والموقع، في 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 من عنصرين:

  • عميل. يوفر واجهات برمجة التطبيقات التي يستخدمها 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 بالفعل واجهة محددة جيدًا لمكونات مثل Block Storage، والشبكة، ووحدة التحكم، والإدخال، والمقبس، والإنتروبيا. بالنسبة لهذه الأنظمة الفرعية، يستخدم AAOS برنامج التشغيل كما هو، مثل virtio-blk و virtio-input و virtio-console و virtio-net .

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