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

طبقة HAL (Sensors Hardware Abstraction Layer) هي الواجهة بين قاعدة برمجة التطبيقات لأجهزة استشعار Android وأدوات استشعار الجهاز، مثل مقياس التسارع أو الجيروسكوب. تحدد طبقة تجريد الأجهزة (HAL) لأجهزة الاستشعار الوظائف التي يجب تنفيذها للسماح لإطار العمل بالتحكم في أجهزة الاستشعار.

يتوفّر Sensors HAL 2.0 في Android 10 والإصدارات الأحدث للأجهزة الجديدة والأجهزة التي تمت ترقيتها. يستند Sensors HAL 2.0 إلى Sensors HAL 1.0، ولكنّه يختلف عنه في عدة جوانب رئيسية، مما يمنع توافقه مع الإصدارات القديمة. يستخدم Sensors HAL 2.0 قوائم الرسائل السريعة (FMQ) لإرسال أحداث الاستشعار من HAL إلى إطار عمل أدوات استشعار Android.

يتوفّر حِزم HAL 2.1 لأجهزة الاستشعار في الإصدار 11 من نظام التشغيل Android والإصدارات الأحدث للأجهزة الجديدة والأجهزة التي تمت ترقيتها. ‫Sensors HAL 2.1 هو إصدار من Sensors HAL 2.0 يعرض نوع أداة الاستشعار HINGE_ANGLE ويعدّل طُرقًا مختلفة لقبول نوع HINGE_ANGLE.

واجهة HAL 2.1

يندرج المصدر الرئيسي للتوثيق المتعلق بأداة الاستشعار HAL 2.1 ضمن تعريف HAL في hardware/interfaces/sensors/2.1/ISensors.hal. إذا كان هناك تعارض في المتطلبات بين هذه الصفحة وISensors.hal، استخدِم المتطلبات في ISensors.hal.

واجهة HAL 2.0

يندرج المصدر الرئيسي للتوثيق المتعلق بأداة الاستشعار HAL 2.0 ضمن تعريف HAL في hardware/interfaces/sensors/2.0/ISensors.hal. في حال تعارض المتطلبات بين هذه الصفحة وISensors.hal، استخدِم المتطلّب الوارد في ISensors.hal.

تنفيذ حِزم HAL 2.0 وHAL 2.1 لأجهزة الاستشعار

لتطبيق HAL 2.0 أو 2.1 من أدوات الاستشعار، يجب أن يوسِّع الكائن واجهة ISensors وتنفيذ جميع الدوال المحددة في 2.0/ISensors.hal أو 2.1/ISensors.hal.

بدء HAL

يجب أن يبدأ إطار عمل أجهزة الاستشعار في Android عملية إعداد واجهة برمجة التطبيقات لأجهزة الاستشعار (HAL) قبل أن يمكن استخدامها. يستدعي إطار العمل الدالة initialize() لـ HAL 2.0 والدالة initialize_2_1() لـ HAL 2.1 لتوفير ثلاث معلمات لأدوات الاستشعار HAL: اثنان واصفان FMQ ومؤشر واحد إلى كائن ISensorsCallback.

يستخدم HAL الوصف الأوّل لإنشاء Event FMQ المستخدَم لكتابة أحداث الاستشعار في إطار العمل. يستخدم HAL المعرّف الثاني لإنشاء FMQ لـ Wake Lock المستخدَم للمزامنة عندما يُطلق HAL قفل التنشيط لأحداث WAKE_UP الاستشعار. يجب أن يحفظ HAL مؤشرًا إلى عنصر ISensorsCallback حتى تتمكّن من استدعاء أيّ دوال ردّ اتصال ضرورية.

يجب أن تكون الدالة initialize() أو initialize_2_1() هي الدالة الأولى التي يتمّ استدعاؤها عند بدء تشغيل حزمة HAL الخاصة بأجهزة الاستشعار.

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

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

إذا كانت هناك عدة أجهزة استشعار تشترك في نوع أداة الاستشعار نفسه وخاصية التنشيط، يكون اسم المستشعر الأول في القائمة هو أداة الاستشعار التلقائية ويتم إرجاعها إلى التطبيقات التي تستخدم وظيفة getDefaultSensor(int sensorType, bool wakeUp).

قائمة ثبات أجهزة الاستشعار

بعد إعادة تشغيل حزمة HAL الخاصة بأجهزة الاستشعار، إذا كانت البيانات التي تعرضها getSensorsList() أو getSensorsList_2_1() تشير إلى تغيير كبير مقارنةً بقائمة أجهزة الاستشعار التي تم استردادها قبل إعادة التشغيل، يُشغِّل إطار العمل إعادة تشغيل وقت تشغيل Android. تشمل التغييرات المهمة التي يتم إجراؤها على قائمة أجهزة الاستشعار الحالات التي يكون فيها جهاز استشعار بمقبض معيّن غير موجود أو تم فيه تغيير سمات أو الحالات التي يتم فيها إدخال أجهزة استشعار جديدة. على الرغم من أنّ إعادة تشغيل نظام التشغيل Android Runtime يتسبب في تعطيل المستخدم، إلا أنّه إجراء مطلوب لأنّ إطار عمل Android لم يعُد يستوفي عقد Android API الذي ينص على عدم تغيير أدوات الاستشعار الثابتة (غير الديناميكية) أثناء مدة استخدام التطبيق. وقد يمنع ذلك أيضًا إطار العمل من إعادة تأسيس طلبات أدوات الاستشعار النشطة التي تقدّمها التطبيقات. لذلك، ننصح مورّدي HAL بمحاولة تجنُّب تغييرات قائمة أجهزة الاستشعار التي يمكن تجنُّبها.

لضمان تثبيت مقابض أداة استشعار ثابتة، يجب أن تربط تقنية HAL بشكل قاطع بأداة استشعار مادية في الجهاز بمقبضها. على الرغم من أنّ واجهة Sensors HAL لا تفرض أي تنفيذ محدّد، يتوفّر للمطوّرين عدد من الخيارات لتلبية هذا الشرط.

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

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

قبل تفعيل أداة الاستشعار، يجب ضبطها باستخدام فترة قياس كثافة العينة ومدة الاستجابة القصوى لإعداد التقارير باستخدام الدالة batch().

يجب أن تتوفر إمكانية إعادة ضبط أي جهاز استشعار في أي وقت باستخدام batch() بدون فقدان بيانات جهاز الاستشعار.

فترة أخذ العيّنات

يختلف معنى فترة أخذ العينات حسب نوع المستشعر الذي يتم إعداده:

  • مستمر: يتم إنشاء أحداث أجهزة الاستشعار بمعدّل مستمر.
  • عند التغيير: لا يتم إنشاء الأحداث بسرعة أكبر من فترة أخذ العيّنات، وقد يتم إنشاؤها بمعدّل أبطأ من فترة أخذ العيّنات إذا لم تتغيّر القيمة التي تمّ قياسها.
  • قياس لمرة واحدة: يتم تجاهل فترة أخذ العينات.
  • خاص: لمزيد من التفاصيل، يُرجى الاطّلاع على أنواع أجهزة الاستشعار.

للتعرّف على التفاعل بين فترة أخذ العينات وmodi reporting لجهاز الاستشعار، اطّلِع على وضعَي إعداد التقارير.

الحد الأقصى لوقت استجابة إعداد التقارير

يحدِّد الحد الأقصى لمُدد الاستجابة في إعداد التقارير الحد الأقصى للوقت الذي يمكن فيه تأخير الأحداث وتخزينها في ذاكرة التخزين المؤقت للأجهزة أولاً قبل كتابتها في ذاكرة التخزين المؤقت للأحداث من خلال HAL عندما تكون وحدة المعالجة المركزية (SoC) مفعَّلة.

تشير القيمة صفر إلى أنه يجب الإبلاغ عن الأحداث فور قياسها، إما عبر تخطي مقياس FIFO تمامًا، أو تفريغ FIFO عند توفّر حدث واحد من جهاز الاستشعار في FIFO.

على سبيل المثال، يُشغّل مقياس التسارع الذي يتم تفعيله بمعدّل 50 هرتز مع الحد الأقصى لوقت المعالجة الذي يساوي صفرًا عمليات المقاطعة 50 مرة في الثانية عندما يكون المعالج المتكامل للنظام قيد التشغيل.

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

يرتبط كل حدث بطابع زمني. يجب ألا يؤثر تأخير وقت الإبلاغ عن الحدث في الطابع الزمني للحدث يجب أن يكون الطابع الزمني دقيقًا وأن يتطابق مع وقت وقوع الحدث، وليس وقت الإبلاغ عنه.

للحصول على معلومات ومتطلبات إضافية حول الإبلاغ عن أحداث أجهزة الاستشعار التي تتضمن وقت استجابة أقصى غير صفري للإبلاغ، يُرجى الاطّلاع على تجميع البيانات.

تفعيل أدوات الاستشعار

يفعّل إطار العمل أدوات الاستشعار ويوقفها باستخدام الدالة activate(). قبل تفعيل أداة استشعار، يجب أن يضبط إطار العمل أداة الاستشعار أولاً باستخدام batch().

بعد إيقاف جهاز استشعار، يجب عدم تسجيل أحداث إضافية من هذا الجهاز في "قائمة الانتظار للطلبات الفورية للأحداث".

أجهزة استشعار التنظيف

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

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

إذا لم يكن لدى أداة الاستشعار المحدّدة قائمة انتظار أولوية (FIFO) (لا يمكن تخزين البيانات مؤقتًا)، أو إذا كانت قائمة الانتظار خالية في وقت المكالمة، يجب أن تنجح flush() وتُرسِل حدثًا يشير إلى اكتمال تنظيف ذاكرة التخزين المؤقت لتلك أداة الاستشعار. ينطبق ذلك على جميع أدوات الاستشعار بخلاف أدوات الاستشعار التي تعمل لمرة واحدة.

إذا تمّ استدعاء flush() لجهاز استشعار لمرة واحدة، يجب أن يعرض flush()BAD_VALUE بدون إنشاء حدث اكتمال تنظيف.

كتابة أحداث أجهزة الاستشعار في "الملفّ الموحّد للطلبات"

يتم استخدام إطار FMQ بواسطة أجهزة الاستشعار HAL لتوجيه أحداث أداة الاستشعار إلى إطار عمل أجهزة الاستشعار في Android.

إنّ "قائمة انتظار الرسائل الفورية للأحداث" هي قائمة انتظار متزامنة للرسائل الفورية، ما يعني أنّ أي محاولة لكتابة عدد أحداث أكبر من المساحة المتاحة في قائمة الانتظار للرسائل الفورية تؤدي إلى تعذُّر الكتابة. في هذه الحالة، يجب أن يحدّد HAL ما إذا كان سيتم كتابة المجموعة الحالية من الأحداث كجماعتَين أصغر من الأحداث أو كتابة جميع الأحداث معًا عندما تتوفّر مساحة كافية.

عندما يكتب Sensors HAL العدد المطلوب من أحداث أجهزة الاستشعار في ملف رسائل Event FMQ، يجب أن يُعلم Sensors HAL إطار العمل بأنّ الأحداث جاهزة من خلال كتابة البت EventQueueFlagBits::READ_AND_PROCESS في دالة EventFlag::wake الخاصة بملف رسائل Event FMQ. يمكن إنشاء EventFlag من Event FMQ باستخدام EventFlag::createEventFlag ودالة getEventFlagWord() في Event FMQ.

يتوافق Sensors HAL 2.0/2.1 مع كل من write وwriteBlocking في Event FMQ. توفّر عملية التنفيذ التلقائية مرجعًا لاستخدام write. في حال استخدام الدالة writeBlocking، يجب ضبط العلامة readNotification على EventQueueFlagBits::EVENTS_READ، وهو ما يضبطه الإطار عند قراءة الأحداث من Event FMQ. يجب ضبط علامة إشعار الكتابة على EventQueueFlagBits::READ_AND_PROCESS، ما يُعلم إطار العمل بأنّه تمت كتابة الأحداث في Event FMQ.

أحداث WAKE_UP

أحداث WAKE_UP هي أحداث أجهزة الاستشعار التي تؤدي إلى بدء تشغيل وحدة معالجة التطبيقات (AP) ومعالجة الحدث على الفور. عند كتابة حدث WAKE_UP في Event FMQ، يجب أن يحصل Sensors HAL على قفل تنبيه لضمان بقاء النظام في وضع التشغيل إلى أن يتمكّن إطار العمل من معالجة الحدث. عند تلقّي حدث WAKE_UP، يُحصّن إطار العمل قفل التنشيط الخاص به، ما يسمح لواجهة برمجة التطبيقات (HAL) لأجهزة الاستشعار بإزالة قفل التنشيط. لمزامنة البيانات عندما يُبطل Sensors HAL قفل التنشيط، استخدِم Wake Lock FMQ.

يجب أن تقرأ أجهزة الاستشعار HAL FMQ من Wake Lock لتحديد عدد أحداث WAKE_UP التي عالجها إطار العمل. يجب ألا يُطلق HAL قفل التنشيط لأحداث WAKE_UP إلا إذا كان إجمالي عدد أحداث WAKE_UP غير المُعالجة يساوي صفرًا. بعد التعامل مع أحداث أداة الاستشعار، يحتسب إطار العمل عدد الأحداث التي يتم وضع علامة عليها كأحداث WAKE_UP ويكتب هذا الرقم مجددًا في ميزة Wake Lock FMQ.

يضبط إطار العمل إشعار WakeLockQueueFlagBits::DATA_WRITTEN write في "قائمة الانتظار للرسائل الفورية" لميزة "قفل التنشيط" كلما كتب البيانات في "قائمة الانتظار للرسائل الفورية" لميزة "قفل التنشيط".

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

أجهزة الاستشعار الديناميكية هي أجهزة استشعار ليست جزءًا من الجهاز جسديًا ولكن يمكن استخدامها كمدخلات للجهاز، مثل جهاز تحكم ألعاب مزوّد بمقياس تسارع.

عند توصيل جهاز استشعار ديناميكي، يجب استدعاء الدالة onDynamicSensorConnected في ISensorsCallback من Sensors HAL. يؤدي ذلك إلى إرسال إشعار إلى الإطار العملي بشأن أداة الاستشعار الديناميكية الجديدة والسماح بالتحكم في أداة الاستشعار من خلال الإطار العملي واستخدام العملاء لأحداث أداة الاستشعار.

وبالمثل، عند انقطاع الاتصال بجهاز استشعار ديناميكي، يجب استدعاء onDynamicSensorDisconnected في ISensorsCallback ليكون بإمكان الإطار الأساسي إزالة أي جهاز استشعار لم يعُد متاحًا.

قناة مباشرة

القناة المباشرة هي طريقة تشغيل يتم فيها كتابة أحداث أجهزة الاستشعار في ذاكرة معيّنة بدلاً من كتابة تلك الأحداث في Event FMQ بدون استخدام إطار عمل Android Sensors Framework. على العميل الذي يسجّل قناة مباشرة قراءة أحداث أجهزة الاستشعار مباشرةً من الذاكرة التي تم استخدامها لإنشاء القناة المباشرة ولن يتم تلقّي أحداث أجهزة الاستشعار من خلال الإطار. تشبه الدالة configDirectReport() الدالة batch() للتشغيل العادي، وتضبط قناة التقرير المباشر.

تنشئ الدالتان registerDirectChannel() وunregisterDirectChannel() قناة مباشرة جديدة أو تُزيلانها.

أوضاع التشغيل

تسمح دالة setOperationMode() للإطار بضبط أداة استشعار كي يتمكّن الإطار من إدخال بيانات أداة الاستشعار في أداة الاستشعار. ويُعدّ ذلك مفيدًا في الاختبار، خاصةً بالنسبة إلى الخوارزميات التي تقع أسفل إطار العمل.

تُستخدَم الدالة injectSensorData() في HAL 2.0 والدالة injectSensorsData_2_1() في HAL 2.0 عادةً لدفع المَعلمات التشغيلية إلى HAL Sensors. ويمكن استخدام الدالة أيضًا لحقن أحداث أداة الاستشعار في جهاز استشعار معيّن.

التحقُّق

للتحقّق من صحة تنفيذك لواجهة HAL الخاصة بأجهزة الاستشعار، عليك إجراء اختبارَي CTS وVTS لأجهزة الاستشعار.

اختبارات CTS

تتوفّر اختبارات CTS لأداة الاستشعار في كل من اختبارات CTS الآلية وتطبيق CTS Verifier اليدوي.

يمكن العثور على الاختبارات المبرمَجة فيملف ‎ cts/tests/sensor/src/android/hardware/cts. تتحقّق هذه الاختبارات من الوظائف العادية لأدوات الاستشعار، مثل تفعيل أدوات الاستشعار وتجميعها ومعدّلات أحداث أدوات الاستشعار.

يمكن العثور على اختبارات أداة التحقّق من التوافق (CTS Verifier) في cts/apps/CtsVerifier/src/com/android/cts/verifier/sensors. تتطلب هذه الاختبارات إدخالاً يدويًا من مشغّل الاختبار والتأكد من أن أجهزة الاستشعار تبلغ عن قيم دقيقة.

إنّ اجتياز اختبارات CTS أمر مهم لضمان استيفاء الجهاز الخاضع للاختبار لجميع متطلبات CDD.

اختبارات VTS

يمكن العثور على اختبارات VTS لـ Sensors HAL 2.0 في ملف برمجي في المسار hardware/interfaces/sensors/2.0/vts. تتوفّر اختبارات VTS لأجهزة الاستشعار HAL 2.1 في hardware/interfaces/sensors/2.1/vts. تضمن هذه الاختبارات تنفيذ طبقة تجريد الأجهزة (HAL) لأجهزة الاستشعار بشكل صحيح واستيفاء جميع المتطلبات ضمن ISensors.hal وISensorsCallback.hal على نحو سليم.

الترقية إلى أجهزة الاستشعار HAL 2.1 من الإصدار 2.0

عند الترقية إلى Sensors HAL 2.1 من 2.0، يجب أن يتضمّن تنفيذ HAL methods initialize_2_1() وgetSensorsList_2_1() وinjectSensorsData_2_1() بالإضافة إلى أنواع HAL 2.1. يجب أن تستوفي هذه الطرق المتطلبات نفسها الموضّحة أعلاه لـ HAL 2.0.

وبما أنّ واجهات HAL ذات الإصدارات الثانوية يجب أن توفّر جميع الدوال من واجهات HAL السابقة، يجب أن توفّر واجهات HAL‏ 2.1 إمكانية بدء التشغيل كواجهات HAL‏ 2.0. لتجنُّب تعقيد إتاحة كلا إصدارَي HAL، ننصحك بشدة باستخدام Multi-HAL 2.1.

للحصول على مثال على كيفية تنفيذ حزمة HAL الخاصة بواجهة Sensors 2.1، يُرجى الاطّلاع على Sensors.h.

الترقية إلى Sensors HAL 2.0 من الإصدار 1.0

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

تهيئة HAL

يجب أن تكون الدالة initialize() متوافقة لإنشاء قوائم انتظار الطلبات الفورية بين الإطار وHAL.

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

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

كتابة أحداث أجهزة الاستشعار في "الملفّ الموحّد للطلبات"

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

أحداث WAKE_UP

في Sensors HAL 1.0، تمكّن HAL من إزالة قفل التنشيط لأي حدث WAKE_UP عند أيّ طلب لاحق إلى poll() بعد نشر WAKE_UP في poll() لأنّ ذلك يشير إلى أنّ الإطار الأساسي قد عالج جميع أحداث الاستشعار وحصل على قفل تنشيط، إذا لزم الأمر. وبما أنّه في Sensors HAL 2.0، لم يعُد بإمكان HAL معرفة وقت معالجة إطار العمل للأحداث المكتوبة في FMQ، يسمح Wake Lock FMQ لإطار العمل بالتواصل مع HAL عند معالجته لأحداث WAKE_UP.

في Sensors HAL 2.0، يجب أن يبدأ قفل التنشيط الذي يؤمنه Sensors HAL لأحداث WAKE_UP بـ SensorsHAL_WAKEUP.

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

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

أوضاع التشغيل

يجب أن يكون وضع DATA_INJECTION لأجهزة استشعار WAKE_UP متوافقًا مع Sensors HAL 2.0.

التوافق مع بروتوكولات HAL المتعددة

يتيح Sensors HAL 2.0 و2.1 استخدام واجهات HAL متعددة باستخدام إطار عمل Sensors Multi-HAL. للاطّلاع على تفاصيل التنفيذ، يُرجى الاطّلاع على نقل البيانات من Sensors HAL 1.0.