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

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

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

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

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

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

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

1. Выберите следующую серию патчей ядра (при необходимости):
   • Если вы загружаетесь без ramdisk и используете «загрузку в режиме восстановления», выберите android-review.googlesource.com/#/c/158491/ .
   • Чтобы настроить dm-verity без ramdisk, выберите android-review.googlesource.com/#/q/status:merged+project:kernel/common+branch:android-3.18+topic:A_B_Changes_3.18 .
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> — это идентификатор открытого ключа, используемого для проверки подписи таблицы verity (подробности см. в 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 не нужен раздел восстановления или раздел кэша, поскольку Android больше не использует эти разделы. Раздел данных теперь используется для загруженного пакета 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 перед его применением.

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

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

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

Фстаб

Аргумент 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 . Получить подробную информацию о командах.

Если загрузчик реализует fastboot, он должен поддерживать команду set_active <slot> , которая устанавливает текущий активный слот в указанный слот (это также должно очистить флаг незагружаемости для этого слота и сбросить счетчик повторов до значений по умолчанию). Загрузчик также должен поддерживать следующие переменные:

• has-slot:<partition-base-name-without-suffix> . Возвращает «yes», если данный раздел поддерживает слоты, «no» в противном случае.
• current-slot . Возвращает суффикс слота, который будет загружен следующим.
• slot-count . Возвращает целое число, представляющее количество доступных слотов. В настоящее время поддерживаются два слота, поэтому это значение равно 2 .
• slot-successful:<slot-suffix> . Возвращает «yes», если указанный слот был отмечен как успешно загружаемый, в противном случае — «no».
• slot-unbootable:<slot-suffix> . Возвращает «yes», если указанный слот помечен как незагружаемый, «no» в противном случае.
• 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 ). Список разделов, для которых генератор полезной нагрузки определяет обновление, настраивается переменной AB_OTA_PARTITIONS make.

Например, если включена пара разделов bootloader_a и booloader_b ( _a и _b — суффиксы слотов), вы можете обновить эти разделы, указав следующее в конфигурации продукта или платы:

AB_OTA_PARTITIONS := \
  boot \
  system \
  bootloader

Все разделы, обновленные update_engine не должны изменяться остальной частью системы. Во время инкрементальных или дельта- обновлений двоичные данные из текущего слота используются для генерации данных в новом слоте. Любое изменение может привести к тому, что данные нового слота не пройдут проверку во время процесса обновления, и, следовательно, обновление не будет выполнено.

Настроить послеустановку

Вы можете настроить шаг postinstall по-разному для каждого обновленного раздела, используя набор пар ключ-значение. Чтобы запустить программу, расположенную в /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 при первой загрузке .