नीचे दी गई इमेज में, Android सेंसर स्टैक दिखाया गया है. हर कॉम्पोनेंट, सिर्फ़ अपने ठीक ऊपर और नीचे मौजूद कॉम्पोनेंट से कम्यूनिकेट करता है. हालांकि, कुछ सेंसर, सेंसर हब के मौजूद होने पर भी उसे बायपास कर सकते हैं. कंट्रोल, ऐप्लिकेशन से सेंसर तक जाता है. वहीं, डेटा सेंसर से ऐप्लिकेशन तक जाता है.
पहली इमेज. Android सेंसर स्टैक की लेयर और उनके मालिक
SDK टूल
ऐप्लिकेशन, Sensors SDK (सॉफ़्टवेयर डेवलपमेंट किट) API के ज़रिए सेंसर ऐक्सेस करते हैं. एसडीके में, उपलब्ध सेंसर की सूची बनाने और किसी सेंसर के लिए रजिस्टर करने के फ़ंक्शन शामिल होते हैं.
किसी सेंसर के लिए रजिस्टर करते समय, ऐप्लिकेशन अपनी पसंद के मुताबिक सैंपलिंग फ़्रीक्वेंसी और लेटेंसी से जुड़ी ज़रूरी शर्तों के बारे में बताता है.
- उदाहरण के लिए, कोई ऐप्लिकेशन डिफ़ॉल्ट ऐक्सिलरोमीटर के लिए रजिस्टर कर सकता है. साथ ही, 100 हर्ट्ज़ पर इवेंट का अनुरोध कर सकता है. इसके अलावा, इवेंट को एक सेकंड की देरी से रिपोर्ट करने की अनुमति दे सकता है.
- ऐप्लिकेशन को ऐक्सिलरोमीटर से इवेंट, कम से कम 100 हर्ट्ज़ की दर से मिलेंगे. साथ ही, इनमें एक सेकंड तक की देरी हो सकती है.
एसडीके के बारे में ज़्यादा जानने के लिए, डेवलपर दस्तावेज़ देखें.
Framework
फ़्रेमवर्क, कई ऐप्लिकेशन को HAL से लिंक करने का काम करता है. HAL, सिंगल-क्लाइंट होता है. फ़्रेमवर्क लेवल पर मल्टीप्लेक्सिंग की सुविधा न होने पर, किसी भी समय सिर्फ़ एक ऐप्लिकेशन हर सेंसर को ऐक्सेस कर सकता है.
- जब कोई ऐप्लिकेशन पहली बार किसी सेंसर के लिए रजिस्टर करता है, तो फ़्रेमवर्क, HAL को सेंसर चालू करने का अनुरोध भेजता है.
- जब एक ही सेंसर के लिए अतिरिक्त ऐप्लिकेशन रजिस्टर किए जाते हैं, तो फ़्रेमवर्क हर ऐप्लिकेशन की ज़रूरी शर्तों को ध्यान में रखता है. साथ ही, अपडेट किए गए अनुरोधित पैरामीटर, HAL को भेजता है.
- सैंपलिंग फ़्रीक्वेंसी, अनुरोध की गई सैंपलिंग फ़्रीक्वेंसी में से सबसे ज़्यादा होगी. इसका मतलब है कि कुछ ऐप्लिकेशन को, अनुरोध की गई फ़्रीक्वेंसी से ज़्यादा फ़्रीक्वेंसी पर इवेंट मिलेंगे.
- रिपोर्टिंग में लगने वाला ज़्यादा से ज़्यादा समय, अनुरोध किए गए समय में से सबसे कम समय होगा. अगर कोई ऐप्लिकेशन, ऐसे सेंसर का अनुरोध करता है जिसकी रिपोर्टिंग में ज़्यादा से ज़्यादा 0 का समय लगता है, तो सभी ऐप्लिकेशन को इस सेंसर से इवेंट लगातार मिलते रहेंगे. भले ही, कुछ ऐप्लिकेशन ने ऐसे सेंसर का अनुरोध किया हो जिसकी रिपोर्टिंग में ज़्यादा से ज़्यादा 0 से ज़्यादा का समय लगता है. ज़्यादा जानकारी के लिए, बैचिंग देखें.
- जब किसी सेंसर के लिए रजिस्टर किया गया आखिरी ऐप्लिकेशन उससे अनरजिस्टर हो जाता है, तो फ़्रेमवर्क, एचएएल को सेंसर बंद करने का अनुरोध भेजता है. इससे, बैटरी की खपत ज़रूरत से ज़्यादा नहीं होती.
मल्टीप्लेक्सिंग का असर
फ़्रेमवर्क में मल्टीप्लेक्सिंग लेयर की ज़रूरत से, डिज़ाइन से जुड़े कुछ फ़ैसलों के बारे में पता चलता है.
- जब कोई ऐप्लिकेशन, सैंपलिंग की फ़्रीक्वेंसी के लिए अनुरोध करता है, तो इस बात की कोई गारंटी नहीं होती कि इवेंट तेज़ी से नहीं आएंगे. अगर किसी दूसरे ऐप्लिकेशन ने उसी सेंसर के लिए ज़्यादा फ़्रीक्वेंसी पर अनुरोध किया है, तो पहले ऐप्लिकेशन को भी ज़्यादा फ़्रीक्वेंसी पर डेटा मिलेगा.
- रिपोर्टिंग में कम से कम समय लगने की गारंटी नहीं दी जाती. यह बात, रिपोर्टिंग में कम से कम समय लगने के लिए किए गए अनुरोध पर भी लागू होती है: ऐसा हो सकता है कि ऐप्लिकेशन को इवेंट, अनुरोध किए गए समय से पहले मिल जाएं.
- सेंसर के पैरामीटर कॉन्फ़िगर नहीं किए जा सकते. इसके अलावा, सैंपलिंग फ़्रीक्वेंसी और रिपोर्टिंग में लगने वाले ज़्यादा से ज़्यादा समय को भी कॉन्फ़िगर नहीं किया जा सकता.
- उदाहरण के लिए, मान लें कि कोई फ़िज़िकल सेंसर “ज़्यादा सटीक” और “कम पावर” मोड, दोनों में काम कर सकता है.
- Android डिवाइस पर, इन दोनों मोड में से सिर्फ़ एक का इस्तेमाल किया जा सकता है. ऐसा इसलिए, क्योंकि अगर ऐसा नहीं किया जाता है, तो एक ऐप्लिकेशन, ज़्यादा सटीक मोड का अनुरोध कर सकता है और दूसरा ऐप्लिकेशन, कम बैटरी खर्च करने वाले मोड का अनुरोध कर सकता है. ऐसे में, फ़्रेमवर्क के पास दोनों ऐप्लिकेशन के अनुरोधों को पूरा करने का कोई तरीका नहीं होगा. फ़्रेमवर्क को हमेशा अपने सभी क्लाइंट की ज़रूरतों को पूरा करना चाहिए. इसलिए, यह विकल्प नहीं है.
- ऐप्लिकेशन से सेंसर या उनके ड्राइवर को डेटा भेजने का कोई तरीका नहीं है. इससे यह पक्का होता है कि कोई ऐप्लिकेशन, सेंसर के व्यवहार में बदलाव नहीं कर सकता. इससे दूसरे ऐप्लिकेशन काम नहीं करते.
सेंसर फ़्यूज़न
Android फ़्रेमवर्क, कुछ कंपोज़िट सेंसर के लिए डिफ़ॉल्ट रूप से लागू होने वाली सुविधा देता है. अगर किसी डिवाइस में जाइरोस्कोप, ऐक्सलरोमीटर, और मैग्नेटोमीटर मौजूद हैं, लेकिन रोटेशन वेक्टर, ग्रैविटी, और लीनियर ऐक्सलरेशन सेंसर मौजूद नहीं हैं, तो फ़्रेमवर्क इन सेंसर को लागू करता है, ताकि ऐप्लिकेशन इनका इस्तेमाल कर सकें.
डिफ़ॉल्ट तौर पर लागू किए गए सिस्टम के पास, उस पूरे डेटा का ऐक्सेस नहीं होता जिसका ऐक्सेस अन्य सिस्टम के पास होता है. साथ ही, इसे एसओसी पर चलाना होता है. इसलिए, यह अन्य सिस्टम की तरह सटीक और कम बैटरी खर्च करने वाला नहीं होता. डिवाइस बनाने वाली कंपनियों को, इस डिफ़ॉल्ट सेटिंग पर भरोसा करने के बजाय, अपने फ़्यूज़ किए गए सेंसर (रोटेशन वेक्टर, गुरुत्वाकर्षण, और लीनियर ऐक्सलरेशन के साथ-साथ गेम रोटेशन वेक्टर जैसे नए कंपोज़िट सेंसर) तय करने चाहिए. डिवाइस बनाने वाली कंपनियां, सेंसर चिप बनाने वाली कंपनियों से भी इस सुविधा को लागू करने का अनुरोध कर सकती हैं.
सेंसर फ़्यूज़न के डिफ़ॉल्ट तरीके को बनाए नहीं रखा जा रहा है. इस वजह से, इस पर निर्भर रहने वाले डिवाइसों के लिए, सीटीएस पास करना मुश्किल हो सकता है.
हुड के अंतर्गत
यह सेक्शन, Android Open Source Project (AOSP) के फ़्रेमवर्क कोड को बनाए रखने वाले लोगों के लिए, बैकग्राउंड की जानकारी के तौर पर दिया गया है. यह हार्डवेयर बनाने वाली कंपनियों के लिए काम की नहीं है.
JNI
यह फ़्रेमवर्क, android.hardware से जुड़े Java नेटिव इंटरफ़ेस (जेएनआई) का इस्तेमाल करता है. यह 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 पर अपग्रेड करने के तरीके के बारे में जानने के लिए, एचएएल के वर्शन को बंद करना लेख पढ़ें.
कर्नेल ड्राइवर
सेंसर ड्राइवर, फ़िज़िकल डिवाइसों के साथ इंटरैक्ट करते हैं. कुछ मामलों में, HAL और ड्राइवर एक ही सॉफ़्टवेयर इकाई होते हैं. अन्य मामलों में, हार्डवेयर इंटिग्रेटर, सेंसर चिप बनाने वाली कंपनियों से ड्राइवर उपलब्ध कराने का अनुरोध करता है. हालांकि, एचएएल को लागू करने का काम हार्डवेयर इंटिग्रेटर ही करता है.
सभी मामलों में, एचएएल लागू करने और कर्नेल ड्राइवर बनाने की ज़िम्मेदारी हार्डवेयर बनाने वाली कंपनियों की होती है. Android, इन्हें बनाने के लिए कोई पसंदीदा तरीका नहीं बताता है.
सेंसर हब
किसी डिवाइस के सेंसर स्टैक में, सेंसर हब को शामिल किया जा सकता है. यह कम पावर में कुछ बुनियादी काम करने के लिए फ़ायदेमंद होता है. वहीं, SoC को स्लीप मोड में रखा जा सकता है. उदाहरण के लिए, इन चिप पर कदमों की गिनती या सेंसर फ़्यूज़न किया जा सकता है. यह सेंसर बैचिंग को लागू करने के लिए भी एक अच्छी जगह है. साथ ही, सेंसर इवेंट के लिए हार्डवेयर FIFO जोड़ना भी यहां आसान है. ज़्यादा जानकारी के लिए, बैचिंग देखें.
ध्यान दें: नए सेंसर या एलईडी का इस्तेमाल करने वाली ContextHub की नई सुविधाएं डेवलप करने के लिए, Hikey या Hikey960 डेवलपमेंट बोर्ड से कनेक्ट किए गए Neonkey SensorHub का भी इस्तेमाल किया जा सकता है.
सेंसर हब को कैसे लागू किया जाता है, यह आर्किटेक्चर पर निर्भर करता है. कभी-कभी यह एक अलग चिप होती है और कभी-कभी इसे SoC के साथ एक ही चिप में शामिल किया जाता है. सेंसर हब की अहम विशेषताएं यह हैं कि इसमें बैचिंग के लिए ज़रूरी मेमोरी होनी चाहिए. साथ ही, इसमें बहुत कम बैटरी की खपत होनी चाहिए, ताकि कम बैटरी की खपत करने वाले Android सेंसर को लागू किया जा सके. कुछ सेंसर हब में, सामान्य कंप्यूटेशन के लिए माइक्रोकंट्रोलर होता है. साथ ही, कम पावर वाले सेंसर के लिए बहुत कम पावर वाले कंप्यूटेशन को चालू करने के लिए, हार्डवेयर ऐक्सेलरेटर होते हैं.
सेंसर हब का आर्किटेक्चर कैसा है और यह सेंसर और SoC (I2C बस, SPI बस वगैरह) के साथ कैसे कम्यूनिकेट करता है, यह Android तय नहीं करता. हालांकि, इसका मकसद यह होना चाहिए कि बिजली की खपत कम से कम हो.
एक विकल्प ऐसा है जिससे लागू करने में आसानी होती है. इसमें सेंसर हब से एसओसी तक दो इंटरप्ट लाइनें होती हैं: एक वेक-अप इंटरप्ट के लिए (वेक-अप सेंसर के लिए) और दूसरी नॉन-वेक-अप इंटरप्ट के लिए (नॉन-वेक-अप सेंसर के लिए).
सेंसर
ये मेज़रमेंट करने वाले फ़िज़िकल MEMs चिप हैं. कई मामलों में, एक ही चिप पर कई फ़िज़िकल सेंसर मौजूद होते हैं. उदाहरण के लिए, कुछ चिप में एक्सलरोमीटर, जाइरोस्कोप, और मैग्नेटोमीटर शामिल होते हैं. (इस तरह के चिप को अक्सर 9-ऐक्सिस चिप कहा जाता है, क्योंकि हर सेंसर तीन ऐक्सिस पर डेटा उपलब्ध कराता है.)
इनमें से कुछ चिप में, सामान्य तौर पर होने वाली कंप्यूटिंग के लिए भी कुछ लॉजिक होता है. जैसे, मोशन का पता लगाना, कदमों का पता लगाना, और नौ ऐक्सिस वाले सेंसर फ़्यूज़न का इस्तेमाल करना.
हालांकि, सीडीडी की ज़रूरी शर्तों और सुझावों में, Android सेंसर को ध्यान में रखा जाता है, न कि फ़िज़िकल सेंसर को. हालांकि, इन ज़रूरी शर्तों का असर फ़िज़िकल सेंसर के चुनाव पर पड़ता है. उदाहरण के लिए, गेम रोटेशन वेक्टर के लिए सटीक जानकारी की ज़रूरत होती है. इसलिए, फ़िज़िकल जायरोस्कोप के लिए भी सटीक जानकारी की ज़रूरत होती है. फ़िज़िकल सेंसर के लिए ज़रूरी शर्तें तय करने की ज़िम्मेदारी, डिवाइस बनाने वाली कंपनी की होती है.