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

اندروید ۱۰ از پارتیشن‌های پویا پشتیبانی می‌کند، یک سیستم پارتیشن‌بندی فضای کاربری که می‌تواند در طول به‌روزرسانی‌های OTA پارتیشن‌ها را ایجاد، تغییر اندازه و از بین ببرد.

این صفحه نحوه تغییر اندازه پارتیشن‌های پویا توسط کلاینت‌های OTA را در طول به‌روزرسانی برای دستگاه‌های A/B که بدون پشتیبانی از پارتیشن‌های پویا راه‌اندازی شده‌اند و نحوه ارتقاء کلاینت‌های OTA به اندروید ۱۰ را شرح می‌دهد.

پیشینه

در طول به‌روزرسانی یک دستگاه A/B برای پشتیبانی از پارتیشن‌های پویا، جدول پارتیشن GUID (GPT) روی دستگاه حفظ می‌شود، بنابراین هیچ پارتیشن super روی دستگاه وجود ندارد. فراداده در system_a و system_b ذخیره می‌شود، اما می‌توان با تغییر BOARD_SUPER_PARTITION_METADATA_DEVICE آن را سفارشی کرد.

در هر یک از دستگاه‌های بلوکی، دو اسلات فراداده وجود دارد. فقط یک اسلات فراداده در هر دستگاه بلوکی استفاده می‌شود. برای مثال، فراداده ۰ در system_a و فراداده ۱ در system_b به ترتیب مربوط به پارتیشن‌ها در اسلات‌های A و B هستند. در زمان اجرا، فرقی نمی‌کند کدام اسلات به‌روزرسانی شود.

در این صفحه، اسلات‌های فراداده، فراداده S (منبع) و فراداده T (هدف) نامیده می‌شوند. به طور مشابه، پارتیشن‌ها نیز با نام‌های system_s ، vendor_t و غیره شناخته می‌شوند.

برای اطلاعات بیشتر در مورد پیکربندی‌های سیستم ساخت ، به ارتقاء دستگاه‌ها مراجعه کنید.

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

نمونه‌ای از فراداده‌ها در یک دستگاه به شرح زیر است:

  • دستگاه بلوک فیزیکی system_a
    • فراداده 0
      • گروه foo_a
        • system_a پارتیشن منطقی (پویا)
        • پارتیشن منطقی (پویا) product_services_a
        • پارتیشن‌های دیگر توسط فو به‌روزرسانی شدند
      • bar_a گروهی_a
        • vendor_a پارتیشن منطقی (پویا)
        • پارتیشن منطقی (پویا) product_a
        • پارتیشن‌های دیگر توسط Bar به‌روزرسانی شدند
    • فراداده ۱ (استفاده نشده)
  • دستگاه بلوک فیزیکی system_b
    • فراداده ۰ (استفاده نشده)
    • فراداده ۱
      • گروه foo_b
        • system_b پارتیشن منطقی (پویا)_b
        • پارتیشن منطقی (پویا) product_services_b
        • پارتیشن‌های دیگر توسط فو به‌روزرسانی شدند
      • نوار گروه
        • vendor_b پارتیشن منطقی (پویا)_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

یک به‌روزرسانی را مقاوم‌سازی کنید

در دستگاه‌هایی که اندروید ۹ و پایین‌تر دارند، کلاینت OTA روی دستگاه قبل از به‌روزرسانی از نگاشت پارتیشن‌های پویا پشتیبانی نمی‌کند. مجموعه‌ای اضافی از وصله‌ها ایجاد می‌شود تا نگاشت بتواند مستقیماً روی پارتیشن‌های فیزیکی موجود اعمال شود.

مولد OTA فایل نهایی super.img را می‌سازد که شامل محتوای تمام پارتیشن‌های پویا است، سپس تصویر را به چندین تصویر که با اندازه دستگاه‌های بلوک فیزیکی مربوط به system، vendor و غیره مطابقت دارند، تقسیم می‌کند. این تصاویر super_system.img ، super_vendor.img و غیره نامگذاری می‌شوند. کلاینت OTA این تصاویر را به پارتیشن‌های فیزیکی اعمال می‌کند، نه اینکه تصاویر را برای پارتیشن‌های منطقی (پویا) اعمال کند.

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

روند به‌روزرسانی مشابه اندروید ۹ است.

قبل از بروزرسانی: 

ro.boot.dynamic_partitions=
ro.boot.dynamic_partitions_retrofit=

بعد از آپدیت:

ro.boot.dynamic_partitions=true
ro.boot.dynamic_partitions_retrofit=true

به‌روزرسانی‌های آینده پس از به‌روزرسانی

پس از به‌روزرسانی مقاوم‌سازی، کلاینت 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. برای اجرای اسکریپت پس از نصب، پارتیشن‌ها را mount کنید و سپس پارتیشن‌ها را unmount کنید.
  3. پارتیشن‌های هدف را از حالت نگاشت خارج کنید.

جریان به‌روزرسانی با استفاده از بسته به‌روزرسانی مقاوم‌سازی

اگر بسته به‌روزرسانی Retrofit روی دستگاهی اعمال شود که از قبل پارتیشن‌های پویا را فعال کرده است، کلاینت OTA فایل split super.img را مستقیماً روی دستگاه‌های بلوکی اعمال می‌کند. روند به‌روزرسانی مشابه به‌روزرسانی Retrofit است. برای جزئیات بیشتر به Retrofitting an update مراجعه کنید.

برای مثال، موارد زیر را فرض کنید:

  • اسلات A، اسلات فعال است.
  • system_a شامل فراداده‌های فعال در اسلات ۰ است.
  • system_a ، vendor_a و product_a به عنوان دستگاه‌های بلوکی استفاده می‌شوند.

وقتی کلاینت OTA بسته به‌روزرسانی مقاوم‌سازی را دریافت می‌کند، 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 را تعریف می‌کند یا خیر.

  • اگر نسخه پایه متغیرها را تعریف نکرده باشد ، این یک به‌روزرسانی مقاوم‌سازی است. بسته به‌روزرسانی شامل فایل super.img تقسیم‌شده است و مرحله پس از نصب را غیرفعال می‌کند.
  • اگر نسخه پایه متغیرها را تعریف کند ، این همان به‌روزرسانی معمولی با پارتیشن‌های پویا است. بسته به‌روزرسانی شامل تصاویر مربوط به پارتیشن‌های منطقی (پویا) است. مرحله پس از نصب را می‌توان فعال کرد.

کامل از طریق OTA

دو بسته کامل OTA برای دستگاه‌های ارتقا یافته تولید می‌شوند.

  • $(PRODUCT)-ota-retrofit-$(TAG).zip ‎ همیشه شامل super.img جدا شده است و مرحله پس از نصب برای به‌روزرسانی مقاوم‌سازی را غیرفعال می‌کند.
    • این با یک آرگومان اضافی --retrofit_dynamic_partitions به اسکریپت ota_from_target_files تولید می‌شود.
    • قابل اجرا روی همه سازه ها.
  • $(PRODUCT)-ota-$(TAG).zip ‎ شامل تصاویر منطقی برای به‌روزرسانی‌های آینده است.
    • این مورد را فقط برای سازه‌هایی که پارتیشن‌های پویا در آنها فعال است اعمال کنید. جزئیات مربوط به اجرای این مورد را در زیر مشاهده کنید.

به‌روزرسانی بدون نیاز به مقاوم‌سازی در نسخه‌های قدیمی را رد کنید

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