Правильный размер super важен для возможности обновления устройства. Размер напрямую влияет на количество обновлений, которые может принять устройство, и на количество пользователей, которые смогут успешно установить эти обновления.
Необходимо учитывать несколько важных переменных. Первая — это заводской размер , то есть размер всех динамических разделов на момент первой прошивки устройства. Вторая — это темп роста , то есть процентное увеличение размера операционной системы за весь период обновления устройства.
Кроме того, виртуальные устройства A/B могут использовать пространство в каталоге /data во время обновления, и это необходимо учитывать при определении размера super . Если на /data требуется слишком много места, то некоторые пользователи не смогут (или не захотят) выполнить обновление. Однако, если известно, что у большинства пользователей есть определенный процент свободного места, то устройства могут спокойно вычесть это пространство из super . Или же устройства могут гарантировать, что /data никогда не понадобится, просто увеличив размер super до достаточного значения.
Ниже представлены некоторые модели, которые помогут определить оптимальный размер super с учетом этих переменных.
Полагайтесь на /data
Виртуальный A/B-тестирование способствует уменьшению размера super , чтобы увеличить размер раздела /data . Часть этого пространства необходима при обновлении. Чтобы понять влияние на возможность обновления, важно знать, какой процент устройств, вероятно, будет иметь этот объем свободного места с течением времени. Определение этого числа в значительной степени зависит от аппаратного обеспечения устройства и поведения пользователей на этом устройстве. В приведенных ниже примерах это число обозначается как AllowedUserdataUse .
Без сжатия
Без сжатия для полного обновления по воздуху (OTA) требуется снимок примерно такого же размера, как и операционная система, поэтому это необходимо учитывать при определении размера super :
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)
Например, рассмотрим виртуальное устройство A/B с заводским размером 4 ГБ, ожидаемым ростом на 50% и информацией о том, что почти у всех пользователей есть 1 ГБ свободного места (или они готовы освободить до 1 ГБ места для обновления). Для этого устройства размер super может быть следующим:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)
Таким образом, это устройство должно иметь super объемом 11 ГБ.
Сжатие
При использовании сжатия для полной OTA-обновления требуется снимок, составляющий примерно 70% от размера операционной системы:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)
Например, рассмотрим устройство, настроенное с использованием виртуального A/B-сжатия, с заводским размером 4 ГБ, ожидаемым увеличением на 50% и информацией о том, что почти у всех пользователей есть 1 ГБ свободного места (или они готовы освободить до 1 ГБ места для обновления). Для этого устройства размер super может быть определен следующим образом:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB Super = Max(6GB, 6GB + 4.2GB - 1GB) = Max(6GB, 9.2GB) = 9.2GB
Таким образом, на этом устройстве должен быть super размером 9,2 ГБ.
Без использования /data
Если вы хотите, чтобы OTA-обновления никогда не требовали места для снимков в /data , то задать размер super очень просто.
Без сжатия
Для виртуального A/B-устройства без сжатия или для обычного A/B-устройства:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = FinalDessertSize * 2
Например, рассмотрим виртуальное устройство A/B с заводским объемом 4 ГБ и ожидаемым увеличением на 50%. Чтобы гарантировать, что это устройство никогда не будет использовать /data для OTA-снимков, расчет будет выглядеть следующим образом:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = FinalDessertSize * 2 = 12GB
Таким образом, это устройство должно иметь super объемом 12 ГБ.
Сжатие
Для виртуального устройства A/B с компрессией:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = FinalDessertSize + FinalOTASnapshotSize
Например, рассмотрим виртуальное устройство сжатия A/B с заводским размером 4 ГБ и ожидаемым увеличением на 50%. Чтобы гарантировать, что это устройство никогда не будет использовать /data для OTA-снимков, его расчет будет выглядеть следующим образом:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB Super = 6GB + 4.2GB = 10.2GB
Таким образом, на этом устройстве должен быть super размером 10,2 ГБ.
Предостережения
Может показаться заманчивым заметить, что если размер заводского раздела составляет 4 ГБ, а размер финального обновления — 5 ГБ, то для super потребуется 9 ГБ, а не 10 ГБ. Однако, если и первое, и финальное обновление занимают по 5 ГБ, то места в super может оказаться недостаточно для финального обновления. Приведенные выше формулы предполагают, что увеличение размера раздела может произойти в любой момент. Объем пространства, необходимого для применения финального обновления, может быть таким же, как и для применения первого обновления.
Обратите внимание, что коэффициенты сжатия являются приблизительными. Образ операционной системы может сжиматься лучше или хуже в зависимости от его содержимого. При использовании сжатой файловой системы, такой как EROFS, дополнительное сжатие от Virtual A/B имеет убывающую отдачу. В этом случае лучше использовать одну из формул для несжатого образа в качестве ориентира.
Рассчитайте размер
Чтобы найти значение FactorySize в приведенных выше примерах, сложите размеры всех динамических разделов. Образы динамических разделов AOSP:
-
system.img -
vendor.img -
product.img -
system_ext.img -
vendor_dlkm.img -
system_dlkm.img
Обязательно рассчитывайте размер на основе неразреженных изображений. При сборке Android 12 или более ранних версий изображения по умолчанию разрежены, но их можно разрежить с помощью simg2img .
Также можно рассчитать размеры разделов из OTA-пакета. При этом также оценивается размер виртуального A/B-снимка для каждого раздела:
python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip
Или же вы можете использовать инструмент анализа OTA-обновлений . Этот инструмент не загружает никаких файлов и анализирует OTA-пакеты локально.
Чтобы найти значение ExpectedGrowth , используйте ранее выпущенное устройство. Для расчета роста используйте самый ранний и самый последний super образ.