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

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

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

खास कॉन्सेप्ट

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

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

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

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

सीएचआरई फ़्रेमवर्क का आर्किटेक्चर

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

Context Hub HAL

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

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

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

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

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

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

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

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

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

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

सीएचआरई सिस्टम के बारे में खास जानकारी

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

बिल्ड सिस्टम

Context Hub HAL और एपी-साइड के अन्य ज़रूरी कॉम्पोनेंट, 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 पर चल सकता है. साथ ही, रनटाइम के दौरान यह तय कर सकता है कि उसे इस्तेमाल करने के लिए, एपीआई 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)

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

वर्शन 1.2 (Android 9)

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

वर्शन 1.3 (Android 10)

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

वर्शन 1.4 (Android 11)

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

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

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

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

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

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

  • C++ अपवाद और रनटाइम टाइप की जानकारी (RTTI)
  • स्टैंडर्ड लाइब्रेरी में मल्टीथ्रेडिंग की सुविधा, जिसमें 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 एपीआई फ़ंक्शन और मंज़ूरी पा चुके स्टैंडर्ड लाइब्रेरी फ़ंक्शन तक सीमित न कर दे.

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

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

सेंसर

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

जीएनएसएस

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

वाई-फ़ाई

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

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

WWAN

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

ऑडियो

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

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

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

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