يمثل الشكل أدناه حزمة مستشعر 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 على تسهيل الاتصال عبر حدود العملية.
هال
واجهة برمجة تطبيقات Sensors Hardware Abstraction Layer (HAL) هي الواجهة بين برامج تشغيل الأجهزة وإطار عمل Android. وهو يتألف من مستشعرات واجهة HAL واحدة وتنفيذ HAL واحد نشير إليه باسم المستشعرات. 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 الأساليب المفضلة لكتابتها.
محور الاستشعار
يمكن أن تشتمل مجموعة المستشعرات الخاصة بالجهاز اختياريًا على محور مستشعر ، وهو مفيد لإجراء بعض العمليات الحسابية منخفضة المستوى بطاقة منخفضة بينما يمكن أن تكون SoC في وضع التعليق. على سبيل المثال ، يمكن إجراء عد الخطوات أو اندماج المستشعرات على هذه الرقائق. إنه أيضًا مكان جيد لتنفيذ تجميع المستشعرات ، وإضافة FIFOs للأجهزة لأحداث المستشعر. انظر التجميع لمزيد من المعلومات.
ملاحظة: لتطوير ميزات ContextHub الجديدة التي تستخدم مستشعرات أو مصابيح LED جديدة ، يمكنك أيضًا استخدام Neonkey SensorHub المتصل بلوحة تطوير Hikey أو Hikey960.
تعتمد كيفية تجسيد محور المستشعر على البنية. تكون أحيانًا شريحة منفصلة ، وأحيانًا يتم تضمينها على نفس الشريحة مثل شركة نفط الجنوب. من الخصائص المهمة لمحور المستشعر أنه يجب أن يحتوي على ذاكرة كافية للتجميع ويستهلك القليل جدًا من الطاقة لتمكين تنفيذ مستشعرات Android منخفضة الطاقة. تحتوي بعض محاور المستشعرات على متحكم دقيق للحساب العام ، ومسرعات الأجهزة لتمكين حساب الطاقة المنخفضة جدًا لأجهزة الاستشعار منخفضة الطاقة.
لم يتم تحديد كيفية تصميم محور المستشعر وكيفية اتصاله مع المستشعرات و SoC (ناقل I2C ، ناقل SPI ، ...) بواسطة Android ، ولكن يجب أن يهدف إلى تقليل استخدام الطاقة بشكل عام.
أحد الخيارات التي يبدو أن لها تأثيرًا كبيرًا على بساطة التنفيذ هو وجود سطرين للمقاطعة ينتقلان من محور المستشعر إلى SoC: أحدهما لمقاطعات الاستيقاظ (لمستشعرات التنبيه) ، والآخر لمقاطعات عدم الاستيقاظ (لأجهزة استشعار عدم الاستيقاظ).
مجسات
هذه هي رقائق MEM المادية التي تقوم بالقياسات. في كثير من الحالات ، توجد العديد من أجهزة الاستشعار المادية على نفس الشريحة. على سبيل المثال ، تشتمل بعض الرقائق على مقياس تسارع وجيروسكوب ومقياس مغناطيسي. (تسمى هذه الرقائق غالبًا رقائق ذات 9 محاور ، حيث يوفر كل جهاز استشعار بيانات عبر 3 محاور.)
تحتوي بعض هذه الشرائح أيضًا على بعض المنطق لإجراء العمليات الحسابية المعتادة مثل اكتشاف الحركة واكتشاف الخطوة ودمج مستشعر 9 محاور.
على الرغم من أن متطلبات وتوصيات قوة ودقة CDD تستهدف مستشعر Android وليس المستشعرات المادية ، فإن هذه المتطلبات تؤثر على اختيار أجهزة الاستشعار المادية. على سبيل المثال ، فإن متطلبات الدقة في متجه دوران اللعبة لها آثار على الدقة المطلوبة للجيروسكوب المادي. الأمر متروك لجهة تصنيع الجهاز في اشتقاق متطلبات أجهزة الاستشعار المادية.