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