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

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

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

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

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

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

این بخش جزئیات نحوه پیاده‌سازی پارتیشن‌های پویا در دستگاه‌های جدیدی که با اندروید ۱۰ و بالاتر عرضه می‌شوند را شرح می‌دهد. برای به‌روزرسانی دستگاه‌های موجود، به «ارتقاء دستگاه‌های اندروید» مراجعه کنید.

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

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

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

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

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

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

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

ترازبندی پارتیشن

اگر پارتیشن super به درستی تراز نشده باشد، ماژول نگاشت دستگاه ممکن است با کارایی کمتری عمل کند. پارتیشن super باید با حداقل اندازه درخواست ورودی/خروجی که توسط لایه بلوک تعیین می‌شود، تراز شود. به طور پیش‌فرض، سیستم ساخت (از طریق lpmake که تصویر پارتیشن super را تولید می‌کند) فرض می‌کند که ترازبندی ۱ مگابایتی برای هر پارتیشن پویا کافی است. با این حال، فروشندگان باید اطمینان حاصل کنند که پارتیشن 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

در اینجا یک دستگاه مثالی آورده شده است که سرویس‌های system و 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
  • برای دستگاه‌های راه‌اندازی مجازی A/B، مجموع حداکثر اندازه‌های همه گروه‌ها باید حداکثر باشد:
    BOARD_SUPER_PARTITION_SIZE - سربار
    به بخش پیاده‌سازی A/B مجازی مراجعه کنید.
  • برای دستگاه‌های پرتاب A/B، مجموع حداکثر اندازه‌های همه گروه‌ها باید برابر باشد با:
    BOARD_SUPER_PARTITION_SIZE / 2 - سربار
  • برای دستگاه‌های غیر A/B و دستگاه‌های A/B ارتقا یافته، مجموع حداکثر اندازه‌های همه گروه‌ها باید برابر باشد با:
    BOARD_SUPER_PARTITION_SIZE - سربار
  • در زمان ساخت، مجموع اندازه تصاویر هر پارتیشن در یک گروه به‌روزرسانی نباید از حداکثر اندازه گروه بیشتر شود.
  • سربار در محاسبات برای در نظر گرفتن فراداده‌ها، ترازبندی‌ها و غیره مورد نیاز است. سربار معقول ۴ مگابایت است، اما می‌توانید سربار بیشتری را در صورت نیاز دستگاه انتخاب کنید.

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

قبل از پارتیشن‌های پویا، اندازه پارتیشن‌ها بیش از حد اختصاص داده می‌شد تا اطمینان حاصل شود که فضای کافی برای به‌روزرسانی‌های آینده دارند. اندازه واقعی به همان صورت در نظر گرفته می‌شد و اکثر پارتیشن‌های فقط خواندنی مقداری فضای خالی در سیستم فایل خود داشتند. در پارتیشن‌های پویا، آن فضای خالی غیرقابل استفاده است و می‌توان از آن برای افزایش پارتیشن‌ها در طول 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 مگابایت فضای استفاده نشده داشته باشد.

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

دستگاه‌هایی که با اندروید ۱۰ عرضه می‌شوند، نباید از system-as-root استفاده کنند.

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

BOARD_BUILD_SYSTEM_ROOT_IMAGE تنظیم نکنید. در اندروید ۱۰، پرچم 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 برای تصمیم‌گیری در مورد اینکه در کدام حالت بوت شود استفاده می‌کرد. برای دستگاه‌های اندروید ۱۰، بوت‌لودر نباید skip_initramfs به خط فرمان هسته ارسال کند. در عوض، بوت‌لودر باید androidboot.force_normal_boot=1 را ارسال کند تا از بازیابی صرف‌نظر کرده و اندروید معمولی را بوت کند. دستگاه‌هایی که با اندروید ۱۲ یا بالاتر راه‌اندازی می‌شوند باید از bootconfig برای ارسال androidboot.force_normal_boot=1 استفاده کنند.

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

هنگام استفاده از 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 را تعبیه کرده است، پچ‌های زیر را اضافه کنید:

اگر از پارتیشن‌های زنجیری استفاده می‌کنید، یک وصله اضافی اضافه کنید:

  • 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: از vbmeta blobs در ابتدای پارتیشن پشتیبانی می‌کند."

تغییرات خط فرمان هسته

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

برای مثال، اگر لینک نمادین پارتیشن super به صورت /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 flag و first_stage_mount flag باشد که در اندروید ۱۰ معرفی شده است و نشان می‌دهد که یک پارتیشن قرار است در مرحله اول mount شود.
  • یک پارتیشن می‌تواند avb= vbmeta partition name به عنوان یک پرچم fs_mgr مشخص کند و سپس پارتیشن vbmeta مشخص شده قبل از تلاش برای نصب هر دستگاهی، توسط init مرحله اول مقداردهی اولیه می‌شود.
  • فیلد dev باید نام پارتیشن باشد.

ورودی‌های fstab زیر، system، vendor و product را به عنوان پارتیشن‌های منطقی با پیروی از قوانین فوق تنظیم می‌کنند. 

#<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

فایل 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 مشکل ایجاد می‌کنند زیرا دیگر فضای خالی در هر سیستم فایل وجود ندارد. برای رفع این مشکل، دستگاه‌ها می‌توانند overlayfs را فعال کنند. تا زمانی که فضای خالی در super partition وجود داشته باشد، adb remount به طور خودکار یک پارتیشن پویای موقت ایجاد می‌کند و از overlayfs برای نوشتن استفاده می‌کند. پارتیشن موقت scratch نام دارد، بنابراین از این نام برای پارتیشن‌های دیگر استفاده نکنید.

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

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

اگر دستگاهی را به اندروید ۱۰ ارتقا دهید و بخواهید پشتیبانی از پارتیشن‌های پویا را در 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 بدون پارتیشن‌های پویا مراجعه کنید.

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

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

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

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

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

تنظیم دستگاه ذخیره سازی نگاشت کننده دستگاه

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

مکانیزمی درون init mountها را ردیابی کرده و به صورت غیرهمزمان ویژگی‌های اندروید را به‌روزرسانی می‌کند. تضمین نمی‌شود که مدت زمان این کار در یک دوره خاص باشد، بنابراین باید زمان کافی برای واکنش همه triggerهای on property فراهم کنید. این ویژگی‌ها 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 به ویژگی‌های اندروید اجازه می‌دهد تا به عنوان بخشی از قوانین، گسترش یابند و دستگاه‌های ذخیره‌سازی می‌توانند توسط پلتفرم در صورت نیاز با دستوراتی مانند این تنظیم شوند: 

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 فعال می‌شود و مقادیر شروع به به‌روزرسانی می‌کنند. با این حال، از آنجا که محرک‌های ویژگی تا late- init فعال نیستند، نمی‌توان از آنها در مراحل اولیه بوت برای مدیریت root ، system یا vendor استفاده کرد. ممکن است انتظار داشته باشید که read_ahead_kb پیش‌فرض هسته تا زمانی که اسکریپت‌های init.rc بتوانند در early-fs (زمانی که سرویس‌ها و امکانات مختلف شروع می‌شوند) لغو شوند، کافی باشد. بنابراین، گوگل توصیه می‌کند که از ویژگی 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}