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