Criar pacotes OTA

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

Para dispositivos com o Android 11 ou mais recente, você pode criar um pacote OTA para vários dispositivos com SKUs diferentes. Isso exige configurar os dispositivos de destino para usar impressões digitais dinâmicas; e atualizando os metadados OTA para incluir o dispositivo e impressão digital nas entradas de pré e pós-condição.

O Android 8.0 suspendeu o uso de pacotes OTA baseados em arquivos para dispositivos não A/B, que precisam use pacotes OTA baseados em bloco. Para gerar pacotes OTA baseados em blocos ou dispositivos com Android 7.x ou anterior, passar 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 da dispositivo, como partições de sistema, inicialização e recuperação. Contanto que o dispositivo seja compatível de receber e aplicar o pacote, o pacote pode instalar a versão seja qual for o estado atual do dispositivo. Por exemplo, o seguinte usam ferramentas de lançamento para criar o arquivo target-files.zip dos tardis dispositivo.

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

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 está configurado em $PATH, e o Python resultante binário está localizado no diretório out/.

O ota_update.zip agora está pronto para ser enviado aos dispositivos de teste (tudo está assinado) com a chave de teste). Para dispositivos de usuários, gere e use suas próprias chaves privadas como 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 os dados que já estão no dispositivo. Os pacotes com atualizações incrementais geralmente são menores pois não precisam incluir arquivos inalterados. Além disso, à medida que os arquivos alterados são 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 com 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 (o que você quer para atualizar from), bem como o arquivo target_files.zip do novo build. Para 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 a atualização incremental (incremental_ota_update.zip) é muito menor do que o atualização completa (cerca de 1 MB em vez de 60 MB).

Distribuir um pacote incremental apenas para dispositivos que funcionam exatamente da mesma forma build anterior usado como ponto de partida do pacote incremental. Você deve atualizar as imagens em PREVIOUS-tardis-target_files.zip ou PREVIOUS-tardis-img.zip (ambos criados com make dist, para serem atualizados com fastboot update), em vez de aqueles no diretório PRODUCT_OUT (criados com make, que serão atualizado com fastboot flashall). Tentando instalar o pacote incremental em um dispositivo com outro build resulta em erro de instalação. Quando o falha na instalação, o dispositivo permanece no mesmo estado de trabalho (executando o sistema o pacote verifica o estado anterior de todos os arquivos atualizados antes de tocá-los, para que o dispositivo não fique preso em um estado meio atualizado.

Para a melhor experiência do usuário, ofereça uma atualização completa a cada três a quatro atualizações. Isso ajuda os usuários a ficarem por dentro da versão mais recente e evitar uma longa de instalação de atualizações incrementais.

Criar pacotes OTA para várias SKUs

O Android 11 ou versões mais recentes oferecem suporte ao uso de uma única atualização OTA para vários dispositivos com SKUs diferentes. Para isso, é preciso configurar que os dispositivos de destino usem impressões digitais dinâmicas e atualizem os metadados OTA (usando ferramentas OTA) para incluir o nome do dispositivo e a impressão digital nas respostas entradas de condição.

Sobre SKUs

O formato de uma SKU é uma variação do modelo combinado de parâmetros e normalmente é 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. usando uma única imagem para essas SKUs. Por exemplo, a SKU a seguir tem diversas 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íficos de países ou idiomas (como JPN, ENG ou CHN)

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

Usar impressões digitais dinâmicas

Uma impressão digital é uma concatenação definida de elementos build parâmetros como ro.product.brand, ro.product.name e ro.product.device. A impressão digital de um dispositivo é derivada da impressão digital de partição do sistema e é usada como identificador exclusivo das imagens (e bytes) em execução no dispositivo. Para criar um dinâmica, use lógica dinâmica no arquivo build.prop do dispositivo para acesse 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 o dispositivo.

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

• Atualize o arquivo odm/etc/build_std.prop para conter a linha a seguir.

  ro.odm.product.device=tardis
  

• Atualize o arquivo odm/etc/build_pro.prop para conter a linha a seguir.

  ro.odm.product.device=tardispro
  

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

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

Essas linhas definem dinamicamente o nome do dispositivo, a impressão digital e ro.build.fingerprint valores com base no valor do Propriedade do carregador de inicialização ro.boot.product.hardware.sku (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 o precondition e o postcondition do OTA . Por exemplo, o código a seguir é o arquivo de metadados de um pacote OTA segmentando o 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 estado que um dispositivo deve ter antes que o pacote OTA possa ser instalado. A Os valores post-build-incremental e post-build definem o estado em que um dispositivo se encontra. esperada após a instalação do pacote OTA. Os valores de pre- e Os campos 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 dos ro.build.fingerprint.

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

• Sintaxe: --boot_variable_file <path>
• Descrição: especifica um caminho para um arquivo que contém os valores possíveis de ro.boot.*. Usado para calcular as possíveis impressões digitais durante a 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, a Os metadados OTA para os 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 referência implementação. Esta lista de mudanças analisa condicionalmente as instruções import no build.prop , que permite que as substituições de propriedade sejam reconhecidas e refletidas no metadados OTA finais.