आरआईएल रिफैक्टरिंग

एंड्रॉइड 7.0 ने आरआईएल कार्यक्षमता में सुधार के लिए सुविधाओं के एक सेट का उपयोग करके रेडियो इंटरफ़ेस लेयर (आरआईएल) को दोबारा तैयार किया। इन सुविधाओं को लागू करने के लिए पार्टनर कोड में बदलाव की आवश्यकता है, जो वैकल्पिक हैं लेकिन प्रोत्साहित किए जाते हैं। रिफैक्टरिंग परिवर्तन पिछड़े संगत हैं, इसलिए रिफैक्टरिंग सुविधाओं का पूर्व कार्यान्वयन काम करना जारी रखता है।

आरआईएल रीफैक्टरिंग में निम्नलिखित सुधार शामिल हैं:

• आरआईएल त्रुटि कोड। मौजूदा GENERIC_FAILURE कोड के अतिरिक्त विशिष्ट त्रुटि कोड सक्षम करता है। यह त्रुटियों के कारण के बारे में अधिक विशिष्ट जानकारी प्रदान करके त्रुटि समस्या निवारण में सहायता करता है।
• आरआईएल संस्करण. अधिक सटीक और कॉन्फ़िगर करने में आसान संस्करण जानकारी प्रदान करता है।
• वेकलॉक का उपयोग करके आरआईएल संचार। डिवाइस बैटरी प्रदर्शन में सुधार करता है।

आप उपरोक्त किसी भी या सभी सुधारों को लागू कर सकते हैं। अधिक जानकारी के लिए, https://android.googlesource.com/platform/hardware/ril/+/main/include/telephony/ril.h में RIL वर्जनिंग पर कोड टिप्पणियाँ देखें।

उन्नत आरआईएल त्रुटि कोड लागू करना

लगभग सभी आरआईएल अनुरोध कॉल किसी त्रुटि के जवाब में GENERIC_FAILURE त्रुटि कोड लौटा सकते हैं। यह ओईएम द्वारा लौटाई गई सभी अपेक्षित प्रतिक्रियाओं के साथ एक समस्या है, जिससे बग रिपोर्ट से किसी समस्या को डीबग करना मुश्किल हो सकता है यदि अलग-अलग कारणों से आरआईएल कॉल द्वारा समान GENERIC_FAILURE त्रुटि कोड लौटाया जाता है। विक्रेताओं को यह पहचानने में भी काफी समय लग सकता है कि कोड का कौन सा भाग GENERIC_FAILURE कोड लौटा सकता है।

Android 7.x और उच्चतर में, OEM प्रत्येक भिन्न त्रुटि से संबद्ध एक विशिष्ट त्रुटि कोड मान लौटा सकते हैं जिसे वर्तमान में GENERIC_FAILURE के रूप में वर्गीकृत किया गया है। जो OEM अपने कस्टम त्रुटि कोड को सार्वजनिक रूप से प्रकट नहीं करना चाहते हैं, वे OEM_ERROR_1 से OEM_ERROR_X के रूप में मैप किए गए पूर्णांकों (जैसे 1 से x) के एक अलग सेट के रूप में त्रुटियों को वापस कर सकते हैं। विक्रेताओं को यह सुनिश्चित करना चाहिए कि प्रत्येक ऐसे नकाबपोश त्रुटि कोड ने कोड में एक अद्वितीय त्रुटि कारण के लिए मानचित्र लौटाए। जब भी OEM द्वारा सामान्य त्रुटियाँ लौटाई जाती हैं, तो विशिष्ट त्रुटि कोड का उपयोग करने से RIL डिबगिंग में तेजी आ सकती है, क्योंकि GENERIC_FAILURE त्रुटि कोड के सटीक कारण की पहचान करने में अक्सर बहुत अधिक समय लग सकता है (और कभी-कभी इसका पता लगाना असंभव होता है)।

इसके अलावा, ril.h एनम RIL_LastCallFailCause और RIL_DataCallFailCause के लिए अधिक त्रुटि कोड जोड़ता है ताकि विक्रेता कोड CALL_FAIL_ERROR_UNSPECIFIED और PDP_FAIL_ERROR_UNSPECIFIED जैसी सामान्य त्रुटियों को वापस करने से बच सके।

उन्नत आरआईएल त्रुटि कोड को मान्य किया जा रहा है

GENERIC_FAILURE कोड को बदलने के लिए नए त्रुटि कोड जोड़ने के बाद, सत्यापित करें कि GENERIC_FAILURE के बजाय RIL कॉल द्वारा नए त्रुटि कोड लौटाए गए हैं।

उन्नत आरआईएल संस्करण को लागू करना

पुराने एंड्रॉइड रिलीज़ में आरआईएल संस्करण समस्याग्रस्त था: संस्करण स्वयं सटीक नहीं था, आरआईएल संस्करण की रिपोर्ट करने का तंत्र अस्पष्ट था (जिसके कारण कुछ विक्रेताओं ने गलत संस्करण की रिपोर्ट की थी), और संस्करण का अनुमान लगाने के लिए समाधान में अशुद्धि होने का खतरा था।

एंड्रॉइड 7.x और उच्चतर में, ril.h सभी RIL संस्करण मानों को दस्तावेज़ित करता है, संबंधित RIL संस्करण का वर्णन करता है, और उस संस्करण के लिए सभी परिवर्तनों को सूचीबद्ध करता है। RIL संस्करण के अनुरूप परिवर्तन करते समय, विक्रेताओं को अपने संस्करण को कोड में अपडेट करना होगा और उस संस्करण को RIL_REGISTER में वापस करना होगा।

उन्नत आरआईएल संस्करण को मान्य किया जा रहा है

सत्यापित करें कि आपके RIL कोड से संबंधित RIL संस्करण RIL_REGISTER के दौरान लौटाया गया है ( ril.h में परिभाषित RIL_VERSION के बजाय)।

वैकलॉक का उपयोग करके आरआईएल संचार को कार्यान्वित करना

आरआईएल संचार में समयबद्ध वैकलॉक का उपयोग गलत तरीके से किया जाता है, जो बैटरी के प्रदर्शन को नकारात्मक रूप से प्रभावित करता है। एंड्रॉइड 7.x और उच्चतर में, आप आरआईएल अनुरोधों को वर्गीकृत करके और विभिन्न अनुरोध प्रकारों के लिए वैकलॉक को अलग-अलग तरीके से संभालने के लिए कोड अपडेट करके प्रदर्शन में सुधार कर सकते हैं।

आरआईएल अनुरोधों को वर्गीकृत करना

आरआईएल अनुरोध या तो अनुरोधित या अनचाहे हो सकते हैं। विक्रेताओं को अनुरोधित अनुरोधों को निम्नलिखित में से एक के रूप में वर्गीकृत करना चाहिए:

• तुल्यकालिक । ऐसे अनुरोध जिनका जवाब देने में अधिक समय नहीं लगता। उदाहरण के लिए, RIL_REQUEST_GET_SIM_STATUS ।
• अतुल्यकालिक । ऐसे अनुरोध जिनका जवाब देने में काफी समय लगता है। उदाहरण के लिए, RIL_REQUEST_QUERY_AVAILABLE_NETWORKS ।

अतुल्यकालिक अनुरोधित आरआईएल अनुरोधों में काफी समय लग सकता है। विक्रेता कोड से एक एसीसी प्राप्त करने के बाद, आरआईएल जावा वैकलॉक जारी करता है, जिसके कारण एप्लिकेशन प्रोसेसर निष्क्रिय से निलंबित स्थिति में जा सकता है। जब प्रतिक्रिया विक्रेता कोड से उपलब्ध होती है, तो आरआईएल जावा (एप्लिकेशन प्रोसेसर) वैकलॉक को फिर से प्राप्त करता है, प्रतिक्रिया को संसाधित करता है, फिर निष्क्रिय हो जाता है। इस तरह निष्क्रिय से सस्पेंड से निष्क्रिय में जाने से बहुत अधिक बिजली की खपत हो सकती है।

यदि प्रतिक्रिया समय पर्याप्त लंबा नहीं है, तो वेकलॉक को पकड़ना और प्रतिक्रिया देने में लगने वाले पूरे समय के लिए निष्क्रिय रहना, वेकलॉक जारी करके निलंबित स्थिति में जाने और प्रतिक्रिया आने पर जागने की तुलना में अधिक शक्ति कुशल हो सकता है। विक्रेताओं को समय T के थ्रेशोल्ड मान को निर्धारित करने के लिए प्लेटफ़ॉर्म-विशिष्ट पावर माप का उपयोग करना चाहिए, जब पूरे समय T के लिए निष्क्रिय रहने से खपत होने वाली बिजली निष्क्रिय से निलंबित होने और एक ही समय T में निष्क्रिय होने पर खपत होने वाली बिजली से अधिक होती है। जब समय T ज्ञात होता है, तो समय T से अधिक समय लेने वाले आरआईएल कमांड को एसिंक्रोनस के रूप में वर्गीकृत किया जा सकता है और शेष कमांड को सिंक्रोनस के रूप में वर्गीकृत किया जा सकता है।

आरआईएल संचार परिदृश्य

निम्नलिखित चित्र सामान्य आरआईएल संचार परिदृश्यों को दर्शाते हैं और आरआईएल के अनुरोधित और अनचाहे अनुरोधों को संभालने के लिए कोड को संशोधित करने के लिए समाधान प्रदान करते हैं।

नोट: निम्नलिखित आरेखों में उपयोग किए गए कार्यों पर कार्यान्वयन विवरण के लिए, ril.cpp में acquireWakeLock() , decrementWakeLock() और clearWakeLock( ) तरीकों को देखें।

परिदृश्य: आरआईएल अनुरोध और अतुल्यकालिक प्रतिक्रिया का अनुरोध किया

इस परिदृश्य में, यदि आरआईएल द्वारा मांगी गई प्रतिक्रिया में काफी समय लगने की उम्मीद है (यानी RIL_REQUEST_GET_AVAILABLE_NETWORKS की प्रतिक्रिया), तो एप्लिकेशन प्रोसेसर साइड पर वेकलॉक लंबे समय तक आयोजित किया जाता है। मॉडेम समस्याओं के कारण लंबा इंतजार भी करना पड़ सकता है।

चित्र 1. आरआईएल ने अतुल्यकालिक प्रतिक्रिया मांगी।

समाधान 1: मॉडेम आरआईएल अनुरोध और अतुल्यकालिक प्रतिक्रिया के लिए वैकलॉक रखता है।

चित्र 2. मॉडेम द्वारा धारण किया गया वेकलॉक।

1. आरआईएल अनुरोध भेजा जाता है और मॉडेम उस अनुरोध को संसाधित करने के लिए वैकलॉक प्राप्त करता है।
2. मॉडेम पावती भेजता है जिसके कारण जावा पक्ष वैकलॉक काउंटर को कम कर देता है और काउंटर मान 0 होने पर इसे जारी कर देता है।

   नोट: अनुरोध-एसीके अनुक्रम के लिए वैकलॉक टाइमआउट अवधि वर्तमान में उपयोग की जाने वाली टाइमआउट अवधि से छोटी होगी क्योंकि एके को काफी जल्दी प्राप्त किया जाना चाहिए।

3. अनुरोध को संसाधित करने के बाद, मॉडेम विक्रेता कोड को एक इंटरप्ट भेजता है जो वेकलॉक प्राप्त करता है और ril.cpp को एक प्रतिक्रिया भेजता है, जो बदले में वेकलॉक प्राप्त करता है और जावा पक्ष को एक प्रतिक्रिया भेजता है।
4. जब प्रतिक्रिया जावा पक्ष तक पहुंचती है, तो वैकलॉक हासिल कर लिया जाता है और कॉल करने वाले को प्रतिक्रिया लौटा दी जाती है।
5. प्रतिक्रिया को सभी मॉड्यूल द्वारा संसाधित करने के बाद, पावती (सॉकेट के माध्यम से) वापस ril.cpp पर भेजी जाती है, जो चरण 3 में प्राप्त वेकलॉक को जारी करती है।

समाधान 2: मॉडेम में वैकलॉक नहीं है और प्रतिक्रिया त्वरित है (सिंक्रोनस आरआईएल अनुरोध और प्रतिक्रिया)। सिंक्रोनस बनाम एसिंक्रोनस व्यवहार को एक विशिष्ट आरआईएल कमांड के लिए हार्डकोड किया जाता है और कॉल-दर-कॉल आधार पर निर्णय लिया जाता है।

चित्र 3. वेकलॉक मॉडेम द्वारा धारण नहीं किया गया।

1. आरआईएल अनुरोध जावा पक्ष पर acquireWakeLock() कॉल करके भेजा जाता है।
2. विक्रेता कोड को वैकलॉक प्राप्त करने की आवश्यकता नहीं है और वह अनुरोध को संसाधित कर सकता है और तुरंत प्रतिक्रिया दे सकता है।
3. जब जावा पक्ष द्वारा प्रतिक्रिया प्राप्त होती है, तो decrementWakeLock() को कॉल किया जाता है, जो वैकलॉक काउंटर को कम करता है और यदि काउंटर मान 0 है तो वेकलॉक जारी करता है।

परिदृश्य: आरआईएल की अनचाही प्रतिक्रिया

इस परिदृश्य में, आरआईएल की अनचाही प्रतिक्रियाओं में एक वेकलॉक प्रकार का ध्वज होता है जो इंगित करता है कि विक्रेता प्रतिक्रिया के लिए एक वेकलॉक प्राप्त करने की आवश्यकता है या नहीं। यदि ध्वज सेट किया गया है, तो एक समयबद्ध वैकलॉक सेट किया जाता है और प्रतिक्रिया सॉकेट पर जावा पक्ष में भेजी जाती है। जब टाइमर समाप्त हो जाता है, तो वैकलॉक जारी हो जाता है। विभिन्न आरआईएल की अनचाही प्रतिक्रियाओं के लिए समयबद्ध वैकलॉक बहुत लंबा या बहुत छोटा हो सकता है।

चित्र 4. आरआईएल की अनचाही प्रतिक्रिया।

समाधान: अवांछित प्रतिक्रिया भेजते समय मूल पक्ष पर समयबद्ध वैकलॉक रखने के बजाय जावा कोड से मूल पक्ष ( ril.cpp ) पर एक पावती भेजी जाती है।

चित्र 5. समयबद्ध वेकलॉक के बजाय एके का उपयोग करना।

पुन: डिज़ाइन किए गए वेकलॉक को मान्य किया जा रहा है

सत्यापित करें कि आरआईएल कॉल की पहचान सिंक्रोनस या एसिंक्रोनस के रूप में की गई है। क्योंकि बैटरी बिजली की खपत हार्डवेयर/प्लेटफ़ॉर्म पर निर्भर हो सकती है, विक्रेताओं को यह पता लगाने के लिए कुछ आंतरिक परीक्षण करना चाहिए कि क्या एसिंक्रोनस कॉल के लिए नए वैकलॉक सिमेंटिक्स का उपयोग करने से बैटरी बिजली की बचत होती है।