پیاده سازی پارتیشن های پویا

پارتیشن بندی پویا با استفاده از ماژول dm-linear device-mapper در هسته لینوکس پیاده سازی می شود. super پارتیشن حاوی ابرداده است که نام ها و محدوده بلوک هر پارتیشن پویا را در super فهرست می کند. در مرحله اول، این init تجزیه و اعتبارسنجی می‌شود و دستگاه‌های بلوک مجازی برای نمایش هر پارتیشن پویا ایجاد می‌شوند.

هنگام اعمال OTA، پارتیشن های پویا به طور خودکار ایجاد می شوند، اندازه آنها تغییر می کند یا در صورت نیاز حذف می شوند. برای دستگاه‌های A/B، دو نسخه از ابرداده وجود دارد و تغییرات فقط روی نسخه‌ای اعمال می‌شود که نشان‌دهنده شکاف هدف است.

از آنجایی که پارتیشن‌های پویا در فضای کاربران پیاده‌سازی می‌شوند، پارتیشن‌های مورد نیاز بوت‌لودر را نمی‌توان پویا کرد. به عنوان مثال، boot ، dtbo ، و vbmeta توسط بوت لودر خوانده می شوند و بنابراین باید به عنوان پارتیشن های فیزیکی باقی بمانند.

هر پارتیشن پویا می تواند به یک گروه به روز رسانی تعلق داشته باشد. این گروه ها حداکثر فضایی را که پارتیشن های آن گروه می توانند مصرف کنند محدود می کنند. به عنوان مثال، system و vendor می توانند به گروهی تعلق داشته باشند که اندازه کل system و vendor را محدود می کند.

پیاده سازی پارتیشن های پویا در دستگاه های جدید

این بخش نحوه پیاده‌سازی پارتیشن‌های پویا را در دستگاه‌های جدیدی که با اندروید 10 و بالاتر راه‌اندازی می‌شوند، توضیح می‌دهد. برای به‌روزرسانی دستگاه‌های موجود، به ارتقای دستگاه‌های Android مراجعه کنید.

تغییرات پارتیشن

برای دستگاه هایی که با اندروید 10 راه اندازی می شوند، پارتیشنی به نام super ایجاد کنید. پارتیشن super به صورت داخلی اسلات های A/B را کنترل می کند، بنابراین دستگاه های A/B به پارتیشن های جداگانه super_a و super_b نیاز ندارند. تمام پارتیشن‌های AOSP فقط خواندنی که توسط بوت‌لودر استفاده نمی‌شوند باید پویا باشند و باید از جدول پارتیشن GUID (GPT) حذف شوند. پارتیشن های خاص فروشنده لازم نیست پویا باشند و ممکن است در GPT قرار گیرند.

توجه: از قرار دادن userdata یا هر پارتیشن خواندن و نوشتن دائمی دیگر در super خودداری کنید.

برای تخمین اندازه super ، اندازه پارتیشن هایی که از GPT حذف می شوند را اضافه کنید. برای دستگاه های A/B، این باید شامل اندازه هر دو اسلات باشد. شکل 1 نمونه ای از جدول پارتیشن را قبل و بعد از تبدیل به پارتیشن های پویا نشان می دهد.

شکل 1. طرح بندی جدید جدول پارتیشن فیزیکی هنگام تبدیل به پارتیشن های پویا

پارتیشن های پویا پشتیبانی شده عبارتند از:

• سیستم
• فروشنده
• محصول
• خروجی سیستم
• ODM

برای دستگاه هایی که با Android 10 راه اندازی می شوند، گزینه خط فرمان هسته androidboot.super_partition باید خالی باشد تا دستور sysprop ro.boot.super_partition خالی باشد.

تراز پارتیشن

اگر پارتیشن super به درستی تراز نشده باشد، ماژول نقشه‌بردار دستگاه ممکن است کارایی کمتری داشته باشد. پارتیشن super باید با حداقل اندازه درخواست ورودی/خروجی که توسط لایه بلوک تعیین می شود، تراز شود. به‌طور پیش‌فرض، سیستم ساخت (از طریق lpmake ، که تصویر پارتیشن super را تولید می‌کند)، فرض می‌کند که یک تراز 1 مگابایتی برای هر پارتیشن پویا کافی است. با این حال، فروشندگان باید اطمینان حاصل کنند که پارتیشن super به درستی تراز شده است.

با بررسی sysfs می توانید حداقل اندازه درخواست یک دستگاه بلوک را تعیین کنید. به عنوان مثال:

# ls -l /dev/block/by-name/super
lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17
# cat /sys/block/sda/queue/minimum_io_size
786432

می‌توانید تراز پارتیشن super را به روشی مشابه تأیید کنید:

# cat /sys/block/sda/sda17/alignment_offset

افست تراز باید 0 باشد.

پیکربندی دستگاه تغییر می کند

برای فعال کردن پارتیشن بندی پویا، پرچم زیر را در device.mk اضافه کنید:

PRODUCT_USE_DYNAMIC_PARTITIONS := true

تغییرات پیکربندی برد

شما باید اندازه پارتیشن super را تنظیم کنید:

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

در دستگاه های A/B، اگر اندازه کل تصاویر پارتیشن پویا بیش از نیمی از اندازه پارتیشن super باشد، سیستم ساخت خطا می دهد.

شما می توانید لیست پارتیشن های پویا را به صورت زیر پیکربندی کنید. برای دستگاه‌هایی که از گروه‌های به‌روزرسانی استفاده می‌کنند، گروه‌ها را در متغیر BOARD_SUPER_PARTITION_GROUPS فهرست کنید. سپس نام هر گروه دارای یک متغیر BOARD_ group _SIZE و BOARD_ group _PARTITION_LIST است. برای دستگاه‌های A/B، حداکثر اندازه یک گروه باید فقط یک اسلات را پوشش دهد، زیرا نام گروه‌ها در داخل اسلات پسوند هستند.

در اینجا یک دستگاه نمونه است که همه پارتیشن ها را در گروهی به نام example_dynamic_partitions قرار می دهد:

BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product

در اینجا یک دستگاه نمونه است که خدمات سیستم و محصول را در group_foo و vendor ، product و odm در group_bar قرار می دهد:

BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar
BOARD_GROUP_FOO_SIZE := 4831838208
BOARD_GROUP_FOO_PARTITION_LIST := system product_services
BOARD_GROUP_BAR_SIZE := 1610612736
BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm

توجه: از انتخاب نام هایی که ممکن است با متغیرهای ساخت تضاد داشته باشند، خودداری کنید، مانند super و super_partition . برای خوانایی، نام‌هایی مانند foo_dp ، foo_dynamic_partitions ، foo_dp_group ، super_foo ، یا group_foo را انتخاب کنید (که foo نام طرفی است که یک گروه را به‌روزرسانی می‌کند). به عنوان مثال، group_OEM یا group_VENDOR .

توجه: ممکن است یک یا چند گروه به‌روزرسانی در دستگاه شما وجود داشته باشد.

• برای دستگاه‌های راه‌اندازی مجازی A/B، مجموع حداکثر اندازه‌های همه گروه‌ها باید حداکثر باشد:
  BOARD_SUPER_PARTITION_SIZE - سربار
  به پیاده سازی A/B مجازی مراجعه کنید.
• برای دستگاه‌های پرتاب A/B، مجموع حداکثر اندازه‌های همه گروه‌ها باید باشد:
  BOARD_SUPER_PARTITION_SIZE / 2 - سربار
• برای دستگاه‌های غیر A/B و دستگاه‌های مقاوم‌سازی A/B، مجموع حداکثر اندازه‌های همه گروه‌ها باید باشد:
  BOARD_SUPER_PARTITION_SIZE - سربار
• در زمان ساخت، مجموع اندازه‌های تصاویر هر پارتیشن در یک گروه به‌روزرسانی نباید از حداکثر اندازه گروه تجاوز کند.
• سربار در محاسبات برای محاسبه ابرداده ها، ترازها و غیره مورد نیاز است. سربار معقول 4 مگابایت است، اما می‌توانید در صورت نیاز دستگاه، سربار بزرگ‌تری را انتخاب کنید.

اندازه پارتیشن های پویا

قبل از پارتیشن های پویا، اندازه پارتیشن ها بیش از حد تخصیص داده می شد تا اطمینان حاصل شود که فضای کافی برای به روز رسانی های آینده دارند. اندازه واقعی همانطور که هست گرفته شد و اکثر پارتیشن های فقط خواندنی مقداری فضای خالی در سیستم فایل خود داشتند. در پارتیشن های پویا، این فضای آزاد غیرقابل استفاده است و می تواند برای رشد پارتیشن ها در طول OTA استفاده شود. بسیار مهم است که اطمینان حاصل شود که پارتیشن ها فضا را هدر نمی دهند و به حداقل اندازه ممکن اختصاص داده می شوند.

برای تصاویر ext4 فقط خواندنی، اگر اندازه پارتیشن هاردکد مشخص نشده باشد، سیستم ساخت به طور خودکار حداقل اندازه را اختصاص می دهد. سیستم ساخت با تصویر متناسب است تا فایل سیستم تا حد امکان فضای بلااستفاده کمتری داشته باشد. این تضمین می کند که دستگاه فضایی را که می تواند برای OTA استفاده شود هدر نمی دهد.

علاوه بر این، تصاویر ext4 را می‌توان با فعال کردن حذف مجدد در سطح بلوک فشرده‌تر کرد. برای فعال کردن این، از تنظیمات زیر استفاده کنید:

BOARD_EXT4_SHARE_DUP_BLOCKS := true

اگر تخصیص خودکار حداقل اندازه پارتیشن نامطلوب باشد، دو راه برای کنترل اندازه پارتیشن وجود دارد. می‌توانید حداقل فضای خالی را با BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE تعیین کنید، یا می‌توانید BOARD_ partition IMAGE_PARTITION_SIZE تعیین کنید تا پارتیشن‌های پویا را به یک اندازه خاص وادار کنید. هیچ کدام از اینها توصیه نمی شود مگر در موارد ضروری.

به عنوان مثال:

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

این باعث می شود سیستم فایل در product.img 50 مگابایت فضای بلااستفاده داشته باشد.

توجه: سیستم ساخت تنها می‌تواند تصاویر سیستم فایل ext4 را به بهترین نحو و فقط بر روی تصاویر تولید شده توسط بیلد منطبق کند. برای تصاویر از پیش ساخته شده یا تصاویری که از سیستم های فایل دیگر استفاده می کنند، مهم است که به صورت دستی اطمینان حاصل کنید که سیستم فایل فضای روی دیسک را هدر نمی دهد.

تغییرات سیستم به عنوان ریشه

دستگاه هایی که با اندروید 10 راه اندازی می شوند نباید از سیستم به عنوان ریشه استفاده کنند.

دستگاه‌های دارای پارتیشن‌های پویا (چه با پارتیشن‌های دینامیک راه‌اندازی شوند یا به‌روزرسانی شوند) نباید از system-as-root استفاده کنند. هسته لینوکس نمی تواند پارتیشن super را تفسیر کند و بنابراین نمی تواند خود system نصب کند. اکنون system توسط init مرحله اول که در ramdisk قرار دارد نصب شده است.

BOARD_BUILD_SYSTEM_ROOT_IMAGE را تنظیم نکنید. در Android 10، پرچم BOARD_BUILD_SYSTEM_ROOT_IMAGE فقط برای تشخیص اینکه آیا سیستم توسط هسته نصب شده است یا توسط مرحله اول init در ramdisk استفاده می شود.

تنظیم BOARD_BUILD_SYSTEM_ROOT_IMAGE روی true باعث ایجاد خطای ساخت می شود در حالی که PRODUCT_USE_DYNAMIC_PARTITIONS نیز true است.

وقتی BOARD_USES_RECOVERY_AS_BOOT روی true تنظیم شود، تصویر بازیابی به صورت boot.img ساخته می‌شود که حاوی ramdisk بازیابی است. پیش از این، بوت لودر از پارامتر خط فرمان هسته skip_initramfs برای تصمیم گیری در مورد اینکه در کدام حالت بوت شود استفاده می کرد. برای دستگاه های اندروید 10، بوت لودر نباید skip_initramfs به خط فرمان هسته ارسال کند. در عوض، bootloader باید androidboot.force_normal_boot=1 برای رد شدن از بازیابی و بوت کردن اندروید معمولی عبور دهد. دستگاه‌هایی که با Android 12 یا جدیدتر راه‌اندازی می‌شوند باید از bootconfig برای عبور androidboot.force_normal_boot=1 استفاده کنند.

تنظیمات AVB تغییر می کند

احتیاط: پارتیشن‌های پویا به Android Verified Boot (AVB) نیاز دارند و با Verified Boot 1.0 کار نمی‌کنند.

هنگام استفاده از Android Verified Boot 2.0 ، اگر دستگاه از توصیفگرهای پارتیشن زنجیره ای استفاده نمی کند، هیچ تغییری لازم نیست. اگر از پارتیشن‌های زنجیره‌ای استفاده می‌کنید و یکی از پارتیشن‌های تایید شده پویا است، تغییرات لازم است.

در اینجا یک پیکربندی مثال برای دستگاهی است که vbmeta برای system و پارتیشن‌های vendor زنجیره‌ای می‌کند.

BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1

BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1

با این پیکربندی، بوت لودر انتظار دارد یک پاورقی vbmeta در انتهای system و پارتیشن های vendor پیدا کند. از آنجایی که این پارتیشن ها دیگر برای بوت لودر قابل مشاهده نیستند (در super قرار دارند)، دو تغییر لازم است.

• پارتیشن های vbmeta_system و vbmeta_vendor را به جدول پارتیشن دستگاه اضافه کنید. برای دستگاه‌های A/B، vbmeta_system_a ، vbmeta_system_b ، vbmeta_vendor_a ، و vbmeta_vendor_b را اضافه کنید. اگر یک یا چند مورد از این پارتیشن ها را اضافه کنید، باید به اندازه پارتیشن vbmeta باشند.
• با افزودن VBMETA_ پرچم‌های پیکربندی را تغییر نام دهید و مشخص کنید زنجیره‌بندی به کدام پارتیشن‌ها گسترش می‌یابد:

  BOARD_AVB_VBMETA_SYSTEM := system
  BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
  BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048
  BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
  BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1
  
  BOARD_AVB_VBMETA_VENDOR := vendor
  BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
  BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048
  BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
  BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1

ممکن است یک دستگاه از یکی، هر دو یا هیچ یک از این پارتیشن ها استفاده نکند. تغییرات تنها زمانی لازم است که به یک پارتیشن منطقی زنجیر شوند.

تغییرات بوت لودر AVB

اگر بوت لودر libavb را تعبیه کرده است، وصله های زیر را وارد کنید:

• 818cf56740775446285466eda984acedd4baeac0 — "libavb: فقط زمانی از GUID های پارتیشن پرس و جو کنید که خط cmdline به آنها نیاز دارد."
• 5abd6bc2578968d24406d834471adfd995a0c2e9 — "اجازه دهید پارتیشن سیستم وجود نداشته باشد"
• 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "اصلاح AvbSlotVerifyData->cmdline ممکن است NULL باشد"

اگر از پارتیشن های زنجیره ای استفاده می کنید، یک پچ اضافی اضافه کنید:

• 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: پشتیبانی از vbmeta blobs در ابتدای پارتیشن."
  توجه: قبلاً پیاده سازی get_size_of_partition در AvbOps اختیاری بود. بعد از این تغییر نیاز است و بوت لودر باید این تابع را پیاده سازی کند.

خط فرمان کرنل تغییر می کند

یک پارامتر جدید، androidboot.boot_devices ، باید به خط فرمان هسته اضافه شود. این توسط init برای فعال کردن /dev/block/by-name استفاده می‌شود. این باید جزء مسیر دستگاه برای پیوند نمادین نام اصلی ایجاد شده توسط ueventd باشد، یعنی /dev/block/platform/ device-path /by-name/ partition-name . دستگاه‌هایی که با Android 12 یا جدیدتر راه‌اندازی می‌شوند باید از bootconfig برای ارسال androidboot.boot_devices برای init استفاده کنند.

به عنوان مثال، اگر پیوند نمادین پارتیشن فوق‌العاده /dev/block/platform/ soc/100000.ufshc /by-name/super باشد، می‌توانید پارامتر خط فرمان را به صورت زیر در فایل BoardConfig.mk اضافه کنید:

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc

می توانید پارامتر bootconfig را در فایل BoardConfig.mk به صورت زیر اضافه کنید:

BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

fstab تغییر می کند

درخت دستگاه و همپوشانی درخت دستگاه نباید حاوی ورودی های fstab باشد. از یک فایل fstab استفاده کنید که بخشی از ramdisk خواهد بود.

برای پارتیشن های منطقی باید تغییراتی در فایل fstab اعمال شود:

• فیلد fs_mgr flags باید شامل پرچم logical و پرچم first_stage_mount معرفی شده در اندروید 10 باشد که نشان می دهد پارتیشن قرار است در مرحله اول نصب شود.
• یک پارتیشن ممکن است avb= vbmeta partition name به عنوان یک پرچم fs_mgr مشخص کند و سپس پارتیشن vbmeta مشخص شده توسط مرحله اول init قبل از تلاش برای نصب هر دستگاه مقداردهی اولیه می شود.
• فیلد dev باید نام پارتیشن باشد.

ورودی های fstab زیر سیستم، فروشنده و محصول را به عنوان پارتیشن های منطقی با رعایت قوانین بالا تنظیم می کنند.

#<dev>  <mnt_point> <type>  <mnt_flags options> <fs_mgr_flags>
system   /system     ext4    ro,barrier=1        wait,slotselect,avb=vbmeta,logical,first_stage_mount
vendor   /vendor     ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount
product  /product    ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount

توجه: slotselect برای دستگاه های غیر A/B درج نکنید.

فایل fstab را در مرحله اول ramdisk کپی کنید.

SELinux تغییر می کند

دستگاه بلوک پارتیشن فوق العاده باید با برچسب super_block_device علامت گذاری شود. به عنوان مثال، اگر پیوند نمادین پارتیشن فوق العاده /dev/block/platform/ soc/100000.ufshc /by-name/super است، خط زیر را به file_contexts اضافه کنید:

/dev/block/platform/soc/10000\.ufshc/by-name/super   u:object_r:super_block_device:s0

فست بوت

بوت لودر (یا هر ابزار چشمک زن غیر فضای کاربری) پارتیشن های پویا را درک نمی کند، بنابراین نمی تواند آنها را فلش کند. برای رفع این مشکل، دستگاه ها باید از یک پیاده سازی فضای کاربری پروتکل fastboot به نام fastbootd استفاده کنند.

برای اطلاعات بیشتر در مورد نحوه اجرای fastbootd، به انتقال Fastboot به فضای کاربری مراجعه کنید.

نصب مجدد adb

برای توسعه دهندگانی که از بیلدهای eng یا userdebug استفاده می کنند، adb remount برای تکرار سریع بسیار مفید است. پارتیشن های پویا مشکلی را برای adb remount ایجاد می کنند زیرا دیگر فضای خالی در هر فایل سیستم وجود ندارد. برای رفع این مشکل، دستگاه ها می توانند همپوشانی ها را فعال کنند. تا زمانی که فضای خالی در پارتیشن فوق العاده وجود دارد، adb remount به طور خودکار یک پارتیشن پویا موقت ایجاد می کند و از overlayf ها برای نوشتن استفاده می کند. پارتیشن موقت scratch نام دارد، بنابراین از این نام برای پارتیشن های دیگر استفاده نکنید.

برای اطلاعات بیشتر در مورد نحوه فعال کردن همپوشانی ها، روی همپوشانی README در AOSP مراجعه کنید.

دستگاه های اندروید را ارتقا دهید

اگر دستگاهی را به اندروید 10 ارتقا می دهید و می خواهید پشتیبانی از پارتیشن های پویا را در OTA قرار دهید، نیازی به تغییر جدول پارتیشن داخلی ندارید. برخی از تنظیمات اضافی مورد نیاز است.

پیکربندی دستگاه تغییر می کند

برای بازسازی پارتیشن بندی پویا، پرچم های زیر را در device.mk اضافه کنید:

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

تغییرات پیکربندی برد

شما باید متغیرهای برد زیر را تنظیم کنید:

• BOARD_SUPER_PARTITION_BLOCK_DEVICES را روی فهرست دستگاه‌های بلوک مورد استفاده برای ذخیره وسعت پارتیشن‌های پویا تنظیم کنید. این لیستی از نام پارتیشن های فیزیکی موجود در دستگاه است.
• BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE به ترتیب به اندازه هر دستگاه بلوک در BOARD_SUPER_PARTITION_BLOCK_DEVICES تنظیم کنید. این لیست اندازه پارتیشن های فیزیکی موجود در دستگاه است. این معمولاً BOARD_ partition IMAGE_PARTITION_SIZE در پیکربندی‌های برد موجود است.
• BOARD_ partition IMAGE_PARTITION_SIZE برای همه پارتیشن‌های موجود در BOARD_SUPER_PARTITION_BLOCK_DEVICES لغو تنظیم کنید.
• BOARD_SUPER_PARTITION_SIZE را روی مجموع BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE تنظیم کنید.
• BOARD_SUPER_PARTITION_METADATA_DEVICE را روی دستگاه بلوکی که در آن فراداده پارتیشن پویا ذخیره می شود، تنظیم کنید. باید یکی از BOARD_SUPER_PARTITION_BLOCK_DEVICES باشد. معمولاً این روی system تنظیم می شود.
• به ترتیب BOARD_SUPER_PARTITION_GROUPS ، BOARD_ group _SIZE و BOARD_ group _PARTITION_LIST را تنظیم کنید. برای جزئیات بیشتر به تغییرات پیکربندی برد در دستگاه های جدید مراجعه کنید.

به عنوان مثال، اگر دستگاه از قبل دارای پارتیشن‌های سیستم و فروشنده است و می‌خواهید آنها را به پارتیشن‌های پویا تبدیل کنید و یک پارتیشن محصول جدید در طول به‌روزرسانی اضافه کنید، این پیکربندی برد را تنظیم کنید:

BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor
BOARD_SUPER_PARTITION_METADATA_DEVICE := system

# Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE.
BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes>

# Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes>

# This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

# Configuration for dynamic partitions. For example:
BOARD_SUPER_PARTITION_GROUPS := group_foo
BOARD_GROUP_FOO_SIZE := <size-in-bytes>
BOARD_GROUP_FOO_PARTITION_LIST := system vendor product

SELinux تغییر می کند

دستگاه های بلوک پارتیشن فوق العاده باید با ویژگی super_block_device_type علامت گذاری شوند. برای مثال، اگر دستگاه از قبل دارای پارتیشن‌های system و vendor است، می‌خواهید از آن‌ها به‌عنوان دستگاه‌های بلوک برای ذخیره گستره‌های پارتیشن‌های پویا استفاده کنید، و پیوندهای نمادین آن‌ها به‌عنوان system_block_device علامت‌گذاری می‌شوند:

/dev/block/platform/soc/10000\.ufshc/by-name/system   u:object_r:system_block_device:s0
/dev/block/platform/soc/10000\.ufshc/by-name/vendor   u:object_r:system_block_device:s0

سپس خط زیر را به device.te اضافه کنید:

typeattribute system_block_device super_block_device_type;

برای پیکربندی های دیگر، به پیاده سازی پارتیشن های پویا در دستگاه های جدید مراجعه کنید.

برای اطلاعات بیشتر درباره به‌روزرسانی‌های مقاوم‌سازی، OTA برای دستگاه‌های A/B بدون پارتیشن پویا را ببینید.

تصاویر کارخانه

برای دستگاهی که با پشتیبانی از پارتیشن‌های پویا راه‌اندازی می‌شود، از استفاده از userspace fastboot برای فلش کردن تصاویر کارخانه خودداری کنید، زیرا بوت شدن در فضای کاربر کندتر از سایر روش‌های فلش کردن است.

برای رفع این مشکل، make dist اکنون یک تصویر super.img اضافی می سازد که می تواند مستقیماً به پارتیشن فوق العاده فلش شود. این به طور خودکار محتویات پارتیشن های منطقی را بسته بندی می کند، به این معنی که شامل system.img ، vendor.img و غیره، علاوه بر ابرداده های پارتیشن super است. این تصویر را می توان مستقیماً بدون هیچ ابزار اضافی یا با استفاده از fastbootd به پارتیشن super فلش کرد. پس از ساخت، super.img در ${ANDROID_PRODUCT_OUT} قرار می گیرد.

برای دستگاه‌های A/B که با پارتیشن‌های پویا راه‌اندازی می‌شوند، super.img حاوی تصاویر در شکاف A است. پس از فلش مستقیم تصویر فوق العاده، قبل از راه اندازی مجدد دستگاه، شکاف A را به عنوان قابل بوت علامت گذاری کنید.

برای دستگاه‌های مقاوم‌سازی، make dist مجموعه‌ای از تصاویر super_*.img را ایجاد کنید که می‌توانند مستقیماً به پارتیشن‌های فیزیکی مربوطه فلش شوند. برای مثال، زمانی که BOARD_SUPER_PARTITION_BLOCK_DEVICES فروشنده سیستم است، ساخت‌های dist super_system.img و super_vendor.img را make dist . این تصاویر در پوشه OTA در target_files.zip قرار می گیرند.

دستگاه نقشه‌بردار ذخیره‌سازی-تنظیم دستگاه

پارتیشن بندی پویا تعدادی از اشیاء نقشه‌بردار دستگاه غیر قطعی را در خود جای می‌دهد. اینها ممکن است همه آن‌طور که انتظار می‌رود نمونه‌سازی نشوند، بنابراین باید همه مانت‌ها را ردیابی کنید و ویژگی‌های Android همه پارتیشن‌های مرتبط را با دستگاه‌های ذخیره‌سازی زیربنایی‌شان به‌روزرسانی کنید.

مکانیزمی در داخل init مانت ها را ردیابی می کند و به طور ناهمزمان ویژگی های اندروید را به روز می کند. مدت زمانی که این کار طول می کشد تضمین نمی شود که در یک دوره خاص باشد، بنابراین باید زمان کافی برای واکنش همه محرک های on property فراهم کنید. ویژگی ها dev.mnt.blk. <partition> به عنوان مثال dev.mnt.blk. <partition> که در آن <partition> root ، system ، data یا vendor است. همانطور که در این مثال ها نشان داده شده است، هر ویژگی با نام دستگاه ذخیره سازی پایه مرتبط است:

taimen:/ % getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [sda]
[dev.mnt.blk.firmware]: [sde]
[dev.mnt.blk.metadata]: [sde]
[dev.mnt.blk.persist]: [sda]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.vendor]: [dm-1]

blueline:/ $ getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [dm-4]
[dev.mnt.blk.metadata]: [sda]
[dev.mnt.blk.mnt.scratch]: [sda]
[dev.mnt.blk.mnt.vendor.persist]: [sdf]
[dev.mnt.blk.product]: [dm-2]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.system_ext]: [dm-3]
[dev.mnt.blk.vendor]: [dm-1]
[dev.mnt.blk.vendor.firmware_mnt]: [sda]

زبان init.rc اجازه می‌دهد تا ویژگی‌های Android را به عنوان بخشی از قوانین گسترش دهند و دستگاه‌های ذخیره‌سازی را می‌توان در صورت نیاز با دستوراتی مانند این توسط پلتفرم تنظیم کرد:

write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128

هنگامی که پردازش دستور در init دوم شروع می شود، epoll loop فعال می شود و مقادیر شروع به به روز رسانی می کنند. با این حال، از آنجایی که تریگرهای ویژگی تا init فعال نیستند، نمی‌توان از آنها در مراحل اولیه راه‌اندازی برای مدیریت root ، system یا vendor استفاده کرد. ممکن است انتظار داشته باشید که read_ahead_kb پیش‌فرض کرنل تا زمانی که اسکریپت‌های init.rc نتوانند در early-fs (زمانی که دیمون‌ها و امکانات مختلف شروع می‌شوند) نادیده گرفته شوند، کافی باشد. بنابراین، Google توصیه می‌کند که از ویژگی on property ، همراه با یک ویژگی init.rc -controlled مانند sys.read_ahead_kb ، برای مقابله با زمان‌بندی عملیات و جلوگیری از شرایط مسابقه، مانند مثال‌های زیر، استفاده کنید:

on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on early-fs:
    setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048}

on property:sys.boot_completed=1
   setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}