Dimensionar a super corretamente é importante para a capacidade de atualização do dispositivo. O tamanho afeta diretamente quantas atualizações um dispositivo pode receber e quantos usuários podem obter essas atualizações com êxito.
Existem algumas variáveis importantes a serem consideradas. O primeiro é o tamanho de fábrica , que é o tamanho de todas as partições dinâmicas quando o dispositivo é atualizado pela primeira vez. A segunda é a taxa de crescimento , que é a porcentagem que o tamanho do sistema operacional aumenta durante toda a vida útil atualizável do dispositivo.
Além disso, os dispositivos A/B virtuais podem usar espaço em /data durante uma atualização, e isso deve ser considerado ao dimensionar super . Se for necessário muito espaço em /data , alguns usuários não podem (ou não querem) fazer a atualização. No entanto, se for conhecido que a maioria dos usuários tem alguma porcentagem de espaço livre, os dispositivos podem subtrair confortavelmente esse espaço de super . Ou, os dispositivos podem garantir que /data nunca seja necessário, simplesmente tornando super grande o suficiente.
Abaixo estão alguns modelos para ajudar a orientar o dimensionamento da super com base nessas variáveis.
Confiando em /dados
O A/B virtual incentiva o super para permitir o aumento do tamanho de /data . Parte desse espaço é necessário durante uma atualização. Para entender o impacto na capacidade de atualização, é essencial saber qual porcentagem de dispositivos provavelmente terá essa quantidade de espaço livre ao longo do tempo. Descobrir esse número depende muito do hardware do dispositivo e do comportamento dos usuários desse dispositivo. Nos exemplos abaixo, esse número é referido como AllowedUserdataUse .
Sem compressão
Sem compactação, um OTA completo precisa de um snapshot aproximadamente do mesmo tamanho do SO, portanto, isso deve ser levado em consideração ao dimensionar super :
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)
Por exemplo, considere um dispositivo A/B virtual com tamanho de fábrica de 4 GB, crescimento esperado de 50% e conhecimento de que quase todos os usuários têm 1 GB livre (ou estão dispostos a liberar até 1 GB de espaço para uma atualização) . Para este dispositivo, super pode ser dimensionado assim:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)
Assim, este dispositivo deve ter uma super partição de 11 GB.
Com compressão
Com compactação, um OTA completo precisa de um instantâneo de aproximadamente 70% do tamanho do sistema operacional:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)
Por exemplo, considere um dispositivo configurado com compactação A/B Virtual, com tamanho de fábrica de 4 GB, crescimento esperado de 50% e conhecimento de que quase todos os usuários têm 1 GB livre (ou estão dispostos a liberar até 1 GB de espaço para uma atualização). Para este dispositivo, super pode ser dimensionado assim:
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
Assim, este dispositivo deve ter uma super partição de 9,2 GB.
Sem depender de /data
Se você deseja ter OTAs que nunca exijam espaço de instantâneo em /data , o dimensionamento super é simples.
Sem compressão
Para um dispositivo A/B virtual sem compactação ou um dispositivo A/B normal:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = FinalDessertSize * 2
Por exemplo, considere um dispositivo A/B virtual com tamanho de fábrica de 4 GB e crescimento esperado de 50%. Para garantir que este dispositivo nunca use /data para instantâneos OTA, seu cálculo ficaria assim:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = FinalDessertSize * 2 = 12GB
Assim, este dispositivo deve ter uma super partição de 12 GB.
Com compressão
Para um dispositivo A/B virtual com compactação:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = FinalDessertSize + FinalOTASnapshotSize
Por exemplo, considere um dispositivo de compactação A/B virtual com tamanho de fábrica de 4 GB e crescimento esperado de 50%. Para garantir que este dispositivo nunca use /data para instantâneos OTA, seu cálculo ficaria assim:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB Super = 6GB + 4.2GB = 10.2GB
Assim, este dispositivo deve ter uma super de 10,2 GB.
Ressalvas
Pode ser tentador observar que, se o tamanho de fábrica for de 4 GB e a atualização final for de 5 GB, o super precisa ser de 9 GB, em vez de 10 GB. No entanto, se a primeira atualização e a atualização final forem de 5 GB, o espaço em super poderá ser insuficiente para a atualização final. As fórmulas acima assumem que o crescimento da partição pode ocorrer a qualquer momento. O espaço necessário para aplicar a atualização final pode ser o mesmo necessário para aplicar a primeira atualização.
Observe que as taxas de compressão são uma estimativa. Uma imagem do sistema operacional pode ser compactada melhor ou pior dependendo de seu conteúdo. Se estiver usando um sistema de arquivos compactado, como EROFS, a compactação adicional do Virtual A/B terá retornos decrescentes. Nesse caso, é melhor usar uma das fórmulas não compactadas como diretriz.
Medindo
Para encontrar o valor de FinalDessertSize nos exemplos acima, adicione os tamanhos de todas as partições dinâmicas. As imagens de partição dinâmica AOSP são:
-
system.img -
vendor.img -
product.img -
system_ext.img -
vendor_dlkm.img -
system_dlkm.img
Certifique-se de calcular o tamanho com base em imagens não esparsas. Ao compilar o Android 12 ou inferior, as imagens são esparsas por padrão e podem ser não esparsas com simg2img .
Também é possível calcular tamanhos de partição de um pacote OTA. Fazer isso também estima o tamanho do instantâneo A/B virtual para cada partição:
python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip
Ou você pode usar a Ferramenta de Análise OTA . Esta ferramenta não carrega nenhum arquivo e analisa os pacotes OTA localmente.
Para encontrar o valor de ExpectedGrowth , use um dispositivo lançado anteriormente. Use a super mais antiga e mais recente para calcular o crescimento.