एंड्रॉइड 10 में, कॉन्फिगस्टोर एचएएल vendor विभाजन में कॉन्फ़िगरेशन मानों को संग्रहीत करने के लिए बिल्ड फ्लैग का उपयोग करता है, और system विभाजन में एक सेवा एचआईडीएल का उपयोग करके उन मूल्यों तक पहुंचती है (यह एंड्रॉइड 9 में भी सच है)। हालांकि, उच्च स्मृति खपत और कठिन उपयोग के कारण, कॉन्फिगस्टोर एचएएल को हटा दिया गया है।
कॉन्फिगस्टोर एचएएल लीगेसी विक्रेता विभाजन का समर्थन करने के लिए एओएसपी में रहता है। Android 10 या बाद के संस्करण चलाने वाले उपकरणों पर, surfaceflinger पहले सिस्टम गुण पढ़ता है; यदि `SurfaceFlingerProperties.sysprop` में कॉन्फ़िगरेशन आइटम के लिए कोई सिस्टम गुण परिभाषित नहीं है, तो `surfaceflinger` कॉन्फिगस्टोर एचएएल पर वापस आ जाता है।
एंड्रॉइड 8.0 मोनोलिथिक एंड्रॉइड ओएस को जेनेरिक ( system.img ) और हार्डवेयर-विशिष्ट (वेंडर. odm.img vendor.img विभाजन में विभाजित करता है। इस परिवर्तन के परिणामस्वरूप, सिस्टम विभाजन में स्थापित मॉड्यूल से सशर्त संकलन को हटा दिया जाना चाहिए और ऐसे मॉड्यूल को रनटाइम पर सिस्टम के कॉन्फ़िगरेशन को निर्धारित करना चाहिए (और उस कॉन्फ़िगरेशन के आधार पर अलग व्यवहार करना चाहिए)।
कॉन्फिगस्टोर एचएएल एंड्रॉइड फ्रेमवर्क को कॉन्फ़िगर करने के लिए उपयोग किए जाने वाले रीड-ओनली कॉन्फ़िगरेशन आइटम तक पहुंचने के लिए एपीआई का एक सेट प्रदान करता है। यह पृष्ठ कॉन्फिगस्टोर एचएएल के डिजाइन का वर्णन करता है (और इस उद्देश्य के लिए सिस्टम गुणों का उपयोग क्यों नहीं किया गया); इस खंड के अन्य पृष्ठ एचएएल इंटरफ़ेस , सेवा कार्यान्वयन और क्लाइंट-साइड उपयोग का विवरण देते हैं, सभी एक उदाहरण के रूप में surfaceflinger का उपयोग करते हैं। ConfigStore इंटरफ़ेस क्लासेस में मदद के लिए, इंटरफ़ेस क्लासेस और आइटम्स जोड़ना देखें।
सिस्टम गुणों का उपयोग क्यों नहीं करें?
हमने सिस्टम गुणों का उपयोग करने पर विचार किया, लेकिन कई मूलभूत मुद्दे पाए, जिनमें शामिल हैं:
- मूल्यों पर लंबाई सीमा। सिस्टम गुणों की उनके मानों की लंबाई (92 बाइट्स) पर सख्त सीमाएं होती हैं। इसके अलावा, चूंकि इन सीमाओं को सीधे सी मैक्रोज़ के रूप में एंड्रॉइड ऐप्स के संपर्क में लाया गया है, इसलिए लंबाई बढ़ाने से पिछड़े-संगतता के मुद्दे हो सकते हैं।
- कोई प्रकार का समर्थन नहीं। सभी मान अनिवार्य रूप से तार हैं, और एपीआई केवल स्ट्रिंग को
intयाboolमें पार्स करते हैं। अन्य मिश्रित डेटा प्रकार (उदाहरण के लिए, सरणी और संरचना) को क्लाइंट द्वारा एन्कोड/डिकोड किया जाना चाहिए (उदाहरण के लिए,"aaa,bbb,ccc"को तीन स्ट्रिंग्स की एक सरणी के रूप में कोडित किया जा सकता है)। - ओवरराइट करता है। क्योंकि केवल-पढ़ने के लिए सिस्टम गुणों को एक बार लिखने के गुणों के रूप में कार्यान्वित किया जाता है, वेंडर/ओडीएम जो एओएसपी-परिभाषित रीड-ओनली मानों को ओवरराइड करना चाहते हैं, उन्हें एओएसपी-परिभाषित रीड-ओनली मानों से पहले अपने स्वयं के रीड-ओनली मानों को आयात करना होगा। यह, बदले में, विक्रेता-परिभाषित पुनर्लेखन योग्य मूल्यों को एओएसपी-परिभाषित मूल्यों द्वारा ओवरराइड किया जा रहा है।
- पता स्थान आवश्यकताओं। सिस्टम गुण प्रत्येक प्रक्रिया में अपेक्षाकृत बड़ी मात्रा में पता स्थान लेते हैं। सिस्टम गुणों को 128 KB के एक निश्चित आकार के साथ
prop_areaइकाइयों में समूहीकृत किया जाता है, जिनमें से सभी को एक प्रक्रिया पता स्थान पर आवंटित किया जाता है, भले ही इसमें केवल एक सिस्टम संपत्ति का उपयोग किया जा रहा हो। यह 32-बिट उपकरणों पर समस्याएँ पैदा कर सकता है जहाँ पता स्थान कीमती है।
हमने संगतता का त्याग किए बिना इन सीमाओं को पार करने का प्रयास किया, लेकिन इस बात को लेकर चिंतित रहे कि सिस्टम गुण केवल-पढ़ने के लिए कॉन्फ़िगरेशन आइटम तक पहुँचने का समर्थन करने के लिए डिज़ाइन नहीं किए गए थे। अंततः हमने तय किया कि सिस्टम गुण वास्तविक समय में सभी Android पर कुछ गतिशील रूप से अपडेट किए गए आइटम साझा करने के लिए बेहतर अनुकूल हैं, और यह कि केवल-पढ़ने के लिए कॉन्फ़िगरेशन आइटम तक पहुँचने के लिए समर्पित एक नई प्रणाली की आवश्यकता मौजूद है।
कॉन्फिगस्टोर एचएएल डिजाइन
मूल डिजाइन सरल है:
चित्रा 1. कॉन्फिगस्टोर एचएएल डिजाइन
- HIDL में बिल्ड फ्लैग (वर्तमान में सशर्त रूप से ढांचे को संकलित करने के लिए उपयोग किया जाता है) का वर्णन करें।
- विक्रेता और ओईएम एचएएल सेवा को लागू करके झंडे बनाने के लिए एसओसी और डिवाइस-विशिष्ट मूल्य प्रदान करते हैं।
- रनटाइम पर कॉन्फ़िगरेशन आइटम का मान खोजने के लिए एचएएल सेवा का उपयोग करने के लिए ढांचे को संशोधित करें।
वर्तमान में ढांचे द्वारा संदर्भित कॉन्फ़िगरेशन आइटम एक संस्करणित एचआईडीएल पैकेज ( android.hardware.configstore@1.0 ) में शामिल हैं। विक्रेता/OEM इस पैकेज में इंटरफेस को लागू करके कॉन्फ़िगरेशन आइटम को मान प्रदान करते हैं, और जब कॉन्फ़िगरेशन आइटम के लिए मान प्राप्त करने की आवश्यकता होती है तो फ्रेमवर्क इंटरफेस का उपयोग करता है।
सुरक्षा विचार
समान इंटरफ़ेस में परिभाषित बिल्ड फ़्लैग समान SELinux नीति से प्रभावित होते हैं। यदि एक या अधिक बिल्ड फ़्लैग की SELinux नीतियां भिन्न होनी चाहिए, तो उन्हें दूसरे इंटरफ़ेस से अलग किया जाना चाहिए । इसके लिए android.hardware.configstore package के बड़े संशोधन की आवश्यकता हो सकती है क्योंकि अलग किए गए इंटरफेस अब पिछड़े-संगत नहीं हैं।