Sensors HAL 2.0

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

يتوفّر Sensors HAL 2.0 في الإصدار 10 من نظام التشغيل Android والإصدارات الأحدث للأجهزة الجديدة والأجهزة التي تمت ترقيتها. يستند 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 لأجهزة الاستشعار

لتنفيذ Sensors 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 المعرّف الثاني لإنشاء "قائمة الانتظار للطلبات الفورية" لـ "قفل التنشيط" المستخدَمة للمزامنة عندما يُطلق HAL قفل التنشيط لأحداث WAKE_UP الاستشعار. يجب أن يحفظ HAL مؤشرًا إلى عنصر ISensorsCallback حتى تتمكّن من استدعاء أيّ وظائف ردّ اتصال ضرورية.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الحد الأقصى لمُدد استغراق إعداد التقارير

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إنّ "قائمة انتظار الرسائل الفورية للأحداث" هي قائمة انتظار متزامنة للرسائل الفورية، ما يعني أنّ أي محاولة لكتابة عدد أحداث أكبر من المساحة المتاحة في قائمة الانتظار للرسائل الفورية تؤدي إلى تعذُّر الكتابة. في هذه الحالة، يجب أن يحدّد 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.

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

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

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

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

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

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

قناة مباشرة

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

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

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

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

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

التحقُّق

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

اختبارات CTS

تتوفّر اختبارات CTS الخاصة بأجهزة الاستشعار في كلّ من اختبارات CTS المبرمَجة وتطبيق "أداة التحقّق من توافق الأجهزة مع CTS" يدوية الاستخدام.

يمكن العثور على الاختبارات المبرمَجة فيملف: 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 لـ Sensors HAL 2.1 في ملف برمجي في المسار: hardware/interfaces/sensors/2.1/vts. تضمن هذه الاختبارات تنفيذ حزمة HAL الخاصة بأجهزة الاستشعار بشكل صحيح واستيفاء جميع المتطلبات الواردة في ISensors.hal وISensorsCallback.hal بشكل صحيح.

الترقية إلى Sensors 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 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()، يجب أن يسجِّل Sensors HAL 2.0 بشكل استباقي أحداث أجهزة الاستشعار في Event 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() في Sensors 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.