Criar pacotes OTA

Você pode usar a ferramenta ota_from_target_files fornecida em build/make/tools/releasetools para criar pacotes OTA completos e incrementais para dispositivos que usam atualizações do sistema A/B ou atualizações do sistema não A/B. A ferramenta usa como entrada o arquivo target-files.zip produzido pelo sistema de build do Android.

Para dispositivos com Android 11 ou versões mais recentes, é possível criar um pacote OTA para vários dispositivos com SKUs diferentes. Para isso, é necessário configurar os dispositivos de destino para usar impressões digitais dinâmicas e atualizar os metadados OTA para incluir o nome e a impressão digital do dispositivo nas entradas de pré e pós-condição.

O Android 8.0 descontinuou os pacotes OTA baseados em arquivos para dispositivos não A/B, que precisam usar pacotes OTA baseados em blocos. Para gerar pacotes OTA baseados em blocos ou dispositivos com Android 7.x ou versões anteriores, transmita a opção --block ao parâmetro ota_from_target_files.

Criar atualizações completas

Uma atualização completa é um pacote OTA que contém todo o estado final do dispositivo (partições de sistema, inicialização e recuperação). Desde que o dispositivo seja capaz de receber e aplicar o pacote, ele poderá instalar o build independente do estado atual. Por exemplo, os comandos a seguir usam ferramentas de lançamento para criar o arquivo target-files.zip para o dispositivo tardis.

. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output

O make dist cria um pacote OTA completo (em $OUT). O arquivo .zip resultante contém tudo o que é necessário para construir pacotes OTA para o dispositivo tardis. Também é possível criar o ota_from_target_files como um binário Python e chamá-lo para criar pacotes completos ou incrementais.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

O caminho ota_from_target_files é configurado em $PATH, e o binário python resultante está localizado no diretório out/.

O ota_update.zip está pronto para ser enviado a dispositivos de teste. Tudo está assinado com a chave de teste. Para dispositivos do usuário, gere e use suas próprias chaves privadas, conforme detalhado em Assinar builds para lançamento.

Criar atualizações incrementais

Uma atualização incremental é um pacote OTA que contém patches binários para dados já presentes no dispositivo. Pacotes com atualizações incrementais geralmente são menores, já que não precisam incluir arquivos inalterados. Além disso, como os arquivos alterados geralmente são muito semelhantes às versões anteriores, o pacote só precisa incluir uma codificação das diferenças entre os dois arquivos.

Só é possível instalar um pacote de atualização incremental em dispositivos que têm o build de origem usado na construção do pacote. Para criar uma atualização incremental, você precisa do arquivo target_files.zip do build anterior (aquele que você quer atualizar de) e do arquivo target_files.zip do novo build. Por exemplo, os comandos a seguir usam ferramentas de lançamento para criar uma atualização incremental para o dispositivo tardis.

ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

Esse build é muito semelhante ao anterior, e o pacote de atualização incremental (incremental_ota_update.zip) é muito menor do que a atualização completa correspondente (cerca de 1 MB em vez de 60 MB).

Distribua um pacote incremental apenas para dispositivos que executam exatamente o mesmo build anterior usado como ponto de partida do pacote incremental. Você precisa atualizar as imagens em PREVIOUS-tardis-target_files.zip ou PREVIOUS-tardis-img.zip (ambas criadas com make dist, para serem atualizadas com fastboot update), em vez das que estão no diretório PRODUCT_OUT (criadas com make, que serão atualizadas com fastboot flashall). Tentar instalar o pacote incremental em um dispositivo com outra build resulta em um erro de instalação. Quando a instalação falha, o dispositivo permanece no mesmo estado de funcionamento (executando o sistema antigo). O pacote verifica o estado anterior de todos os arquivos que ele atualiza antes de tocar neles, para que o dispositivo não fique em um estado parcialmente atualizado.

Para oferecer a melhor experiência aos usuários, faça uma atualização completa a cada 3 ou 4 atualizações incrementais. Isso ajuda os usuários a acompanhar a versão mais recente e evita uma longa sequência de instalação de atualizações incrementais.

Criar pacotes OTA para várias SKUs

O Android 11 ou versões mais recentes são compatíveis com o uso de um único pacote OTA para vários dispositivos com SKUs diferentes. Para isso, é necessário configurar os dispositivos de destino para usar impressões digitais dinâmicas e atualizar os metadados OTA (usando ferramentas OTA) para incluir o nome do dispositivo e a impressão digital nas entradas de pré e pós condição.

Sobre as SKUs

O formato de um SKU é uma variação de valores combinados de parâmetro de build e geralmente é um subconjunto não declarado dos parâmetros build_fingerprint atuais. Os OEMs podem usar qualquer combinação de parâmetros de build aprovados pelo CDD para uma SKU e usar uma única imagem para essas SKUs. Por exemplo, a SKU a seguir tem várias variações:

SKU = <product><device><modifierA><modifierB><modifierC>

• modifierA é o nível do dispositivo (como Pro, Premium ou Plus)
• modifierB é a variação de hardware (como rádio)
• modifierC é a região, que pode ser geral (como NA, EMEA ou CHN) ou específica de país ou idioma (como JPN, ENG ou CHN).

Muitos OEMs usam uma única imagem para vários SKUs e derivam o nome do produto final e a impressão digital do dispositivo no tempo de execução após a inicialização do dispositivo. Esse processo simplifica o desenvolvimento da plataforma, permitindo que dispositivos com pequenas personalizações, mas nomes de produtos diferentes, compartilhem imagens comuns (como tardis e tardispro).

Usar impressões digitais dinâmicas

Uma impressão digital é uma concatenação definida de parâmetros de build, como ro.product.brand, ro.product.name e ro.product.device. A impressão digital de um dispositivo é derivada da impressão digital da partição do sistema e usada como um identificador exclusivo das imagens (e bytes) em execução no dispositivo. Para criar uma impressão digital dinâmica, use a lógica dinâmica no arquivo build.prop do dispositivo para receber o valor das variáveis do carregador de inicialização no momento da inicialização do dispositivo e use esses dados para criar uma impressão digital dinâmica para ele.

Por exemplo, para usar impressões digitais dinâmicas em dispositivos tardis e tardispro, atualize os arquivos a seguir conforme mostrado abaixo.

• Atualize o arquivo odm/etc/build_std.prop para incluir a seguinte linha:

  ro.odm.product.device=tardis
  

• Atualize o arquivo odm/etc/build_pro.prop para incluir a seguinte linha:

  ro.odm.product.device=tardispro
  

• Atualize o arquivo odm/etc/build.prop para conter as seguintes linhas.

  ro.odm.product.device=tardis
  import /odm/etc/build_${ro.boot.product.hardware.sku}.prop
  

Essas linhas definem dinamicamente o nome, a impressão digital e os valores de ro.build.fingerprint do dispositivo com base no valor da propriedade ro.boot.product.hardware.sku do carregador de inicialização (somente leitura).

Atualizar metadados do pacote OTA

Um pacote OTA contém um arquivo de metadados (META-INF/com/android/metadata) que descreve o pacote, incluindo a pré-condição e a pós-condição do pacote OTA. Por exemplo, o código a seguir é o arquivo de metadados de um pacote OTA destinado ao dispositivo tardis.

post-build=google/tardis/tardis:11/RP1A.200521.001/6516341:userdebug/dev-keys
post-build-incremental=6516341
post-sdk-level=30
post-security-patch-level=2020-07-05
post-timestamp=1590026334
pre-build=google/tardis/tardis:11/RP1A.200519.002.A1/6515794:userdebug/dev-keys
pre-build-incremental=6515794
pre-device=tardis

Os valores pre-device, pre-build-incremental e pre-build definem o estado que um dispositivo precisa ter antes da instalação do pacote OTA. Os valores post-build-incremental e post-build definem o estado esperado de um dispositivo após a instalação do pacote OTA. Os valores dos campos pre- e post- são derivados das seguintes propriedades de build correspondentes.

• O valor pre-device é derivado da propriedade de build ro.product.device.
• Os valores pre-build-incremental e post-build-incremental são derivados da propriedade de build ro.build.version.incremental.
• Os valores pre-build e post-build são derivados da propriedade de build ro.build.fingerprint.

Em dispositivos com Android 11 ou mais recente, use a flag --boot_variable_file nas ferramentas OTA para especificar um caminho para um arquivo que contém os valores das variáveis de tempo de execução usadas na criação da impressão digital dinâmica do dispositivo. Os dados são usados para atualizar os metadados OTA e incluir o nome e a impressão digital do dispositivo nas condições pre- e post- (usando o caractere de barra vertical | como delimitador). A flag --boot_variable_file tem a seguinte sintaxe e descrição.

• Sintaxe: --boot_variable_file <path>
• Descrição: especifica um caminho para um arquivo que contém os valores possíveis das propriedades ro.boot.*. Usado para calcular as possíveis impressões digitais de tempo de execução quando algumas propriedades ro.product.* são substituídas pela instrução de importação. O arquivo espera uma propriedade por linha, em que cada linha tem o seguinte formato: prop_name=value1,value2.

Por exemplo, quando a propriedade é ro.boot.product.hardware.sku=std,pro, os metadados de OTA para dispositivos tardis e tardispro são mostrados abaixo.

post-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-device=tardis|tardispro

Para oferecer suporte a essa funcionalidade em dispositivos com o Android 10, consulte a implementação de referência. Essa lista de mudanças analisa condicionalmente as instruções import no arquivo build.prop, o que permite que as substituições de propriedades sejam reconhecidas e refletidas nos metadados finais da OTA.