একটি ডিভাইসে কনফিগারেশন তথ্য সংরক্ষণের জন্য AOSP নিম্নলিখিত বিকল্পগুলি প্রদান করে:
- সিস্টেমের বৈশিষ্ট্য
- আর্লি বুট ডিভাইস কনফিগারেশন
- হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL) বৈশিষ্ট্য
- সিস্টেম কনফিগারেশন XML ফাইল
- রিসোর্স ওভারলে (স্ট্যাটিক এবং রানটাইম)
সিস্টেমের বৈশিষ্ট্য
সিস্টেম প্রোপার্টি হলো build.prop গ্লোবাল ডিকশনারিতে সংরক্ষিত স্ট্রিং কী/ভ্যালু পেয়ার। সিস্টেম প্রোপার্টি হলো সিস্টেম-ব্যাপী রিসোর্স যা ব্যবহার করা সহজ এবং এর পারফরম্যান্স ওভারহেড কম। সিস্টেম প্রোপার্টি ব্যবহার করার সময়, একাধিক প্রসেসের মধ্যে শেয়ার করা হলেও ইন্টারপ্রসেস কমিউনিকেশন (IPC) ব্যবহার করার প্রয়োজন হয় না। তবে, সিস্টেম প্রোপার্টি গ্লোবাল ভেরিয়েবলের মতোই এবং এর অপব্যবহার ক্ষতিকর হতে পারে। সিস্টেম প্রোপার্টির অপব্যবহারের ফলে নিরাপত্তা ঝুঁকি এবং অ্যাপ ব্যবহারকারীদের জন্য অ্যাক্সেসযোগ্য না হওয়ার মতো সমস্যা দেখা দিতে পারে। কনফিগারেশন তথ্য সংরক্ষণের জন্য সিস্টেম প্রোপার্টি ব্যবহার করার আগে, অন্যান্য কনফিগারেশন বিকল্পগুলো বিবেচনা করুন।
সিস্টেম প্রোপার্টি সম্পর্কে আরও তথ্যের জন্য, সিস্টেম প্রোপার্টি যোগ করুন দেখুন।
আর্লি বুট ডিভাইস কনফিগারেশন
অ্যান্ড্রয়েড ১৭ এবং এর পরবর্তী সংস্করণগুলোতে, 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-এ একটি নতুন HAL মেথড সংজ্ঞায়িত করুন। HAL তৈরি করার বিষয়ে আরও তথ্যের জন্য, AIDL for HALs দেখুন।
সিস্টেম কনফিগারেশন XML ফাইল
যখন কনফিগারেশন ডেটা স্থির কিন্তু জটিল (কাঠামোগত) হয়, তখন কনফিগারেশন ডেটার জন্য XML বা এই জাতীয় অন্যান্য ফরম্যাট ব্যবহার করার কথা বিবেচনা করুন। ফাইল স্কিমা যেন স্থিতিশীল থাকে তা নিশ্চিত করুন। XML ফাইলের ক্ষেত্রে, স্কিমা স্থিতিশীল রাখতে এবং স্বয়ংক্রিয়ভাবে তৈরি হওয়া XML পার্সারের সুবিধা নিতে আপনি xsd_config ব্যবহার করতে পারেন।
রিসোর্স ওভারলে
আপনি একটি পণ্যকে কাস্টমাইজ করতে রিসোর্স ওভারলে ব্যবহার করতে পারেন। রিসোর্স ওভারলে দুই প্রকারের হয়:
স্ট্যান্ডার্ড রিসোর্স ওভারলে বিল্ড করার সময় একটি প্রোডাক্টকে কাস্টমাইজ করতে ব্যবহৃত হয়। স্ট্যান্ডার্ড রিসোর্স ওভারলে সম্পর্কে তথ্যের জন্য, ‘রিসোর্স ওভারলে ব্যবহার করে বিল্ড কাস্টমাইজ করা’ দেখুন।
রানটাইম রিসোর্স ওভারলে (RRO) রানটাইমে একটি টার্গেট প্যাকেজের রিসোর্স ভ্যালু পরিবর্তন করতে ব্যবহৃত হয়। উদাহরণস্বরূপ, সিস্টেম ইমেজে ইনস্টল করা একটি অ্যাপ কোনো রিসোর্সের ভ্যালুর উপর ভিত্তি করে তার আচরণ পরিবর্তন করতে পারে। বিল্ড টাইমে রিসোর্স ভ্যালু হার্ডকোড করার পরিবর্তে, একটি ভিন্ন পার্টিশনে ইনস্টল করা RRO রানটাইমে অ্যাপটির রিসোর্সগুলোর ভ্যালু পরিবর্তন করতে পারে। RRO সম্পর্কে আরও তথ্যের জন্য, "রানটাইমে একটি অ্যাপের রিসোর্সের ভ্যালু পরিবর্তন করুন" দেখুন।