Внедрение обновлений A/B

OEM-производители и поставщики SoC, которые хотят реализовать обновления системы A/B, должны убедиться, что их загрузчик реализует HAL boot_control и передает правильные параметры ядру.

Реализуйте контроль загрузки HAL.

Загрузчики с поддержкой A/B должны реализовать HAL boot_control в hardware/libhardware/include/hardware/boot_control.h . Вы можете протестировать реализации с помощью утилиты system/extras/bootctl и system/extras/tests/bootloader/ .

Вы также должны реализовать конечный автомат, показанный ниже:

Рисунок 1. Конечный автомат загрузчика

Настройте ядро

Чтобы внедрить обновления системы A/B:

  1. Cherrypick следующую серию патчей ядра (при необходимости):
  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> — это идентификатор открытого ключа, используемого для проверки подписи таблицы достоверности (подробнее см. dm-verity ).
  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 указывает на наличие открытого ключа в системном наборе ключей (выделение означает идентификатор открытого ключа).
    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 не нужен раздел восстановления или раздел кэша, поскольку Android больше не использует эти разделы. Раздел данных теперь используется для загруженного OTA-пакета, а код образа восстановления находится в загрузочном разделе. Все разделы A/B должны иметь следующие имена (слоты всегда называются a , b и т. д.): boot_a , boot_b , system_a , system_b , vendor_a , vendor_b .

Кэш

Для обновлений, отличных от A/B, раздел кэша использовался для хранения загруженных OTA-пакетов и временного хранения блоков во время применения обновлений. Никогда не существовало хорошего способа определения размера раздела кэша: насколько он должен быть большим, зависело от того, какие обновления вы хотели применить. В худшем случае это будет раздел кэша размером с образ системы. При использовании обновлений A/B нет необходимости хранить блоки (поскольку вы всегда записываете в раздел, который в данный момент не используется), а при потоковой передаче A/B нет необходимости загружать весь пакет OTA перед его применением.

Восстановление

RAM-диск восстановления теперь содержится в файле boot.img . При входе в рекавери загрузчик не может поставить skip_initramfs в командной строке ядра.

Для обновлений, отличных от A/B, раздел восстановления содержит код, используемый для применения обновлений. Обновления A/B применяются update_engine , работающим в обычном загружаемом образе системы. По-прежнему существует режим восстановления, используемый для сброса заводских настроек и загрузки неопубликованных пакетов обновлений (отсюда и произошло название «восстановление»). Код и данные режима восстановления хранятся в обычном загрузочном разделе виртуального диска; для загрузки образа системы загрузчик сообщает ядру пропустить виртуальный диск (иначе устройство загружается в режим восстановления. Режим восстановления небольшой (и большая его часть уже была в загрузочном разделе), поэтому загрузочный раздел не увеличивается по размеру.

Фстаб

Аргумент slotselect должен находиться в строке для разделов A/B. Например:

<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 . Переопределите поведение по умолчанию и предложите fastboot перепрограммировать слот, переданный в качестве аргумента.
  • --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:<slot-suffix> . Количество оставшихся попыток загрузки данного слота.

Чтобы просмотреть все переменные, запустите 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 ). Список разделов, для которых генератор полезных данных определяет обновление, настраивается переменной make 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

Компилировать приложения

Приложения можно скомпилировать в фоновом режиме перед перезагрузкой с новым образом системы. Чтобы скомпилировать приложения в фоновом режиме, добавьте следующее в конфигурацию устройства продукта (в файле 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
    

Информацию об установке предварительно выбранных файлов в неиспользуемый второй системный раздел см. в разделе Первая загрузочная установка файлов DEX_PREOPT .