اندروید 10 از پارتیشنهای پویا پشتیبانی میکند، یک سیستم پارتیشنبندی فضای کاربران که میتواند پارتیشنها را در طول بهروزرسانیهای هوایی (OTA) ایجاد، تغییر اندازه و از بین ببرد.
این صفحه نحوه تغییر اندازه پارتیشنهای پویا توسط کلاینتهای OTA را در حین بهروزرسانی برای دستگاههای A/B که بدون پشتیبانی از پارتیشنهای پویا راهاندازی شدهاند و نحوه ارتقای مشتریان OTA به Android 10 توضیح میدهد.
پس زمینه
در طول بهروزرسانی یک دستگاه A/B برای پشتیبانی از پارتیشنهای پویا، جدول پارتیشن GUID (GPT) روی دستگاه حفظ میشود، بنابراین هیچ پارتیشن super
در دستگاه وجود ندارد. فراداده در system_a
و system_b
ذخیره میشود، اما میتوان با تغییر BOARD_SUPER_PARTITION_METADATA_DEVICE
، آن را سفارشی کرد.
در هر یک از دستگاه های بلوک، دو اسلات ابرداده وجود دارد. فقط یک اسلات ابرداده در هر دستگاه بلوک استفاده می شود. به عنوان مثال، Metadata 0 در system_a
و Metadata 1 در system_b
به ترتیب با پارتیشن هایی در اسلات A و B مطابقت دارند. در زمان اجرا، مهم نیست که کدام اسلات در حال به روز رسانی است.
در این صفحه، اسلات های ابرداده به نام Metadata S (منبع) و Metadata T (هدف) هستند. به طور مشابه، پارتیشن ها با نام های system_s
، vendor_t
و غیره نامیده می شوند.
برای اطلاعات بیشتر در مورد پیکربندی های سیستم ساخت ، به ارتقای دستگاه ها مراجعه کنید.
برای اطلاعات بیشتر درباره نحوه تعلق پارتیشنها به گروههای بهروزرسانی ، به تغییرات پیکربندی برد برای دستگاههای جدید مراجعه کنید.
مثالی از ابرداده در یک دستگاه به شرح زیر است:
- دستگاه بلوک فیزیکی
system_a
- فراداده 0
- گروه
foo_a
-
system_a
پارتیشن منطقی (پویا)_a - پارتیشن منطقی (پویا)
product_services_a
- سایر پارتیشن های به روز شده توسط Foo
-
- گروه
bar_a
- پارتیشن منطقی (پویا)
vendor_a
- پارتیشن منطقی (پویا)
product_a
- سایر پارتیشن های به روز شده توسط Bar
- پارتیشن منطقی (پویا)
- گروه
- فراداده 1 (استفاده نشده)
- فراداده 0
- دستگاه بلوک فیزیکی
system_b
- فراداده 0 (استفاده نشده)
- فراداده 1
- گروه foo_b
-
system_b
پارتیشن منطقی (پویا)_b - پارتیشن منطقی (پویا)
product_services_b
- سایر پارتیشن های به روز شده توسط Foo
-
- گروه bar_b
- پارتیشن منطقی (پویا)
vendor_b
- پارتیشن منطقی (پویا)
product_b
- سایر پارتیشن های به روز شده توسط Bar
- پارتیشن منطقی (پویا)
- گروه foo_b
میتوانید از ابزار lpdump
در قسمت system/extras/partition_tools
برای تخلیه ابردادهها در دستگاه خود استفاده کنید. به عنوان مثال:
lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b
به روز رسانی مجدد
در دستگاههای دارای Android 9 و پایینتر، سرویس گیرنده OTA روی دستگاه از نقشهبرداری پارتیشنهای پویا قبل از بهروزرسانی پشتیبانی نمیکند. مجموعهای از وصلههای اضافی ایجاد میشود تا بتوان نقشهبرداری را مستقیماً روی پارتیشنهای فیزیکی موجود اعمال کرد.
ژنراتور OTA فایل super.img
نهایی را که حاوی محتوای تمام پارتیشنهای پویا است میسازد، سپس تصویر را به چندین تصویر منطبق با اندازه دستگاههای بلوک فیزیکی مربوط به سیستم، فروشنده و غیره تقسیم میکند. این تصاویر super_system.img
، super_vendor.img
و غیره نام دارند. مشتری OTA این تصاویر را به جای اعمال تصاویر برای پارتیشن های منطقی (پویا) روی پارتیشن های فیزیکی اعمال می کند.
از آنجایی که سرویس گیرنده OTA نمی داند چگونه پارتیشن های پویا را نقشه برداری کند، تمام مراحل پس از نصب به طور خودکار برای این پارتیشن ها هنگام تولید بسته به روز رسانی غیرفعال می شوند. برای جزئیات بیشتر به پیکربندی پس از نصب مراجعه کنید.
جریان به روز رسانی مانند اندروید 9 است.
قبل از آپدیت:
ro.boot.dynamic_partitions= ro.boot.dynamic_partitions_retrofit=
بعد از آپدیت:
ro.boot.dynamic_partitions=true ro.boot.dynamic_partitions_retrofit=true
به روز رسانی های آینده پس از بازسازی
پس از به روز رسانی retrofit، مشتری OTA برای کار با پارتیشن های پویا به روز می شود. گستره پارتیشنهای منبع هرگز در سراسر پارتیشنهای فیزیکی هدف قرار نمیگیرد.
جریان به روز رسانی را با استفاده از یک بسته به روز رسانی معمولی انجام دهید
- فراداده پارتیشن
super
را راه اندازی کنید.- ابرداده جدید M را از فراداده S (فراداده منبع) بسازید. برای مثال، اگر ابرداده S از [
system_s
،vendor_s
،product_s
] به عنوان دستگاههای بلوک استفاده میکند، سپس ابرداده جدید M از [system_t
،vendor_t
،product_t
] به عنوان دستگاههای بلوک استفاده میکند. همه گروه ها و پارتیشن ها در M حذف می شوند. - گروهها و پارتیشنهای هدف را مطابق فیلد
dynamic_partition_metadata
در مانیفست بهروزرسانی اضافه کنید. اندازه هر پارتیشن را می توان درnew_partition_info
یافت. - M را در فراداده T بنویسید.
- پارتیشنهای اضافهشده را روی نقشهبردار دستگاه بهعنوان قابل نوشتن ترسیم کنید.
- ابرداده جدید M را از فراداده S (فراداده منبع) بسازید. برای مثال، اگر ابرداده S از [
- به روز رسانی را روی دستگاه های بلوک اعمال کنید.
- در صورت لزوم، پارتیشنهای منبع را روی نقشهبردار دستگاه بهصورت فقط خواندنی نگاشت کنید. این برای بارگذاری جانبی ضروری است زیرا پارتیشن های منبع قبل از به روز رسانی نقشه برداری نمی شوند.
- بهروزرسانی کامل یا دلتا را برای همه دستگاههای بلوک در شکاف هدف اعمال کنید.
- پارتیشنها را برای اجرای اسکریپت پس از نصب نصب کنید و سپس پارتیشنها را جدا کنید.
- پارتیشن های مورد نظر را از نقشه بردارید.
جریان به روز رسانی را با استفاده از بسته به روز رسانی retrofit
اگر بسته بهروزرسانی retrofit روی دستگاهی اعمال شود که قبلاً پارتیشنهای پویا را فعال کرده است، مشتری OTA فایل split super.img
را مستقیماً روی دستگاههای بلوک اعمال میکند. جریان به روز رسانی مشابه به روز رسانی به روز رسانی است. برای جزئیات بیشتر به تعمیر به روز رسانی مراجعه کنید.
برای مثال موارد زیر را فرض کنید:
- اسلات A اسلات فعال است.
-
system_a
حاوی فراداده فعال در اسلات 0 است. -
system_a
،vendor_a
، وproduct_a
به عنوان دستگاههای بلوک استفاده میشوند.
هنگامی که سرویس گیرنده OTA بسته به روز رسانی retrofit دریافت می کند، super_system.img
در فیزیکی system_b
، super_vendor.img
را در vendor_b
فیزیکی و super_product.img
در فیزیکی product_b
اعمال می کند. دستگاه بلوک فیزیکی system_b
حاوی متادیتای صحیحی برای ترسیم سیستم منطقی system_b
، vendor_b
و product_b
در زمان راهاندازی است.
تولید بسته های به روز رسانی
OTA افزایشی
هنگام ایجاد OTA افزایشی برای دستگاههای مقاومسازی، بهروزرسانیها به این بستگی دارد که آیا ساخت پایه PRODUCT_USE_DYNAMIC_PARTITIONS
و PRODUCT_RETROFIT_DYNAMIC_PARTITIONS
را تعریف میکند یا خیر.
- اگر ساخت پایه متغیرها را تعریف نمی کند ، این یک به روز رسانی مقاوم سازی شده است. بسته به روز رسانی حاوی فایل split
super.img
است و مرحله پس از نصب را غیرفعال می کند. - اگر بیلد پایه متغیرها را تعریف کند ، این همان بهروزرسانی معمولی با پارتیشنهای پویا است. بسته به روز رسانی شامل تصاویر پارتیشن های منطقی (پویا) است. مرحله پس از نصب را می توان فعال کرد.
OTA کامل
دو بسته کامل OTA برای دستگاه های مقاوم سازی تولید می شود.
-
$(PRODUCT)-ota-retrofit-$(TAG).zip
همیشه حاوی splitsuper.img
است و مرحله پس از نصب را برای بهروزرسانی جدید غیرفعال میکند.- با یک آرگومان اضافی
--retrofit_dynamic_partitions
به اسکریپتota_from_target_files
ایجاد می شود. - می توان آن را برای همه بیلدها اعمال کرد.
- با یک آرگومان اضافی
-
$(PRODUCT)-ota-$(TAG).zip
حاوی تصاویر منطقی برای بهروزرسانیهای آینده است.- این را فقط برای ساخت هایی با پارتیشن های پویا فعال کنید. جزئیات زیر را در مورد اجرای این موضوع ببینید.
به روز رسانی nonretrofit را در ساخت های قدیمی رد کنید
بسته معمولی کامل OTA را فقط برای ساختهایی که پارتیشنهای پویا فعال هستند اعمال کنید. اگر سرور OTA به درستی پیکربندی نشده باشد و این بستهها را به دستگاههای دارای Android 9 یا پایینتر فشار دهد، دستگاهها راهاندازی نمیشوند. سرویس گیرنده OTA در اندروید 9 و پایین تر نمی تواند تفاوت بین بسته OTA اصلاح شده و بسته OTA معمولی را تشخیص دهد، بنابراین مشتری بسته کامل را رد نمی کند.
برای جلوگیری از پذیرش بسته کامل OTA توسط دستگاه، میتوانید به یک مرحله پس از نصب برای بررسی پیکربندی دستگاه موجود نیاز داشته باشید. به عنوان مثال:
device/ device_name /dynamic_partitions/check_dynamic_partitions
#!/system/bin/sh DP_PROPERTY_NAME="ro.boot.dynamic_partitions" DP_RETROFIT_PROPERTY_NAME="ro.boot.dynamic_partitions_retrofit" DP_PROPERTY=$(getprop ${DP_PROPERTY_NAME}) DP_RETROFIT_PROPERTY=$(getprop ${DP_RETROFIT_PROPERTY_NAME}) if [ "${DP_PROPERTY}" != "true" ] || [ "${DP_RETROFIT_PROPERTY}" != "true" ] ; then echo "Error: applied non-retrofit update on build without dynamic" \ "partitions." echo "${DP_PROPERTY_NAME}=${DP_PROPERTY}" echo "${DP_RETROFIT_PROPERTY_NAME}=${DP_RETROFIT_PROPERTY}" exit 1 fi
device/ device_name /dynamic_partitions/Android.mk
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE:= check_dynamic_partitions LOCAL_MODULE_TAGS := optional LOCAL_MODULE_CLASS := EXECUTABLES LOCAL_SRC_FILES := check_dynamic_partitions LOCAL_PRODUCT_MODULE := true include $(BUILD_PREBUILT)
device/ device_name /device.mk
PRODUCT_PACKAGES += check_dynamic_partitions # OPTIONAL=false so that the error in check_dynamic_partitions will be # propagated to OTA client. AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_product=true \ POSTINSTALL_PATH_product=bin/check_dynamic_partitions \ FILESYSTEM_TYPE_product=ext4 \ POSTINSTALL_OPTIONAL_product=false \
هنگامی که بسته OTA معمولی روی دستگاهی بدون فعال بودن پارتیشن های پویا اعمال می شود، مشتری OTA check_dynamic_partitions
به عنوان مرحله پس از نصب اجرا می کند و به روز رسانی را رد می کند.