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اجرا می‌شود، کتابخانه‌های bionic ارائه‌شده توسط APEX هنوز به‌طور کامل دردسترس نیستند. در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)
برای اطلاعات درباره استفاده از init_dev_config برای فعال‌سازی و غیرفعال‌سازی APEX،
انتخاب APEX فروشنده در راه‌اندازی را ببینید.
خصوصیات HAL
وقتی منبع حقیقت برای پیکربندی از مؤلفه سخت‌افزاری در دستگاه باشد، «لایه انتزاع سخت‌افزار» برای سخت‌افزار باید اطلاعات آن مؤلفه را ارائه دهد. روش HAL جدیدی را در HAL موجود برای دسترسی به پیکربندی تعریف کنید. برای اطلاعات بیشتر درباره توسعه HAL، به AIDL برای HAL مراجعه کنید.
فایل‌های XML پیکربندی سیستم
وقتی داده‌های پیکربندی ثابت اما پیچیده (ساختاریافته) است،
از XML یا قالب‌های مشابه دیگر برای داده‌های پیکربندی استفاده کنید. مطمئن شوید که طرح فایل ثابت باقی می‌ماند. برای فایل‌های XML، می‌توانید از
xsd_config
برای حفظ پایداری طرحواره و بهره‌گیری از تجزیه‌کننده XML
خودکار تولیدشده استفاده کنید.
رونهاد منبع
می‌توانید از رونهادهای منبع برای سفارشی‌سازی محصول استفاده کنید. دو نوع رونهاد منبع وجود دارد:
از رونهاد منبع استاندارد برای سفارشی‌سازی محصول در زمان ساخت استفاده می‌شود. برای اطلاعات درباره رونهادهای منبع استاندارد، سفارشی‌سازی ساخت با رونهادهای منبع را ببینید.
از رونهاد منبع زمان اجرا (RRO) برای تغییر مقادیر منبع بسته هدف در زمان اجرا استفاده می‌شود. برای مثال، برنامه‌ای که در تصویر سیستم نصب شده است ممکن است عملکردش را براساس مقدار منبع تغییر دهد. به‌جای کدنویسی سخت مقدار منبع در زمان ساخت، یک RRO نصب‌شده در پارتیشن متفاوت می‌تواند مقادیر منابع برنامه را در زمان اجرا تغییر دهد. برای اطلاعات بیشتر درباره RRO، به تغییر مقدار منابع برنامه در زمان اجرا مراجعه کنید.