AOSP কোনও ডিভাইসে কনফিগারেশন সংক্রান্ত তথ্য স্টোর করার জন্য নিম্নলিখিত বিকল্পগুলি প্রদান করে:
- সিস্টেম প্রপার্টি
- ডিভাইস কনফিগারেশন আগেভাগে বুট করা
- হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার (HAL) প্রপার্টি
- সিস্টেম কনফিগারেশন XML ফাইল
- রিসোর্স ওভারলে (স্ট্যাটিক ও রানটাইম)
সিস্টেম প্রপার্টি
সিস্টেম প্রপার্টি হল স্ট্রিং কী/ভ্যালু পেয়ার যা build.prop
গ্লোবাল ডিকশনারিতে স্টোর করা থাকে। সিস্টেম প্রপার্টি হল সিস্টেম-ব্যাপী রিসোর্স যা ব্যবহার করা সহজ এবং এর পারফর্ম্যান্স ওভারহেড কম। সিস্টেম প্রপার্টি ব্যবহার করার সময়, একাধিক প্রসেস জুড়ে সিস্টেম প্রপার্টি শেয়ার করা থাকলেও,
আপনাকে ইন্টারপ্রসেস কমিউনিকেশন (IPC) ব্যবহার করতে
হবে না। তবে, সিস্টেম প্রপার্টি গ্লোবাল ভেরিয়েবেলের মতো এবং
অপব্যবহার করা হলে তা ক্ষতিকর হতে পারে। সিস্টেম প্রপার্টির অপব্যবহারের ফলে
নিরাপত্তা সংক্রান্ত দুর্বলতা এবং ব্যবহারকারীদের জন্য অ্যাপ অ্যাক্সেসযোগ্য না হওয়ার
মতো সমস্যা হতে পারে। কনফিগারেশন সংক্রান্ত তথ্য সেভ করার জন্য সিস্টেম প্রপার্টি ব্যবহার করার আগে,
অন্যান্য কনফিগারেশন বিকল্প বিবেচনা করুন।
সিস্টেম প্রপার্টি সম্পর্কে আরও তথ্যের জন্য, সিস্টেম প্রপার্টি যোগ করুন দেখুন
ডিভাইস কনফিগারেশন আগেভাগে বুট করা
Android 17 ও তার পরবর্তী যেকোনও ভার্সনে, init_dev_config পরিষেবা ডিভাইস কনফিগারেশন ও সিস্টেম প্রপার্টি ইনিশিয়ালাইজেশনের জন্য সহায়তা প্রদান করে। এই ডায়নামিক
আর্কিটেকচারাল মেকানিজমটি প্রাথমিক বুটে অটোমেটিক রান করে।
যখন একটি সিস্টেম বা ভেন্ডর ইমেজকে একাধিক হার্ডওয়্যার ভেরিয়েন্টকে সাপোর্ট করতে হয়,
তখন কনফিগারেশন ভ্যালু সবসময় বিল্ড করার সময় হার্ডকোড করা যায় না। init_dev_config
পরিষেবা early-init ফেজ চলাকালীন, ঠিক apexd-bootstrap-এর আগে এক্সিকিউট হয়,
যা ভেন্ডরদের হার্ডওয়্যার স্টেট (যেমন, বুটলোডার আর্গুমেন্ট, আর্লি-মাউন্টেড পার্টিশন বা হার্ডওয়্যার কনফিগারেশন
টেবিল থেকে) পরীক্ষা করতে এবং নির্ভরশীল পরিষেবা ও লাইব্রেরি শুরু করার আগে
সিস্টেম প্রপার্টি ডাইনামিকভাবে শুরু করতে দেয়।
পরিষেবা ইন্টিগ্রেশন ও লাইফসাইকেল
init_dev_config পরিষেবাটি সিস্টেমে ডিফল্ট হিসেবে সংজ্ঞায়িত করা হয়
init.rc এবং early-init চলাকালীন সিঙ্ক্রোনাসভাবে এক্সিকিউট করা হয়, apexd-bootstrap-এর আগে
। ইন্টিগ্রেটরদের নতুন 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 ডেভেলপ করা সম্পর্কে আরও তথ্য পেতে, HAL-এর জন্য AIDL দেখুন।
সিস্টেম কনফিগারেশন XML ফাইল
কনফিগারেশন ডেটা স্ট্যাটিক কিন্তু জটিল (স্ট্রাকচার্ড) হলে, কনফিগারেশন ডেটার জন্য XML বা এই ধরনের অন্যান্য ফর্ম্যাট ব্যবহার করার কথা বিবেচনা করুন। নিশ্চিত করুন যে ফাইল স্কিমা স্থিতিশীল আছে।
XML ফাইলের জন্য, স্কিমা স্থিতিশীল রাখতে এবং অটোমেটিক তৈরি হওয়া XML
পার্সারের সুবিধা নিতে, আপনি
xsd_config
ব্যবহার করতে পারেন।
রিসোর্স ওভারলে
আপনি কোনও প্রোডাক্ট কাস্টমাইজ করতে রিসোর্স ওভারলে ব্যবহার করতে পারেন। রিসোর্স ওভারলে দুই ধরনের হয়:
বিল্ড টাইমে কোনও প্রোডাক্ট কাস্টমাইজ করতে স্ট্যান্ডার্ড রিসোর্স ওভারলে ব্যবহার করা হয়। স্ট্যান্ডার্ড রিসোর্স ওভারলে সংক্রান্ত তথ্যের জন্য, রিসোর্স ওভারলে দিয়ে বিল্ড কাস্টমাইজ করা দেখুন।
রানটাইমে টার্গেট প্যাকেজের রিসোর্স ভ্যালু পরিবর্তন করতে রানটাইম রিসোর্স ওভারলে (RRO) ব্যবহার করা হয়। যেমন, সিস্টেম ইমেজে ইনস্টল করা কোনও অ্যাপ রিসোর্সের ভ্যালুর উপর ভিত্তি করে তার আচরণ পরিবর্তন করতে পারে। বিল্ড টাইমে রিসোর্স ভ্যালু হার্ডকোড করার পরিবর্তে, অন্য পার্টিশনে ইনস্টল করা RRO রানটাইমে অ্যাপের রিসোর্সের ভ্যালু পরিবর্তন করতে পারে। RRO সম্পর্কে আরও তথ্য পেতে, রানটাইমে অ্যাপের রিসোর্সের ভ্যালু পরিবর্তন করুন লিঙ্ক দেখুন।