يمثّل الشكل أدناه حِزمة أدوات استشعار Android. لا يتواصل كل مكوّن إلا مع المكوّنات التي تقع فوقه أو تحته مباشرةً، إلا أنّ بعض أجهزة الاستشعار يمكنها تجاوز مركز أجهزة الاستشعار عند توفّره. يتم نقل الإشارات من التطبيقات إلى أدوات الاستشعار، كما يتم نقل البيانات من أدوات الاستشعار إلى التطبيقات.
![الطبقات وأصحاب حِزم أجهزة استشعار Android](https://source.android.google.cn/static/docs/core/interaction/sensors/images/ape_fwk_sensors.png?authuser=4&hl=ar)
الشكل 1: طبقات حِزمة أجهزة الاستشعار في Android ومالكوها المعنيون
SDK
تحصل التطبيقات على بيانات من أجهزة الاستشعار من خلال واجهة برمجة تطبيقات حزمة تطوير البرامج (SDK) الخاصة بأجهزة الاستشعار. يحتوي حِزم تطوير البرامج (SDK) على دوال لتعداد أجهزة الاستشعار المتاحة والتسجيل في أحد أجهزة الاستشعار.
عند التسجيل في أداة استشعار، يحدّد التطبيق معدّل أخذ العينات المفضّل ومتطلبات وقت الاستجابة.
- على سبيل المثال، قد يسجِّل أحد التطبيقات مقياس التسارع التلقائي، ويطلب الأحداث بمعدّل 100 هرتز، ويسمح بالإبلاغ عن الأحداث بمعدّل تأخُّر ثانية واحدة.
- سيتلقّى التطبيق أحداثًا من مقياس التسارع بمعدّل 100 هرتز على الأقل، وقد يتأخّر وصولها إلى ثانية واحدة.
اطّلِع على مستندات المطوّرين للحصول على مزيد من المعلومات عن حزمة SDK.
إطار العمل
يتولّى إطار العمل ربط التطبيقات المتعددة بـ HAL. وHAL نفسه مخصّص لعميل واحد. بدون حدوث هذا الربط المتعدّد على مستوى الإطار، يمكن لتطبيق واحد فقط الوصول إلى كل جهاز استشعار في أي وقت معيّن.
- عندما يسجِّل التطبيق الأول نفسه في أداة استشعار، يُرسِل إطار العمل طلبًا إلى HAL لتفعيل أداة الاستشعار.
- عند تسجيل تطبيقات إضافية في أداة الاستشعار نفسها، يأخذ الإطار المرجعي
في الاعتبار متطلبات كل تطبيق ويرسل المَعلمات المطلوبة المعدَّلة
إلى HAL.
- سيكون معدل أخذ العينات هو الحد الأقصى لمعدّلات أخذ العينات المطلوبة، ما يعني أنّ بعض التطبيقات ستتلقّى الأحداث بمعدّل أعلى من المعدّل الذي طلبته.
- سيكون الحد الأقصى لمُدد الاستجابة في إعداد التقارير هو الحد الأدنى لمُدد الاستجابة المطلوبة. إذا طلب تطبيق واحد جهاز استشعار واحدًا بحد أقصى لمعدّل استجابة إعداد التقارير يبلغ 0، ستتلقّى جميع التطبيقات الأحداث من هذا الجهاز الاستشعاري في الوضع المستمر حتى إذا طلبت بعض التطبيقات الجهاز الاستشعاري بحد أقصى لمعدّل استجابة إعداد التقارير غير صفري. يمكنك الاطّلاع على المعالجة المجمّعة لمزيد من التفاصيل.
- عندما يُلغي آخر تطبيق مسجَّل في أحد أجهزة الاستشعار تسجيله منه، تُرسِل منصّات التطوير طلبًا إلى HAL لإيقاف جهاز الاستشعار كي لا يتم استهلاك الطاقة بدون داعٍ.
تأثير تعدد الإرسال
وتوضّح الحاجة إلى طبقة تعدد الإرسال في الإطار بعض قرارات التصميم.
- عندما يطلب أحد التطبيقات معدّل تكرار تحليل عينات معيّنًا، لا يمكن التأكّد من أنّ الأحداث لن تصل بمعدّل أسرع. إذا طلب تطبيق آخر بيانات من أداة الاستشعار نفسها بمعدّل أسرع، سيتلقّى التطبيق الأول البيانات أيضًا بمعدّل سريع.
- ينطبق عدم الضمان نفسه على الحد الأقصى المطلوب لوقت استجابة إعداد التقارير: قد تتلقّى التطبيقات الأحداث بوقت استجابة أقل بكثير مما طلبته.
- بالإضافة إلى معدّل أخذ العينات والحد الأقصى لمُدد الاستجابة في إعداد التقارير، لا يمكن للتطبيقات
ضبط مَعلمات أجهزة الاستشعار.
- على سبيل المثال، تخيل أداة استشعار مادية يمكنها العمل في وضعَي "دقة عالية" و"طاقة منخفضة".
- لا يمكن استخدام أحد هذين الوضعَين فقط على جهاز Android، لأنّه بخلاف ذلك، يمكن أن يطلب أحد التطبيقات وضع الدقة العالية، ويطلب تطبيق آخر وضع استهلاك الطاقة المنخفض، ولن يكون بإمكان إطار العمل تلبية متطلبات كلا التطبيقَين. يجب أن يكون إطار العمل قادرًا دائمًا على إرضاء جميع العملاء، لذلك ليس هذا خيارًا.
- لا تتوفّر آلية لإرسال البيانات من التطبيقات إلى أدوات الاستشعار أو برامج تشغيلها. ويضمن ذلك عدم تمكّن تطبيق واحد من تعديل سلوك أجهزة الاستشعار، ما يؤدي إلى إيقاف التطبيقات الأخرى.
دمج أدوات الاستشعار
يقدّم إطار عمل Android تنفيذًا تلقائيًا لبعض أجهزة الاستشعار المركبة. عندما يتوفّر جيروسكوب ومقياس تسارع ومقياس مغناطيسي على الجهاز، ولكن لا يتوفّر متجه الدوران ومقياس الجاذبية ومقياس التسارع الخطي، ينفِّذ إطار العمل هذه الأدوات حتى تتمكّن التطبيقات من استخدامها.
لا يمكن لتنفيذ الإعداد التلقائي الوصول إلى كل البيانات التي يمكن لعمليات التنفيذ الأخرى الوصول إليها، ويجب تشغيله على وحدة المعالجة المركزية (SoC)، لذا فهو ليس دقيقًا أو فعّالاً في استخدام الطاقة بقدر ما يمكن أن تكون عمليات التنفيذ الأخرى. على قدر الإمكان، يجب أن يحدّد مصنعو الأجهزة أدوات الاستشعار المدمجة الخاصة بهم (مثل متجه الدوران وقوة الجاذبية والتسارع الخطي، بالإضافة إلى أدوات الاستشعار المركبة الأحدث مثل متجه دوران اللعبة) بدلاً من الاعتماد على هذا التنفيذ التلقائي. يمكن لصنّاع الأجهزة أيضًا أن يطلبوا من مورّدي شرائح الاستشعار تزويدهم بتطبيق.
لا يتم الاحتفاظ بتنفيذ الدمج التلقائي لبيانات أجهزة الاستشعار، وقد يؤدي ذلك إلى عدم اجتياز الأجهزة التي تعتمد عليه لاختبار CTS.
الخيارات المتقدمة
يتم توفير هذا القسم كمعلومات أساسية لأولئك الذين يحافظون على رمز إطار عمل "المشروع المفتوح المصدر لنظام Android" (AOSP). ولا ينطبق ذلك على مصنعي الأجهزة.
JNI
يستخدم إطار العمل Java Native Interface (JNI) المرتبط بـ android.hardware والموجود في الدليل frameworks/base/core/jni/
. يستدعي هذا الرمز
الرمز الأصلي من المستوى الأدنى للحصول على إذن الوصول إلى جهاز الاستشعار.
إطار عمل أصلي
يتم تعريف إطار العمل الأصلي في frameworks/native/
ويقدّم بديلاً أصليًا
لحزمة android.hardware. يطلب إطار العمل الأصلي وكلاء Binder IPC للحصول على إذن بالوصول إلى خدمات
الخاصة بأجهزة الاستشعار.
وحدات تنظيم بسحّاب IPC
تسهِّل الوكلاء لبروتوكول IPC في Binder عملية التواصل عبر حدود العمليات.
HAL
واجهة برمجة التطبيقات Sensors Hardware Abstraction Layer (HAL) هي الواجهة بين برامج تشغيل الأجهزة وإطار عمل Android. يتألّف من واجهة HAL واحدة sensors.h وتنفيذ HAL واحد نشير إليه باسم sensors.cpp.
يحدِّد مساهمو Android وAOSP الواجهة، ويقدّم المصنّع للجهاز عملية التنفيذ.
يمكن العثور على واجهة HAL الخاصة بجهاز الاستشعار في hardware/libhardware/include/hardware
.
اطّلِع على sensors.h
للحصول على تفاصيل إضافية.
دورة الإصدار
يحدِّد تنفيذ HAL إصدار واجهة HAL الذي
ينفذه من خلال ضبط your_poll_device.common.version
. يتم تحديد إصدارات واجهة HAL
الحالية في ملف sensors.h، وترتبط الوظائف بهذه الإصدارات.
يتيح إطار عمل Android حاليًا الإصدارَين 1.0 و1.3، ولكن سيتم قريبًا عدم السماح بالإصدار 1.0. توضِّح هذه المستندات سلوك الإصدار 1.3 الذي يجب ترقية جميع الأجهزة إليه. لمعرفة التفاصيل حول كيفية الترقية إلى الإصدار 1.3، يُرجى الاطّلاع على مقالة إيقاف إصدار HAL نهائيًا.
برنامج تشغيل النواة
تتفاعل برامج تشغيل أجهزة الاستشعار مع الأجهزة المادية. في بعض الحالات، يكون تنفيذ HAL وبرامج التشغيل هما عنصر البرنامج نفسه. في الحالات الأخرى، يطلب مُدمِج الأجهزة من الشركات المصنّعة لشرائح الاستشعار توفير برامج التشغيل، ولكنّهم هم من يكتبون رمز تنفيذ HAL.
في جميع الحالات، تقع مسؤولية تنفيذ HAL وبرامج تشغيل النواة على عاتق المصنّعين للأجهزة، ولا يوفّر نظام التشغيل Android طرقًا مفضّلة لكتابة هذه البرامج.
مركز الاستشعار
يمكن أن تتضمّن حزمة أجهزة الاستشعار في الجهاز بشكل اختياري مركز أجهزة استشعار، وهو مفيد في تنفيذ بعض العمليات الحسابية من المستوى المنخفض باستخدام طاقة منخفضة بينما يمكن أن يكون المعالج المتكامل في وضع تعليق. على سبيل المثال، يمكن إجراء عملية احتساب الخطوات أو دمج البيانات من أجهزة الاستشعار على هذه الشرائح. وهي أيضًا مكان جيد لتنفيذ تجميع بيانات أدوات الاستشعار، وإضافة قوائم انتظار الأجهزة للوصول أولاً إلى البيانات (FIFO) لأحداث أدوات الاستشعار. يمكنك الاطّلاع على المعالجة المجمّعة للحصول على مزيد من المعلومات.
ملاحظة: لتطوير ميزات جديدة في ContextHub تستخدم مصابيح LED أو أدوات استشعار جديدة، يمكنك أيضًا استخدام Neonkey SensorHub المتصل بأحد لوحات التطوير Hikey أو Hikey960.
تعتمد طريقة إنشاء مركز الاستشعار على البنية الأساسية. في بعض الأحيان، يكون هذا المعالج عبارة عن شريحة منفصلة، وفي أحيان أخرى يكون مضمّنًا في الشريحة نفسها التي تتضمّن مجموعة المعالجة المركزية (SoC). ومن أهم خصائص وحدة تحكّم الاستشعار أن تحتوي على ذاكرة كافية لتجميع البيانات وأن تستهلك طاقة قليلة جدًا لتفعيل استخدام أدوات استشعار Android المنخفضة الطاقة. تحتوي بعض وحدات تحكّم المستشعرات على وحدة تحكّم دقيق للعمليات الحسابية العامة، وأجهزة تسريع للأجهزة لتفعيل العمليات الحسابية ذات الطاقة المنخفضة جدًا لأجهزة الاستشعار ذات الطاقة المنخفضة.
لا يحدِّد نظام التشغيل Android بنية مركز الاستشعار وطريقة تواصله مع أجهزة الاستشعار ووحدة المعالجة المركزية (حافلة I2C وحافلة SPI وما إلى ذلك)، ولكن يجب أن يهدف إلى تقليل إجمالي استهلاك الطاقة.
من الخيارات التي يبدو أنّها لها تأثير كبير في بساطة التنفيذ أن يكون هناك خطان للمقاطعة من مركز الاستشعار إلى وحدة المعالجة المركزية: أحدهما للمقاطعات المتعلّقة بالتنشيط (لأجهزة استشعار التنشيط)، والآخر للمقاطعات المتعلّقة بغير التنشيط (لأجهزة الاستشعار غير المخصّصة للتنشيط).
أجهزة الاستشعار
هذه هي شرائح MEMs المادية التي تُجري عمليات القياس. في كثير من الحالات، تتوفّر عدة أدوات استشعار خارجية على الشريحة نفسها. على سبيل المثال، تتضمّن بعض الشرائح مقياس تسارع وجيروسكوب ومقياس مغناطيسي. (غالبًا ما يُطلق على هذه الشرائح اسم "شرائح التسارع بـ 9 محاور"، لأنّ كل أداة استشعار تقدّم بيانات على 3 محاور).
تحتوي بعض هذه الشرائح أيضًا على بعض المنطق لإجراء العمليات الحسابية المعتادة، مثل رصد الحركة ورصد الخطوات ودمج بيانات 9 أدوات استشعار.
على الرغم من أنّ متطلبات CDD واقتراحاته المتعلّقة بالقوة والدقة تستهدف أداة استشعار Android وليس أدوات الاستشعار المادية، إلا أنّ هذه المتطلبات تؤثّر في اختيار أدوات الاستشعار المادية. على سبيل المثال، يؤثر شرط الدقة في متجه دوران اللعبة في الدقة المطلوبة للمقياس المغناطيسي. على الشركة المصنّعة للجهاز تحديد متطلبات أجهزة الاستشعار المادية.