كومة الاستشعار

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

طبقات ومالكي مكدس مستشعر Android

الشكل 1. طبقات مجموعة مستشعرات Android وأصحابها

SDK

تصل التطبيقات إلى أجهزة الاستشعار من خلال واجهة برمجة تطبيقات Sensors SDK (مجموعة تطوير البرامج) . يحتوي SDK على وظائف لسرد المستشعرات المتاحة والتسجيل في المستشعر.

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

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

راجع وثائق المطور لمزيد من المعلومات حول SDK.

نطاق

الإطار مسؤول عن ربط العديد من التطبيقات بـ HAL . HAL نفسه هو عميل واحد. وبدون حدوث هذا التعدد على مستوى الإطار، لا يمكن إلا لتطبيق واحد الوصول إلى كل مستشعر في أي وقت.

  • عندما يسجل التطبيق الأول على جهاز استشعار، يرسل الإطار طلبًا إلى HAL لتنشيط المستشعر.
  • عندما يتم تسجيل تطبيقات إضافية على نفس المستشعر، يأخذ الإطار في الاعتبار المتطلبات من كل تطبيق ويرسل المعلمات المطلوبة المحدثة إلى HAL.
    • سيكون تردد أخذ العينات هو الحد الأقصى لترددات أخذ العينات المطلوبة، مما يعني أن بعض التطبيقات ستستقبل الأحداث بتردد أعلى من التردد الذي طلبته.
    • سيكون الحد الأقصى لزمن وصول التقارير هو الحد الأدنى المطلوب. إذا طلب أحد التطبيقات مستشعرًا واحدًا بحد أقصى لزمن انتقال التقارير يبلغ 0، فستتلقى جميع التطبيقات الأحداث من هذا المستشعر في الوضع المستمر حتى إذا طلب البعض المستشعر بوقت استجابة أقصى للإبلاغ غير صفر. انظر الخلط لمزيد من التفاصيل.
  • عندما يتم إلغاء تسجيل آخر تطبيق مسجل على أحد أجهزة الاستشعار، ترسل الأنظمة طلبًا إلى HAL لإلغاء تنشيط المستشعر حتى لا يتم استهلاك الطاقة دون داعٍ.

تأثير تعدد الإرسال

هذه الحاجة إلى طبقة تعدد الإرسال في الإطار تشرح بعض قرارات التصميم.

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

اندماج الاستشعار

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

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

لا يتم الحفاظ على تنفيذ دمج المستشعر الافتراضي وقد يتسبب في فشل الأجهزة التي تعتمد عليه في فشل CTS.

تحت الغطاء

يتم توفير هذا القسم كمعلومات أساسية لأولئك الذين يحافظون على رمز إطار عمل مشروع Android مفتوح المصدر (AOSP). أنها ليست ذات صلة لمصنعي الأجهزة.

JNI

يستخدم إطار العمل واجهة Java الأصلية (JNI) المرتبطة بـ android.hardware والموجودة في دليل frameworks/base/core/jni/ . يستدعي هذا الرمز الكود الأصلي ذي المستوى الأدنى للوصول إلى أجهزة الاستشعار.

الإطار الأصلي

يتم تعريف إطار العمل الأصلي في frameworks/native/ ويوفر مكافئًا أصليًا لحزمة android.hardware . يستدعي إطار العمل الأصلي وكلاء Binder IPC للوصول إلى الخدمات الخاصة بالمستشعر.

الموثق IPC

تعمل وكلاء Binder IPC على تسهيل الاتصال عبر حدود العملية.

هال

واجهة برمجة تطبيقات طبقة تجريد أجهزة الاستشعار (HAL) هي الواجهة بين برامج تشغيل الأجهزة وإطار عمل Android. وهو يتألف من مستشعر واجهة HAL واحد.h وتنفيذ HAL واحد نشير إليه باسم Sensors.cpp.

يتم تعريف الواجهة بواسطة المساهمين في Android وAOSP، ويتم توفير التنفيذ من قبل الشركة المصنعة للجهاز.

توجد واجهة HAL للمستشعر في hardware/libhardware/include/hardware . راجع Sensors.h للحصول على تفاصيل إضافية.

دورة الإصدار

يحدد تطبيق HAL إصدار واجهة HAL الذي يقوم بتنفيذه عن طريق تعيين your_poll_device.common.version . يتم تعريف إصدارات واجهة HAL الحالية في أجهزة الاستشعار.h، وترتبط الوظيفة بتلك الإصدارات.

يدعم إطار عمل Android حاليًا الإصدارين 1.0 و1.3، ولكن لن يتم دعم الإصدار 1.0 قريبًا. تصف هذه الوثائق سلوك الإصدار 1.3، الذي يجب ترقية كافة الأجهزة إليه. للحصول على تفاصيل حول كيفية الترقية إلى الإصدار 1.3، راجع إهمال إصدار HAL .

سائق النواة

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

في جميع الحالات، تقع مسؤولية تنفيذ HAL وبرامج تشغيل kernel على عاتق الشركات المصنعة للأجهزة، ولا يوفر Android الأساليب المفضلة لكتابتها.

محور الاستشعار

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

ملاحظة: لتطوير ميزات contextHub الجديدة التي تستخدم أجهزة استشعار أو مصابيح LED جديدة، يمكنك أيضًا استخدام Neonkey SensorHub المتصل بلوحة تطوير Hikey أو Hikey960.

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

لم يتم تحديد كيفية تصميم مركز المستشعر وكيفية تواصله مع المستشعرات وSOC (ناقل I2C، ناقل SPI، ...) بواسطة Android، ولكن يجب أن يهدف إلى تقليل الاستخدام الإجمالي للطاقة.

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

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

تلك هي شرائح MEMs المادية التي تجري القياسات. في كثير من الحالات، توجد العديد من أجهزة الاستشعار المادية على نفس الشريحة. على سبيل المثال، تشتمل بعض الرقائق على مقياس تسارع وجيروسكوب ومقياس مغناطيسي. (تسمى هذه الرقائق غالبًا بالرقائق ذات 9 محاور، حيث يوفر كل مستشعر بيانات عبر 3 محاور.)

تحتوي بعض هذه الرقائق أيضًا على بعض المنطق لإجراء العمليات الحسابية المعتادة مثل اكتشاف الحركة واكتشاف الخطوات ودمج أجهزة الاستشعار ذات 9 محاور.

على الرغم من أن متطلبات وتوصيات قوة CDD ودقتها تستهدف مستشعر Android وليس المستشعرات المادية، إلا أن هذه المتطلبات تؤثر على اختيار المستشعرات المادية. على سبيل المثال، متطلبات الدقة في متجه دوران اللعبة لها آثار على الدقة المطلوبة للجيروسكوب الفعلي. الأمر متروك للشركة المصنعة للجهاز لاستخلاص متطلبات أجهزة الاستشعار المادية.