در اندروید 10، سیستم فایل ریشه دیگر در ramdisk.img
گنجانده نمی شود و در عوض در system.img
ادغام می شود (یعنی system.img
همیشه طوری ایجاد می شود که گویی BOARD_BUILD_SYSTEM_ROOT_IMAGE
تنظیم شده است). دستگاه هایی که با اندروید 10 راه اندازی می شوند:
- از طرحبندی پارتیشن سیستم بهعنوان ریشه (بهطور خودکار توسط بیلد بدون هیچ گزینهای برای تغییر رفتار اعمال میشود) استفاده کنید.
- باید از ramdisk استفاده کنید که برای dm-linear لازم است.
- باید
BOARD_BUILD_SYSTEM_ROOT_IMAGE
را رویfalse
تنظیم کنید. این تنظیم فقط برای تمایز بین دستگاههایی که از ramdisk استفاده میکنند و دستگاههایی که از ramdisk استفاده نمیکنند استفاده میشود (و در عوض مستقیماًsystem.img
سوار میکنند).
معنای پیکربندی system-as-root بین Android 9 و Android 10 متفاوت است. در پیکربندی Android 9 system-as-root، BOARD_BUILD_SYSTEM_ROOT_IMAGE
روی true
تنظیم شده است، که ساخت را مجبور می کند تا فایل سیستم فایل ریشه را در system.img
ادغام کند و سپس mount system.img
به عنوان فایل سیستم ریشه (rootfs). این پیکربندی برای دستگاههایی که با Android 9 راهاندازی میشوند اجباری است، اما برای دستگاههایی که به Android 9 ارتقا مییابند و برای دستگاههایی که از نسخههای پایینتر Android استفاده میکنند اختیاری است. در پیکربندی سیستم بهعنوان ریشه Android 10، ساخت همیشه $TARGET_SYSTEM_OUT
و $TARGET_ROOT_OUT
در system.img
ادغام میکند. این پیکربندی رفتار پیشفرض برای همه دستگاههای دارای اندروید 10 است.
اندروید 10 تغییرات بیشتری را برای پشتیبانی از پارتیشنهای پویا ایجاد میکند، یک سیستم پارتیشنبندی فضای کاربران که بهروزرسانیهای هوایی (OTA) را برای ایجاد، تغییر اندازه یا تخریب پارتیشنها امکانپذیر میکند. به عنوان بخشی از این تغییر، هسته لینوکس دیگر نمیتواند پارتیشن سیستم منطقی را روی دستگاههای دارای اندروید 10 نصب کند، بنابراین این عملیات توسط مرحله اول init انجام میشود.
بخشهای زیر نیازمندیهای سیستم بهعنوان ریشه برای OTAهای فقط سیستم را توضیح میدهند، راهنمایی در مورد بهروزرسانی دستگاهها برای استفاده از سیستم بهعنوان ریشه (از جمله تغییرات طرح پارتیشن و الزامات هسته dm-verity) ارائه میدهند. برای جزئیات تغییرات در ramdisk، به پارتیشن های Ramdisk مراجعه کنید.
درباره OTA های فقط سیستم
OTAهای فقط سیستمی، که به نسخههای Android امکان بهروزرسانی system.img
و product.img
را بدون تغییر پارتیشنهای دیگر میدهند، به طرحبندی پارتیشن سیستم بهعنوان ریشه نیاز دارند. همه دستگاههای دارای Android 10 باید از طرحبندی پارتیشن system-as-root برای فعال کردن OTAهای فقط سیستم استفاده کنند.
- دستگاههای A/B که پارتیشن
system
بهعنوان rootf نصب میکنند، قبلاً از system-as-root استفاده میکنند و برای پشتیبانی OTA سیستم نیازی به تغییرات ندارند. - دستگاههای غیر A/B که پارتیشن
system
در/system
نصب میکنند، باید برای استفاده از طرحبندی پارتیشن سیستم بهعنوان ریشه برای پشتیبانی از OTAهای سیستم، بهروزرسانی شوند.
برای جزئیات بیشتر در مورد دستگاههای A/B و غیر A/B، به بهروزرسانیهای سیستم A/B (بدون درز) مراجعه کنید.
استفاده از پوشش فروشنده (<=AOSP 14)
Vendor Overlay به شما امکان می دهد تا تغییرات پارتیشن vendor
را در زمان راه اندازی دستگاه پوشش دهید. پوشش فروشنده مجموعهای از ماژولهای فروشنده در پارتیشن product
است که هنگام بوت شدن دستگاه، روی پارتیشن vendor
پوشانده میشوند، ماژولهای موجود را جایگزین و به آن اضافه میکنند.
هنگامی که دستگاه بوت می شود، فرآیند init
مرحله اول را کامل می کند و ویژگی های پیش فرض را می خواند. سپس /product/vendor_overlay/<target_vendor_version>
را جستجو میکند و در صورت وجود شرایط زیر، هر زیر شاخه را در فهرست پارتیشن vendor
مربوطه خود نصب میکند:
-
/vendor/<overlay_dir>
وجود دارد. -
/product/vendor_overlay/<target_vendor_version>/<overlay_dir>
دارای زمینه فایل مشابه با/vendor/<overlay_dir>
است. -
init
مجاز است در زمینه فایل/vendor/<overlay_dir>
سوار شود.
اجرای پوشش فروشنده
فایلهای همپوشانی فروشنده را در /product/vendor_overlay/<target_vendor_version>
نصب کنید. هنگامی که دستگاه بوت میشود، آن فایلها روی پارتیشن vendor
قرار میگیرند، فایلهایی با همین نام جایگزین میشوند و هر فایل جدیدی اضافه میشود. پوشش فروشنده نمی تواند فایل ها را از پارتیشن vendor
حذف کند.
فایلهای همپوشانی فروشنده باید زمینه فایل مشابه فایلهای هدفی را که در پارتیشن vendor
جایگزین میکنند، داشته باشند. به طور پیش فرض، فایل های موجود در فهرست /product/vendor_overlay/<target_vendor_version>
دارای زمینه vendor_file
هستند. اگر بین فایلهای همپوشانی فروشنده و فایلهایی که جایگزین میشوند، متن فایل ناهماهنگی وجود دارد، آن را در سیاستگذاری خاص دستگاه مشخص کنید. زمینه فایل در سطح دایرکتوری تنظیم شده است. اگر زمینه فایل یک پوشه پوشاننده فروشنده با دایرکتوری مورد نظر مطابقت نداشته باشد، و زمینه فایل صحیح در سیاست گذاری خاص دستگاه مشخص نشده باشد، آن دایرکتوری پوشاننده فروشنده روی دایرکتوری هدف قرار نمی گیرد.
برای استفاده از همپوشانی فروشنده، هسته باید OverlayFS را با تنظیم CONFIG_OVERLAY_FS=y
فعال کند. همچنین، هسته باید از هسته معمولی 4.4 یا بالاتر ادغام شود یا با "overlayfs: override_creds=off option bypass creator_cred"
وصله شود.
نمونه اجرای همپوشانی فروشنده
این رویه اجرای یک پوشش فروشنده را نشان می دهد که دایرکتوری های /vendor/lib/*
، /vendor/etc/*
و /vendor/app/*
را پوشش می دهد.
فایل های فروشنده از پیش ساخته شده را در
device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/
اضافه کنید:device/google/device/vendor_overlay/28/lib/libfoo.so device/google/device/vendor_overlay/28/lib/libbar.so device/google/device/vendor_overlay/28/etc/baz.xml device/google/device/vendor_overlay/28/app/qux.apk
فایل های فروشنده از پیش ساخته شده را در
product/vendor_overlay
درdevice/google/device/device.mk
نصب کنید:PRODUCT_COPY_FILES += \ $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)
اگر فایل های پارتیشن
vendor
هدف دارای زمینه هایی غیر ازvendor_file
هستند، زمینه های فایل را تعریف کنید. از آنجا که/vendor/lib/*
از زمینهvendor_file
استفاده می کند، این مثال شامل آن دایرکتوری نمی شود.موارد زیر را به
device/google/device-sepolicy/private/file_contexts
اضافه کنید:/(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)? u:object_r:vendor_configs_file:s0 /(product|system/product)/vendor_overlay/[0-9]+/app(/.*)? u:object_r:vendor_app_file:s0
به فرآیند
init
اجازه دهید تا همپوشانی فروشنده را روی زمینههای فایلی غیر ازvendor_file
نصب کند. از آنجایی که فرآیندinit
از قبل دارای مجوز نصب در زمینهvendor_file
است، این مثال خط مشیvendor_file
را تعریف نمی کند.موارد زیر را به
device/google/device-sepolicy/public/init.te
اضافه کنید:allow init vendor_configs_file:dir mounton; allow init vendor_app_file:dir mounton;
همپوشانی فروشنده را تأیید کنید
برای تأیید پیکربندی پوشش فروشنده، فایلها را در /product/vendor_overlay/<target_vendor_version>/<overlay_dir>
اضافه کنید و بررسی کنید که آیا فایلها روی فایلهای موجود در /vendor/<overlay_dir>
همپوشانی دارند یا خیر.
برای ساخت های userdebug
، یک ماژول تست برای Atest وجود دارد:
$ atest -v fs_mgr_vendor_overlay_test
به روز رسانی به سیستم به عنوان ریشه
برای بهروزرسانی دستگاههای غیر A/B برای استفاده از system-as-root، باید طرح پارتیشنبندی boot.img
و system.img
را بهروزرسانی کنید، dm-verity را راهاندازی کنید، و وابستگیهای بوت را در پوشههای ریشه خاص دستگاه حذف کنید.
به روز رسانی پارتیشن ها
برخلاف دستگاههای A/B که از /boot
به عنوان پارتیشن بازیابی استفاده میکنند، دستگاههای غیر A/B باید پارتیشن /recovery
را جدا نگه دارند زیرا پارتیشن اسلات بازگشتی ندارند (به عنوان مثال، از boot_a
تا boot_b
). اگر /recovery
در دستگاه غیر A/B حذف شود و شبیه طرح A/B باشد، حالت بازیابی ممکن است در طول بهروزرسانی ناموفق پارتیشن /boot
خراب شود. به همین دلیل، پارتیشن /recovery
باید یک پارتیشن مجزا از /boot
برای دستگاههای غیر A/B باشد، که به این معنی است که تصویر بازیابی به روشی معوق بهروزرسانی میشود (یعنی مانند دستگاههایی که Android 8.1 دارند). 0.0 یا کمتر).
جدول زیر تفاوتهای پارتیشن تصویر را برای دستگاههای غیرA/B قبل و بعد از Android 9 فهرست میکند.
تصویر | Ramdisk (قبل از 9) | System-as-root (بعد از 9) |
---|---|---|
boot.img | شامل یک هسته و یک ramdisk.img است: ramdisk.img -/ - init.rc - init - etc -> /system/etc - system/ (mount point) - vendor/ (mount point) - odm/ (mount point) ... | فقط شامل یک هسته بوت معمولی است. |
recovery.img | شامل یک هسته بازیابی و یک بازیابی ramdisk.img است. | |
system.img | شامل موارد زیر است: system.img -/ - bin/ - etc - vendor -> /vendor - ... | حاوی محتوای ادغام شده system.img و ramdisk.img اصلی است: system.img -/ - init.rc - init - etc -> /system/etc - system/ - bin/ - etc/ - vendor -> /vendor - ... - vendor/ (mount point) - odm/ (mount point) ... |
خود پارتیشن ها تغییر نمی کنند. هم ramdisk و هم system-as-root از طرح پارتیشن زیر استفاده می کنند:
-
/boot
-
/system
-
/system
-
/recovery
-
/vendor
و غیره
dm-verity را تنظیم کنید
در system-as-root، هسته باید system.img
در زیر /
(نقطه mount) با dm-verity قرار دهد. AOSP از پیاده سازی های dm-verity زیر برای system.img
پشتیبانی می کند.
vboot 1.0
برای vboot 1.0 ، هسته باید متادیتای خاص اندروید را در /system
تجزیه کند، سپس برای تنظیم dm-verity به پارامترهای dm-verity تبدیل شود (به این وصلههای هسته نیاز دارد). مثال زیر تنظیمات مربوط به dm-verity را برای system-as-root در خط فرمان هسته نشان می دهد:
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="system none ro,0 1 android-verity /dev/sda34" veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f
vboot 2.0
برای vboot 2.0 ( AVB )، بوت لودر باید خارجی/avb/libavb را ادغام کند، که سپس توصیفگر هشتری را برای /system
تجزیه می کند، آن را به پارامترهای dm-verity تبدیل می کند و در نهایت پارامترها را از طریق خط فرمان کرنل به هسته ارسال می کند. (توصیفگرهای هشتری /system
ممکن است در /vbmeta
یا در خود /system
باشند.)
vboot 2.0 به وصله های هسته زیر نیاز دارد:
- https://android-review.googlesource.com/#/c/kernel/common/+/158491/
- وصله های کرنل 4.4 ، وصله های کرنل 4.9 و غیره.
مثال زیر تنظیمات مربوط به dm-verity را برای system-as-root در خط فرمان هسته نشان می دهد:
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="1 vroot none ro 1,0 5159992 verity 1 PARTUUID=00000016-0000-0000-0000-000000000000 PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999 sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2 8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption ignore_zero_blocks use_fec_from_device PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks 650080 fec_start 650080"
از پوشه های ریشه مخصوص دستگاه استفاده کنید
با سیستم بهعنوان ریشه، پس از فلش شدن تصویر سیستم عمومی (GSI) روی دستگاه (و قبل از اجرای تستهای Vendor Test Suite )، هر پوشه ریشه خاص دستگاه که با BOARD_ROOT_EXTRA_FOLDERS
اضافه شده است از بین میرود زیرا کل محتوای فهرست ریشه جایگزین شده است. توسط سیستم به عنوان ریشه GSI. در صورت وجود وابستگی به پوشههای ریشه خاص دستگاه (مثلاً از آنها به عنوان نقاط اتصال استفاده میشود) ممکن است حذف این پوشهها باعث شود که دستگاه غیر قابل بوت شود.
برای جلوگیری از این مشکل، از BOARD_ROOT_EXTRA_FOLDERS
برای افزودن پوشههای ریشه خاص دستگاه استفاده نکنید. اگر میخواهید نقاط نصب مخصوص دستگاه را مشخص کنید، از /mnt/vendor/<mount point>
استفاده کنید (در این لیستهای تغییر اضافه شده است). این نقاط نصب خاص فروشنده را میتوان مستقیماً در درخت دستگاه fstab
(برای نصب مرحله اول) و فایل /vendor/etc/fstab.{ro.hardware}
بدون تنظیمات اضافی مشخص کرد (همانطور که fs_mgr
آنها را در /mnt/vendor/*
ایجاد میکند. /mnt/vendor/*
به طور خودکار).