OTA برای دستگاه های A/B بدون پارتیشن پویا

اندروید 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 (استفاده نشده)
  • دستگاه بلوک فیزیکی system_b
    • فراداده 0 (استفاده نشده)
    • فراداده 1
      • گروه foo_b
        • system_b پارتیشن منطقی (پویا)_b
        • پارتیشن منطقی (پویا) product_services_b
        • سایر پارتیشن های به روز شده توسط Foo
      • گروه bar_b
        • پارتیشن منطقی (پویا) vendor_b
        • پارتیشن منطقی (پویا) product_b
        • سایر پارتیشن های به روز شده توسط Bar

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

جریان به روز رسانی را با استفاده از یک بسته به روز رسانی معمولی انجام دهید

  1. فراداده پارتیشن super را راه اندازی کنید.
    1. ابرداده جدید M را از فراداده S (فراداده منبع) بسازید. برای مثال، اگر ابرداده S از [ system_s ، vendor_s ، product_s ] به عنوان دستگاه‌های بلوک استفاده می‌کند، سپس ابرداده جدید M از [ system_t ، vendor_t ، product_t ] به عنوان دستگاه‌های بلوک استفاده می‌کند. همه گروه ها و پارتیشن ها در M حذف می شوند.
    2. گروه‌ها و پارتیشن‌های هدف را مطابق فیلد dynamic_partition_metadata در مانیفست به‌روزرسانی اضافه کنید. اندازه هر پارتیشن را می توان در new_partition_info یافت.
    3. M را در فراداده T بنویسید.
    4. پارتیشن‌های اضافه‌شده را روی نقشه‌بردار دستگاه به‌عنوان قابل نوشتن ترسیم کنید.
  2. به روز رسانی را روی دستگاه های بلوک اعمال کنید.
    1. در صورت لزوم، پارتیشن‌های منبع را روی نقشه‌بردار دستگاه به‌صورت فقط خواندنی نگاشت کنید. این برای بارگذاری جانبی ضروری است زیرا پارتیشن های منبع قبل از به روز رسانی نقشه برداری نمی شوند.
    2. به‌روزرسانی کامل یا دلتا را برای همه دستگاه‌های بلوک در شکاف هدف اعمال کنید.
    3. پارتیشن‌ها را برای اجرای اسکریپت پس از نصب نصب کنید و سپس پارتیشن‌ها را جدا کنید.
  3. پارتیشن های مورد نظر را از نقشه بردارید.

جریان به روز رسانی را با استفاده از بسته به روز رسانی 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 همیشه حاوی split super.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 به عنوان مرحله پس از نصب اجرا می کند و به روز رسانی را رد می کند.