AOSP, डिवाइस पर कॉन्फ़िगरेशन की जानकारी सेव करने के लिए ये विकल्प देता है:
- सिस्टम प्रॉपर्टी
- डिवाइस के चालू होने से पहले कॉन्फ़िगरेशन
- हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) की प्रॉपर्टी
- सिस्टम कॉन्फ़िगरेशन की एक्सएमएल फ़ाइलें
- रिसॉर्स ओवरले (स्टैटिक और रनटाइम)
सिस्टम प्रॉपर्टी
सिस्टम प्रॉपर्टी, स्ट्रिंग की/वैल्यू पेयर होती हैं. इन्हें build.prop ग्लोबल डिक्शनरी में सेव किया जाता है. सिस्टम प्रॉपर्टी, सिस्टम-वाइड रिसॉर्स होती हैं. इनका इस्तेमाल करना आसान होता है और परफ़ॉर्मेंस पर इनका असर कम पड़ता है. सिस्टम प्रॉपर्टी का इस्तेमाल करते समय, आपको इंटरप्रोसेस कम्यूनिकेशन (आईपीसी) का इस्तेमाल करने की ज़रूरत नहीं होती. भले ही, सिस्टम प्रॉपर्टी को कई प्रोसेस के साथ शेयर किया गया हो. हालांकि, सिस्टम प्रॉपर्टी, ग्लोबल वैरिएबल से मिलती-जुलती होती हैं. इनका गलत इस्तेमाल करने पर नुकसान हो सकता है. सिस्टम प्रॉपर्टी का दुरुपयोग करने से, सुरक्षा जोखिम की आशंका और ऐप्लिकेशन के उपयोगकर्ताओं के लिए पहुंच से बाहर होने जैसी समस्याएं हो सकती हैं. कॉन्फ़िगरेशन की जानकारी सेव करने के लिए सिस्टम प्रॉपर्टी का इस्तेमाल करने से पहले, कॉन्फ़िगरेशन के अन्य विकल्पों पर विचार करें.
सिस्टम प्रॉपर्टी के बारे में ज़्यादा जानने के लिए, सिस्टम प्रॉपर्टी जोड़ना लेख पढ़ें
डिवाइस के चालू होने से पहले कॉन्फ़िगरेशन
Android 17 और इसके बाद के वर्शन में, init_dev_config सेवा डिवाइस कॉन्फ़िगरेशन और सिस्टम प्रॉपर्टी के इनिशियलाइज़ेशन के लिए सहायता उपलब्ध कराती है. यह डाइनैमिक आर्किटेक्चरल मेकेनिज़्म, बूट होने के शुरुआती समय में अपने-आप काम करता है.
जब किसी एक सिस्टम या वेंडर इमेज को कई हार्डवेयर वैरिएंट के साथ काम करना होता है, तो कॉन्फ़िगरेशन वैल्यू को हमेशा बिल्ड टाइम पर हार्डकोड नहीं किया जा सकता. init_dev_config सेवा, early-init फ़ेज़ के दौरान काम करती है. यह apexd-bootstrap से ठीक पहले काम करती है. इससे वेंडर, हार्डवेयर की स्थिति की जांच कर पाते हैं. उदाहरण के लिए, बूटलोडर के आर्ग्युमेंट, पहले से माउंट किए गए पार्टीशन या हार्डवेयर कॉन्फ़िगरेशन टेबल से. साथ ही, यह सेवा, निर्भर सेवाओं और लाइब्रेरी के शुरू होने से पहले, सिस्टम की प्रॉपर्टी को डाइनैमिक तरीके से शुरू कर पाती है.
सेवा इंटिग्रेशन और लाइफ़साइकल
init_dev_config सेवा को सिस्टम init.rc में डिफ़ॉल्ट रूप से तय किया जाता है. साथ ही, इसे apexd-bootstrap से पहले early-init के दौरान सिंक्रोनस तरीके से लागू किया जाता है. इंटीग्रेटर को नई init सेवा के बारे में जानकारी देने की ज़रूरत नहीं है.
इसके बजाय, मौजूदा सेवा अपने एक्ज़ीक्यूटेबल पाथ पर प्रॉपर्टी एक्सपैंशन का इस्तेमाल करती है. इससे सिस्टम सेवा के एलान को वेंडर बाइनरी से अलग किया जाता है. इंटीग्रेटर, ro.vendor.init_dev_config.path प्रॉपर्टी का इस्तेमाल करके, वेंडर बाइनरी का पाथ तय करते हैं. साथ ही, इसे ज़रूरी SELinux लेबल और अनुमतियों के साथ कॉन्फ़िगर करते हैं.
वेंडर के लिए, इस सुविधा को लागू करने से जुड़ी ज़रूरी शर्तें
init_dev_config के साथ इंटिग्रेट करने के लिए:
PRODUCT_VENDOR_PROPERTIESका इस्तेमाल करके, बिल्ड प्रोसेस में लगने वाले समय पर वेंडर बाइनरी पाथ को कॉन्फ़िगर करें. दिया गया बाइनरी पाथ, सिस्टम में इंस्टॉल की गई बाइनरी का मान्य पाथ होना चाहिए:PRODUCT_VENDOR_PROPERTIES += \ ro.vendor.init_dev_config.path=/vendor/bin/init_dev_configअगर इस प्रॉपर्टी को सेट नहीं किया जाता है, तो
initसेवा को लागू नहीं करता है और बूटिंग सामान्य तरीके से जारी रहती है.यह सेवा
apexd-bootstrapसे पहले चलती है. इसलिए, APEX से मिली पूरी bionic लाइब्रेरी अभी उपलब्ध नहीं हैं.Android.bpमें,bootstrap: trueसेट करें:rust_binary { name: "init_dev_config", vendor: true, srcs: ["src/main.rs"], rustlibs: [ "librustutils", ], bootstrap: true, }हार्डवेयर वैरिएंट का पता लगाने और सिस्टम की सही प्रॉपर्टी सेट करने के लिए, सेवा का लॉजिक लिखें:
use rustutils::system_properties; fn main() { let hw_sku = read_hardware_sku(); // Dynamically initialize vendor-specific properties: let display_type = match hw_sku { 1 => "oled", _ => "lcd", }; system_properties::write("vendor.display.panel_type", display_type) .expect("Failed to set vendor display property"); }वेंडर की बाइनरी को
init_dev_config_execसे लेबल करें:/vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0ज़रूरी प्रॉपर्टी टाइप सेट करने के लिए,
init_dev_configडोमेन को अनुमति दें:set_prop(init_dev_config, vendor_my_sku_prop)
APEX को चालू और बंद करने के लिए, init_dev_config का इस्तेमाल करने के बारे में जानकारी पाने के लिए, बूटअप के समय वेंडर APEX चुनना लेख पढ़ें.
एचएएल प्रॉपर्टी
जब किसी कॉन्फ़िगरेशन के लिए, डिवाइस पर मौजूद हार्डवेयर कॉम्पोनेंट से जानकारी मिलती है, तो हार्डवेयर के लिए HAL को उस कॉम्पोनेंट की जानकारी देनी होती है. कॉन्फ़िगरेशन को ऐक्सेस करने के लिए, मौजूदा HAL में एक नया HAL तरीका तय करें. एचएएल डेवलप करने के बारे में ज़्यादा जानकारी के लिए, एचएएल के लिए एआईडीएल लेख पढ़ें.
सिस्टम कॉन्फ़िगरेशन की एक्सएमएल फ़ाइलें
अगर कॉन्फ़िगरेशन डेटा स्टैटिक है, लेकिन जटिल (स्ट्रक्चर्ड) है, तो कॉन्फ़िगरेशन डेटा के लिए एक्सएमएल या इस तरह के अन्य फ़ॉर्मैट का इस्तेमाल करें. पक्का करें कि फ़ाइल स्कीमा में कोई बदलाव न हो. एक्सएमएल फ़ाइलों के लिए, स्कीमा को स्थिर रखने और अपने-आप जनरेट होने वाले एक्सएमएल पार्सर का फ़ायदा पाने के लिए, xsd_config का इस्तेमाल किया जा सकता है.
रिसोर्स ओवरले
किसी प्रॉडक्ट को पसंद के मुताबिक बनाने के लिए, संसाधन ओवरले का इस्तेमाल किया जा सकता है. संसाधन ओवरले दो तरह के होते हैं:
स्टैंडर्ड रिसोर्स ओवरले का इस्तेमाल, बिल्ड टाइम पर किसी प्रॉडक्ट को पसंद के मुताबिक बनाने के लिए किया जाता है. स्टैंडर्ड रिसॉर्स ओवरले के बारे में जानकारी के लिए, रिसॉर्स ओवरले की मदद से बिल्ड को पसंद के मुताबिक बनाना लेख पढ़ें.
रनटाइम रिसोर्स ओवरले (आरआरओ) का इस्तेमाल, रनटाइम के दौरान टारगेट पैकेज की रिसोर्स वैल्यू बदलने के लिए किया जाता है. उदाहरण के लिए, सिस्टम इमेज पर इंस्टॉल किया गया कोई ऐप्लिकेशन, किसी संसाधन की वैल्यू के आधार पर अपना व्यवहार बदल सकता है. बिल्ड टाइम में संसाधन की वैल्यू को हार्डकोड करने के बजाय, किसी दूसरे पार्टीशन पर इंस्टॉल किया गया RRO, रनटाइम में ऐप्लिकेशन के संसाधनों की वैल्यू बदल सकता है. आरआरओ के बारे में ज़्यादा जानकारी के लिए, रनटाइम के दौरान ऐप्लिकेशन के संसाधनों की वैल्यू बदलना लेख पढ़ें.