Android 10 поддерживает динамические разделы — систему разделения пользовательского пространства, которая может создавать, изменять размер и уничтожать разделы во время обновлений по беспроводной сети (OTA).
На этой странице описано, как клиенты OTA изменяют размеры динамических разделов во время обновления для устройств A/B, запущенных без поддержки динамических разделов, и как клиенты OTA обновляются до Android 10.
Фон
Во время обновления устройства A/B для поддержки динамических разделов таблица разделов GUID (GPT) на устройстве сохраняется, поэтому на устройстве нет super
. Метаданные хранятся в system_a
и system_b
, но их можно настроить, изменив BOARD_SUPER_PARTITION_METADATA_DEVICE
.
В каждом из блочных устройств имеется два слота метаданных. В каждом блочном устройстве используется только один слот метаданных. Например, Метаданные 0 в system_a
и Метаданные 1 в system_b
соответствуют разделам в слотах A и B соответственно. Во время выполнения не имеет значения, какой слот обновляется.
На этой странице слоты метаданных называются Метаданные S (источник) и Метаданные T (цель). Аналогичным образом разделы называются system_s
, vendor_t
и т. д.
Дополнительные сведения о конфигурациях системы сборки см. в разделе Обновление устройств .
Дополнительные сведения о том, как разделы относятся к группам обновлений , см. в разделе Изменения конфигурации платы для новых устройств.
Пример метаданных на устройстве:
- Физическое блочное устройство
system_a
- Метаданные 0
- Группа
foo_a
- Логический (динамический) раздел
system_a
- Логический (динамический) раздел
product_services_a
- Другие разделы обновлены Foo
- Логический (динамический) раздел
- Группа
bar_a
- Логический (динамический)
vendor_a
- Логический (динамический) раздел
product_a
- Другие разделы обновлены Баром
- Логический (динамический)
- Группа
- Метаданные 1 (не используются)
- Метаданные 0
- Физическое блочное устройство
system_b
- Метаданные 0 (не используются)
- Метаданные 1
- Группа foo_b
- Логический (динамический) раздел
system_b
- Логический (динамический) раздел
product_services_b
- Другие разделы обновлены Foo
- Логический (динамический) раздел
- Группа bar_b
- Логический (динамический)
vendor_b
- Логический (динамический) раздел
product_b
- Другие разделы обновлены Баром
- Логический (динамический)
- Группа foo_b
Вы можете использовать инструмент 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 не знает, как сопоставлять динамические разделы, все действия после установки автоматически отключаются для этих разделов при создании пакета обновления. Дополнительные сведения см. в разделе Настройка после установки .
Порядок обновления такой же, как и в Android 9.
До обновления:
ro.boot.dynamic_partitions= ro.boot.dynamic_partitions_retrofit=
После обновления:
ro.boot.dynamic_partitions=true ro.boot.dynamic_partitions_retrofit=true
Будущие обновления после модернизации
После дооснащения клиента OTA обновляется для работы с динамическими разделами. Экстенты исходных разделов никогда не охватывают целевые физические разделы.
Процесс обновления с использованием обычного пакета обновлений
- Инициализируйте метаданные
super
.- Создайте новые метаданные M из метаданных S (исходные метаданные). Например, если метаданные S используют [
system_s
,vendor_s
,product_s
] в качестве блочных устройств, то новые метаданные M используют [system_t
,vendor_t
,product_t
] в качестве блочных устройств. Все группы и разделы удаляются в M. - Добавьте целевые группы и разделы в соответствии с полем
dynamic_partition_metadata
в манифесте обновления. Размер каждого раздела можно найти вnew_partition_info
. - Запишите M в метаданные T.
- Сопоставьте добавленные разделы в сопоставителе устройств как доступные для записи.
- Создайте новые метаданные M из метаданных S (исходные метаданные). Например, если метаданные S используют [
- Примените обновление на блочных устройствах.
- При необходимости сопоставьте исходные разделы в сопоставителе устройств как доступные только для чтения. Это необходимо для загрузки неопубликованных файлов, поскольку исходные разделы не сопоставляются до обновления.
- Примените полное или дельта-обновление ко всем блочным устройствам в целевом слоте.
- Подключите разделы, чтобы запустить сценарий после установки, а затем отключите разделы.
- Отмените сопоставление целевых разделов.
Процесс обновления с использованием модифицированного пакета обновлений
Если пакет обновлений применяется на устройстве, которое уже поддерживает динамические разделы, клиент OTA применяет разделенный файл super.img
непосредственно на блочных устройствах. Процесс обновления аналогичен обновлению дооснащения. Подробности см. в разделе «Модернизация обновления» .
Например, предположим следующее:
- Слот A является активным слотом.
-
system_a
содержит активные метаданные в слоте 0. -
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 для модернизированных устройств обновления зависят от того, определены ли в базовой сборке PRODUCT_USE_DYNAMIC_PARTITIONS
и PRODUCT_RETROFIT_DYNAMIC_PARTITIONS
.
- Если базовая сборка не определяет переменные, это модернизирующее обновление. Пакет обновления содержит разделенный файл
super.img
и отключает этап после установки. - Если базовая сборка определяет переменные, это то же самое, что и обычное обновление с динамическими разделами. Пакет обновления содержит образы логических (динамических) разделов. Можно включить этап после установки.
Полное ОТА
Для модернизированных устройств создаются два полных пакета OTA.
-
$(PRODUCT)-ota-retrofit-$(TAG).zip
всегда содержит разделенныйsuper.img
и отключает этап после установки для дооснащения обновления.- Он генерируется с дополнительным аргументом
--retrofit_dynamic_partitions
сценарияota_from_target_files
. - Его можно применить ко всем конструкциям.
- Он генерируется с дополнительным аргументом
-
$(PRODUCT)-ota-$(TAG).zip
содержит логические образы для будущих обновлений.- Применяйте это только к сборкам с включенными динамическими разделами. Подробнее об обеспечении соблюдения этого правила см. ниже.
Отклонить обновление без модернизации в старых сборках
Применяйте обычный полный пакет OTA только к сборкам с включенными динамическими разделами. Если сервер OTA настроен неправильно и отправляет эти пакеты на устройства под управлением Android 9 или более ранней версии, устройства не загружаются. Клиент OTA на Android 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
в качестве шага после установки и отклоняет обновление.