طرح پارتیشن، طرح پارتیشن

در اندروید 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/* را پوشش می دهد.

1. فایل های فروشنده از پیش ساخته شده را در 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

2. فایل های فروشنده از پیش ساخته شده را در 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)

3. اگر فایل های پارتیشن 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

4. به فرآیند 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 و غیره.

توجه: فایل‌های پچ کرنل مخصوص AVB در خارجی/avb/contrib/linux/ نیز موجود است.

مثال زیر تنظیمات مربوط به 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/* به طور خودکار).