التنفيذ المرجعي

نوفّر تنفيذًا مرجعيًا لواجهة AIDL VHAL. يتم تنفيذ سلسلة تعليمات الخدمة الرئيسية في VehicleService.cpp. يقع تنفيذ واجهة VHAL في DefaultVehicleHal.cpp.

يستند التنفيذ المرجعي إلى بنية ذات طبقتين. في الطبقة العليا، DefaultVehicleHal، يتم تنفيذ واجهة AIDL الخاصة بطبقة تجريد الأجهزة في المركبات (VHAL) وتوفير منطق VHAL العام لجميع أجهزة الأجهزة. في الطبقة السفلية، FakeVehicleHardware، يتم تنفيذ واجهة IVehicleHardware. يحاكي هذا الصف منطق VHAL للتفاعل مع الأجهزة الفعلية أو ناقل بيانات المركبة، وهو خاص بالجهاز. يمكن للمورّدين اختياريًا استخدام البنية نفسها وإعادة استخدام فئة DefaultVehicleHal نفسها (مع توسيعها لتجاوز إحدى الطرق) وتوفير تنفيذ IVehicleHardware الخاص بهم.

التنفيذ المرجعي لواجهة برمجة تطبيقات VHAL
الشكل 1. التنفيذ المرجعي لواجهة برمجة تطبيقات VHAL

يتضمّن DefaultVehicleHal المنطق التالي الذي يُعدّ عامًا ويمكن تطبيقه على أي عملية تنفيذ لواجهة VHAL.

  • تنفّذ هذه الفئة واجهة IVehicle.
  • تُجري عمليات التحقّق الأساسية من الإدخالات، بما في ذلك التحقّق من المعرّفات المكرّرة.
  • تخصّص هذه السمة عناصر العميل (مثل GetValuesClient) لكل عملية لكل عميل من عملاء Binder، وتضيف كل عنصر إلى مجموعة عامة.
  • تدير هذه السمة منطق عمليات معاودة الاتصال غير المتزامنة، مثل إضافة طلب في انتظار المراجعة إلى مجموعة طلبات في انتظار المراجعة. يحلّ هذا الإجراء الطلبات المعلّقة عندما نتلقّى النتائج أو يعرض رسالة خطأ عند انتهاء المهلة المحدّدة لأحد الطلبات المعلّقة.
  • تتم عملية التسلسل وإلغاء التسلسل لـ LargeParcelable (راجِع ParcelableUtils.h).
  • إدارة الاشتراك (راجِع SubscriptionManager.h)
  • للتحقّق من الأذونات (اطّلِع على الدالتَين checkReadPermission وcheckWritePermission).
  • يستدعي الدالة IVehicleHardware.checkHealth بشكل دوري ويرسل إشارات نبض القلب (راجِع الدالة checkHealth).

‫IVehicleHardware هي واجهة عامة تُستخدَم لتمثيل التنفيذ الخاص بالأجهزة في VHAL. تكون عملية التنفيذ المرجعية لـ IVehicleHardware هي FakeVehicleHardware، التي تستخدم خريطة في الذاكرة لتخزين قيمة السمة ولا تتواصل مع ناقل مركبة فعلي. وهو مصمّم للتشغيل على محاكي ولا يتضمّن أي تبعيات خاصة بالأجهزة. يجب ألا تستخدم عمليات تنفيذ المورّدين هذه السمة كما هي، بل يجب إضافة منطق خاص بحافلة المركبة.

بدءًا من Android 14، يقرأ FakeVehicleHardware إعدادات الخصائص المتوافقة في وقت التشغيل أثناء عملية التهيئة من مجلد /vendor/etc/automotive/vhalconfig/ على الجهاز، والذي يحتوي على ملف إعداد بتنسيق JSON. راجِع ملف VHAL README المرجعي للاطّلاع على تنسيق ملف الإعداد ومحتواه.

تتيح FakeVehicleHardware أيضًا إمكانية تجاهل ملف الإعداد لأغراض الاختبار. إذا تم ضبط سمة النظام persist.vendor.vhal_init_value_override (يجب ضبط هذه السمة في مدّة التصميم أو في وقت مبكر جدًا أثناء تشغيل الجهاز قبل إعداد VHAL)، سيتم استخدام ملف إعداد من المجلد /vendor/etc/automotive/vhaloverride/ على الجهاز لتجاوز الإعداد الحالي. يمكن أن يستخدم تنفيذ المورّد أسلوبًا مشابهًا حتى لا يتم ترميز إعدادات الخصائص المتوافقة مع VHAL بشكل ثابت، ويمكن تحديدها بشكل ديناميكي في وقت البدء. يجب أن تكون قائمة إعدادات خصائص المركبة ثابتة بعد إعداد VHAL.

بدءًا من Android 16، يوفّر GRPCVehicleHardware مرجعًا آخر لتنفيذ IVehicleHardware. يفترض هذا التنفيذ وجود خادم منفصل يعمل على جهاز أو جهاز افتراضي بعيد يحتوي على منطق معالجة البيانات. تعمل طبقة تجريد الأجهزة في السيارة (VHAL) على أجهزة AAOS كخادم وكيل يعيد توجيه الطلبات إلى الخادم البعيد. لمزيد من التفاصيل، يُرجى الاطّلاع على grpc.