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

स्मार्टफ़ोन में कई प्रोसेसर होते हैं. हर प्रोसेसर को अलग-अलग टास्क करने के लिए ऑप्टिमाइज़ किया जाता है. हालांकि, 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 के रेफ़रंस इंप्लीमेंटेशन के साथ काम करता है. यह system/chre/host पर उपलब्ध है.

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

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

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

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

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

Context Hub 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, बुनियादी सुविधाओं का एक सेट उपलब्ध कराता है. साथ ही, यह कॉन्टेक्स्ट के हिसाब से सिग्नल ऐक्सेस करने की सुविधाएं भी देता है. जैसे, सेंसर, GNSS, वाई-फ़ाई, WWAN, और ऑडियो. इसे वेंडर के हिसाब से उपलब्ध कराई गई अतिरिक्त सुविधाओं के साथ भी इस्तेमाल किया जा सकता है. इन सुविधाओं का इस्तेमाल, वेंडर के हिसाब से उपलब्ध कराए गए नैनो ऐप्लिकेशन कर सकते हैं.

बिल्ड सिस्टम

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

हर वर्शन की खास जानकारी देखने के लिए, version.h पर जाएं.

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

सेंसर्स जैसे कॉन्टेक्स्ट के हिसाब से सिग्नल देने वाले सोर्स को, वैकल्पिक सुविधा वाले क्षेत्रों में बांटा गया है. हालांकि, कुछ मुख्य फ़ंक्शन सभी 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 API जैसी सुविधाओं का सेट उपलब्ध कराना है. इनमें, बैटरी की खपत को कम करने के लिए सेंसर के सैंपल को बैच करने की सुविधा भी शामिल है. CHRE में सेंसर डेटा को प्रोसेस करने से, एपी पर चलने की तुलना में मोशन सिग्नल को प्रोसेस करने में बहुत कम बैटरी खर्च होती है और कम समय लगता है.

जीएनएसएस

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

वाई-फ़ाई

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

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

WWAN

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

ऑडियो

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

ब्लूटूथ

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

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

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

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