AOSP گزینههای زیر را برای ذخیره اطلاعات پیکربندی روی یک دستگاه ارائه میدهد:
- ویژگیهای سیستم
- پیکربندی اولیه دستگاه بوت
- ویژگیهای لایه انتزاع سختافزار (HAL)
- فایلهای XML پیکربندی سیستم
- همپوشانی منابع (استاتیک و زمان اجرا)
ویژگیهای سیستم
ویژگیهای سیستم، جفتهای کلید/مقدار رشتهای هستند که در دیکشنری سراسری build.prop ذخیره میشوند. ویژگیهای سیستم، منابعی در سطح سیستم هستند که استفاده از آنها آسان است و سربار عملکردی کمی دارند. هنگام استفاده از ویژگیهای سیستم، حتی اگر یک ویژگی سیستم بین چندین فرآیند به اشتراک گذاشته شود، نیازی به استفاده از ارتباط بین فرآیندی (IPC) ندارید. با این حال، ویژگیهای سیستم مشابه متغیرهای سراسری هستند و در صورت سوءاستفاده میتوانند مضر باشند. سوءاستفاده از ویژگیهای سیستم میتواند منجر به مسائلی مانند آسیبپذیریهای امنیتی و غیرقابل دسترس شدن برنامهها برای کاربران شود. قبل از استفاده از ویژگیهای سیستم برای ذخیره اطلاعات پیکربندی، سایر گزینههای پیکربندی را در نظر بگیرید.
برای اطلاعات بیشتر در مورد ویژگیهای سیستم، به افزودن ویژگیهای سیستم مراجعه کنید.
پیکربندی اولیه دستگاه بوت
در اندروید ۱۷ و بالاتر، سرویس 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 هنوز در دسترس نیستند. در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 موجود برای دسترسی به پیکربندی تعریف کنید. برای اطلاعات بیشتر در مورد توسعه HAL، به AIDL برای HALها مراجعه کنید.
فایلهای XML پیکربندی سیستم
وقتی دادههای پیکربندی ایستا اما پیچیده (ساختاریافته) هستند، استفاده از XML یا سایر فرمتهای مشابه را برای دادههای پیکربندی در نظر بگیرید. مطمئن شوید که طرحواره فایل پایدار باقی میماند. برای فایلهای XML، میتوانید از xsd_config برای پایدار نگه داشتن طرحواره و استفاده از یک تجزیهکننده XML خودکار استفاده کنید.
همپوشانی منابع
شما میتوانید از پوششهای منابع برای سفارشیسازی یک محصول استفاده کنید. دو نوع پوشش منابع وجود دارد:
پوشش منابع استاندارد که برای سفارشیسازی یک محصول در زمان ساخت استفاده میشود. برای اطلاعات در مورد پوششهای منابع استاندارد، به سفارشیسازی ساخت با پوششهای منابع مراجعه کنید.
پوشش منابع زمان اجرا (RRO) برای تغییر مقادیر منابع یک بسته هدف در زمان اجرا استفاده میشود. به عنوان مثال، یک برنامه نصب شده روی تصویر سیستم ممکن است رفتار خود را بر اساس مقدار یک منبع تغییر دهد. به جای کدگذاری ثابت مقدار منبع در زمان ساخت، یک RRO نصب شده روی یک پارتیشن متفاوت میتواند مقادیر منابع برنامه را در زمان اجرا تغییر دهد. برای اطلاعات بیشتر در مورد RROها، به بخش تغییر مقدار منابع یک برنامه در زمان اجرا مراجعه کنید.