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

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

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

يتم التعبير عن قيم أحداث المستشعر من العديد من أجهزة الاستشعار في إطار محدد ثابت بالنسبة للجهاز.

محاور الجهاز المحمول

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

الشكل 1. نظام تنسيق (متعلق بجهاز محمول) يستخدمه Sensor API

محاور السيارات

في تطبيقات Android Automotive ، يتم تحديد المحاور فيما يتعلق بإطار هيكل السيارة. أصل الإطار المرجعي للسيارة هو مركز المحور الخلفي. يتم توجيه الإطار المرجعي للسيارة بحيث:

• يشير المحور X إلى اليمين وهو على مستوى أفقي ، عموديًا على مستوى تناظر المركبة.
• يشير المحور Y إلى الأمام وهو على مستوى أفقي.

الشكل 2. نظام الإحداثيات (بالنسبة لجهاز السيارة) المستخدم بواسطة Sensor API

الإطار المرجعي للسيارة هو نظام إحداثيات يميني. لذلك ، يشير المحور Z إلى الأعلى.

يتم محاذاة المحور Z للإطار المرجعي مع الجاذبية ، مما يعني أن كلا من المحور X والمحور Y أفقيان. نتيجة لذلك ، قد لا يمر المحور Y دائمًا عبر المحور الأمامي.

مجسات القاعدة

تتم تسمية أنواع المستشعرات الأساسية على اسم المستشعرات المادية التي تمثلها. تنقل هذه المستشعرات البيانات من مستشعر مادي واحد (على عكس المستشعرات المركبة التي تولد البيانات من أجهزة الاستشعار الأخرى). تتضمن أمثلة أنواع أجهزة الاستشعار الأساسية ما يلي:

• SENSOR_TYPE_ACCELEROMETER
• SENSOR_TYPE_GYROSCOPE
• SENSOR_TYPE_MAGNETOMETER

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

على سبيل المثال ، قد تختلف خصائص المستشعر الأساسي عن خصائص المستشعر المادي الأساسي في حالات الاستخدام التالية:

• شريحة جيروسكوب مصنفة بمدى تحيز 1 درجة / ثانية.
  • بعد معايرة المصنع ، يتم تطبيق تعويض درجة الحرارة وتعويض التحيز ، سيتم تقليل التحيز الفعلي لمستشعر Android ، وقد يصل إلى نقطة يكون فيها التحيز أقل من 0.01 درجة / ثانية.
  • في هذه الحالة ، نقول أن مستشعر Android به انحياز أقل من 0.01 درجة / ثانية ، على الرغم من أن ورقة بيانات المستشعر الأساسي ذكرت 1 درجة / ثانية.
• بارومتر باستهلاك طاقة 100 uW.
  • نظرًا لأن البيانات التي تم إنشاؤها يجب نقلها من الشريحة إلى SoC ، فقد تكون تكلفة الطاقة الفعلية لجمع البيانات من مستشعر مقياس الضغط الجوي أعلى بكثير ، على سبيل المثال 1000 uW.
  • في هذه الحالة ، نقول إن مستشعر Android لديه استهلاك طاقة يبلغ 1000 uW ، على الرغم من أن استهلاك الطاقة المقاس عند قياسات شريحة البارومتر هو 100uW.
• مقياس مغناطيسي يستهلك 100uW عند معايرته ، ولكنه يستهلك أكثر عند المعايرة.
  • قد يتطلب روتين المعايرة الخاص به تنشيط الجيروسكوب ، واستهلاك 5000 uW ، وتشغيل بعض الخوارزمية ، مما يكلف 900 uW أخرى.
  • في هذه الحالة ، نقول أن الحد الأقصى لاستهلاك الطاقة لمستشعر (مقياس المغناطيسية) Android هو 6000 uW.
  • في هذه الحالة ، يكون متوسط ​​استهلاك الطاقة هو المقياس الأكثر فائدة ، وهو ما يتم الإبلاغ عنه في الخصائص الثابتة للمستشعر من خلال HAL.

مقياس التسارع

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER) غير نشط

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

جميع القيم بوحدات SI (م / ث ^ 2) وتقيس تسارع الجهاز مطروحًا منه قوة الجاذبية على طول محاور الاستشعار الثلاثة.

فيما يلي بعض الأمثلة:

• يجب أن يكون معيار (x، y، z) قريبًا من الصفر في حالة السقوط الحر.
• عندما يكون الجهاز مسطحًا على طاولة ويتم دفعه على جانبه الأيسر نحو اليمين ، تكون قيمة التسارع x موجبة.
• عندما يكون الجهاز مسطحًا على طاولة ، تكون قيمة التسارع على طول z +9.81 alo ، وهو ما يتوافق مع تسارع الجهاز (0 m / s ^ 2) مطروحًا منه قوة الجاذبية (-9.81 m / s ^ 2).
• عندما يكون الجهاز مسطحًا على طاولة ويتم دفعه نحو السماء ، تكون قيمة التسارع أكبر من +9.81 ، وهو ما يتوافق مع تسارع الجهاز (+ A م / ث ^ 2) مطروحًا منه قوة الجاذبية (-9.81 م) / ق ^ 2).

يتم معايرة القراءات باستخدام:

• تعويض درجة الحرارة
• معايرة التحيز عبر الإنترنت
• معايرة الميزان عبر الإنترنت

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

يُبلغ مقياس التسارع أيضًا عن مدى الدقة التي يتوقعها أن تكون قراءاته من خلال sensors_event_t.acceleration.status . راجع SensorManager SENSOR_STATUS_* لمزيد من المعلومات حول القيم الممكنة لهذا الحقل.

درجة الحرارة المحيطة

وضع التقارير: عند التغيير

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE) غير نشط

يوفر هذا المستشعر درجة حرارة الغرفة (الغرفة) بالدرجات المئوية.

مستشعر المجال المغناطيسي

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD) غير نشط

SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD

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

يتم الإبلاغ عن القياس في الحقول x و y و z من sensors_event_t.magnetic وجميع القيم في micro-Tesla (uT).

يُبلغ مقياس المغنطيسية أيضًا عن مدى الدقة التي يتوقعها أن تكون قراءاته من خلال sensors_event_t.magnetic.status . راجع SensorManager SENSOR_STATUS_* لمزيد من المعلومات حول القيم الممكنة لهذا الحقل.

يتم معايرة القراءات باستخدام:

• تعويض درجة الحرارة
• معايرة الحديد اللين في المصنع (أو عبر الإنترنت)
• معايرة الحديد الصلب على الإنترنت

جيروسكوب

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_GYROSCOPE) بإرجاع مستشعر غير تنشيط

يقوم مستشعر الجيروسكوب بالإبلاغ عن معدل دوران الجهاز حول محاور الاستشعار الثلاثة.

يكون الدوران موجبًا في اتجاه عكس عقارب الساعة (القاعدة اليمنى). أي أن المراقب الذي ينظر من بعض المواقع الإيجابية على المحور x أو y أو z في جهاز موضوع على الأصل سيبلغ عن دوران إيجابي إذا بدا أن الجهاز يدور في عكس اتجاه عقارب الساعة. لاحظ أن هذا هو التعريف الرياضي القياسي للدوران الإيجابي ولا يتفق مع تعريف الفضاء الجوي للفة.

يتم الإبلاغ عن القياس في الحقول x و y و z من sensors_event_t.gyro وجميع القيم بالراديان في الثانية (راديان / ثانية).

يتم معايرة القراءات باستخدام:

• تعويض درجة الحرارة
• تعويض مقياس المصنع (أو عبر الإنترنت)
• معايرة التحيز عبر الإنترنت (لإزالة الانجراف)

يوضح الجيروسكوب أيضًا مدى الدقة التي يتوقع أن تكون قراءاته من خلالها من خلال sensors_event_t.gyro.status . راجع SensorManager SENSOR_STATUS_* لمزيد من المعلومات حول القيم الممكنة لهذا الحقل.

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

معدل ضربات القلب

وضع التقارير: عند التغيير

getDefaultSensor(SENSOR_TYPE_HEART_RATE) غير نشط

يقوم مستشعر معدل ضربات القلب بالإبلاغ عن معدل ضربات القلب الحالي للشخص الذي يلمس الجهاز.

يتم الإبلاغ عن معدل ضربات القلب الحالي في نبضة في الدقيقة (BPM) في sensors_event_t.heart_rate.bpm ويتم الإبلاغ عن حالة المستشعر في المستشعرات_ sensors_event_t.heart_rate.status . راجع SensorManager SENSOR_STATUS_* لمزيد من المعلومات حول القيم الممكنة لهذا الحقل. على وجه الخصوص ، عند التنشيط الأول ، ما لم يكن معروفًا أن الجهاز ليس على الجسم ، يجب تعيين حقل الحالة للحدث الأول على SENSOR_STATUS_UNRELIABLE . نظرًا لأن هذا المستشعر قيد التغيير ، يتم إنشاء الأحداث عندما وفقط عندما heart_rate.bpm أو heart_rate.status منذ الحدث الأخير. لا يتم إنشاء الأحداث أسرع من كل sampling_period .

sensor_t.requiredPermission يكون الإذن دائمًا SENSOR_PERMISSION_BODY_SENSORS .

خفيفة

وضع التقارير: عند التغيير

getDefaultSensor(SENSOR_TYPE_LIGHT) غير نشط

يقوم مستشعر الضوء بالإبلاغ عن الإضاءة الحالية بوحدات SI lux.

يتم الإبلاغ عن القياس في sensors_event_t.light .

القرب

وضع التقارير: عند التغيير

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

getDefaultSensor(SENSOR_TYPE_PROXIMITY) تنبيه

يسجل مستشعر القرب المسافة من المستشعر إلى أقرب سطح مرئي.

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

يتم الإبلاغ عن القياس بالسنتيمتر في sensors_event_t.distance . لاحظ أن بعض مستشعرات التقارب تدعم فقط القياس الثنائي "القريب" أو "البعيد". في هذه الحالة ، يُبلغ المستشعر عن قيمة sensor_t.maxRange الخاصة به في الحالة "far" وقيمة أقل من sensor_t.maxRange في الحالة "near".

ضغط

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_PRESSURE) غير نشط

يُبلغ مستشعر الضغط (المعروف أيضًا باسم البارومتر) عن الضغط الجوي في هيكتوباسكال (hPa).

يتم معايرة القراءات باستخدام

• تعويض درجة الحرارة
• معايرة تحيز المصنع
• معايرة مقياس المصنع

غالبًا ما يستخدم البارومتر لتقدير تغيرات الارتفاع. لتقدير الارتفاع المطلق ، يجب استخدام ضغط مستوى سطح البحر (يتغير تبعًا للطقس) كمرجع.

الرطوبة النسبية

وضع التقارير: عند التغيير

getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY) غير نشط

يقيس مستشعر الرطوبة النسبية رطوبة الهواء المحيط النسبية ويرجع قيمة بالنسبة المئوية.

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

ينشئ المستشعر المركب البيانات عن طريق معالجة و / أو دمج البيانات من واحد أو أكثر من أجهزة الاستشعار المادية. (يسمى أي مستشعر ليس مستشعرًا أساسيًا بالمستشعر المركب). تتضمن أمثلة المستشعرات المركبة ما يلي:

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

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

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

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

= مستشعر منخفض الطاقة

مجسات النشاط المركب

تسارع خطي

المستشعرات الفيزيائية الأساسية: مقياس التسارع والجيروسكوب (إن وجد) (أو مقياس المغناطيسية في حالة عدم وجود الجيروسكوب)

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION) غير نشط

يقوم مستشعر التسارع الخطي بالإبلاغ عن التسارع الخطي للجهاز في إطار المستشعر ، ولا يشمل الجاذبية.

الناتج مفاهيمي: خرج مقياس التسارع مطروحًا منه خرج مستشعر الجاذبية . تم الإبلاغ عنه في m / s ^ 2 في مجالات x و y و z من sensors_event_t.acceleration .

يجب أن تكون القراءات على جميع المحاور قريبة من 0 عندما يكون الجهاز غير متحرك.

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

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

حركة كبيرة

المستشعر المادي الأساسي: مقياس التسارع (أو آخر طالما أن الطاقة منخفضة)

وضع الإبلاغ: طلقة واحدة

طاقة منخفضة

استخدم فقط إصدار التنبيه لهذا المستشعر.

getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION) تنبيه

يتم تشغيل كاشف حركة مهم عند اكتشاف حركة مهمة : حركة قد تؤدي إلى تغيير في موقع المستخدم.

أمثلة على هذه الحركات الهامة هي:

• المشي أو ركوب الدراجات
• الجلوس في سيارة متحركة أو مدرب أو قطار

أمثلة على المواقف التي لا تؤدي إلى إحداث حركة كبيرة:

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

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

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

• الهدف من هذا المستشعر هو توفير الطاقة.
• إن بدء حدث عندما لا يتحرك المستخدم (إيجابية كاذبة) مكلف من حيث القوة ، لذا يجب تجنبه.
• يعد عدم تشغيل حدث أثناء تحرك المستخدم (سلبي كاذب) مقبولًا طالما لم يتم تكرار ذلك. إذا كان المستخدم يمشي لمدة 10 ثوانٍ ، فلن يُقبل عدم تشغيل حدث خلال تلك العشر ثوانٍ.

يبلغ كل حدث مستشعر 1 في sensors_event_t.data[0] .

كاشف الخطوة

المستشعر المادي الأساسي: مقياس التسارع (+ ربما الآخرين طالما أن الطاقة منخفضة)

وضع التقارير: خاص (حدث واحد لكل خطوة)

طاقة منخفضة

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR) غير نشط

يقوم كاشف الخطوة بإنشاء حدث في كل مرة يتخذ فيها المستخدم خطوة.

يتوافق الطابع الزمني للحدث sensors_event_t.timestamp مع الوقت الذي اصطدمت فيه القدم بالأرض ، مما أدى إلى تباين كبير في التسارع.

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

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

sampling_period_ns ليس لها أي تأثير على أجهزة الكشف عن الخطوة.

يبلغ كل حدث مستشعر 1 في sensors_event_t.data[0] .

عداد الخطوة

المستشعر المادي الأساسي: مقياس التسارع (+ ربما الآخرين طالما أن الطاقة منخفضة)

وضع التقارير: عند التغيير

طاقة منخفضة

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER) غير نشط

يقوم عداد الخطوات بالإبلاغ عن عدد الخطوات التي اتخذها المستخدم منذ آخر إعادة تشغيل أثناء التنشيط.

يتم الإبلاغ عن القياس على أنه uint64_t في sensors_event_t.step_counter ويتم إعادة تعيينه إلى الصفر فقط عند إعادة تشغيل النظام.

يتم تعيين الطابع الزمني للحدث على الوقت الذي تم فيه اتخاذ الخطوة الأخيرة لهذا الحدث.

انظر نوع مستشعر كاشف الخطوة للدلالة على وقت الخطوة.

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

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

كما هو مذكور في التفاعل ، أثناء عمل هذا المستشعر ، يجب ألا يعطل أي مستشعرات أخرى ، على وجه الخصوص ، مقياس التسارع ، الذي قد يكون قيد الاستخدام جيدًا.

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

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

كاشف الميل

المستشعر المادي الأساسي: مقياس التسارع (+ ربما الآخرين طالما أن الطاقة منخفضة)

وضع التقارير: خاص

طاقة منخفضة

استخدم فقط إصدار التنبيه لهذا المستشعر.

getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR) تنبيه

يقوم كاشف الإمالة بإنشاء حدث في كل مرة يتم فيها اكتشاف حدث الإمالة.

يتم تحديد حدث الإمالة من خلال اتجاه متوسط ​​الجاذبية للنافذة لمدة ثانيتين والذي يتغير بمقدار 35 درجة على الأقل منذ التنشيط أو الحدث الأخير الذي تم إنشاؤه بواسطة المستشعر. هنا الخوارزمية:

• reference_estimated_gravity = متوسط ​​قياسات مقياس التسارع خلال الثانية الأولى بعد التنشيط أو الجاذبية المقدرة عند إنشاء حدث الإمالة الأخير.
• current_estimated_gravity = متوسط ​​قياسات مقياس التسارع خلال آخر ثانيتين.
• الزناد عند angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees

لا ينبغي أن تؤدي التسارعات الكبيرة بدون تغيير في اتجاه الهاتف إلى حدوث حدث إمالة. على سبيل المثال ، لا ينبغي أن يؤدي الانعطاف الحاد أو التسارع القوي أثناء قيادة السيارة إلى حدوث ميل ، على الرغم من أن زاوية متوسط ​​التسارع قد تختلف بأكثر من 35 درجة. عادة ، يتم تنفيذ هذا المستشعر بمساعدة مقياس التسارع فقط. يمكن استخدام أجهزة استشعار أخرى أيضًا إذا لم تزيد من استهلاك الطاقة بشكل كبير. هذا مستشعر منخفض الطاقة يجب أن يسمح لشركة SoC بالدخول في وضع التعليق. لا تقم بمحاكاة هذا المستشعر في HAL. يبلغ كل حدث مستشعر 1 في sensors_event_t.data[0] .

مجسات الموقف المركب

ناقل الدوران

المستشعرات الفيزيائية الأساسية: مقياس التسارع ومقياس المغناطيسية والجيروسكوب

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR) غير نشط

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

• تشير X إلى الشرق وهي عرضية للأرض.
• يشير Y إلى الشمال وهو عرضي للأرض.
• يشير Z إلى السماء وهو عمودي على الأرض.

يتم تمثيل اتجاه الهاتف بالدوران اللازم لمحاذاة إحداثيات الشرق - الشمال - لأعلى مع إحداثيات الهاتف. أي أن تطبيق التدوير على إطار العالم (X ، Y ، Z) من شأنه أن يحاذيها مع إحداثيات الهاتف (x ، y ، z).

يمكن اعتبار الدوران بمثابة تدوير للهاتف بزاوية ثيتا حول محور rot_axis للانتقال من اتجاه الجهاز المرجعي (محاذاة من الشرق إلى الشمال إلى الأعلى) إلى اتجاه الجهاز الحالي. يتم ترميز الاستدارة على أنها أربع وحدات أقل من x ، y ، z ، w من وحدة رباعية:

• sensors_event_t.data[0] = rot_axis.x*sin(theta/2)
• sensors_event_t.data[1] = rot_axis.y*sin(theta/2)
• sensors_event_t.data[2] = rot_axis.z*sin(theta/2)
• sensors_event_t.data[3] = cos(theta/2)

أين:

• الحقول x و y و z rot_axis هي إحداثيات شرق-شمال-لأعلى لمتجه طول الوحدة الذي يمثل محور الدوران
• theta هي زاوية الدوران

الرباعي هو وحدة رباعية: يجب أن يكون من المعيار 1 . سيؤدي عدم التأكد من ذلك إلى سلوك العميل غير المنتظم.

بالإضافة إلى ذلك ، يبلغ هذا المستشعر عن دقة عنوان مقدرة:

sensors_event_t.data[4] = estimated_accuracy (بالراديان)

يجب أن يكون خطأ العنوان أقل من الدقة estimated_accuracy بنسبة 95٪ من الوقت. يجب أن يستخدم هذا المستشعر جيروسكوب كمدخل رئيسي لتغيير الاتجاه.

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

لعبة تناوب ناقلات

المستشعرات الفيزيائية الأساسية: مقياس التسارع والجيروسكوب (بدون مقياس مغناطيسي)

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR) غير نشط

يشبه مستشعر ناقل دوران اللعبة مستشعر ناقل الدوران ولكنه لا يستخدم المجال المغنطيسي الأرضي. لذلك لا يشير المحور Y إلى الشمال ولكن بدلاً من ذلك يشير إلى مرجع آخر. يُسمح لهذا المرجع بالانجراف بنفس الترتيب من حيث الحجم حيث ينجرف الجيروسكوب حول المحور Z.

راجع مستشعر ناقل الدوران للحصول على تفاصيل حول كيفية تعيين sensors_event_t.data[0-3] . لا يُبلغ هذا المستشعر عن دقة العنوان المقدرة: sensors_event_t.data[4] محجوز ويجب تعيينه على 0 .

في الحالة المثالية ، يجب أن يُبلغ الهاتف الذي يتم تدويره وإعادته إلى نفس اتجاه العالم الحقيقي عن نفس متجه دوران اللعبة.

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

الجاذبية

المستشعرات الفيزيائية الأساسية: مقياس التسارع والجيروسكوب (إن وجد) (أو مقياس المغناطيسية في حالة عدم وجود الجيروسكوب)

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_GRAVITY) غير نشط

يقوم مستشعر الجاذبية بالإبلاغ عن اتجاه وحجم الجاذبية في إحداثيات الجهاز.

تم الإبلاغ عن مكونات متجه الجاذبية في m / s ^ 2 في x و y و z مجالات sensors_event_t.acceleration .

عندما يكون الجهاز في حالة راحة ، يجب أن يكون خرج مستشعر الجاذبية مطابقًا لمقياس التسارع. على الأرض ، القدر حوالي 9.8 م / ث ^ 2.

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

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

ناقل الدوران المغنطيسي الأرضي

المستشعرات الفيزيائية الأساسية: مقياس التسارع ومقياس المغناطيسية (بدون جيروسكوب)

وضع التقارير: مستمر

طاقة منخفضة

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) بإرجاع مستشعر غير تنشيط

متجه الدوران المغنطيسي الأرضي مشابه لمستشعر ناقل الدوران ولكن باستخدام مقياس مغناطيسي ولا يوجد جيروسكوب.

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

راجع مستشعر ناقل الدوران للحصول على تفاصيل حول كيفية ضبط sensors_event_t.data[0-4] .

تمامًا مثل مستشعر ناقل الدوران ، يجب أن يكون خطأ العنوان أقل من الدقة المقدرة ( sensors_event_t.data[4] ) 95٪ من الوقت.

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

الاتجاه (مهمل)

المستشعرات الفيزيائية الأساسية: مقياس التسارع ومقياس المغناطيسية وجيروسكوب (إن وجد)

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_ORIENTATION) غير نشط

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

يقوم مستشعر التوجيه بالإبلاغ عن موقف الجهاز. يتم الإبلاغ عن القياسات بالدرجات في مجالات x و y و z الخاصة sensors_event_t.orientation :

• sensors_event_t.orientation.x : السمت ، الزاوية بين اتجاه الشمال المغناطيسي والمحور Y ، حول المحور Z ( 0<=azimuth<360 ). 0 = الشمال ، 90 = الشرق ، 180 = الجنوب ، 270 = الغرب.
• sensors_event_t.orientation.y : الملعب ، الدوران حول المحور X ( -180<=pitch<=180 ) ، مع القيم الموجبة عندما يتحرك المحور Z نحو المحور Y.
• sensors_event_t.orientation.z : الدوران ، الدوران حول المحور Y ( -90<=roll<=90 ) ، بقيم موجبة عندما يتحرك المحور X نحو المحور Z.

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

الشكل 3. الاتجاه بالنسبة للجهاز

يختلف هذا التعريف عن الانحراف والخطوة واللفافة المستخدمة في الطيران حيث يكون المحور X على طول الجانب الطويل من الطائرة (من الذيل إلى الأنف).

يشير مستشعر التوجيه أيضًا إلى مدى الدقة التي يتوقع أن تكون قراءاته من خلالها من خلال sensors_event_t.orientation.status . راجع SensorManager SENSOR_STATUS_* لمزيد من المعلومات حول القيم الممكنة لهذا الحقل.

مجسات غير معايرة

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

التسارع غير معاير

المستشعر المادي الأساسي: مقياس التسارع

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED) غير نشط

يشير مستشعر التسارع غير المعاير إلى تسارع الجهاز على طول محاور المستشعر الثلاثة دون أي تصحيح للانحياز (يتم تطبيق انحياز المصنع وتعويض درجة الحرارة على القياسات غير المُعايرة) ، جنبًا إلى جنب مع تقدير التحيز. جميع القيم في وحدات SI (م / ث ^ 2) ويتم الإبلاغ عنها في مجالات sensors_event_t.uncalibrated_accelerometer :

• x_uncalib : تسريع (بدون تعويض التحيز) على طول المحور X.
• y_uncalib : تسارع (بدون تعويض التحيز) على طول المحور ص
• z_uncalib : تسريع (بدون تعويض التحيز) على طول المحور Z.
• x_bias : التحيز المقدر على طول المحور X.
• y_bias : التحيز المقدر على طول المحور ص
• z_bias : التحيز المقدر على طول المحور Z.

الجيروسكوب غير معاير

المستشعر المادي الأساسي: الجيروسكوب

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED) بإرجاع مستشعر غير تنشيط

يوضح الجيروسكوب غير المعاير معدل الدوران حول محاور المستشعر دون تطبيق تعويض التحيز عليها ، إلى جانب تقدير التحيز. جميع القيم بالراديان / بالثانية ويتم الإبلاغ عنها في مجالات sensors_event_t.uncalibrated_gyro :

• x_uncalib : السرعة الزاوية (بدون تعويض الانجراف) حول المحور X.
• y_uncalib : السرعة الزاوية (بدون تعويض الانجراف) حول المحور Y.
• z_uncalib : السرعة الزاوية (بدون تعويض الانجراف) حول المحور Z.
• x_bias : الانجراف المقدر حول المحور X.
• y_bias : الانجراف المقدر حول المحور ص
• z_bias : الانجراف المقدر حول المحور Z.

من الناحية المفاهيمية ، فإن القياس غير المعاير هو مجموع القياس المعاير وتقدير التحيز: _uncalibrated = _calibrated + _bias .

من المتوقع أن تقفز قيم x_bias و y_bias و z_bias بمجرد أن يتغير تقدير التحيز ، ويجب أن تكون مستقرة بقية الوقت.

راجع تعريف مستشعر الجيروسكوب للحصول على تفاصيل حول نظام الإحداثيات المستخدم.

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

إذا كان هذا المستشعر موجودًا ، فيجب أن يكون مستشعر الجيروسكوب المقابل موجودًا أيضًا ويجب أن يشترك كلا المستشعرين في قيم sensor_t.vendor sensor_t.name

المجال المغناطيسي غير معاير

المستشعر المادي الأساسي: مقياس المغناطيسية

وضع التقارير: مستمر

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED) غير تنشيط

يشير مستشعر المجال المغناطيسي غير المعاير إلى المجال المغناطيسي المحيط مع تقدير معايرة الحديد الصلب. جميع القيم في micro-Tesla (uT) ويتم الإبلاغ عنها في مجالات sensors_event_t.uncalibrated_magnetic :

• x_uncalib : مجال مغناطيسي (بدون تعويض الحديد الصلب) على طول المحور X.
• y_uncalib : مجال مغناطيسي (بدون تعويض الحديد الصلب) على طول المحور ص
• z_uncalib : مجال مغناطيسي (بدون تعويض الحديد الصلب) على طول المحور Z.
• x_bias : تقدير انحياز الحديد الصلب على طول المحور X.
• y_bias : تقدير انحياز الحديد الصلب على طول المحور ص
• z_bias : تقدير انحياز الحديد الصلب على طول المحور Z.

من الناحية المفاهيمية ، فإن القياس غير المعاير هو مجموع القياس المعاير وتقدير التحيز: _uncalibrated = _calibrated + _bias .

يسمح مقياس المغناطيسية غير المعاير لخوارزميات المستوى الأعلى بالتعامل مع تقدير الحديد الصلب السيئ. من المتوقع أن تقفز قيم x_bias و y_bias و z_bias بمجرد أن يتغير تقدير قيمة الحديد الصلب ، ويجب أن تكون مستقرة بقية الوقت.

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

إذا كان هذا المستشعر موجودًا ، فيجب أن يكون مستشعر المجال المغناطيسي المقابل موجودًا ويجب أن يشترك كلا sensor_t.vendor في نفس قيم sensor_t.name .

زاوية المفصلة

وضع التقارير: عند التغيير

getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) أداة استشعار التنبيه

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

حساسات التفاعل المركبة

تستخدم بعض المستشعرات في الغالب لاكتشاف التفاعلات مع المستخدم. We don't define how those sensors must be implemented, but they must be low power and it's the responsibility of the device manufacturer to verify their quality in terms of user experience.

Wake up gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_WAKE_GESTURE) returns a wake-up sensor

A wake up gesture sensor enables waking up the device based on a device specific motion. When this sensor triggers, the device behaves as if the power button was pressed, turning the screen on. This behavior (turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings don't impact the behavior of the sensor: only whether the framework turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.

This sensor must be low power, as it's likely to be activated 24/7.

Each sensor event reports 1 in sensors_event_t.data[0] .

Pick up gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE) returns a wake-up sensor

A pick-up gesture sensor triggers when the device is picked up regardless of wherever it was before (desk, pocket, bag).

Each sensor event reports 1 in sensors_event_t.data[0] .

Glance gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE) returns a wake-up sensor

A glance gesture sensor enables briefly turning the screen on to enable the user to glance content on screen based on a specific motion. When this sensor triggers, the device will turn the screen on momentarily to allow the user to glance notifications or other content while the device remains locked in a non-interactive state (dozing), then the screen will turn off again. This behavior (briefly turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings do not impact the behavior of the sensor: only whether the framework briefly turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.

This sensor must be low power, as it's likely to be activated 24/7. Each sensor event reports 1 in sensors_event_t.data[0] .

Limited axes IMU sensors

Available from Android 13, limited axes IMU sensors are sensors that support use cases where not all three axes (x, y, z) are available. Standard IMU types in Android (such as SENSOR_TYPE_ACCELEROMETER and SENSOR_TYPE_GYROSCOPE ) assume that all three axes are supported. However, not all form factors and devices support 3-axis accelerometers and 3-axis gyroscopes.

Accelerometer limited axes

Underlying physical sensors: Accelerometer

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES) returns a non-wake-up sensor

An accelerometer limited axes sensor is equivalent to TYPE_ACCELEROMETER but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the acceleration value for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the acceleration values for unused axes to 0 , instead of having undefined values.

Gyroscope limited axes

Underlying physical sensors: Gyroscope

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES) returns a non-wake-up sensor

A gyroscope limited axes sensor is equivalent to TYPE_GYROSCOPE but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the angular speed value for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the angular speed values for unused axes to 0 .

Accelerometer limited axes uncalibrated

Underlying physical sensors: Accelerometer

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED) returns a non-wake-up sensor

An accelerometer limited axes uncalibrated sensor is equivalent to TYPE_ACCELEROMETER_UNCALIBRATED but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the acceleration and bias values for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the acceleration and bias values for unused axes to 0 .

Gyroscope limited axes uncalibrated

Underlying physical sensors: Gyroscope

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED) returns a non-wake-up sensor

A gyroscope limited axes uncalibrated sensor is equivalent to TYPE_GYROSCOPE_UNCALIBRATED but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the angular speed and drift values for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the angular speed and drift values for unused axes to 0 .

Composite limited axes IMU

Underlying physical sensors: Any combination of 3-axis accelerometer, 3-axis gyroscope, 3-axis accelerometer uncalibrated, and 3-axis gyroscope uncalibrated sensors.

Reporting-mode: Continuous

A composite limited axes IMU sensor is equivalent to a limited axes IMU sensor but instead of being supported at the HAL, it converts the 3-axis sensor data into the equivalent limited axes variants. These composite sensors are only enabled for automotive devices.

The following table shows an example conversion from a standard 3-axis accelerometer to a composite limited axes accelerometer.

Automotive sensors

Sensors to support automotive use cases.

Heading

Underlying physical sensors: Any combination of GPS, magnetometer, accelerometer, and gyroscope.

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_HEADING) returns a non-wake-up sensor

Available from Android 13, a heading sensor measures the direction in which the device is pointing relative to true north in degrees. The heading sensor includes two SensorEvent values. One for the measured device heading and one for the accuracy of the provided heading value.

Heading values reported by this sensor must be between 0.0 (inclusive) and 360.0 (exclusive), with 0 indicating north, 90 east, 180 south, and 270 west.

Accuracy for this sensor is defined at 68 percent confidence. In the case where the underlying distribution is Gaussian normal, the accuracy is one standard deviation. For example, if the heading sensor returns a heading value of 60 degrees and an accuracy value of 10 degrees, there's a 68 percent probability of the true heading being between 50 degrees and 70 degrees.

This section describes sensor axes, base sensors, and composite sensors (activity, attitude, uncalibrated, and interaction).

Sensor axes

Sensor event values from many sensors are expressed in a specific frame that is static relative to the device.

Mobile device axes

The Sensor API is relative only to the natural orientation of the screen (axes aren't swapped when the device's screen orientation changes.

Figure 1. Coordinate system (relative to a mobile device) used by the Sensor API

Automotive axes

In Android Automotive implementations, axes are defined with respect to the vehicle body frame. The origin of the vehicle reference frame is the center of the rear axle. The vehicle reference frame is oriented so that the:

• X-axis points to the right and is on a horizontal plane, perpendicular to the vehicle plane of symmetry.
• Y-axis points forward and is on a horizontal plane.

Figure 2. Coordinate system (relative to an automotive device) used by the Sensor API

The vehicle reference frame is a right-handed coordinate system. Therefore, the Z-axis points up.

The Z-axis of the reference frame is aligned to gravity, which means that the X-axis and Y-axis are both horizontal. As a result, the Y-axis may not always go through the front axle.

Base sensors

Base sensor types are named after the physical sensors they represent. These sensors relay data from a single physical sensor (as opposed to composite sensors that generate data out of other sensors). Examples of base sensor types include:

• SENSOR_TYPE_ACCELEROMETER
• SENSOR_TYPE_GYROSCOPE
• SENSOR_TYPE_MAGNETOMETER

However, base sensors aren't equal to and shouldn't be confused with their underlying physical sensor. The data from a base sensor is not the raw output of the physical sensor because corrections (such as bias compensation and temperature compensation) are applied.

For example, the characteristics of a base sensor might be different from the characteristics of its underlying physical sensor in the following use cases:

• A gyroscope chip rated to have a bias range of 1 deg/sec.
  • After factory calibration, temperature compensation and bias compensation are applied, the actual bias of the Android sensor will be reduced, may be to a point where the bias is guaranteed to be below 0.01 deg/sec.
  • In this situation, we say that the Android sensor has a bias below 0.01 deg/sec, even though the data sheet of the underlying sensor said 1 deg/sec.
• A barometer with a power consumption of 100 uW.
  • Because the generated data needs to be transported from the chip to the SoC, the actual power cost to gather data from the barometer Android sensor might be much higher, for example 1000 uW.
  • In this situation, we say that the Android sensor has a power consumption of 1000 uW, even though the power consumption measured at the barometer chip leads is 100uW.
• A magnetometer that consumes 100uW when calibrated, but consumes more when calibrating.
  • Its calibration routine might require activating the gyroscope, consuming 5000 uW, and running some algorithm, costing another 900 uW.
  • In this situation, we say that the maximum power consumption of the (magnetometer) Android sensor is 6000 uW.
  • In this case, the average power consumption is the more useful measure, and it's what is reported in the sensor static characteristics through the HAL.

Accelerometer

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER) returns a non-wake-up sensor

An accelerometer sensor reports the acceleration of the device along the three sensor axes. The measured acceleration includes both the physical acceleration (change of velocity) and the gravity. The measurement is reported in the x, y, and z fields of sensors_event_t.acceleration.

All values are in SI units (m/s^2) and measure the acceleration of the device minus the force of gravity along the three sensor axes.

Here are examples:

• The norm of (x, y, z) should be close to 0 when in free fall.
• When the device lies flat on a table and is pushed on its left side toward the right, the x acceleration value is positive.
• When the device lies flat on a table, the acceleration value along z is +9.81 alo, which corresponds to the acceleration of the device (0 m/s^2) minus the force of gravity (-9.81 m/s^2).
• When the device lies flat on a table and is pushed toward the sky, the acceleration value is greater than +9.81, which corresponds to the acceleration of the device (+A m/s^2) minus the force of gravity (-9.81 m/s^2).

The readings are calibrated using:

• Temperature compensation
• Online bias calibration
• Online scale calibration

The bias and scale calibration must only be updated while the sensor is deactivated, so as to avoid causing jumps in values during streaming.

The accelerometer also reports how accurate it expects its readings to be through sensors_event_t.acceleration.status . See the SensorManager 's SENSOR_STATUS_* constants for more information on possible values for this field.

Ambient temperature

Reporting-mode: On-change

getDefaultSensor(SENSOR_TYPE_AMBIENT_TEMPERATURE) returns a non-wake-up sensor

This sensor provides the ambient (room) temperature in degrees Celsius.

Magnetic field sensor

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD) returns a non-wake-up sensor

SENSOR_TYPE_GEOMAGNETIC_FIELD == SENSOR_TYPE_MAGNETIC_FIELD

A magnetic field sensor (also known as magnetometer) reports the ambient magnetic field, as measured along the three sensor axes.

The measurement is reported in the x, y, and z fields of sensors_event_t.magnetic and all values are in micro-Tesla (uT).

The magnetometer also reports how accurate it expects its readings to be through sensors_event_t.magnetic.status . See the SensorManager 's SENSOR_STATUS_* constants for more information on possible values for this field.

The readings are calibrated using:

• Temperature compensation
• Factory (or online) soft-iron calibration
• Online hard-iron calibration

Gyroscope

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_GYROSCOPE) returns a non-wake-up sensor

A gyroscope sensor reports the rate of rotation of the device around the three sensor axes.

Rotation is positive in the counterclockwise direction (right-hand rule). That is, an observer looking from some positive location on the x, y, or z axis at a device positioned on the origin would report positive rotation if the device appeared to be rotating counter clockwise. Note that this is the standard mathematical definition of positive rotation and does not agree with the aerospace definition of roll.

The measurement is reported in the x, y, and z fields of sensors_event_t.gyro and all values are in radians per second (rad/s).

The readings are calibrated using:

• Temperature compensation
• Factory (or online) scale compensation
• Online bias calibration (to remove drift)

The gyroscope also reports how accurate it expects its readings to be through sensors_event_t.gyro.status . See the SensorManager 's SENSOR_STATUS_* constants for more information on possible values for this field.

The gyroscope can't be emulated based on magnetometers and accelerometers, as this would cause it to have reduced local consistency and responsiveness. It must be based on a usual gyroscope chip.

Heart Rate

Reporting-mode: On-change

getDefaultSensor(SENSOR_TYPE_HEART_RATE) returns a non-wake-up sensor

A heart rate sensor reports the current heart rate of the person touching the device.

The current heart rate in beats per minute (BPM) is reported in sensors_event_t.heart_rate.bpm and the status of the sensor is reported in sensors_event_t.heart_rate.status . See the SensorManager 's SENSOR_STATUS_* constants for more information on possible values for this field. In particular, upon the first activation, unless the device is known to not be on the body, the status field of the first event must be set to SENSOR_STATUS_UNRELIABLE . Because this sensor is on-change, events are generated when and only when heart_rate.bpm or heart_rate.status have changed since the last event. The events are generated no faster than every sampling_period .

sensor_t.requiredPermission is always SENSOR_PERMISSION_BODY_SENSORS .

Light

Reporting-mode: On-change

getDefaultSensor(SENSOR_TYPE_LIGHT) returns a non-wake-up sensor

A light sensor reports the current illumination in SI lux units.

The measurement is reported in sensors_event_t.light .

Proximity

Reporting-mode: On-change

Usually defined as a wake-up sensor

getDefaultSensor(SENSOR_TYPE_PROXIMITY) returns a wake-up sensor

A proximity sensor reports the distance from the sensor to the closest visible surface.

Up to Android 4.4, the proximity sensors were always wake-up sensors, waking up the SoC when detecting a change in proximity. After Android 4.4, we advise to implement the wake-up version of this sensor first, as it's the one that is used to turn the screen on and off while making phone calls.

The measurement is reported in centimeters in sensors_event_t.distance . Note that some proximity sensors only support a binary "near" or "far" measurement. In this case, the sensor report its sensor_t.maxRange value in the "far" state and a value less than sensor_t.maxRange in the "near" state.

Pressure

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_PRESSURE) returns a non-wake-up sensor

A pressure sensor (also known as barometer) reports the atmospheric pressure in hectopascal (hPa).

The readings are calibrated using

• Temperature compensation
• Factory bias calibration
• Factory scale calibration

The barometer is often used to estimate elevation changes. To estimate absolute elevation, the sea-level pressure (changing depending on the weather) must be used as a reference.

Relative humidity

Reporting-mode: On-change

getDefaultSensor(SENSOR_TYPE_RELATIVE_HUMIDITY) returns a non-wake-up sensor

A relative humidity sensor measures relative ambient air humidity and returns a value in percent.

Composite sensor types

A composite sensor generates data by processing and/or fusing data from one or several physical sensors. (Any sensor that isn't a base sensor is called a composite sensor.) Examples of composite sensors include:

• Step detector and significant motion , which are usually based on an accelerometer, but could be based on other sensors as well, if the power consumption and accuracy was acceptable.
• Game rotation vector , based on an accelerometer and a gyroscope.
• Uncalibrated gyroscope , which is similar to the gyroscope base sensor, but with the bias calibration being reported separately instead of being corrected in the measurement.

As with base sensors, the characteristics of the composite sensors come from the characteristics of their final data. For example, the power consumption of a game rotation vector is probably equal to the sum of the power consumptions of the accelerometer chip, the gyroscope chip, the chip processing the data, and the buses transporting the data. As another example, the drift of a game rotation vector depends as much on the quality of the calibration algorithm as on the physical sensor characteristics.

The following table lists available composite sensor types. Each composite sensor relies on data from one or several physical sensors. Avoid choosing other underlying physical sensors to approximate results as they provide a poor user experience.

Sensor type	Category	Underlying physical sensors	Reporting mode
Game rotation vector	Attitude	Accelerometer, gyroscope, MUST NOT USE magnetometer	Continuous
Geomagnetic rotation vector	Attitude	Accelerometer, magnetometer, MUST NOT USE gyroscope	Continuous
Glance gesture	Interaction	Undefined	One-shot
Gravity	Attitude	Accelerometer, gyroscope	Continuous
Gyroscope uncalibrated	Uncalibrated	Gyroscope	Continuous
Linear acceleration	Activity	Accelerometer, gyroscope (if present), or magnetometer (if gyro not present)	Continuous
Magnetic field uncalibrated	Uncalibrated	Magnetometer	Continuous
Orientation (deprecated)	Attitude	Accelerometer, magnetometer, gyroscope (if present)	Continuous
Pick up gesture	Interaction	Undefined	One-shot
Rotation vector	Attitude	Accelerometer, magnetometer, gyroscope	Continuous
Significant motion	Activity	Accelerometer (or another as long as very low power)	One-shot
Step counter	Activity	Accelerometer	On-change
Step detector	Activity	Accelerometer	Special
Tilt detector	Activity	Accelerometer	Special
Wake up gesture	Interaction	Undefined	One-shot

= Low power sensor

Activity composite sensors

Linear acceleration

Underlying physical sensors: Accelerometer and (if present) gyroscope (or magnetometer if gyroscope not present)

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_LINEAR_ACCELERATION) returns a non-wake-up sensor

A linear acceleration sensor reports the linear acceleration of the device in the sensor frame, not including gravity.

The output is conceptually: output of the accelerometer minus the output of the gravity sensor . It's reported in m/s^2 in the x, y, and z fields of sensors_event_t.acceleration .

Readings on all axes should be close to 0 when the device is immobile.

If the device possesses a gyroscope, the linear acceleration sensor must use the gyroscope and accelerometer as input.

If the device doesn't possess a gyroscope, the linear acceleration sensor must use the accelerometer and the magnetometer as input.

Significant motion

Underlying physical sensor: Accelerometer (or another as long as low power)

Reporting-mode: One-shot

Low power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_SIGNIFICANT_MOTION) returns a wake-up sensor

A significant motion detector triggers when detecting a significant motion : a motion that might lead to a change in the user location.

Examples of such significant motions are:

• Walking or biking
• Sitting in a moving car, coach, or train

Examples of situations that don't trigger significant motion:

• Phone in pocket and person isn't moving
• Phone is on a table and the table shakes a bit due to nearby traffic or washing machine

At the high level, the significant motion detector is used to reduce the power consumption of location determination. When the localization algorithms detect that the device is static, they can switch to a low-power mode, where they rely on significant motion to wake the device up when the user is changing location.

This sensor must be low power. It makes a tradeoff for power consumption that may result in a small amount of false negatives. This is done for a few reasons:

• The goal of this sensor is to save power.
• Triggering an event when the user isn't moving (false positive) is costly in terms of power, so it should be avoided.
• Not triggering an event when the user is moving (false negative) is acceptable as long as it isn't done repeatedly. If the user has been walking for 10 seconds, not triggering an event within those 10 seconds isn't acceptable.

Each sensor event reports 1 in sensors_event_t.data[0] .

Step detector

Underlying physical sensor: Accelerometer (+ possibly others as long as low power)

Reporting-mode: Special (one event per step taken)

Low power

getDefaultSensor(SENSOR_TYPE_STEP_DETECTOR) returns a non-wake-up sensor

A step detector generates an event each time a step is taken by the user.

The timestamp of the event sensors_event_t.timestamp corresponds to when the foot hit the ground, generating a high variation in acceleration.

Compared to the step counter, the step detector should have a lower latency (less than two seconds). Both the step detector and the step counter detect when the user is walking, running, and walking up the stairs. They shouldn't trigger when the user is biking, driving, or in other vehicles.

This sensor must be low power. That is, if the step detection cannot be done in hardware, this sensor shouldn't be defined. In particular, when the step detector is activated and the accelerometer isn't, only steps should trigger interrupts (not every accelerometer reading).

sampling_period_ns has no impact on step detectors.

Each sensor event reports 1 in sensors_event_t.data[0] .

Step counter

Underlying physical sensor: Accelerometer (+ possibly others as long as low power)

Reporting-mode: On-change

Low-power

getDefaultSensor(SENSOR_TYPE_STEP_COUNTER) returns a non-wake-up sensor

A step counter reports the number of steps taken by the user since the last reboot while activated.

The measurement is reported as a uint64_t in sensors_event_t.step_counter and is reset to zero only on a system reboot.

The timestamp of the event is set to the time when the last step for that event was taken.

See the Step detector sensor type for the signification of the time of a step.

Compared to the step detector, the step counter can have a higher latency (up to 10 seconds). Thanks to this latency, this sensor has a high accuracy; the step count after a full day of measures should be within 10% of the actual step count. Both the step detector and the step counter detect when the user is walking, running, and walking up the stairs. They shouldn't trigger when the user is biking, driving, or in other vehicles.

The hardware must ensure the internal step count never overflows. The minimum size of the hardware's internal counter shall be 16 bits. In case of imminent overflow (at most every ~2^16 steps), the SoC can be woken up so the driver can do the counter maintenance.

As stated in Interaction , while this sensor operates, it shall not disrupt any other sensors, in particular, the accelerometer, which might very well be in use.

If a particular device can't support these modes of operation, then this sensor type must not be reported by the HAL. That is, it isn't acceptable to "emulate" this sensor in the HAL.

This sensor must be low power. That is, if the step detection can't be done in hardware, this sensor shouldn't be defined. In particular, when the step counter is activated and the accelerometer isn't, only steps should trigger interrupts (not accelerometer data).

Tilt detector

Underlying physical sensor: Accelerometer (+ possibly others as long as low power)

Reporting-mode: Special

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_TILT_DETECTOR) returns a wake-up sensor

A tilt detector generates an event each time a tilt event is detected.

A tilt event is defined by the direction of the 2-seconds window average gravity changing by at least 35 degrees since the activation or the last event generated by the sensor. Here is the algorithm:

• reference_estimated_gravity = average of accelerometer measurements over the first second after activation or the estimated gravity when the last tilt event was generated.
• current_estimated_gravity = average of accelerometer measurements over the last 2 seconds.
• Trigger when angle(reference_estimated_gravity, current_estimated_gravity) > 35 degrees

Large accelerations without a change in phone orientation shouldn't trigger a tilt event. For example, a sharp turn or strong acceleration while driving a car shouldn't trigger a tilt event, even though the angle of the average acceleration might vary by more than 35 degrees. Typically, this sensor is implemented with the help of only an accelerometer. Other sensors can be used as well if they do not increase the power consumption significantly. This is a low-power sensor that should allow the SoC to go into suspend mode. Do not emulate this sensor in the HAL. Each sensor event reports 1 in sensors_event_t.data[0] .

Attitude composite sensors

Rotation vector

Underlying physical sensors: Accelerometer, magnetometer, and gyroscope

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_ROTATION_VECTOR) returns a non-wake-up sensor

A rotation vector sensor reports the orientation of the device relative to the East-North-Up coordinates frame. It's usually obtained by integration of accelerometer, gyroscope, and magnetometer readings. The East-North-Up coordinate system is defined as a direct orthonormal basis where:

• X points east and is tangential to the ground.
• Y points north and is tangential to the ground.
• Z points towards the sky and is perpendicular to the ground.

The orientation of the phone is represented by the rotation necessary to align the East-North-Up coordinates with the phone's coordinates. That is, applying the rotation to the world frame (X,Y,Z) would align them with the phone coordinates (x,y,z).

The rotation can be seen as rotating the phone by an angle theta around an axis rot_axis to go from the reference (East-North-Up aligned) device orientation to the current device orientation. The rotation is encoded as the four unit-less x, y, z, w components of a unit quaternion:

• sensors_event_t.data[0] = rot_axis.x*sin(theta/2)
• sensors_event_t.data[1] = rot_axis.y*sin(theta/2)
• sensors_event_t.data[2] = rot_axis.z*sin(theta/2)
• sensors_event_t.data[3] = cos(theta/2)

Where:

• The x, y, and z fields of rot_axis are the East-North-Up coordinates of a unit length vector representing the rotation axis
• theta is the rotation angle

The quaternion is a unit quaternion: It must be of norm 1 . Failure to ensure this will cause erratic client behavior.

In addition, this sensor reports an estimated heading accuracy:

sensors_event_t.data[4] = estimated_accuracy (in radians)

The heading error must be less than estimated_accuracy 95% of the time. This sensor must use a gyroscope as the main orientation change input.

This sensor also uses accelerometer and magnetometer input to make up for gyroscope drift, and it can't be implemented using only the accelerometer and magnetometer.

Game rotation vector

Underlying physical sensors: Accelerometer and gyroscope (no magnetometer)

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_GAME_ROTATION_VECTOR) returns a non-wake-up sensor

A game rotation vector sensor is similar to a rotation vector sensor but not using the geomagnetic field. Therefore the Y axis doesn't point north but instead to some other reference. That reference is allowed to drift by the same order of magnitude as the gyroscope drifts around the Z axis.

See the Rotation vector sensor for details on how to set sensors_event_t.data[0-3] . This sensor doesn't report an estimated heading accuracy: sensors_event_t.data[4] is reserved and should be set to 0 .

In an ideal case, a phone rotated and returned to the same real-world orientation should report the same game rotation vector.

This sensor must be based on a gyroscope and an accelerometer. It can't use magnetometer as an input, besides, indirectly, through estimation of the gyroscope bias.

Gravity

Underlying physical sensors: Accelerometer and (if present) gyroscope (or magnetometer if gyroscope not present)

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_GRAVITY) returns a non-wake-up sensor

A gravity sensor reports the direction and magnitude of gravity in the device's coordinates.

The gravity vector components are reported in m/s^2 in the x, y, and z fields of sensors_event_t.acceleration .

When the device is at rest, the output of the gravity sensor should be identical to that of the accelerometer. On Earth, the magnitude is around 9.8 m/s^2.

If the device possesses a gyroscope, the gravity sensor must use the gyroscope and accelerometer as input.

If the device doesn't possess a gyroscope, the gravity sensor must use the accelerometer and the magnetometer as input.

Geomagnetic rotation vector

Underlying physical sensors: Accelerometer and magnetometer (no gyroscope)

Reporting-mode: Continuous

Low-power

getDefaultSensor(SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR) returns a non-wake-up sensor

A geomagnetic rotation vector is similar to a rotation vector sensor but using a magnetometer and no gyroscope.

This sensor must be based on a magnetometer. It can't be implemented using a gyroscope, and gyroscope input can't be used by this sensor.

See the Rotation vector sensor for details on how to set sensors_event_t.data[0-4] .

Just like for the rotation vector sensor, the heading error must be less than the estimated accuracy ( sensors_event_t.data[4] ) 95% of the time.

This sensor must be low power, so it has to be implemented in hardware.

Orientation (deprecated)

Underlying physical sensors: Accelerometer, magnetometer and (if present) gyroscope

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_ORIENTATION) returns a non-wake-up sensor

Note: This is an older sensor type that has been deprecated in the Android SDK. It has been replaced by the rotation vector sensor, which is more clearly defined. Use the rotation vector sensor over the orientation sensor whenever possible.

An orientation sensor reports the attitude of the device. The measurements are reported in degrees in the x, y, and z fields of sensors_event_t.orientation :

• sensors_event_t.orientation.x : azimuth, the angle between the magnetic north direction and the Y axis, around the Z axis ( 0<=azimuth<360 ). 0=North, 90=East, 180=South, 270=West.
• sensors_event_t.orientation.y : pitch, rotation around X axis ( -180<=pitch<=180 ), with positive values when the Z axis moves toward the Y axis.
• sensors_event_t.orientation.z : roll, rotation around Y axis ( -90<=roll<=90 ), with positive values when the X axis moves towards the Z axis.

Please note, for historical reasons the roll angle is positive in the clockwise direction. (Mathematically speaking, it should be positive in the counter-clockwise direction):

Figure 3. Orientation relative to a device

This definition is different from yaw, pitch, and roll used in aviation where the X axis is along the long side of the plane (tail to nose).

The orientation sensor also reports how accurate it expects its readings to be through sensors_event_t.orientation.status . See the SensorManager 's SENSOR_STATUS_* constants for more information on possible values for this field.

Uncalibrated sensors

Uncalibrated sensors provide more raw results and may include some bias but also contain fewer "jumps" from corrections applied through calibration. Some apps may prefer these uncalibrated results as smoother and more reliable. For instance, if an app is attempting to conduct its own sensor fusion, introducing calibrations can actually distort results.

Accelerometer uncalibrated

Underlying physical sensor: Accelerometer

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_UNCALIBRATED) returns a non-wake-up sensor

An uncalibrated accelerometer sensor reports the acceleration of the device along the three sensor axes without any bias correction (factory bias and temperature compensation are applied to uncalibrated measurements), along with a bias estimate. All values are in SI units (m/s^2) and are reported in the fields of sensors_event_t.uncalibrated_accelerometer :

• x_uncalib : acceleration (without bias compensation) along the X axis
• y_uncalib : acceleration (without bias compensation) along the Y axis
• z_uncalib : acceleration (without bias compensation) along the Z axis
• x_bias : estimated bias along X axis
• y_bias : estimated bias along Y axis
• z_bias : estimated bias along Z axis

Gyroscope uncalibrated

Underlying physical sensor: Gyroscope

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_UNCALIBRATED) returns a non-wake-up sensor

An uncalibrated gyroscope reports the rate of rotation around the sensor axes without applying bias compensation to them, along with a bias estimate. All values are in radians/second and are reported in the fields of sensors_event_t.uncalibrated_gyro :

• x_uncalib : angular speed (without drift compensation) around the X axis
• y_uncalib : angular speed (without drift compensation) around the Y axis
• z_uncalib : angular speed (without drift compensation) around the Z axis
• x_bias : estimated drift around X axis
• y_bias : estimated drift around Y axis
• z_bias : estimated drift around Z axis

Conceptually, the uncalibrated measurement is the sum of the calibrated measurement and the bias estimate: _uncalibrated = _calibrated + _bias .

The x_bias , y_bias and z_bias values are expected to jump as soon as the estimate of the bias changes, and they should be stable the rest of the time.

See the definition of the gyroscope sensor for details on the coordinate system used.

Factory calibration and temperature compensation must be applied to the measurements. Also, gyroscope drift estimation must be implemented so that reasonable estimates can be reported in x_bias , y_bias and z_bias . If the implementation isn't able to estimate the drift, then this sensor must not be implemented.

If this sensor is present, then the corresponding Gyroscope sensor must also be present and both sensors must share the same sensor_t.name and sensor_t.vendor values.

Magnetic field uncalibrated

Underlying physical sensor: Magnetometer

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED) returns a non-wake-up sensor

An uncalibrated magnetic field sensor reports the ambient magnetic field together with a hard iron calibration estimate. All values are in micro-Tesla (uT) and are reported in the fields of sensors_event_t.uncalibrated_magnetic :

• x_uncalib : magnetic field (without hard-iron compensation) along the X axis
• y_uncalib : magnetic field (without hard-iron compensation) along the Y axis
• z_uncalib : magnetic field (without hard-iron compensation) along the Z axis
• x_bias : estimated hard-iron bias along the X axis
• y_bias : estimated hard-iron bias along the Y axis
• z_bias : estimated hard-iron bias along the Z axis

Conceptually, the uncalibrated measurement is the sum of the calibrated measurement and the bias estimate: _uncalibrated = _calibrated + _bias .

The uncalibrated magnetometer allows higher level algorithms to handle bad hard iron estimation. The x_bias , y_bias and z_bias values are expected to jump as soon as the estimate of the hard-iron changes, and they should be stable the rest of the time.

Soft-iron calibration and temperature compensation must be applied to the measurements. Also, hard-iron estimation must be implemented so that reasonable estimates can be reported in x_bias , y_bias and z_bias . If the implementation isn't able to estimate the bias, then this sensor must not be implemented.

If this sensor is present, then the corresponding magnetic field sensor must be present and both sensors must share the same sensor_t.name and sensor_t.vendor values.

Hinge angle

Reporting-mode: On-change

getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) returns a wake-up sensor

A hinge angle sensor measures the angle, in degrees, between two integral parts of the device. Movement of a hinge measured by this sensor type is expected to alter the ways in which the user can interact with the device, for example, by unfolding or revealing a display.

Interaction composite sensors

Some sensors are mostly used to detect interactions with the user. We don't define how those sensors must be implemented, but they must be low power and it's the responsibility of the device manufacturer to verify their quality in terms of user experience.

Wake up gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_WAKE_GESTURE) returns a wake-up sensor

A wake up gesture sensor enables waking up the device based on a device specific motion. When this sensor triggers, the device behaves as if the power button was pressed, turning the screen on. This behavior (turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings don't impact the behavior of the sensor: only whether the framework turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.

This sensor must be low power, as it's likely to be activated 24/7.

Each sensor event reports 1 in sensors_event_t.data[0] .

Pick up gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_PICK_UP_GESTURE) returns a wake-up sensor

A pick-up gesture sensor triggers when the device is picked up regardless of wherever it was before (desk, pocket, bag).

Each sensor event reports 1 in sensors_event_t.data[0] .

Glance gesture

Underlying physical sensors: Undefined (anything low power)

Reporting-mode: One-shot

Low-power

Implement only the wake-up version of this sensor.

getDefaultSensor(SENSOR_TYPE_GLANCE_GESTURE) returns a wake-up sensor

A glance gesture sensor enables briefly turning the screen on to enable the user to glance content on screen based on a specific motion. When this sensor triggers, the device will turn the screen on momentarily to allow the user to glance notifications or other content while the device remains locked in a non-interactive state (dozing), then the screen will turn off again. This behavior (briefly turning on the screen when this sensor triggers) might be deactivated by the user in the device settings. Changes in settings do not impact the behavior of the sensor: only whether the framework briefly turns the screen on when it triggers. The actual gesture to be detected isn't specified, and can be chosen by the manufacturer of the device.

This sensor must be low power, as it's likely to be activated 24/7. Each sensor event reports 1 in sensors_event_t.data[0] .

Limited axes IMU sensors

Available from Android 13, limited axes IMU sensors are sensors that support use cases where not all three axes (x, y, z) are available. Standard IMU types in Android (such as SENSOR_TYPE_ACCELEROMETER and SENSOR_TYPE_GYROSCOPE ) assume that all three axes are supported. However, not all form factors and devices support 3-axis accelerometers and 3-axis gyroscopes.

Accelerometer limited axes

Underlying physical sensors: Accelerometer

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES) returns a non-wake-up sensor

An accelerometer limited axes sensor is equivalent to TYPE_ACCELEROMETER but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the acceleration value for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the acceleration values for unused axes to 0 , instead of having undefined values.

Gyroscope limited axes

Underlying physical sensors: Gyroscope

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES) returns a non-wake-up sensor

A gyroscope limited axes sensor is equivalent to TYPE_GYROSCOPE but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the angular speed value for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the angular speed values for unused axes to 0 .

Accelerometer limited axes uncalibrated

Underlying physical sensors: Accelerometer

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED) returns a non-wake-up sensor

An accelerometer limited axes uncalibrated sensor is equivalent to TYPE_ACCELEROMETER_UNCALIBRATED but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the acceleration and bias values for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the acceleration and bias values for unused axes to 0 .

Gyroscope limited axes uncalibrated

Underlying physical sensors: Gyroscope

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED) returns a non-wake-up sensor

A gyroscope limited axes uncalibrated sensor is equivalent to TYPE_GYROSCOPE_UNCALIBRATED but supports cases where one or two axes aren't supported.

The last three sensor event values reported by the sensor represent whether the angular speed and drift values for the x, y, and z axes are supported. A value of 1.0 indicates that the axis is supported, and a value of 0 indicates it isn't supported. Device manufacturers identify the supported axes at build time and the values don't change during runtime.

Device manufacturers must set the angular speed and drift values for unused axes to 0 .

Composite limited axes IMU

Underlying physical sensors: Any combination of 3-axis accelerometer, 3-axis gyroscope, 3-axis accelerometer uncalibrated, and 3-axis gyroscope uncalibrated sensors.

Reporting-mode: Continuous

A composite limited axes IMU sensor is equivalent to a limited axes IMU sensor but instead of being supported at the HAL, it converts the 3-axis sensor data into the equivalent limited axes variants. These composite sensors are only enabled for automotive devices.

The following table shows an example conversion from a standard 3-axis accelerometer to a composite limited axes accelerometer.

Automotive sensors

Sensors to support automotive use cases.

Heading

Underlying physical sensors: Any combination of GPS, magnetometer, accelerometer, and gyroscope.

Reporting-mode: Continuous

getDefaultSensor(SENSOR_TYPE_HEADING) returns a non-wake-up sensor

Available from Android 13, a heading sensor measures the direction in which the device is pointing relative to true north in degrees. The heading sensor includes two SensorEvent values. One for the measured device heading and one for the accuracy of the provided heading value.

Heading values reported by this sensor must be between 0.0 (inclusive) and 360.0 (exclusive), with 0 indicating north, 90 east, 180 south, and 270 west.

Accuracy for this sensor is defined at 68 percent confidence. In the case where the underlying distribution is Gaussian normal, the accuracy is one standard deviation. For example, if the heading sensor returns a heading value of 60 degrees and an accuracy value of 10 degrees, there's a 68 percent probability of the true heading being between 50 degrees and 70 degrees.