Android 10 में, ConfigStore HAL, बिल्ड फ़्लैग का इस्तेमाल करके, vendor पार्टिशन में कॉन्फ़िगरेशन वैल्यू सेव करता है. साथ ही, system पार्टिशन में मौजूद कोई सेवा, HIDL का इस्तेमाल करके उन वैल्यू को ऐक्सेस करती है. Android 9 में भी ऐसा ही होता है. हालांकि, ConfigStore HAL को बंद कर दिया गया है, क्योंकि यह ज़्यादा मेमोरी इस्तेमाल करता है और इसका इस्तेमाल करना मुश्किल है.
AOSP में, ConfigStore HAL अब भी मौजूद है, ताकि पुराने वेंडर पार्टिशन को सपोर्ट किया जा सके. 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 में बड़ा बदलाव करना पड़ सकता है, क्योंकि अलग किए गए इंटरफ़ेस, अब बैकवर्ड-कम्पैटबिलटी के साथ काम नहीं करते.