Android 10 में, ConfigStore HAL, vendor पार्टिशन में कॉन्फ़िगरेशन वैल्यू सेव करने के लिए, बिल्ड फ़्लैग का इस्तेमाल करता है. साथ ही, system पार्टिशन में मौजूद कोई सेवा, 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) पार्टिशन में बांटता है. इस बदलाव के बाद, सिस्टम पार्टिशन में इंस्टॉल किए गए मॉड्यूल से, शर्तों के हिसाब से कंपाइल करने की सुविधा हटानी होगी. साथ ही, ऐसे मॉड्यूल को रनटाइम पर सिस्टम का कॉन्फ़िगरेशन तय करना होगा. इसके अलावा, उन्हें उस कॉन्फ़िगरेशन के हिसाब से अलग-अलग तरीके से काम करना होगा.
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 में, बिल्ड फ़्लैग के बारे में बताएं. इनका इस्तेमाल फ़िलहाल, शर्तों के हिसाब से फ़्रेमवर्क को कंपाइल करने के लिए किया जाता है.
- वेंडर और ओईएम, HAL सेवा को लागू करके, बिल्ड फ़्लैग के लिए SoC और डिवाइस के हिसाब से वैल्यू उपलब्ध कराते हैं.
- रनटाइम पर, किसी कॉन्फ़िगरेशन आइटम की वैल्यू ढूंढने के लिए, HAL सेवा का इस्तेमाल करने के लिए फ़्रेमवर्क में बदलाव करें.
फ़िलहाल, फ़्रेमवर्क में जिन कॉन्फ़िगरेशन आइटम का रेफ़रंस दिया गया है वे वर्शन वाले HIDL पैकेज (android.hardware.configstore@1.0) में शामिल हैं. वेंडर/ओईएम, इस पैकेज में इंटरफ़ेस लागू करके, कॉन्फ़िगरेशन आइटम के लिए वैल्यू उपलब्ध कराते हैं. साथ ही, फ़्रेमवर्क, किसी कॉन्फ़िगरेशन आइटम की वैल्यू पाने के लिए, इंटरफ़ेस का इस्तेमाल करता है.
सुरक्षा से जुड़ी बातें
एक ही इंटरफ़ेस में तय किए गए बिल्ड फ़्लैग पर, एक ही SELinux नीति लागू होती है. अगर एक या एक से ज़्यादा बिल्ड फ़्लैग के लिए, अलग-अलग SELinux नीतियां होनी चाहिए, तो उन्हें किसी दूसरे इंटरफ़ेस में अलग किया जाना चाहिए. इसके लिए, android.hardware.configstore package में बड़ा बदलाव करना पड़ सकता है, क्योंकि अलग किए गए इंटरफ़ेस अब बैकवर्ड-कम्पैटबिल नहीं हैं.