कॉन्टेक्स्ट हब रनटाइम एनवायरमेंट (सीएचआरई)

स्मार्टफ़ोन में कई प्रोसेसर होते हैं. हर प्रोसेसर को अलग-अलग टास्क करने के लिए ऑप्टिमाइज़ किया जाता है. हालांकि, Android सिर्फ़ एक प्रोसेसर पर काम करता है: ऐप्लिकेशन प्रोसेसर (एपी). एपी को स्क्रीन चालू होने पर, गेमिंग जैसे इस्तेमाल के मामलों में बेहतरीन परफ़ॉर्मेंस देने के लिए ट्यून किया गया है. हालांकि, यह उन सुविधाओं के लिए बहुत ज़्यादा बैटरी खर्च करता है जिनके लिए, स्क्रीन बंद होने पर भी लगातार प्रोसेसिंग की ज़रूरत होती है. छोटे प्रोसेसर, इन वर्कलोड को ज़्यादा कुशलता से हैंडल कर पाते हैं. साथ ही, बैटरी लाइफ़ पर ज़्यादा असर डाले बिना अपने टास्क पूरे कर पाते हैं. हालांकि, कम पावर वाले इन प्रोसेसर में सॉफ़्टवेयर एनवायरमेंट ज़्यादा सीमित होते हैं और इनमें काफ़ी अंतर हो सकता है. इस वजह से, क्रॉस-प्लैटफ़ॉर्म डेवलपमेंट करना मुश्किल हो जाता है.

कॉन्टेक्स्ट हब रनटाइम एनवायरमेंट (सीएचआरई), कम पावर वाले प्रोसेसर पर ऐप्लिकेशन चलाने के लिए एक सामान्य प्लैटफ़ॉर्म उपलब्ध कराता है. इसमें एक आसान, स्टैंडर्ड, और एम्बेड करने में आसान एपीआई होता है. CHRE की मदद से, डिवाइस ओईएम और उनके भरोसेमंद पार्टनर, एपी से प्रोसेसिंग को ऑफ़लोड कर सकते हैं. इससे बैटरी की बचत होती है और उपयोगकर्ता अनुभव के अलग-अलग पहलुओं को बेहतर बनाया जा सकता है. साथ ही, हमेशा चालू रहने वाली और कॉन्टेक्स्ट के हिसाब से काम करने वाली सुविधाओं को चालू किया जा सकता है. खास तौर पर, परिवेश को समझने के लिए मशीन लर्निंग का इस्तेमाल करने वाली सुविधाओं को चालू किया जा सकता है.

वीडियो के विषय से जुड़े मुख्य कॉन्सेप्ट

CHRE एक सॉफ़्टवेयर एनवायरमेंट है. इसमें नैनोऐप्लिकेशन कहे जाने वाले छोटे नेटिव ऐप्लिकेशन, कम पावर वाले प्रोसेसर पर काम करते हैं. साथ ही, ये सामान्य CHRE API के ज़रिए, सिस्टम के साथ इंटरैक्ट करते हैं. CHRE एपीआई को सही तरीके से लागू करने की प्रोसेस को तेज़ करने के लिए, CHRE के क्रॉस-प्लैटफ़ॉर्म रेफ़रंस को AOSP में शामिल किया गया है. रेफ़रंस के तौर पर लागू किए गए इस कोड में, सामान्य कोड और ऐब्स्ट्रैक्शन शामिल होते हैं. ये ऐब्स्ट्रैक्शन, प्लैटफ़ॉर्म ऐब्स्ट्रैक्शन लेयर (पीएएल) की सीरीज़ के ज़रिए, हार्डवेयर और सॉफ़्टवेयर के साथ काम करते हैं. नैनोऐप्लिकेशन, Android में चलने वाले एक या उससे ज़्यादा क्लाइंट ऐप्लिकेशन से जुड़े होते हैं. ये क्लाइंट ऐप्लिकेशन, CHRE और नैनोऐप्लिकेशन के साथ इंटरैक्ट करते हैं. इसके लिए, ये ContextHubManager सिस्टम एपीआई का इस्तेमाल करते हैं. इन एपीआई को सीमित ऐक्सेस दिया जाता है.

ऊंचे लेवल पर, CHRE और Android के आर्किटेक्चर के बीच समानताएं देखी जा सकती हैं. हालांकि, इनमें कुछ अहम अंतर हैं:

• CHRE, सिर्फ़ नेटिव कोड (C या C++) में डेवलप किए गए नैनो ऐप्लिकेशन चलाने की सुविधा देता है. यह Java के साथ काम नहीं करता.
• संसाधनों की कमी और सुरक्षा से जुड़ी पाबंदियों की वजह से, CHRE को तीसरे पक्ष के किसी भी Android ऐप्लिकेशन के लिए उपलब्ध नहीं कराया गया है. सिर्फ़ सिस्टम के भरोसेमंद ऐप्लिकेशन इसे ऐक्सेस कर सकते हैं.

इसके अलावा, CHRE और सेंसर हब के बीच के अंतर को समझना भी ज़रूरी है. सेंसर हब और CHRE को लागू करने के लिए, एक ही हार्डवेयर का इस्तेमाल करना आम बात है. हालांकि, CHRE खुद Android Sensors HAL के लिए ज़रूरी सेंसर की सुविधाएं उपलब्ध नहीं कराता है. CHRE, कॉन्टेक्स्ट हब HAL से जुड़ा होता है. यह किसी डिवाइस के सेंसर फ़्रेमवर्क के क्लाइंट के तौर पर काम करता है, ताकि एपी को शामिल किए बिना सेंसर डेटा मिल सके.

पहली इमेज. CHRE फ़्रेमवर्क का आर्किटेक्चर

कॉन्टेक्स्ट हब एचएएल

कॉन्टेक्स्ट हब हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल), Android फ़्रेमवर्क और डिवाइस के CHRE के बीच इंटरफ़ेस होता है. इसे hardware/interfaces/contexthub पर तय किया गया है. कॉन्टेक्स्ट हब एचएएल, उन एपीआई को तय करता है जिनकी मदद से Android फ़्रेमवर्क, उपलब्ध कॉन्टेक्स्ट हब और उनके नैनोऐप्लिकेशन का पता लगाता है. साथ ही, मैसेज पास करने की सुविधा के ज़रिए उन नैनोऐप्लिकेशन के साथ इंटरैक्ट करता है. इसके अलावा, यह नैनोऐप्लिकेशन को लोड और अनलोड करने की अनुमति देता है. CHRE के रेफ़रंस इंप्लीमेंटेशन के साथ काम करने वाले Context Hub HAL का रेफ़रंस इंप्लीमेंटेशन, system/chre/host पर उपलब्ध है.

अगर इस दस्तावेज़ और एचएएल की परिभाषा के बीच कोई टकराव होता है, तो एचएएल की परिभाषा को प्राथमिकता दी जाएगी.

डेटा लेयर में इवेंट बनाने की प्रोसेस

जब Android बूट अप होता है, तब ContextHubService, getHubs() HAL फ़ंक्शन को कॉल करता है. इससे यह पता चलता है कि डिवाइस पर कोई कॉन्टेक्स्ट हब उपलब्ध है या नहीं. यह एक बार किया जाने वाला कॉल है, जो बूटिंग को रोकता है. इसलिए, इसे तुरंत पूरा करना ज़रूरी है, ताकि बूटिंग में देरी न हो. साथ ही, इसे सटीक नतीजे देने चाहिए, क्योंकि इसके बाद नए कॉन्टेक्स्ट हब नहीं जोड़े जा सकते.

नैनो ऐप्लिकेशन लोड और अनलोड करना

कॉन्टेक्स्ट हब में, नैनोऐप्लिकेशन का एक सेट शामिल हो सकता है. ये नैनोऐप्लिकेशन, डिवाइस की इमेज में शामिल होते हैं और CHRE शुरू होने पर लोड होते हैं. इन्हें प्रीलोड किए गए नैनो ऐप्लिकेशन कहा जाता है. इन्हें queryApps() के पहले जवाब में शामिल किया जाना चाहिए.

कॉन्टेक्स्ट हब HAL, loadNanoApp() और unloadNanoApp() फ़ंक्शन की मदद से, रनटाइम में नैनो ऐप्लिकेशन को डाइनैमिक तरीके से लोड और अनलोड करने की सुविधा भी देता है. नैनो ऐप्लिकेशन, एचएएल को बाइनरी फ़ॉर्मैट में दिए जाते हैं. यह फ़ॉर्मैट, डिवाइस के CHRE हार्डवेयर और सॉफ़्टवेयर के हिसाब से तय होता है.

अगर किसी नैनोऐप्लिकेशन को लोड करने के लिए, उसे नॉनवॉलेटाइल मेमोरी में सेव करना पड़ता है, जैसे कि CHRE चलाने वाले प्रोसेसर से अटैच किया गया फ़्लैश स्टोरेज, तो CHRE को हमेशा इन डाइनैमिक नैनोऐप्लिकेशन के साथ बूट अप करना चाहिए. हालांकि, इन्हें बंद रखा जाना चाहिए. इसका मतलब है कि जब तक HAL के ज़रिए enableNanoapp() अनुरोध नहीं मिलता, तब तक नैनो ऐप्लिकेशन का कोई भी कोड एक्ज़ीक्यूट नहीं होता. पहले से लोड किए गए नैनो ऐप्लिकेशन, चालू स्थिति में शुरू हो सकते हैं.

कॉन्टेक्स्ट हब रीस्टार्ट हो रहा है

आम तौर पर, CHRE के काम करने के दौरान इसे रीस्टार्ट करने की ज़रूरत नहीं पड़ती. हालांकि, कुछ असामान्य स्थितियों में ऐसा करना ज़रूरी हो सकता है. जैसे, किसी ऐसे मेमोरी पते को ऐक्सेस करने की कोशिश करना जिसे मैप नहीं किया गया है. इन स्थितियों में, CHRE, Android से अलग रीस्टार्ट होता है. HAL, Android को इसकी सूचना RESTARTED इवेंट के ज़रिए देता है. इसे यह इवेंट सिर्फ़ तब भेजना चाहिए, जब CHRE को फिर से शुरू कर दिया गया हो, ताकि वह नए अनुरोध स्वीकार कर सके. जैसे, queryApps().

CHRE सिस्टम के बारे में खास जानकारी

CHRE को इवेंट-ड्रिवन आर्किटेक्चर के हिसाब से डिज़ाइन किया गया है. इसमें कंप्यूटेशन की मुख्य यूनिट, इवेंट होती है. यह इवेंट, नैनो ऐप्लिकेशन के इवेंट हैंडलिंग एंट्री पॉइंट को पास किया जाता है. CHRE फ़्रेमवर्क को मल्टीथ्रेड किया जा सकता है. हालांकि, किसी नैनो ऐप्लिकेशन को एक साथ कई थ्रेड से कभी भी एक्ज़ीक्यूट नहीं किया जाता. CHRE फ़्रेमवर्क, दिए गए नैनो ऐप्लिकेशन के साथ इंटरैक्ट करता है. इसके लिए, नैनो ऐप्लिकेशन के तीन एंट्री पॉइंट (nanoappStart(), nanoappHandleEvent(), और nanoappEnd()) में से किसी एक का इस्तेमाल किया जाता है. इसके अलावा, CHRE फ़्रेमवर्क, CHRE एपीआई कॉल में दिए गए कॉलबैक के ज़रिए भी नैनो ऐप्लिकेशन के साथ इंटरैक्ट करता है. वहीं, नैनो ऐप्लिकेशन, CHRE फ़्रेमवर्क और उससे जुड़े सिस्टम के साथ इंटरैक्ट करते हैं. इसके लिए, CHRE एपीआई का इस्तेमाल किया जाता है. CHRE API, बुनियादी सुविधाओं का एक सेट उपलब्ध कराता है. साथ ही, यह कॉन्टेक्स्ट के हिसाब से सिग्नल ऐक्सेस करने की सुविधाएं भी देता है. जैसे, सेंसर, जीएनएसएस, वाई-फ़ाई, डब्ल्यूडब्ल्यूएएन, और ऑडियो. इसे वेंडर के हिसाब से उपलब्ध कराई गई अतिरिक्त सुविधाओं के साथ भी इस्तेमाल किया जा सकता है. इन सुविधाओं का इस्तेमाल, वेंडर के हिसाब से उपलब्ध कराए गए नैनो ऐप्लिकेशन कर सकते हैं.

बिल्ड सिस्टम

Context Hub HAL और AP-साइड के अन्य ज़रूरी कॉम्पोनेंट, Android के साथ बनाए जाते हैं. हालांकि, CHRE में चलने वाले कोड के लिए ऐसी ज़रूरी शर्तें हो सकती हैं जिनकी वजह से, वह Android के बिल्ड सिस्टम के साथ काम न करे. जैसे, किसी खास टूलचेन की ज़रूरत. इसलिए, AOSP में CHRE प्रोजेक्ट, नैनोऐप्लिकेशन को कंपाइल करने के लिए GNU Make पर आधारित एक आसान बिल्ड सिस्टम उपलब्ध कराता है. साथ ही, CHRE फ़्रेमवर्क को उन लाइब्रेरी में कंपाइल करने का विकल्प भी देता है जिन्हें सिस्टम के साथ इंटिग्रेट किया जा सकता है. डिवाइस बनाने वाली कंपनियों को CHRE के लिए सहायता जोड़ने के लिए, अपने टारगेट डिवाइसों के लिए बिल्ड सिस्टम की सहायता को AOSP में इंटिग्रेट करना चाहिए.

CHRE API को C99 भाषा के स्टैंडर्ड के हिसाब से लिखा गया है. साथ ही, रेफ़रंस इंप्लीमेंटेशन, C++11 के प्रतिबंधित सबसेट का इस्तेमाल करता है. यह ऐसे ऐप्लिकेशन के लिए सही है जिनमें संसाधन सीमित होते हैं.

CHRE API

CHRE API, C हेडर फ़ाइलों का एक कलेक्शन है. ये फ़ाइलें, नैनोऐप्लिकेशन और सिस्टम के बीच सॉफ़्टवेयर इंटरफ़ेस तय करती हैं. इसे इस तरह से डिज़ाइन किया गया है कि CHRE के साथ काम करने वाले सभी डिवाइसों पर, नैनोऐप्लिकेशन का कोड काम करे. इसका मतलब है कि नैनोऐप्लिकेशन के सोर्स कोड में बदलाव करने की ज़रूरत नहीं होती, ताकि वह नए डिवाइस टाइप के साथ काम कर सके. हालांकि, इसे खास तौर पर टारगेट डिवाइस के प्रोसेसर के निर्देश सेट या ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) के लिए फिर से कंपाइल करना पड़ सकता है. CHRE के आर्किटेक्चर और एपीआई डिज़ाइन से यह भी पक्का होता है कि नैनोऐप्लिकेशन, CHRE API के अलग-अलग वर्शन के साथ बाइनरी के तौर पर काम कर सकते हैं. इसका मतलब है कि नैनोऐप्लिकेशन को ऐसे सिस्टम पर चलाने के लिए फिर से कंपाइल करने की ज़रूरत नहीं होती है जो CHRE API के ऐसे वर्शन को लागू करता है जिसे नैनोऐप्लिकेशन के टारगेट एपीआई के मुकाबले कंपाइल किया गया है. दूसरे शब्दों में कहें, तो अगर कोई नैनोऐप्लिकेशन बाइनरी, CHRE API v1.3 के साथ काम करने वाले किसी डिवाइस पर चलती है और उस डिवाइस को CHRE API v1.4 के साथ काम करने के लिए अपग्रेड किया जाता है, तो वही नैनोऐप्लिकेशन बाइनरी काम करती रहती है. इसी तरह, नैनोऐप्लिकेशन CHRE API v1.2 पर चल सकता है. साथ ही, यह रनटाइम में यह तय कर सकता है कि इसे इस्तेमाल करने के लिए, API v1.3 की सुविधाओं की ज़रूरत है या नहीं. इसके अलावा, यह भी तय कर सकता है कि यह काम कर सकता है या नहीं. ऐसा हो सकता है कि कुछ सुविधाएं ठीक से काम न करें.

CHRE API के नए वर्शन, Android के साथ रिलीज़ किए जाते हैं. हालांकि, CHRE को वेंडर के लागू किए गए सिस्टम के तहत लागू किया जाता है. इसलिए, किसी डिवाइस पर काम करने वाला CHRE API वर्शन, Android वर्शन से जुड़ा होना ज़रूरी नहीं है.

वर्शन के बारे में खास जानकारी

Android HIDL वर्शनिंग स्कीम की तरह, CHRE API सिमैंटिक वर्शनिंग का पालन करता है. मेजर वर्शन से बाइनरी कंपैटिबिलिटी का पता चलता है. वहीं, पुराने सिस्टम के साथ काम करने वाली सुविधाएँ उपलब्ध होने पर, माइनर वर्शन को बढ़ाया जाता है. CHRE API में सोर्स कोड के एनोटेशन शामिल होते हैं. इनसे यह पता चलता है कि किस वर्शन में कोई फ़ंक्शन या पैरामीटर जोड़ा गया है. उदाहरण के लिए, @since v1.1.

CHRE लागू करने पर, chreGetVersion() के ज़रिए प्लैटफ़ॉर्म के हिसाब से पैच वर्शन भी दिखता है. इससे पता चलता है कि लागू करने के दौरान, गड़बड़ियों को कब ठीक किया गया या छोटे-मोटे अपडेट कब किए गए.

वर्शन 1.0 (Android 7)

इसमें सेंसर और कोर नैनोऐप्लिकेशन की सुविधाओं के लिए सहायता शामिल है. जैसे, इवेंट और टाइमर.

वर्शन 1.1 (Android 8)

इस अपडेट में, जीएनएसएस से मिली जगह की जानकारी और रॉ मेज़रमेंट, वाई-फ़ाई स्कैनिंग, और मोबाइल नेटवर्क की जानकारी के ज़रिए जगह की जानकारी देने की सुविधाएं जोड़ी गई हैं. साथ ही, नैनोऐप्लिकेशन से नैनोऐप्लिकेशन के बीच कम्यूनिकेशन को चालू करने और अन्य सुधारों के लिए, सामान्य सुधार किए गए हैं.

वर्शन 1.2 (Android 9)

इसमें कम पावर वाले माइक्रोफ़ोन, वाई-फ़ाई आरटीटी रेंजिंग, एपी वेक और स्लीप नोटिफ़िकेशन, और अन्य सुधारों से जुड़ा डेटा शामिल है.

वर्शन 1.3 (Android 10)

इससे सेंसर कैलिब्रेशन डेटा से जुड़ी क्षमताओं को बेहतर बनाया जाता है. साथ ही, यह मांग पर बैच किए गए सेंसर डेटा को फ़्लश करने की सुविधा जोड़ता है. यह स्टेप डिटेक्ट सेंसर टाइप को तय करता है और जीएनएसएस की जगह की जानकारी के इवेंट को ज़्यादा सटीक फ़ील्ड के साथ बढ़ाता है.

वर्शन 1.4 (Android 11)

इसमें 5G सेल की जानकारी, नैनो ऐप्लिकेशन डीबग डंप, और अन्य सुधारों के लिए सहायता जोड़ी गई है.

सिस्टम की ज़रूरी सुविधाएं

सेंसर्स जैसे कॉन्टेक्स्ट के हिसाब से सिग्नल देने वाले सोर्स को वैकल्पिक सुविधा वाले क्षेत्रों में बांटा गया है. हालांकि, कुछ मुख्य फ़ंक्शन सभी CHRE लागू करने के लिए ज़रूरी होते हैं. इसमें मुख्य सिस्टम एपीआई शामिल हैं. जैसे, टाइमर सेट करने, ऐप्लिकेशन प्रोसेसर पर क्लाइंट को मैसेज भेजने और उनसे मैसेज पाने, लॉगिंग करने, और अन्य कामों के लिए एपीआई. पूरी जानकारी के लिए, एपीआई हेडर देखें.

CHRE API में कोड की गई मुख्य सिस्टम सुविधाओं के अलावा, CHRE की सिस्टम-लेवल की ज़रूरी सुविधाएं भी होती हैं. ये सुविधाएं, कॉन्टेक्स्ट हब HAL लेवल पर तय की जाती हैं. इनमें सबसे अहम सुविधा, नैनो ऐप्लिकेशन को डाइनैमिक तरीके से लोड और अनलोड करने की सुविधा है.

C/C++ स्टैंडर्ड लाइब्रेरी

मेमोरी के इस्तेमाल और सिस्टम की जटिलता को कम करने के लिए, CHRE को सिर्फ़ स्टैंडर्ड C और C++ लाइब्रेरी के सबसेट और रनटाइम सपोर्ट की ज़रूरत वाली भाषा की सुविधाओं के साथ काम करना होता है. इन सिद्धांतों के आधार पर, कुछ सुविधाओं को साफ़ तौर पर शामिल नहीं किया गया है. ऐसा इसलिए, क्योंकि वे मेमोरी और ओएस-लेवल की डिपेंडेंसी पर बहुत ज़्यादा निर्भर करती हैं. वहीं, कुछ सुविधाओं को इसलिए शामिल नहीं किया गया है, क्योंकि उनकी जगह CHRE के लिए ज़्यादा सही एपीआई का इस्तेमाल किया जाता है. यहां दी गई सूची में सभी सुविधाएं शामिल नहीं हैं. हालांकि, नैनो ऐप्लिकेशन के लिए ये सुविधाएं उपलब्ध नहीं कराई जाएंगी:

• C++ अपवाद और रनटाइम टाइप की जानकारी (आरटीटीआई)
• स्टैंडर्ड लाइब्रेरी में मल्टीथ्रेडिंग की सुविधा उपलब्ध है. इसमें C++11 हेडर शामिल हैं <thread>, <mutex>, <atomic>, <future>
• C और C++ की स्टैंडर्ड इनपुट/आउटपुट लाइब्रेरी
• C++ स्टैंडर्ड टेंप्लेट लाइब्रेरी (एसटीएल)
• C++ स्टैंडर्ड रेगुलर एक्सप्रेशन लाइब्रेरी
• स्टैंडर्ड फ़ंक्शन (उदाहरण के लिए, malloc, calloc, realloc, free, operator new) और अन्य स्टैंडर्ड लाइब्रेरी फ़ंक्शन के ज़रिए डाइनैमिक मेमोरी का ऐलोकेशन. ये फ़ंक्शन, डाइनैमिक ऐलोकेशन का इस्तेमाल करते हैं. जैसे, std::unique_ptr
• स्थानीय भाषा में उपलब्ध कराने और यूनिकोड वर्णों के इस्तेमाल की सुविधा
• तारीख और समय की लाइब्रेरी
• ऐसे फ़ंक्शन जो प्रोग्राम के सामान्य फ़्लो में बदलाव करते हैं. इनमें <setjmp.h>, <signal.h>, abort, std::terminate शामिल हैं
• होस्ट एनवायरमेंट को ऐक्सेस करना. इसमें system और getenv शामिल हैं
• POSIX और अन्य लाइब्रेरी, C99 या C++11 भाषा के मानकों में शामिल नहीं हैं

कई मामलों में, CHRE API फ़ंक्शन और यूटिलिटी लाइब्रेरी से मिलती-जुलती सुविधाएं उपलब्ध होती हैं. उदाहरण के लिए, chreLog का इस्तेमाल Android logcat सिस्टम को टारगेट करने वाली डीबग लॉगिंग के लिए किया जा सकता है. वहीं, ज़्यादा पारंपरिक प्रोग्राम printf या std::cout का इस्तेमाल कर सकते हैं.

इसके उलट, कुछ स्टैंडर्ड लाइब्रेरी की सुविधाओं का इस्तेमाल करना ज़रूरी है. इन फ़ंक्शन को स्टैटिक लाइब्रेरी के ज़रिए नैनो ऐप्लिकेशन बाइनरी में शामिल करने या नैनो ऐप्लिकेशन और सिस्टम के बीच डाइनैमिक लिंकिंग के ज़रिए उपलब्ध कराने का काम, प्लैटफ़ॉर्म के लागू करने वाले व्यक्ति या कंपनी का होता है. इसमें ये शामिल हैं, लेकिन इनके अलावा और भी चीज़ें शामिल हो सकती हैं:

• स्ट्रिंग और ऐरे यूटिलिटी: memcmp, memcpy, memmove, memset, strlen

• गणित की लाइब्रेरी: सिंगल-प्रेसिशन फ़्लोटिंग-पॉइंट फ़ंक्शन, जिनका आम तौर पर इस्तेमाल किया जाता है:

  • बुनियादी कार्रवाइयाँ: ceilf, fabsf, floorf, fmaxf, fminf, fmodf, roundf, lroundf, remainderf
  • एक्सपोनेंशियल और पावर फ़ंक्शन: expf, log2f, powf, sqrtf
  • त्रिकोणमितीय और हाइपरबोलिक फ़ंक्शन: sinf, cosf, tanf, asinf, acosf, atan2f, tanhf

कुछ प्लैटफ़ॉर्म पर अतिरिक्त सुविधाएं उपलब्ध होती हैं. हालांकि, CHRE के अलग-अलग वर्शन पर नैनो ऐप्लिकेशन को तब तक पोर्टेबल नहीं माना जाता, जब तक कि वह CHRE API फ़ंक्शन और मंज़ूरी पा चुकी स्टैंडर्ड लाइब्रेरी के फ़ंक्शन पर अपनी बाहरी डिपेंडेंसी को सीमित न कर ले.

वैकल्पिक सुविधाएं

हार्डवेयर और सॉफ़्टवेयर का प्रमोशन करने के लिए, CHRE API को अलग-अलग हिस्सों में बांटा गया है. हालांकि, एपीआई के हिसाब से ये हिस्से ज़रूरी नहीं हैं. ऐसा हो सकता है कि इन सुविधाओं की ज़रूरत, CHRE के साथ काम करने वाले किसी डिवाइस पर न हो. हालांकि, किसी खास नैनोऐप्लिकेशन के लिए इनकी ज़रूरत पड़ सकती है. अगर कोई प्लैटफ़ॉर्म, एपीआई के किसी सेट के साथ काम नहीं करता है, तो भी उन फ़ंक्शन का रेफ़रंस देने वाले नैनो ऐप्लिकेशन बनाए और लोड किए जा सकते हैं.

सेंसर

CHRE API, सेंसर से डेटा का अनुरोध करने की सुविधा देता है. इसमें एक्सलरोमीटर, जाइरोस्कोप, मैग्नेटोमीटर, आस-पास की रोशनी का सेंसर, और प्रॉक्सिमिटी सेंसर शामिल हैं. इन एपीआई का मकसद, Android Sensors APIs जैसी सुविधाओं का सेट उपलब्ध कराना है. इनमें, बिजली की खपत को कम करने के लिए सेंसर के सैंपल को बैच करने की सुविधा भी शामिल है. CHRE में सेंसर डेटा को प्रोसेस करने से, एपी पर प्रोसेस करने की तुलना में मोशन सिग्नल को प्रोसेस करने में बहुत कम बैटरी खर्च होती है और कम समय लगता है.

जीएनएसएस

CHRE, ग्लोबल नेविगेशन सैटलाइट सिस्टम (जीएनएसएस) से जगह की जानकारी का डेटा पाने के लिए एपीआई उपलब्ध कराता है. इसमें जीपीएस और अन्य सैटलाइट कॉन्स्टेलेशन शामिल हैं. इसमें समय-समय पर जगह की जानकारी को ठीक करने के अनुरोध शामिल हैं. साथ ही, मेज़रमेंट का रॉ डेटा भी शामिल है. हालांकि, ये दोनों अलग-अलग सुविधाएं हैं. CHRE, GNSS सबसिस्टम से सीधे तौर पर जुड़ा होता है. इसलिए, AP पर आधारित GNSS अनुरोधों की तुलना में, इसमें बिजली की खपत कम होती है. इसकी वजह यह है कि लोकेशन सेशन के पूरे लाइफ़साइकल के दौरान, AP स्लीप मोड में रह सकता है.

वाई-फ़ाई

CHRE, वाई-फ़ाई चिप के साथ इंटरैक्ट करने की सुविधा देता है. इसका मुख्य मकसद, जगह की जानकारी हासिल करना है. जीएनएसएस, खुले में अच्छी तरह से काम करता है. हालांकि, वाई-फ़ाई स्कैन के नतीजे, घर के अंदर और विकसित इलाकों में जगह की सटीक जानकारी दे सकते हैं. स्कैन करने के लिए एपी को चालू करने की लागत से बचने के अलावा, CHRE, कनेक्टिविटी के लिए वाई-फ़ाई फ़र्मवेयर की ओर से किए गए वाई-फ़ाई स्कैन के नतीजों को सुन सकता है. आम तौर पर, ये नतीजे एपी को बिजली की खपत कम करने के लिए नहीं दिए जाते. कनेक्टिविटी स्कैन का इस्तेमाल करके, कॉन्टेक्स्ट के हिसाब से जानकारी पाने में मदद मिलती है. इससे, वाई-फ़ाई स्कैन की कुल संख्या कम हो जाती है और बैटरी की बचत होती है.

CHRE API v1.1 में वाई-फ़ाई के लिए सहायता जोड़ी गई है. इसमें स्कैन के नतीजों को मॉनिटर करने और मांग पर स्कैन ट्रिगर करने की सुविधा भी शामिल है. इन सुविधाओं को v1.2 में बेहतर बनाया गया है. अब ये सुविधाएं, इस सुविधा के साथ काम करने वाले ऐक्सेस पॉइंट के लिए राउंड-ट्रिप टाइम (आरटीटी) मेज़रमेंट कर सकती हैं. इससे, सटीक रिलेटिव पोज़िशन का पता लगाया जा सकता है.

WWAN

CHRE API, सेल की पहचान से जुड़ी जानकारी को वापस पाने की सुविधा देता है. यह जानकारी, सर्विस देने वाली सेल और उसके आस-पास की सेल के लिए होती है. आम तौर पर, इसका इस्तेमाल जगह की सामान्य जानकारी के लिए किया जाता है.

ऑडियो

CHRE, कम पावर वाले माइक्रोफ़ोन से मिले ऑडियो डेटा के बैच को प्रोसेस कर सकता है. आम तौर पर, यह SoundTrigger HAL को लागू करने के लिए इस्तेमाल किए गए हार्डवेयर का इस्तेमाल करता है. CHRE में ऑडियो डेटा को प्रोसेस करने से, इसे मोशन सेंसर जैसे अन्य डेटा के साथ जोड़ा जा सकता है.

रेफ़रंस के तौर पर लागू करना

CHRE फ़्रेमवर्क के लिए रेफ़रंस कोड, AOSP में system/chre प्रोजेक्ट में शामिल किया गया है. इसे C++11 में लागू किया गया है. हालांकि, यह ज़रूरी नहीं है, लेकिन हमारा सुझाव है कि सभी CHRE को इस कोडबेस पर आधारित होना चाहिए. इससे यह पक्का करने में मदद मिलती है कि सभी CHRE एक जैसे हों और नई सुविधाओं को तेज़ी से अपनाया जा सके. इस कोड को Android के मुख्य फ़्रेमवर्क के तौर पर देखा जा सकता है. ऐसा इसलिए, क्योंकि यह ऐप्लिकेशन के इस्तेमाल किए जाने वाले एपीआई का ओपन-सोर्स वर्शन है. यह कंपैटिबिलिटी के लिए, बेसलाइन और स्टैंडर्ड के तौर पर काम करता है. इसे वेंडर के हिसाब से उपलब्ध सुविधाओं के साथ, अपनी पसंद के मुताबिक बनाया और बढ़ाया जा सकता है. हालांकि, हमारा सुझाव है कि सामान्य कोड को रेफ़रंस के जितना हो सके उतना करीब रखें. Android के HAL की तरह, CHRE का रेफ़रंस इंप्लीमेंटेशन, अलग-अलग प्लैटफ़ॉर्म ऐब्स्ट्रैक्शन का इस्तेमाल करता है. इससे, इसे कम से कम ज़रूरी शर्तें पूरी करने वाले किसी भी डिवाइस के हिसाब से बनाया जा सकता है.

तकनीकी जानकारी और पोर्टिंग गाइड के लिए, system/chre प्रोजेक्ट में शामिल README देखें.