اجرای به روزرسانی های A / B

OEM ها و SOC فروشندگان که می خواهند برای اجرای A / B به روز رسانی سیستم باید ابزار بوت لودر خود boot_control HAL اطمینان و عبور پارامترهای صحیح به هسته است.

پیاده سازی HAL کنترل بوت

A / B-بوت لودر باید قادر پیاده سازی boot_control HAL در hardware/libhardware/include/hardware/boot_control.h . شما می توانید پیاده سازی با استفاده از تست system/extras/bootctl ابزار و system/extras/tests/bootloader/ .

شما همچنین باید ماشین حالت زیر را پیاده سازی کنید:

ماشین حالت شکل 1. بوت لودر

راه اندازی هسته

برای پیاده سازی به روز رسانی سیستم A/B:

  1. سری پچ هسته زیر (در صورت نیاز) را انتخاب کنید:
  2. اطمینان از آرگومان های خط فرمان کرنل شامل موارد زیر استدلال اضافی:
    skip_initramfs rootwait ro init=/init root="/dev/dm-0 dm=system none ro,0 1 android-verity <public-key-id> <path-to-system-partition>"
    ... که در آن <public-key-id> ارزش ID از کلید عمومی استفاده می شود به بررسی امضای جدول صحت است (برای جزئیات بیشتر، نگاه کنید به DM-حقیقت ) به
  3. گواهی .X509 حاوی کلید عمومی را به جا کلید سیستم اضافه کنید:
    1. کپی گواهی .X509 فرمت در .der فرمت به ریشه kernel دایرکتوری. اگر گواهی .X509 به عنوان یک فرمت .pem فایل، استفاده از موارد زیر openssl دستور برای تبدیل از .pem به .der فرمت:
      openssl x509 -in <x509-pem-certificate> -outform der -out <x509-der-certificate>
    2. ساخت zImage شامل گواهی به عنوان بخشی از جاکلیدی سیستم. به منظور بررسی، بررسی procfs ورود (نیاز به KEYS_CONFIG_DEBUG_PROC_KEYS فعال شود):
      angler:/# cat /proc/keys
      
      1c8a217e I------     1 perm 1f010000     0     0 asymmetri
      Android: 7e4333f9bba00adfe0ede979e28ed1920492b40f: X509.RSA 0492b40f []
      2d454e3e I------     1 perm 1f030000     0     0 keyring
      .system_keyring: 1/4
      گنجاندن موفقیت آمیز از این گواهی .X509 نشان دهنده وجود کلید عمومی در جاکلیدی سیستم (برجسته نشان دهنده کلید ID عمومی).
    3. به جای فضا با # و با تصویب آن به عنوان <public-key-id> در خط فرمان کرنل. به عنوان مثال، عبور Android:#7e4333f9bba00adfe0ede979e28ed1920492b40f به جای <public-key-id> .

تنظیم متغیرهای ساخت

بوت لودرهای دارای قابلیت A/B باید دارای معیارهای متغیر ساخت زیر باشند:

باید برای هدف A/B تعریف شود
  • AB_OTA_UPDATER := true
  • AB_OTA_PARTITIONS := \
    boot \
    system \
    vendor
    و پارتیشن های دیگر به روز از طریق update_engine (رادیو، بوت لودر، و غیره)
  • PRODUCT_PACKAGES += \
    update_engine \
    update_verifier
برای مثال، اشاره به /device/google/marlin/+/android-7.1.0_r1/device-common.mk . شما به صورت اختیاری می توانید انجام پس از نصب (اما قبل از راه اندازی مجدد سیستم) dex2oat گام در توصیف کامپایل .
به شدت برای هدف A/B توصیه می شود
  • تعریف TARGET_NO_RECOVERY := true
  • تعریف BOARD_USES_RECOVERY_AS_BOOT := true
  • هنوز تعریف نمی BOARD_RECOVERYIMAGE_PARTITION_SIZE
نمی توان برای هدف A/B تعریف کرد
  • BOARD_CACHEIMAGE_PARTITION_SIZE
  • BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE
اختیاری برای ساخت اشکال زدایی PRODUCT_PACKAGES_DEBUG += update_engine_client

تنظیم پارتیشن (اسلات)

دستگاه های A/B نیازی به پارتیشن بازیابی یا پارتیشن کش ندارند زیرا اندروید دیگر از این پارتیشن ها استفاده نمی کند. پارتیشن داده اکنون برای بسته OTA بارگیری شده استفاده می شود و کد تصویر بازیابی در پارتیشن بوت است. همه پارتیشن که A / B-ED باید به شرح زیر نام (اسلات همیشه به نام ، a b ، و غیره): boot_a ، boot_b ، system_a ، system_b ، vendor_a ، vendor_b .

حافظه پنهان

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

بهبود

دیسک بازیابی رم در حال حاضر در موجود boot.img فایل. هنگام رفتن به بازیابی، بوت لودر می توانید قرار داده نشده skip_initramfs گزینه در خط فرمان کرنل.

برای به روزرسانی های غیر A/B ، پارتیشن بازیابی حاوی کدی است که برای اعمال به روز رسانی استفاده می شود. بهروزرسانی / B توسط اعمال update_engine در حال اجرا در تصویر به طور منظم سیستم بوت. هنوز یک حالت بازیابی برای اجرای بازنشانی داده های کارخانه و بارگذاری جانبی بسته های به روزرسانی (که نام "بازیابی" از آنجا آمده است) استفاده می شود. کد و داده های حالت بازیابی در پارتیشن بوت معمولی در ramdisk ذخیره می شود. برای بوت شدن در تصویر سیستم ، بوت لودر به کرنل می گوید که از ramdisk پرش کنید (در غیر این صورت دستگاه به حالت بازیابی راه اندازی می شود. حالت بازیابی کوچک است (و بیشتر آن قبلاً در پارتیشن بوت بود) ، بنابراین پارتیشن بوت افزایش نمی یابد در اندازه.

فستاب

slotselect استدلال باید در خط برای پارتیشن A / B-ED است. مثلا:

<path-to-block-device>/vendor  /vendor  ext4  ro
wait,verify=<path-to-block-device>/metadata,slotselect

بدون پارتیشن باید به نام vendor . در عوض، پارتیشن vendor_a یا vendor_b انتخاب خواهد شد و نصب شده بر روی /vendor سوار نقطه.

استدلال های شکاف هسته

پسوند فعلی اسلات باید یا از طریق یک گره درخت دستگاه خاص (DT) به تصویب رسید ( /firmware/android/slot_suffix ) و یا از طریق androidboot.slot_suffix هسته خط فرمان و یا استدلال bootconfig.

به طور پیش فرض ، fastboot شکاف جاری دستگاه A/B را چشمک می زند. اگر بسته به روز رسانی شامل تصاویری برای شکاف دیگر و غیر جاری است ، fastboot آن تصاویر را نیز چشمک می زند. گزینه های موجود عبارتند از:

  • --slot SLOT . رفتار پیش فرض را نادیده بگیرید و سریع را راه اندازی کنید تا شکافی که به عنوان آرگومان وارد شده است چشمک بزند.
  • --set-active [ SLOT ] . شکاف را به عنوان فعال تنظیم کنید. اگر هیچ آرگومان اختیاری مشخص نشده باشد ، شکاف فعلی به عنوان فعال تنظیم می شود.
  • fastboot --help . جزئیات دستورات را دریافت کنید.

اگر رام ادوات بوت لودر، آن را باید از دستور حمایت set_active <slot> که مجموعه شکاف فعال فعلی به حافظه داده است (این نیز باید پرچم غیر قابل بوت آن شکاف را روشن و بازنشانی تعداد سعی مجدد به مقادیر پیش فرض). بوت لودر همچنین باید متغیرهای زیر را پشتیبانی کند:

  • has-slot:<partition-base-name-without-suffix> . اگر پارتیشن داده شده از اسلات پشتیبانی می کند ، بله را برمی گرداند ، در غیر این صورت "نه".
  • current-slot . پسوند شکافی را که از بعدی بوت می شود برمی گرداند.
  • slot-count . یک عدد صحیح را نشان می دهد که تعداد اسلات های موجود را نشان می دهد. در حال حاضر، دو اسلات پشتیبانی می شوند بنابراین این مقدار 2 .
  • slot-successful:<slot-suffix> . اگر شکاف داده شده به عنوان موفقیت آمیز در راه اندازی علامت گذاری شده باشد ، بله را باز می گرداند ، در غیر این صورت "نه".
  • slot-unbootable:<slot-suffix> . اگر شکاف داده شده به عنوان غیر قابل بوت شدن علامت گذاری شود ، بله را برمی گرداند ، در غیر این صورت "نه".
  • slot-retry-count به تعداد تلاشهای مجدد برای بوت کردن شکاف داده شده باقی مانده است.

برای مشاهده تمام متغیرها، اجرا fastboot getvar all .

تولید بسته های OTA

ابزار بسته OTA دنبال دستورات همان دستورات برای دستگاه های غیر A / B. target_files.zip فایل باید با تعریف متغیر ساخت برای هدف A / B تولید می شود. ابزارهای بسته OTA به طور خودکار بسته هایی را در قالب برای به روزرسانی A/B شناسایی و تولید می کند.

مثال ها:

  • برای تولید یک کامل OTA:
    ./build/make/tools/releasetools/ota_from_target_files \
        dist_output/tardis-target_files.zip \
        ota_update.zip
    
  • برای تولید یک افزایشی OTA:
    ./build/make/tools/releasetools/ota_from_target_files \
        -i PREVIOUS-tardis-target_files.zip \
        dist_output/tardis-target_files.zip \
        incremental_ota_update.zip
    

پیکربندی پارتیشن ها

update_engine می توانید هر جفت از پارتیشن های A / B تعریف شده در دیسک همان به روز رسانی. یک جفت از پارتیشن دارای یک پیشوند مشترک (مانند system و یا boot ) و در هر اسلات پسوند (مانند _a ). لیست پارتیشن ها که ژنراتور محموله را تعریف می کند به روز رسانی توسط پیکربندی AB_OTA_PARTITIONS را متغیر است.

برای مثال، اگر یک جفت از پارتیشن bootloader_a و booloader_b شامل می شوند ( _a و _b پسوند های حافظه می باشد)، شما می توانید این پارتیشن با مشخص کردن زیر بر روی محصول و یا هیئت مدیره پیکربندی به روز رسانی:

AB_OTA_PARTITIONS := \
  boot \
  system \
  bootloader

همه پارتیشن به روز شده توسط update_engine باید توسط بقیه سیستم اصلاح شده است. در به روز رسانی افزایشی یا دلتا، داده های باینری از شکاف فعلی مورد استفاده برای تولید داده ها در حافظه جدید. هرگونه تغییری ممکن است باعث شود داده های شکاف جدید در حین فرایند به روزرسانی تأیید نشوند و بنابراین به روزرسانی ناموفق باشد.

پیکربندی پس از نصب

می توانید مرحله پس از نصب را برای هر پارتیشن به روز شده با استفاده از مجموعه ای از جفت های کلید-مقدار متفاوت پیکربندی کنید. برای اجرای یک برنامه در واقع /system/usr/bin/postinst در یک تصویر جدید، تعیین مسیر نسبت به ریشه از سیستم فایل در پارتیشن سیستم.

به عنوان مثال، usr/bin/postinst است system/usr/bin/postinst (اگر با استفاده از یک دیسک RAM). علاوه بر این، تعیین نوع فایل سیستم برای تصویب به mount(2) سیستم تماس بگیرید. اضافه کردن زیر به کالا و یا دستگاه .mk فایل (در صورت وجود):

AB_OTA_POSTINSTALL_CONFIG += \
  RUN_POSTINSTALL_system=true \
  POSTINSTALL_PATH_system=usr/bin/postinst \
  FILESYSTEM_TYPE_system=ext4

تدوین

به دلایل امنیتی، system_server می توانید استفاده کنید فقط در زمان (JIT) تلفیقی. این یعنی شما باید پیش از فایل های زمان های odex برای کامپایل system_server و وابستگی های آن در حداقل. هر چیز دیگری اختیاری است

برای کامپایل برنامه ها در پس زمینه ، باید موارد زیر را به پیکربندی دستگاه محصول (در device.mk محصول) اضافه کنید:

  1. برای اطمینان از اینکه اسکریپت کامپایل و باینری ها کامپایل شده و در تصویر سیستم گنجانده شده اند ، اجزای اصلی را در بیلد قرار دهید.
      # A/B OTA dexopt package
      PRODUCT_PACKAGES += otapreopt_script
    
  2. اتصال اسکریپت تلفیقی به update_engine به طوری که اجرا می شود به عنوان یک پس از نصب گام.
      # A/B OTA dexopt update_engine hookup
      AB_OTA_POSTINSTALL_CONFIG += \
        RUN_POSTINSTALL_system=true \
        POSTINSTALL_PATH_system=system/bin/otapreopt_script \
        FILESYSTEM_TYPE_system=ext4 \
        POSTINSTALL_OPTIONAL_system=true
    

برای کمک نصب فایل های preopted در استفاده نشده پارتیشن سیستم دوم، برای اشاره نخست نصب و راه اندازی بوت از فایل های DEX_PREOPT .