مستشعرات AIDL HAL

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

يتوفر Sensors AIDL HAL في نظام Android 13 والإصدارات الأحدث للأجهزة الجديدة والمحدثة. مستشعرات AIDL HAL ، التي تعتمد على Sensors HAL 2.1 ، تستخدم واجهة AIDL HAL وتكشف متتبع الرأس وأنواع مستشعرات IMU محدودة المحور.

واجهة AIDL HAL

المصدر الرئيسي لتوثيق أجهزة الاستشعار AIDL HAL هو ضمن تعريف HAL ​​في الأجهزة / الواجهات / أجهزة الاستشعار / AIDL / android / Hardware / sensors / ISensors.aidl .

تنفيذ مجسات AIDL HAL

لتنفيذ Sensors AIDL HAL ، يجب أن يقوم الكائن بتوسيع واجهة ISensors وتنفيذ جميع الوظائف المحددة في الأجهزة / الواجهات / المستشعرات / helpl / android / Hardware / sensors / ISensors.aidl .

تهيئة HAL

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

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

يجب أن تكون وظيفة initialize() هي الوظيفة الأولى التي يتم استدعاؤها عند تهيئة Sensors HAL.

كشف أجهزة الاستشعار المتوفرة

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

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

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

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

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

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

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

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

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

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

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

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

للتعرف على التفاعل بين فترة أخذ العينات وأوضاع إعداد التقارير الخاصة بأجهزة الاستشعار ، راجع أوضاع إعداد التقارير .

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

يحدد الحد الأقصى لوقت استجابة التقارير الحد الأقصى للوقت بالنانو ثانية الذي يمكن فيه تأخير الأحداث وتخزينها في الجهاز FIFO قبل كتابتها إلى Event FMQ من خلال HAL أثناء تنبيه SoC.

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

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

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

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

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

تفعيل المستشعرات

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

بعد إلغاء تنشيط المستشعر ، يجب عدم كتابة أحداث المستشعر الإضافية من هذا المستشعر في Event FMQ.

مجسات التنظيف

إذا تم تكوين جهاز استشعار لتجميع بيانات المستشعر ، يمكن أن يفرض إطار العمل تدفقًا فوريًا لأحداث المستشعرات المجمعة عن طريق استدعاء flush() . يؤدي هذا إلى كتابة أحداث المستشعر المجمعة لمقبض المستشعر المحدد على الفور إلى Event FMQ. يجب أن يُلحق HAL المستشعرات حدث تدفق كامل بنهاية أحداث المستشعر المكتوبة كنتيجة لاستدعاء flush() .

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

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

إذا تم استدعاء flush flush() flush() إلى إرجاع BAD_VALUE وعدم إنشاء حدث تدفق كامل.

أحداث مستشعر الكتابة إلى FMQ

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

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

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

يدعم Sensors AIDL HAL كلاً من حظر write والكتابة في حدث writeBlocking . يوفر التطبيق الافتراضي مرجعًا لاستخدام 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 ، يقوم إطار العمل بتأمين قفل التنشيط الخاص به ، مما يسمح لـ Sensors HAL بإطلاق قفل التنبيه الخاص به. للمزامنة عندما يحرر Sensors HAL قفل التنبيه ، استخدم Wake Lock FMQ.

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

يعيّن إطار العمل WakeLockQueueFlagBits::DATA_WRITTEN إشعار الكتابة على Wake Lock FMQ عندما يكتب البيانات إلى Wake Lock FMQ.

مجسات ديناميكية

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

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

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

قناة مباشرة

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

تعمل registerDirectChannel() و unregisterDirectChannel() على إنشاء قناة مباشرة جديدة أو إتلافها.

وسائط التشغيل

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

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

تصديق

للتحقق من صحة تنفيذ Sensors HAL ، قم بتشغيل اختبارات CTS و VTS الخاصة بالمستشعر.

اختبارات CTS

توجد اختبارات Sensor CTS في كل من اختبارات CTS الآلية وتطبيق CTS Verifier اليدوي.

تقع الاختبارات الآلية في cts / الاختبارات / sensor / src / android / Hardware / cts . تتحقق هذه الاختبارات من الوظائف القياسية لأجهزة الاستشعار ، مثل تنشيط أجهزة الاستشعار ، والتجميع ، ومعدلات أحداث المستشعرات.

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

يعد اجتياز اختبارات CTS أمرًا بالغ الأهمية للتأكد من أن الجهاز قيد الاختبار يلبي جميع متطلبات العناية الواجبة.

اختبارات VTS

توجد اختبارات VTS لأجهزة الاستشعار AIDL HAL في الأجهزة / الواجهات / أجهزة الاستشعار / AIDL / VTS / . تضمن هذه الاختبارات تنفيذ Sensors HAL بشكل صحيح وأن جميع المتطلبات داخل ISensors.aidl و ISensorsCallback.aidl بشكل صحيح.

تهيئة HAL

يجب دعم وظيفة initialize() لإنشاء FMQs بين إطار العمل و HAL.

كشف أجهزة الاستشعار المتوفرة

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

أحداث مستشعر الكتابة إلى FMQ

بدلاً من انتظار استدعاء poll() ، في Sensors AIDL HAL ، يجب على Sensors HAL كتابة أحداث المستشعر بشكل استباقي إلى Event FMQ كلما توفرت أحداث المستشعر. HAL مسؤول أيضًا عن كتابة البتات الصحيحة إلى EventFlag للتسبب في قراءة FMQ داخل إطار العمل.

أحداث WAKE_UP

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

في Sensors AIDL HAL ، يجب أن يبدأ قفل التنشيط المؤمن بواسطة Sensors HAL لأحداث WAKE_UP بـ SensorsHAL_WAKEUP .

مجسات ديناميكية

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

وسائط التشغيل

يجب دعم وضع DATA_INJECTION WAKE_UP .

دعم متعدد HAL

يدعم Sensors AIDL HAL متعدد HAL باستخدام إطار Sensors Multi-HAL . للحصول على تفاصيل التنفيذ ، راجع Porting from Sensors HAL 2.1 .