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 o
arquivo target-files.zip
produzido pelo sistema de build do Android como entrada.
Para dispositivos com o 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 do dispositivo e a 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
usar pacotes OTA baseados em bloco. Para
gerar pacotes OTA baseados em blocos ou dispositivos com o Android 7.x ou versões anteriores, transmita
a opção --block
para o 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). Contanto que o dispositivo seja capaz
de receber e aplicar o pacote, o pacote poderá instalar o build,
independente do estado atual do dispositivo. Por exemplo, os comandos
abaixo usam ferramentas de lançamento para criar o arquivo target-files.zip
do
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 criar 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 binário resultante em Python está localizado no diretório out/
.
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, conforme
detalhado em Como 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, porque 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 tenham o
build de origem usado na criação do pacote. Para criar uma atualização incremental,
você precisa do arquivo target_files.zip
do build anterior (aquele do qual você quer
atualizar ), bem como o arquivo target_files.zip
do novo build. Por
exemplo, os comandos abaixo 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 somente para dispositivos que executam exatamente o mesmo
build anterior usado como ponto de partida do pacote incremental. Atualize
as imagens em PREVIOUS-tardis-target_files.zip
ou PREVIOUS-tardis-img.zip
(ambos criados com make dist
, para atualização com fastboot update
), em vez de
as que estão no diretório PRODUCT_OUT
(criado com make
, que será
atualizado com fastboot flashall
). A tentativa de instalar o pacote incremental
em um dispositivo com outra versão resulta em um erro de instalação. Quando a
instalação falha, o dispositivo permanece no mesmo estado de trabalho (executando o sistema
antigo). 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 incrementais. Isso ajuda os usuários a atualizar para a versão mais recente e evitar 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 oferecem suporte ao 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 SKUs
O formato de uma SKU é uma variação de valores combinados de parâmetros de build 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 e
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 do hardware (como rádio).modifierC
é a região, que pode ser geral (como NA, EMEA ou CHN) ou específica do país ou do idioma (como JPN, ENG ou CHN).
Muitos OEMs usam uma única imagem para várias SKUs e, em seguida, derivam o nome do produto final
e a impressão digital do dispositivo durante a execução depois que o dispositivo é inicializado. Esse processo
simplifica o processo de 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. Depois, 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 seguintes arquivos 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 os valores de ro.build.fingerprint
com base no valor da propriedade do carregador de inicialização ro.boot.product.hardware.sku
(que é 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 abaixo é o arquivo de metadados para 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 que o pacote OTA possa ser instalado. Os
valores post-build-incremental
e post-build
definem o estado que um dispositivo deve
ter após a instalação do pacote OTA. Os valores dos campos pre-
e
post-
são derivados das propriedades de build correspondentes abaixo.
- O valor
pre-device
é derivado da propriedade de buildro.product.device
. - Os valores
pre-build-incremental
epost-build-incremental
são derivados da propriedade de buildro.build.version.incremental
. - Os valores
pre-build
epost-build
são derivados da propriedade de buildro.build.fingerprint
.
Em dispositivos com o Android 11 ou versões mais recentes, é possível usar
a flag --boot_variable_file
em ferramentas OTA para especificar um caminho para um arquivo que
contenha os valores das variáveis de ambiente de execução usadas para criar a
impressão digital dinâmica do dispositivo. Em seguida, os dados são usados para atualizar os metadados 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 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 no ambiente de execução quando algumas propriedadesro.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 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.
Esta lista de mudanças analisa condicionalmente as instruções import
no arquivo build.prop
, o que permite que as substituições de propriedade sejam reconhecidas e refletidas nos
metadados OTA finais.