حزمة HAL متعددة لأجهزة الاستشعار

‫Sensors Multi-HAL هو إطار عمل يسمح بتشغيل واجهات HAL لأجهزة الاستشعار مع واجهات HAL أخرى لأجهزة الاستشعار. تحمِّل حزمة HAL المتعددة لأجهزة الاستشعار بشكل ديناميكي حِزم HAL الفرعية لأجهزة الاستشعار المخزّنة كمكتبات ديناميكية في قسم المورّد، وتمنحها عنصر callback يمكنه معالجة نشر الأحداث واكتساب قفل الاستيقاظ وإلغاء قفله. واجهة HAL الفرعية لأجهزة الاستشعار هي واجهة HAL لأجهزة الاستشعار تم إنشاؤها في عنصر مشترَك على ملف تعريف "المورّد" ويستخدمها إطار عمل HAL المتعدّد. لا تعتمد وحدات HAL الفرعية هذه على بعضها البعض أو على رمز HAL المتعدّد الذي يحتوي على الدالة الرئيسية للعملية.

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

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

الفرق بين Sensors Multi-HAL 2 وSensors HAL 2

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

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

• تُمرِّر طريقة الإعداد فئة IHalProxyCallback بدلاً من فئتَي FMQ وISensorsCallback.
• يجب أن تُنفِّذ واجهات HAL الفرعية دالة لتصحيح الأخطاء من أجل تقديم معلومات تصحيح الأخطاء في تقارير الأخطاء.
• يجب أن تُنفِّذ وحدات HAL الفرعية دالة اسم حتى يمكن تمييز وحدة HAL الفرعية المحمَّلة عن وحدات HAL الفرعية الأخرى.

يكمن الاختلاف الرئيسي بين حزمة Sensors Multi-HAL 2 وحزمة Sensors HAL 2 في وظائف الإعداد. بدلاً من توفير طلبات FMQ، توفّر واجهة IHalProxyCallback طريقتَين، إحداهما لنشر أحداث أجهزة الاستشعار في إطار عمل أجهزة الاستشعار والأخرى لإنشاء عمليات قفل الاستيقاظ. في الخلفية، يدير "HAL المتعدّد للأجهزة الحسّاسة" جميع التفاعلات مع طلبات الجلسة القصيرة (FMQ) لضمان إرسال أحداث الأجهزة الحسّاسة في الوقت المناسب لجميع HAL الفرعية. ننصحك بشدة بأن تستخدم واجهات HAL الفرعية createScopedWakelock لتحديد مهلة قفل الاستيقاظ وتحميلها على واجهة HAL المتعددة لأجهزة الاستشعار، ومركزة استخدام قفل الاستيقاظ على قفل استيقاظ واحد لواجهة HAL المتعددة لأجهزة الاستشعار بالكامل، ما يقلل من عدد طلبات القفل وفتح القفل.

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

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

يتوفّر رمز Multi-HAL الخاص بجميع أدوات الاستشعار في hardware/interfaces/sensors/common/default/2.X/multihal/. في ما يلي بعض الإشارات إلى بعض المراجع.

• HalProxy.h: يتم إنشاء مثيل للكائن HalProxy من خلال حِزم HAL المتعددة الخاصة بأجهزة الاستشعار، ويتولى معالجة نقل البيانات من حِزم HAL الفرعية إلى إطار عمل أجهزة الاستشعار.
• ‫HalProxy.cpp: يحتوي تنفيذ HalProxy على كل المنطق المطلوب للقيام بعمليات معالجة متعدّدة للتواصل بين واجهات HAL الفرعية وإطار عمل أداة الاستشعار.

• SubHal.h: تحدِّد واجهة ISensorsSubHal الواجهة التي يجب أن يليها واجهة HAL الفرعية لتكون متوافقة مع HalProxy. تنفِّذ وحدة HAL الفرعية طريقة initialize لكي يمكن استخدام عنصر 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/: يستخدم مثال تنفيذ HAL الفرعي هذا أجهزة استشعار مزيفة لإنشاء data مزيفة. مفيد لاختبار كيفية تفاعل عدة واجهات HAL فرعية على جهاز.

التنفيذ

يوضّح هذا القسم كيفية تنفيذ حزمة HAL المتعددة لأجهزة الاستشعار في الحالات التالية:

• استخدام حِزم HAL متعددة لأجهزة الاستشعار مع حِزم HAL لأجهزة الاستشعار المستندة إلى واجهة برمجة التطبيقات (AIDL)
• تنفيذ Sensors Multi-HAL 2.1
• نقل البيانات من Sensors Multi-HAL 2.0 إلى Multi-HAL 2.1
• نقل البيانات من Sensors HAL 2.0
• نقل البيانات من Sensors HAL 1.0
• نقل البيانات من Sensors Multi-HAL 1.0

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

للسماح بإمكانية استخدام واجهات HAL متعددة مع حزمة HAL لأجهزة الاستشعار من AIDL، استورِد وحدة طبقة الحشو لواجهة HAL متعددة من AIDL، والتي يمكن العثور عليها في hardware/interfaces/sensors/aidl/default/multihal/. تعالج الوحدة عملية التحويل بين نوعَي تعريف HAL لأجهزة الاستشعار AIDL وHIDL، وتحدِّد حزمة حول واجهة HAL المتعدّدة الموضّحة في مقالة Implementing Sensors Multi-HAL 2.1. تتوافق طبقة الحشو لواجهة HAL المتعدّدة في AIDL مع الأجهزة التي توفّر حزمة Sensors Multi-HAL 2.1.

تسمح لك طبقة الحشو لواجهة HAL المتعدّدة في AIDL بعرض أداة تتبُّع حركة الرأس وأنواع أدوات استشعار IMU ذات المحاور المحدودة في واجهة HAL لأجهزة الاستشعار في AIDL. لاستخدام أنواع هذه الحساسات التي تحدّدها واجهة AIDL HAL، اضبط الحقل type في بنية SensorInfo في عملية تنفيذ getSensorsList_2_1(). وهذا الإجراء آمن لأنّ حقول نوع أجهزة الاستشعار المستندة إلى الأعداد الصحيحة في HAL لأجهزة استشعار AIDL وHIDL لا تتداخل.

تنفيذ Sensors 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 الذي يحتوي على قائمة واجهات HAL المتوافقة على الجهاز.

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.

نقل البيانات من Sensors 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 معها على أنّها واجهات HAL فرعية من الإصدار 2.1.

منفذ من Sensors HAL 2.0

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

بدء HAL

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

نشر أحداث المستشعرات في عملية تنفيذ Multi-HAL

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

أحداث WAKE_UP

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

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

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

منفذ من Sensors HAL 1.0

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

بدء HAL

يجب أن تكون دالة initialize() متوافقة لإنشاء دالة ردّ الاتصال بين HAL الفرعي وتنفيذ Multi-HAL.

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

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

نشر أحداث المستشعرات في عملية تنفيذ Multi-HAL

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

أحداث WAKE_UP

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

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

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

منفذ من Sensors 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. نقل واجهات HAL الفرعية كما هو موضّح في مقالة نقل البيانات من Sensors Hal 1.0
4. اضبط Sensors Multi-HAL 2.0 على أنّه HAL المحدّد باتّباع الخطوتَين 3 و 4 في قسم تنفيذ Sensors Mutli-HAL 2.0.

التحقُّق

تشغيل اختبار VTS

عند دمج حزمة HAL فرعية واحدة أو أكثر مع حزمة Sensors Multi-HAL 2.1، استخدِم مجموعة اختبار المورّد (VTS) للتأكّد من أنّ عمليات تنفيذ حزمة HAL الفرعية تستوفي جميع المتطلبات التي تحدّدها واجهة Sensors 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

إذا كنت تستخدم طبقة الحشو لـ Multi-HAL في AIDL، شغِّل 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

الاختبار باستخدام وحدات HAL الفرعية المزيّفة

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

يمكن استخدام واجهات HAL الفرعية المزيّفة لاختبار كيفية عمل رمز Multi-HAL الكامل مع واجهات HAL الفرعية الأخرى المحمَّلة في النظام ولاختبار جوانب مختلفة من رمز Sensors Multi-HAL.

يتوفّر اثنان من واجهتَي HAL وهميتين على الرابط hardware/interfaces/sensors/common/default/2.X/multihal/tests/fake_subhal/.

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

1. شغِّل الأوامر التالية لإنشاء ملفّات HAL فرعية اصطناعية مختلفة وثلاث ملفات HAL فرعية اصطناعية مختلفة وإرسالها إلى الجهاز:

   $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 باستخدام مسارات HAL الفرعية المزيّفة.

   /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 وحمِّل وحدات HAL الفرعية الجديدة المدرَجة في الإعدادات.

   adb shell stop
   adb shell start

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

يمكن للمطوّرين تصحيح أخطاء إطار العمل باستخدام الأمر lshal. لطلب إخراج تصحيح الأخطاء لواجهة HAL الخاصة بأجهزة الاستشعار، شغِّل الأمر التالي:

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

بعد ذلك، يتم ناتج المعلومات حول الحالة الحالية لـ HalProxy وواجهات HAL الفرعية في المحطة الطرفية. في ما يلي مثال على نتيجة الأمر المتعلّق بعنصر HalProxy وعناصر HAL الفرعية المزيّفة.

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.