नीचे दी गई इमेज में, Android सेंसर स्टैक दिखाया गया है. हर कॉम्पोनेंट सिर्फ़ अपने ठीक ऊपर और नीचे मौजूद कॉम्पोनेंट से कम्यूनिकेट करता है. हालांकि, कुछ सेंसर, सेंसर हब मौजूद होने पर भी उसे बाईपास कर सकते हैं. ऐप्लिकेशन से सेंसर तक कंट्रोल फ़्लो होता है और सेंसर से ऐप्लिकेशन तक डेटा फ़्लो होता है.
पहली इमेज. Android सेंसर स्टैक की लेयर और उनके मालिक
SDK टूल
ऐप्लिकेशन, सेंसर SDK (सॉफ़्टवेयर डेवलपमेंट किट) एपीआई की मदद से सेंसर ऐक्सेस करते हैं. एसडीके में, उपलब्ध सेंसर की सूची बनाने और किसी सेंसर के लिए रजिस्टर करने के फ़ंक्शन शामिल होते हैं.
किसी सेंसर के लिए रजिस्टर करते समय, ऐप्लिकेशन अपनी पसंदीदा सैंपलिंग फ़्रीक्वेंसी और लेटेंसी से जुड़ी ज़रूरी शर्तें बताता है.
- उदाहरण के लिए, कोई ऐप्लिकेशन डिफ़ॉल्ट एक्सलरोमीटर के लिए रजिस्टर कर सकता है. साथ ही, 100 हर्ट्ज़ पर इवेंट का अनुरोध कर सकता है और एक सेकंड की लेटेंसी के साथ इवेंट की रिपोर्ट करने की अनुमति दे सकता है.
- ऐप्लिकेशन को एक्सलरोमीटर से कम से कम 100 हर्ट्ज़ की दर से इवेंट मिलेंगे. साथ ही, इनमें एक सेकंड तक की देरी हो सकती है.
एसडीके के बारे में ज़्यादा जानकारी के लिए, डेवलपर के लिए बनी दस्तावेज़ देखें.
Framework
फ़्रेमवर्क, कई ऐप्लिकेशन को एचएएल से लिंक करने का काम करता है. एचएएल, सिंगल-क्लाइंट होता है. फ़्रेमवर्क लेवल पर मल्टीप्लेक्सिंग न होने पर, किसी भी समय सिर्फ़ एक ऐप्लिकेशन, हर सेंसर को ऐक्सेस कर सकता है.
- जब कोई पहला ऐप्लिकेशन किसी सेंसर के लिए रजिस्टर करता है, तो फ़्रेमवर्क, सेंसर को चालू करने के लिए एचएएल को अनुरोध भेजता है.
- जब एक से ज़्यादा ऐप्लिकेशन, एक ही सेंसर के लिए रजिस्टर करते हैं, तो फ़्रेमवर्क हर ऐप्लिकेशन की ज़रूरी शर्तों को ध्यान में रखता है और एचएएल को अपडेट किए गए अनुरोधित पैरामीटर भेजता है.
- सैंपलिंग फ़्रीक्वेंसी, अनुरोध की गई सैंपलिंग फ़्रीक्वेंसी में से सबसे ज़्यादा होगी. इसका मतलब है कि कुछ ऐप्लिकेशन को, अनुरोध की गई फ़्रीक्वेंसी से ज़्यादा फ़्रीक्वेंसी पर इवेंट मिलेंगे.
- रिपोर्टिंग की ज़्यादा से ज़्यादा लेटेंसी, अनुरोध की गई लेटेंसी में से सबसे कम होगी. अगर कोई ऐप्लिकेशन, किसी सेंसर के लिए रिपोर्टिंग की ज़्यादा से ज़्यादा लेटेंसी 0 के साथ अनुरोध करता है, तो सभी ऐप्लिकेशन को इस सेंसर से इवेंट, लगातार मोड में मिलेंगे. भले ही, कुछ ऐप्लिकेशन ने सेंसर के लिए रिपोर्टिंग की ज़्यादा से ज़्यादा लेटेंसी, शून्य से ज़्यादा के साथ अनुरोध किया हो. ज़्यादा जानकारी के लिए, बैचिंग लेख देखें.
- जब किसी सेंसर के लिए रजिस्टर किया गया आखिरी ऐप्लिकेशन, उससे अनरजिस्टर हो जाता है, तो उसे बंद करने के लिए फ़्रेमवर्क, एचएएल को अनुरोध भेजता है. इससे, बिना वजह पावर की खपत नहीं होती.
मल्टीप्लेक्सिंग का असर
फ़्रेमवर्क में मल्टीप्लेक्सिंग लेयर की ज़रूरत से, डिज़ाइन से जुड़े कुछ फ़ैसलों के बारे में पता चलता है.
- जब कोई ऐप्लिकेशन, सैंपलिंग की किसी खास फ़्रीक्वेंसी का अनुरोध करता है, तो इस बात की कोई गारंटी नहीं होती कि इवेंट, ज़्यादा फ़्रीक्वेंसी पर नहीं पहुंचेंगे. अगर किसी दूसरे ऐप्लिकेशन ने, उसी सेंसर के लिए ज़्यादा फ़्रीक्वेंसी पर अनुरोध किया है, तो पहले ऐप्लिकेशन को भी इवेंट, ज़्यादा फ़्रीक्वेंसी पर मिलेंगे.
- अनुरोध की गई रिपोर्टिंग की ज़्यादा से ज़्यादा लेटेंसी के लिए भी, इसी तरह की कोई गारंटी नहीं होती: हो सकता है कि ऐप्लिकेशन को इवेंट, अनुरोध की गई लेटेंसी से काफ़ी कम लेटेंसी पर मिलें.
- सैंपलिंग फ़्रीक्वेंसी और रिपोर्टिंग की ज़्यादा से ज़्यादा लेटेंसी के अलावा, ऐप्लिकेशन, सेंसर के पैरामीटर कॉन्फ़िगर नहीं कर सकते.
- उदाहरण के लिए, मान लें कि कोई फ़िज़िकल सेंसर, “ज़्यादा सटीक” और “कम पावर” मोड, दोनों में काम कर सकता है.
- Android डिवाइस पर, इन दोनों मोड में से सिर्फ़ एक का इस्तेमाल किया जा सकता है. ऐसा इसलिए, क्योंकि अगर ऐसा नहीं किया जाता, तो कोई ऐप्लिकेशन, ज़्यादा सटीक मोड का अनुरोध कर सकता है और दूसरा ऐप्लिकेशन, बैटरी बचाने वाला मोड का अनुरोध कर सकता है. ऐसे में, फ़्रेमवर्क के पास दोनों ऐप्लिकेशन की ज़रूरतों को पूरा करने का कोई तरीका नहीं होगा. फ़्रेमवर्क को हमेशा अपने सभी क्लाइंट की ज़रूरतों को पूरा करना होता है. इसलिए, यह विकल्प उपलब्ध नहीं है.
- ऐप्लिकेशन से सेंसर या उनके ड्राइवर तक डेटा भेजने का कोई तरीका नहीं है या उनके ड्राइवर. इससे यह पक्का होता है कि कोई ऐप्लिकेशन, सेंसर के व्यवहार में बदलाव नहीं कर सकता. ऐसा करने पर, दूसरे ऐप्लिकेशन काम करना बंद कर सकते हैं.
सेंसर फ़्यूज़न
Android फ़्रेमवर्क, कंपोज़िट सेंसर के लिए डिफ़ॉल्ट तौर पर लागू करने की सुविधा देता है. जब किसी डिवाइस में जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर मौजूद हों, लेकिन रोटेशन वेक्टर, ग्रेविटी, और लीनियर ऐक्सेलरेटर सेंसर मौजूद न हों, तो फ़्रेमवर्क इन सेंसर को लागू करता है. इससे ऐप्लिकेशन अब भी इनका इस्तेमाल कर सकते हैं.
डिफ़ॉल्ट तौर पर लागू करने की सुविधा के पास, वह सारा डेटा ऐक्सेस करने की अनुमति नहीं होती जो अन्य तरीकों से लागू करने पर मिलती है. साथ ही, इसे एसओसी पर चलाना होता है. इसलिए, यह अन्य तरीकों से लागू करने की तुलना में, न तो ज़्यादा सटीक होती है और न ही ज़्यादा पावर-एफ़िशिएंट. डिवाइस बनाने वाली कंपनियों को, डिफ़ॉल्ट तौर पर लागू करने की सुविधा पर निर्भर रहने के बजाय, अपने फ़्यूज़्ड सेंसर (रोटेशन वेक्टर, ग्रेविटी, और लीनियर ऐक्सेलरेटर, साथ ही, गेम रोटेशन वेक्टर जैसे नए कंपोज़िट सेंसर) तय करने चाहिए. डिवाइस बनाने वाली कंपनियां, सेंसर चिप के वेंडर से भी, उन्हें लागू करने की सुविधा देने का अनुरोध कर सकती हैं.
सेंसर फ़्यूज़न को डिफ़ॉल्ट तौर पर लागू करने की सुविधा को अब बनाए नहीं रखा जा रहा है और इसलिए, इस पर निर्भर रहने वाले डिवाइस, सीटीएस में फ़ेल हो सकते हैं.
उन्नत
यह सेक्शन, Android Open Source Project (AOSP) फ़्रेमवर्क कोड को बनाए रखने वाले लोगों के लिए, बैकग्राउंड की जानकारी के तौर पर दिया गया है. यह हार्डवेयर बनाने वाली कंपनियों के लिए काम का नहीं है.
JNI
फ़्रेमवर्क, android.hardware से जुड़े Java Native Interface (JNI) का इस्तेमाल करता है. यह frameworks/base/core/jni/ डायरेक्ट्री में मौजूद होता है. यह कोड, सेंसर हार्डवेयर का ऐक्सेस पाने के लिए, लोअर लेवल के नेटिव कोड को कॉल करता है.
नेटिव फ़्रेमवर्क
नेटिव फ़्रेमवर्क, frameworks/native/ में तय किया गया है. यह नेटिव
सुविधा देता है जो android.hardware पैकेज के बराबर है. नेटिव फ़्रेमवर्क, सेंसर से जुड़ी सेवाओं का ऐक्सेस पाने के लिए, Binder IPC प्रॉक्सी को कॉल करता है
Binder IPC
Binder IPC प्रॉक्सी, प्रोसेस बाउंड्री के बीच कम्यूनिकेशन को आसान बनाती हैं.
HAL
सेंसर हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) एपीआई, हार्डवेयर ड्राइवर और Android फ़्रेमवर्क के बीच इंटरफ़ेस है. इसमें एक एचएएल इंटरफ़ेस sensors.h और एक एचएएल इंप्लीमेंटेशन शामिल है. इसे हम sensors.cpp कहते हैं.
इंटरफ़ेस को Android और AOSP के कॉन्ट्रिब्यूटर तय करते हैं. वहीं, डिवाइस बनाने वाली कंपनी, इसे लागू करने की सुविधा देती है.
सेंसर एचएएल इंटरफ़ेस, hardware/libhardware/include/hardware में मौजूद होता है.
ज़्यादा जानकारी के लिए, sensors.h
देखें.
रिलीज़ साइकल
एचएएल को लागू करने की सुविधा, एचएएल इंटरफ़ेस के किस वर्शन को लागू करती है, यह
तय करने के लिए your_poll_device.common.version सेट करती है. मौजूदा एचएएल
इंटरफ़ेस के वर्शन, sensors.h में तय किए गए हैं. साथ ही, फ़ंक्शनैलिटी इन
वर्शन से जुड़ी होती है.
Android फ़्रेमवर्क, फ़िलहाल वर्शन 1.0 और 1.3 के साथ काम करता है. हालांकि, जल्द ही वर्शन 1.0 के लिए सहायता बंद कर दी जाएगी. इस दस्तावेज़ में, वर्शन 1.3 के व्यवहार के बारे में बताया गया है. सभी डिवाइसों को इस वर्शन पर अपग्रेड करना चाहिए. वर्शन 1.3 पर अपग्रेड करने के बारे में ज़्यादा जानकारी के लिए, एचएएल वर्शन को बंद करना लेख देखें.
कर्नेल ड्राइवर
सेंसर ड्राइवर, फ़िज़िकल डिवाइसों के साथ इंटरैक्ट करते हैं. कुछ मामलों में, एचएएल को लागू करने की सुविधा और ड्राइवर, एक ही सॉफ़्टवेयर एंटिटी होते हैं. अन्य मामलों में, हार्डवेयर इंटिग्रेटर, सेंसर चिप बनाने वाली कंपनियों से ड्राइवर उपलब्ध कराने का अनुरोध करता है. हालांकि, एचएएल को लागू करने की सुविधा, वे ही लिखते हैं.
सभी मामलों में, एचएएल को लागू करने की सुविधा और कर्नेल ड्राइवर की ज़िम्मेदारी, हार्डवेयर बनाने वाली कंपनियों की होती है. साथ ही, Android, इन्हें लिखने के लिए पसंदीदा तरीके नहीं बताता.
सेंसर हब
किसी डिवाइस के सेंसर स्टैक में, सेंसर हब को शामिल किया जा सकता है. यह एसओसी को सस्पेंड मोड में रखते हुए, कम पावर में लो-लेवल की कुछ कंप्यूटिंग करने में मददगार होता है. उदाहरण के लिए, इन चिप पर, कदम गिनने या सेंसर फ़्यूज़न की सुविधा दी जा सकती है. यह सेंसर बैचिंग को लागू करने के लिए भी एक अच्छी जगह है. इसमें सेंसर इवेंट के लिए हार्डवेयर FIFOs जोड़े जाते हैं. ज़्यादा जानकारी के लिए, बैचिंग लेख देखें.
ध्यान दें: नए सेंसर या एलईडी का इस्तेमाल करने वाली ContextHub की नई सुविधाएं डेवलप करने के लिए, Neonkey SensorHub का भी इस्तेमाल किया जा सकता है. इसे Hikey या Hikey960 डेवलपमेंट बोर्ड से कनेक्ट किया गया है.
सेंसर हब को कैसे बनाया जाता है, यह आर्किटेक्चर पर निर्भर करता है. कभी-कभी यह एक अलग चिप होती है और कभी-कभी एसओसी वाली चिप में ही शामिल होती है. सेंसर हब की अहम खासियत यह है कि इसमें बैचिंग के लिए, ज़रूरत के मुताबिक मेमोरी होनी चाहिए. साथ ही, कम पावर वाले Android सेंसर को लागू करने के लिए, यह बहुत कम पावर की खपत करे. कुछ सेंसर हब में, सामान्य कंप्यूटिंग के लिए माइक्रो कंट्रोलर और कम पावर वाले सेंसर के लिए, बहुत कम पावर में कंप्यूटिंग करने के लिए हार्डवेयर ऐक्सेलरेटर शामिल होते हैं.
Android, सेंसर हब के आर्किटेक्चर और सेंसर और एसओसी (I2C बस, एसपीआई बस वगैरह) के साथ इसके कम्यूनिकेट करने के तरीके के बारे में नहीं बताता. हालांकि, इसका मकसद पावर के कुल इस्तेमाल को कम करना होना चाहिए.
एक विकल्प यह है कि सेंसर हब से एसओसी तक दो इंटरप्ट लाइन हों. इससे, लागू करने की प्रोसेस आसान हो जाती है. इनमें से एक लाइन, वेक-अप इंटरप्ट (वेक-अप सेंसर के लिए) और दूसरी लाइन, नॉन-वेक-अप इंटरप्ट (नॉन-वेक-अप सेंसर के लिए) के लिए होती है.
सेंसर
ये फ़िज़िकल MEMs चिप होती हैं, जो मेज़रमेंट करती हैं. कई मामलों में, एक ही चिप पर कई फ़िज़िकल सेंसर मौजूद होते हैं. उदाहरण के लिए, कुछ चिप में एक्सलरोमीटर, जाइरोस्कोप, और मैग्नेटोमीटर शामिल होते हैं. (ऐसी चिप को अक्सर 9-ऐक्सिस चिप कहा जाता है, क्योंकि हर सेंसर तीन ऐक्सिस पर डेटा उपलब्ध कराता है.)
इनमें से कुछ चिप में, हलचल का पता लगाने वाली सुविधा, स्टेप डिटेक्शन, और 9-ऐक्सिस सेंसर फ़्यूज़न जैसी सामान्य कंप्यूटिंग करने के लिए कुछ लॉजिक भी शामिल होते हैं.
सीडीडी में पावर और सटीक होने से जुड़ी ज़रूरी शर्तें और सुझाव, Android सेंसर के लिए हैं, न कि फ़िज़िकल सेंसर के लिए. हालांकि, इन ज़रूरी शर्तों का असर, फ़िज़िकल सेंसर के चुनाव पर पड़ता है. उदाहरण के लिए, गेम रोटेशन वेक्टर के सटीक होने से जुड़ी ज़रूरी शर्त का असर, फ़िज़िकल जाइरोस्कोप के सटीक होने से जुड़ी ज़रूरी शर्त पर पड़ता है. फ़िज़िकल सेंसर के लिए ज़रूरी शर्तें तय करना, डिवाइस बनाने वाली कंपनी पर निर्भर करता है.