تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

مستشعرات متعددة طبقة تجريد الأجهزة (HAL)

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

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

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

الفرق بين أجهزة الاستشعار Multi-HAL 2 وأجهزة الاستشعار HAL 2

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

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

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

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

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

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

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

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

التنفيذ

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

استخدام أجهزة الاستشعار المتعددة HAL مع معيار AIDL HAL لأجهزة الاستشعار
تطبيق أجهزة الاستشعار Multi-HAL 2.1
نقل البيانات من أجهزة الاستشعار Multi-HAL 2.0 إلى Multi-HAL 2.1
نقل البيانات من أجهزة الاستشعار HAL 2.0
نقل البيانات من أجهزة الاستشعار HAL 1.0
نقل البيانات من أجهزة الاستشعار Multi-HAL 1.0

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

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

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

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

لتنفيذ أجهزة الاستشعار Multi-HAL 2.1 على جهاز جديد، يُرجى اتّباع الخطوات التالية:

نفِّذ واجهة ISensorsSubHal كما هو موضّح في SubHal.h.
نفِّذ الطريقة sensorsHalGetSubHal_2_1 في SubHal.h.
أضِف استهداف 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.
أزِل جميع إدخالات android.hardware.sensors من ملف manifest.xml الذي يحتوي على قائمة HALs المتوافقة على الجهاز.
يجب إزالة جميع خدمات 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 الفرعي.

في ما يلي الاختلافات بين واجهتي الإصدار 2.0 و2.1 SubHal:

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

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

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

تهيئة HAL

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

نشر أحداث أداة الاستشعار في التنفيذ المتعدد المستويات (HAL)

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

أحداث WAKE_UP

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

أدوات الاستشعار الديناميكية

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

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

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

تهيئة HAL

يجب دعم الدالة initialize() لإنشاء عملية الاستدعاء بين HAL الفرعي وتنفيذ بروتوكول HAL المتعدد.

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

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

نشر أحداث أداة الاستشعار في التنفيذ المتعدد المستويات (HAL)

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

أحداث WAKE_UP

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

أدوات الاستشعار الديناميكية

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

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

لنقل عملية تنفيذ حالية من Sensors Multi-HAL 1.0، اتّبِع هذه الخطوات.

تأكَّد من ضبط إعدادات HAL لأدوات الاستشعار على /vendor/etc/sensors/hals.conf. قد يشمل ذلك نقل الملف في /system/etc/sensors/hals.conf.
أزِل أي إشارات إلى hardware/hardware.h وhardware/sensors.h لأنّها غير متوافقة مع HAL 2.0.
منفذ HALs فرعي على النحو الموضّح في نقل البيانات من أجهزة الاستشعار Hal 1.0.
ضبط أجهزة الاستشعار 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

إجراء الاختبارات باستخدام طبقات HAL الفرعية الزائفة

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

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

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

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

شغِّل الأوامر التالية لإنشاء حالات HALs فرعية وهمية مختلفة وإرسالها إلى الجهاز:

$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

عدِّل إعدادات HAL1 الخاصة بالمستشعرات في /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

أعِد تشغيل HalProxy وحمِّل حسابات HALs الفرعية الجديدة المدرَجة في الإعداد.
```
adb shell stop
adb shell start
```

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

يمكن للمطوّرين تصحيح أخطاء إطار العمل باستخدام الأمر lshal. لطلب إخراج تصحيح الأخطاء من طبقة تجريد الأجهزة (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 رقمًا كبيرًا (1,000 أو أكثر)، يشير ذلك إلى أنّ هناك العديد من الأحداث التي تنتظر كتابتها في إطار عمل أدوات الاستشعار. ويشير ذلك إلى أنّ خدمة جهاز الاستشعار متوقفة عن العمل أو تعطّلت ولا تعالج أحداث أداة الاستشعار، أو أنّه تم نشر مجموعة كبيرة من أحداث أداة الاستشعار مؤخرًا من طبقة تجريد الأجهزة (HAL) فرعية.

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

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