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