مجسات Multi-HAL

أجهزة الاستشعار Multi-HAL عبارة عن إطار عمل يسمح لأجهزة الاستشعار HALs بالعمل جنبًا إلى جنب مع أجهزة الاستشعار الأخرى. تقوم أجهزة الاستشعار Multi-HAL بتحميل وحدات HAL الفرعية لأجهزة الاستشعار ديناميكيًا والمخزنة كمكتبات ديناميكية على قسم البائع وتمنحها كائن رد اتصال يمكنه التعامل مع أحداث النشر والحصول على قفل التنبيه وتحريره. طبقة HAL الفرعية للمستشعرات هي طبقة HAL لأجهزة الاستشعار المضمنة في كائن مشترك على قسم البائع ويتم استخدامها بواسطة إطار عمل HAL المتعدد. لا تعتمد مناطق HAL الفرعية هذه على بعضها البعض أو على رمز HAL المتعدد الذي يحتوي على الوظيفة الرئيسية للعملية.

أجهزة الاستشعار Multi-HAL 2.1، المتوفرة على الأجهزة التي تعمل بنظام التشغيل Android 11 أو أعلى، هي تكرار لأجهزة الاستشعار Multi-HAL 2.0 التي تدعم تحميل HALs الفرعية التي يمكنها كشف نوع مستشعر الزاوية المفصلية . لدعم هذا النوع من المستشعر، يجب أن تستخدم وحدات HAL الفرعية واجهات برمجة تطبيقات HAL الفرعية المحددة في رأس 2.1 SubHal .

بالنسبة للأجهزة التي تعمل بنظام التشغيل Android 13 أو الإصدارات الأحدث والتي تستخدم أجهزة الاستشعار AIDL HAL ، يمكنك استخدام طبقة الرقائق المتعددة HAL للسماح بقدرة HAL المتعددة. للحصول على تفاصيل التنفيذ، راجع استخدام أجهزة الاستشعار Multi-HAL مع أجهزة الاستشعار AIDL HAL .

الفرق بين حساسات Multi-HAL 2 وحساسات HAL 2

تقدم أجهزة الاستشعار Multi-HAL 2، المتوفرة على الأجهزة التي تعمل بنظام التشغيل Android 10 أو أعلى، العديد من التجريدات أعلى أجهزة الاستشعار HAL 2 لتسهيل التفاعل مع واجهات برمجة تطبيقات HAL. تقدم أجهزة الاستشعار Multi-HAL 2 فئة HalProxy للتعامل مع تنفيذ واجهة Sensors HAL 2 وواجهة V2_1/SubHal (أو V2_0/SubHal ) للسماح لـ HalProxy بالتفاعل مع HALs الفرعية.

تختلف واجهة ISensorsSubHal عن واجهة 2.1/ISensors.hal (أو 2.0/ISensors.hal ) بالطرق التالية:

  • يقوم أسلوب التهيئة بتمرير فئة IHalProxyCallback بدلاً من اثنين من FMQs و ISensorsCallback .
  • يجب أن تقوم وحدات HAL الفرعية بتنفيذ وظيفة تصحيح لتوفير معلومات تصحيح الأخطاء في تقارير الأخطاء.
  • يجب أن تقوم طبقات HAL الفرعية بتنفيذ وظيفة اسم بحيث يمكن تمييز طبقة HAL الفرعية المحملة عن مناطق HAL الفرعية الأخرى.

يكمن الاختلاف الرئيسي بين أجهزة الاستشعار Multi-HAL 2 وأجهزة الاستشعار HAL 2 في وظائف التهيئة. بدلاً من توفير FMQs، توفر واجهة IHalProxyCallback طريقتين، طريقة واحدة لنشر أحداث المستشعر إلى إطار عمل المستشعرات وطريقة واحدة لإنشاء أقفال التنبيه. تحت الغطاء، تدير أجهزة الاستشعار Multi-HAL جميع التفاعلات مع FMQs لضمان تسليم أحداث المستشعر في الوقت المناسب لجميع HALs الفرعية. من المستحسن بشدة أن تستخدم وحدات HAL الفرعية طريقة createScopedWakelock لتفويض عبء مهلة قفل التنشيط إلى أجهزة الاستشعار Multi-HAL ولتركيز استخدام قفل التنشيط على قفل تنشيط مشترك واحد لـ Sensors Multi-HAL بالكامل، مما يقلل من القفل وفتح القفل المكالمات.

تحتوي أجهزة الاستشعار Multi-HAL 2 أيضًا على بعض ميزات الأمان المدمجة. إنه يتعامل مع المواقف التي يكون فيها مستشعر FMQ ممتلئًا أو حيث يتم إعادة تشغيل إطار عمل مستشعر Android وتحتاج حالة المستشعر إلى إعادة التعيين. بالإضافة إلى ذلك، عندما يتم نشر الأحداث إلى فئة HalProxy ولكن إطار عمل المستشعر غير قادر على قبول الأحداث على الفور، يمكن لـ Sensors Multi-HAL نقل الأحداث إلى سلسلة رسائل خلفية للسماح بمواصلة العمل عبر جميع مناطق HAL الفرعية أثناء انتظار الأحداث ليتم نشرها.

كود المصدر وتنفيذ المرجع

يتوفر رمز Multi-HAL لجميع أجهزة الاستشعار في hardware/interfaces/sensors/common/default/2.X/multihal/ . فيما يلي مؤشرات لبعض الموارد.

  • HalProxy.h : يتم إنشاء كائن HalProxy بواسطة أجهزة الاستشعار متعددة HAL ويتعامل مع تمرير البيانات من HALs الفرعية إلى إطار عمل المستشعر.
  • HalProxy.cpp : يحتوي تطبيق HalProxy على كل المنطق اللازم للاتصالات المتعددة بين وحدات HAL الفرعية وإطار عمل المستشعر.
  • SubHal.h : تحدد واجهة ISensorsSubHal الواجهة التي يجب أن تتبعها شرائح HAL الفرعية لتكون متوافقة مع HalProxy . تطبق طبقة HAL الفرعية طريقة التهيئة بحيث يمكن استخدام كائن HalProxyCallback لـ postEvents و createScopedWakelock .

    بالنسبة لتطبيقات Multi-HAL 2.0، استخدم الإصدار 2.0 من SubHal.h .

  • hardware/interfaces/sensors/common/default/2.X/multihal/tests/ : تتحقق اختبارات الوحدة هذه من تنفيذ HalProxy .

  • hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/ : يستخدم هذا المثال لتطبيق sub-HAL أجهزة استشعار زائفة لإنشاء بيانات مزيفة. مفيد لاختبار كيفية تفاعل طبقات HAL المتعددة على الجهاز.

تطبيق

يصف هذا القسم كيفية تنفيذ أجهزة الاستشعار Multi-HAL في المواقف التالية:

استخدم أجهزة الاستشعار Multi-HAL مع أجهزة الاستشعار AIDL HAL

للسماح بقدرة HAL المتعددة مع أجهزة الاستشعار AIDL HAL، قم باستيراد وحدة طبقة الرقائق AIDL Multi-HAL، الموجودة في الأجهزة/الواجهات/أجهزة الاستشعار/aidl/default/multihal/ . تعالج الوحدة التحويل بين أنواع تعريف HAL ​​لمستشعرات AIDL وHIDL وتحدد غلافًا حول واجهة HAL المتعددة الموضحة في تنفيذ أجهزة الاستشعار Multi-HAL 2.1 . تتوافق طبقة الرقائق AIDL multi-HAL مع الأجهزة التي تستخدم Sensors Multi-HAL 2.1.

تسمح لك طبقة الرقائق AIDL multi-HAL بكشف جهاز تعقب الرأس وأنواع مستشعرات IMU ذات المحور المحدود في أجهزة الاستشعار AIDL HAL. لاستخدام أنواع المستشعرات المحددة بواسطة واجهة AIDL HAL، قم بتعيين حقل type في بنية SensorInfo في تطبيق getSensorsList_2_1() . يعد هذا آمنًا لأن حقول نوع المستشعر المدعومة بعدد صحيح لمستشعرات AIDL وHIDL HAL لا تتداخل.

تنفيذ أجهزة الاستشعار Multi-HAL 2.1

لتطبيق Sensors Multi-HAL 2.1 على جهاز جديد، اتبع الخطوات التالية:

  1. قم بتنفيذ واجهة ISensorsSubHal كما هو موضح في SubHal.h .
  2. تنفيذ أسلوب sensorsHalGetSubHal_2_1 في SubHal.h .
  3. قم بإضافة هدف cc_library_shared لإنشاء طبقة HAL الفرعية التي تم تنفيذها حديثًا. عند إضافة الهدف:

    1. تأكد من دفع الهدف إلى مكان ما على قسم البائع بالجهاز.
    2. في ملف التكوين الموجود في /vendor/etc/sensors/hals.conf ، أضف المسار إلى المكتبة في سطر جديد. إذا لزم الأمر، قم بإنشاء ملف hals.conf .

    للحصول على مثال لإدخال Android.bp لإنشاء مكتبة HAL فرعية، راجع hardware/interfaces/sensors/common/default/2.X/multihal/tests/Android.bp .

  4. قم بإزالة كافة إدخالات android.hardware.sensors من ملف manifest.xml ، الذي يحتوي على قائمة HALs المدعومة على الجهاز.

  5. قم بإزالة جميع ملفات خدمة android.hardware.sensors و service.rc من ملف device.mk وأضف android.hardware.sensors@2.1-service.multihal و android.hardware.sensors@2.1-service.multihal.rc إلى PRODUCT_PACKAGES .

عند التمهيد، يبدأ HalProxy ، ويبحث عن طبقة HAL الفرعية التي تم تنفيذها حديثًا، ويقوم بتهيئتها عن طريق استدعاء sensorsHalGetSubHal_2_1 .

المنفذ من أجهزة الاستشعار Multi-HAL 2.0 إلى Multi-HAL 2.1

للانتقال من Multi-HAL 2.0 إلى Multi-HAL 2.1، قم بتنفيذ واجهة SubHal وأعد ترجمة طبقة HAL الفرعية الخاصة بك.

هذه هي الاختلافات بين واجهات SubHal 2.0 و2.1:

  • يستخدم IHalProxyCallback الأنواع التي تم إنشاؤها في الإصدار 2.1 من مواصفات ISensors.hal .
  • تقوم وظيفة initialize() بتمرير IHalProxyCallback جديد بدلاً من ذلك الموجود في واجهة SubHal 2.0
  • يجب أن تقوم وحدات HAL الفرعية بتطبيق getSensorsList_2_1 و injectSensorData_2_1 بدلاً من getSensorsList و injectSensorData حيث تستخدم هذه الطرق الأنواع الجديدة المضافة في الإصدار 2.1 من مواصفات ISensors.hal .
  • يجب أن تعرض وحدات HAL الفرعية sensorsHalGetSubHal_2_1 بدلاً من sensorsHalGetSubHal لـ Multi-HAL لمعاملتها كإصدار 2.1 من وحدات HAL الفرعية.

منفذ من أجهزة الاستشعار HAL 2.0

عند الترقية إلى Sensors Multi-HAL 2.0 من Sensors HAL 2.0 ، تأكد من أن تنفيذ HAL يلبي المتطلبات التالية.

تهيئة HAL

تشتمل أجهزة الاستشعار HAL 2.0 على وظيفة تهيئة تسمح لخدمة المستشعر بتمرير FMQs واستدعاء مستشعر ديناميكي. في Sensors Multi-HAL 2.0، تقوم وظيفة initialize() بتمرير رد اتصال واحد يجب استخدامه لنشر أحداث المستشعر والحصول على أقفال التنبيه والإخطار باتصال المستشعر الديناميكي وقطع الاتصال.

نشر أحداث المستشعر في تطبيق Multi-HAL

بدلاً من نشر أحداث الاستشعار من خلال FMQ، يجب أن يكتب HAL الفرعي أحداث الاستشعار إلى IHalProxyCallback عندما تكون أحداث الاستشعار متوفرة.

أحداث WAKE_UP

في أجهزة الاستشعار HAL 2.0، يمكن لـ HAL إدارة قفل التنبيه لتنفيذه. في أجهزة الاستشعار Multi-HAL 2.0، تسمح وحدات HAL الفرعية لتطبيق Multi-HAL بإدارة أقفال التنشيط ويمكن طلب الحصول على قفل التنشيط عن طريق استدعاء createScopedWakelock . يجب الحصول على قفل تنبيه مقفل النطاق وتمريره إلى postEvents عند نشر أحداث التنبيه إلى تطبيق Multi-HAL.

أجهزة الاستشعار الديناميكية

تتطلب أجهزة الاستشعار Multi-HAL 2.0 أن يتم استدعاء onDynamicSensorsConnected و onDynamicSensorsDisconnected في IHalProxyCallback عندما تتغير اتصالات المستشعر الديناميكي. تتوفر عمليات الاسترجاعات هذه كجزء من مؤشر IHalProxyCallback الذي يتم توفيره من خلال وظيفة initialize() .

منفذ من أجهزة الاستشعار HAL 1.0

عند الترقية إلى Sensors Multi-HAL 2.0 من Sensors HAL 1.0 ، تأكد من أن تنفيذ HAL يلبي المتطلبات التالية.

تهيئة HAL

يجب دعم وظيفة initialize() لتأسيس رد الاتصال بين تطبيق HAL الفرعي وتطبيق Multi-HAL.

فضح أجهزة الاستشعار المتاحة

في Sensors Multi-HAL 2.0، يجب أن تقوم الدالة getSensorsList() بإرجاع نفس القيمة أثناء تشغيل جهاز واحد، حتى عبر أجهزة الاستشعار التي يتم إعادة تشغيلها. يسمح هذا لإطار العمل بمحاولة إعادة إنشاء اتصالات المستشعر في حالة إعادة تشغيل خادم النظام. يمكن أن تتغير القيمة التي يتم إرجاعها بواسطة getSensorsList() بعد قيام الجهاز بإعادة التشغيل.

نشر أحداث المستشعر في تطبيق Multi-HAL

في Sensors HAL 2.0، بدلاً من انتظار استدعاء poll() ، يجب على HAL الفرعي كتابة أحداث المستشعر بشكل استباقي إلى IHalProxyCallback عندما تتوفر أحداث المستشعر.

أحداث WAKE_UP

في أجهزة الاستشعار HAL 1.0، يمكن لـ HAL إدارة قفل التنبيه لتنفيذه. في أجهزة الاستشعار Multi-HAL 2.0، تسمح وحدات HAL الفرعية لتطبيق Multi-HAL بإدارة أقفال التنشيط ويمكن طلب الحصول على قفل التنشيط عن طريق استدعاء createScopedWakelock . يجب الحصول على قفل تنبيه مقفل النطاق وتمريره إلى postEvents عند نشر أحداث التنبيه إلى تطبيق Multi-HAL.

أجهزة الاستشعار الديناميكية

في Sensors HAL 1.0، يتم إرجاع المستشعرات الديناميكية من خلال وظيفة poll() . تتطلب أجهزة الاستشعار Multi-HAL 2.0 أن يتم استدعاء onDynamicSensorsConnected و onDynamicSensorsDisconnected في IHalProxyCallback عندما تتغير اتصالات المستشعر الديناميكي. تتوفر عمليات الاسترجاعات هذه كجزء من مؤشر IHalProxyCallback الذي يتم توفيره من خلال وظيفة initialize() .

منفذ من أجهزة الاستشعار Multi-HAL 1.0

لنقل تطبيق موجود من Sensors Multi-HAL 1.0 ، اتبع الخطوات التالية.

  1. تأكد من وجود تكوين HAL للمستشعرات في /vendor/etc/sensors/hals.conf. قد يتضمن ذلك نقل الملف الموجود في /system/etc/sensors/hals.conf .
  2. قم بإزالة أية إشارات إلى hardware/hardware.h و hardware/sensors.h حيث إنها غير مدعومة لـ HAL 2.0.
  3. منفذ HALs الفرعي كما هو موضح في النقل من أجهزة الاستشعار Hal 1.0 .
  4. قم بتعيين أجهزة الاستشعار Multi-HAL 2.0 باعتبارها HAL المعينة باتباع الخطوتين 3 و4 في قسم تنفيذ أجهزة الاستشعار Mutli-HAL 2.0 .

تصديق

قم بتشغيل خدمة VTS

عندما تقوم بدمج واحدة أو أكثر من مناطق HAL الفرعية مع أجهزة الاستشعار Multi-Hal 2.1، استخدم مجموعة اختبار البائع (VTS) للتأكد من أن تطبيقات HAL الفرعية الخاصة بك تلبي جميع المتطلبات التي حددتها واجهة أجهزة الاستشعار HAL.

لتشغيل اختبارات VTS للمستشعرات فقط عند إعداد VTS على جهاز مضيف، قم بتنفيذ الأوامر التالية:

vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_0Target && \
  vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsHalSensorsV2_1Target

إذا كنت تقوم بتشغيل طبقة الرقائق AIDL Multi-HAL، فقم بتشغيل VtsAidlHalSensorsTargetTest .

vts-tradefed run commandAndExit vts \
    --skip-all-system-status-check \
    --primary-abi-only \
    --skip-preconditions \
    --module VtsAidlHalSensorsTargetTest

تشغيل اختبارات الوحدة

تقوم اختبارات الوحدة في HalProxy_test.cpp باختبار HalProxy باستخدام طبقات HAL الفرعية المزيفة التي تم إنشاء مثيل لها في اختبار الوحدة ولم يتم تحميلها ديناميكيًا. عند إنشاء طبقة HAL فرعية جديدة، يجب أن تكون هذه الاختبارات بمثابة دليل حول كيفية إضافة اختبارات الوحدة التي تتحقق من تنفيذ طبقة HAL الفرعية الجديدة بشكل صحيح.

لإجراء الاختبارات، قم بتنفيذ الأوامر التالية:

cd $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests
atest

اختبار مع HALs الفرعية وهمية

تعد وحدات HAL الفرعية المزيفة تطبيقات وهمية لواجهة ISensorsSubHal . تعرض HALs الفرعية قوائم مختلفة من أجهزة الاستشعار. عندما يتم تنشيط المستشعرات، فإنها تنشر بشكل دوري أحداث المستشعر التي تم إنشاؤها تلقائيًا إلى HalProxy بناءً على الفواصل الزمنية المحددة في طلب مستشعر معين.

يمكن استخدام شرائح HAL الفرعية المزيفة لاختبار كيفية عمل كود Multi-HAL الكامل مع شرائح HAL الفرعية الأخرى المحملة في النظام وللتأكيد على الجوانب المختلفة لرمز Multi-HAL الخاص بالمستشعرات.

يتوفر اثنان من HALs الفرعية المزيفة في hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/ .

لإنشاء شرائح HAL الفرعية المزيفة ودفعها إلى جهاز، قم بتنفيذ الخطوات التالية:

  1. قم بتشغيل الأوامر التالية لإنشاء ودفع ثلاث شرائح فرعية وهمية مختلفة إلى الجهاز:

    $ANDROID_BUILD_TOP/hardware/interfaces/sensors/common/default/2.X/multihal/tests/
    mma
    adb push \
      $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so \
      /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
    adb push \
      $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so \
      /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
    adb push \
      $ANDROID_BUILD_TOP/out/target/product/<device>/symbols/vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so \
      /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so
    
  2. قم بتحديث تكوين HAL للمستشعرات على /vendor/etc/sensors/hals.conf باستخدام مسارات HALs الفرعية المزيفة.

    /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config1.so
    /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config2.so
    /vendor/lib64/android.hardware.sensors@2.X-fakesubhal-config3.so
    
  3. أعد تشغيل HalProxy وقم بتحميل HALs الفرعية الجديدة المدرجة في ملف التكوين.

    adb shell stop
    adb shell start
    

تصحيح الأخطاء

يمكن للمطورين تصحيح إطار العمل باستخدام الأمر lshal . لطلب إخراج التصحيح لـ Sensors HAL، قم بتشغيل الأمر التالي:

adb root
adb shell lshal debug android.hardware.sensors@2.1::ISensors/default

يتم بعد ذلك إخراج المعلومات حول الحالة الحالية لـ HalProxy وHALs الفرعية الخاصة به إلى الجهاز. يظهر أدناه مثال على إخراج الأمر لكائن HalProxy وHALs الفرعية المزيفة.

Internal values:
  Threads are running: true
  Wakelock timeout start time: 200 ms ago
  Wakelock timeout reset time: 73208 ms ago
  Wakelock ref count: 0
  # of events on pending write queue: 0
  # of non-dynamic sensors across all subhals: 8
  # of dynamic sensors across all subhals: 0
SubHals (2):
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2
  Name: FakeSubHal-OnChange
  Debug dump:
Available sensors:
Name: Ambient Temp Sensor
Min delay: 40000
Flags: 2
Name: Light Sensor
Min delay: 200000
Flags: 2
Name: Proximity Sensor
Min delay: 200000
Flags: 3
Name: Relative Humidity Sensor
Min delay: 40000
Flags: 2

إذا كان الرقم المحدد لعدد # of events on pending write queue هو رقم كبير (1000 أو أكثر)، فهذا يشير إلى أن هناك العديد من الأحداث المعلقة ليتم كتابتها في إطار عمل المستشعرات. يشير هذا إلى أن خدمة المستشعر وصلت إلى طريق مسدود أو تعطلت ولا تقوم بمعالجة أحداث المستشعر، أو أنه تم نشر مجموعة كبيرة من أحداث المستشعر مؤخرًا من طبقة HAL فرعية.

إذا كان عدد مرجع قفل التنشيط أكبر من 0 ، فهذا يعني أن HalProxy قد حصل على قفل التنشيط. يجب أن يكون هذا أكبر من 0 فقط إذا تم تعليق ScopedWakelock عن قصد أو إذا تم إرسال أحداث التنبيه إلى HalProxy ولم تتم معالجتها بواسطة إطار عمل المستشعر.

يتم تمرير واصف الملف الذي تم تمريره إلى أسلوب التصحيح الخاص بـ HalProxy إلى كل طبقة HAL فرعية، لذلك يجب على المطورين تنفيذ أسلوب التصحيح كجزء من واجهة ISensorsSubHal .