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 de sistema A/B ou atualizações de sistema não A/B . A ferramenta usa o arquivo target-files.zip
produzido pelo sistema de compilação do Android como entrada.
Para dispositivos com Android 11 ou superior, você pode criar um pacote OTA para vários dispositivos com diferentes SKUs. Fazer isso requer 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 preteriu os pacotes OTA baseados em arquivo para dispositivos não A/B, que devem usar pacotes OTA baseados em bloco . Para gerar pacotes ou dispositivos OTA baseados em blocos que executam o Android 7.x ou inferior, passe a opção --block
para o parâmetro ota_from_target_files
.
Construindo 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 pode instalar a compilação independentemente do estado atual do dispositivo. Por exemplo, os comandos a seguir usam ferramentas de lançamento para construir o arquivo target-files.zip
para o dispositivo tardis
.
. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output
make dist
constrói 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
. Você também pode construir o ota_from_target_files
como um binário python e chamá-lo para construir 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/
.
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ário, gere e use suas próprias chaves privadas conforme detalhado em Assinando compilações para lançamento .
Como criar atualizações incrementais
Uma atualização incremental é um pacote OTA que contém patches binários para dados já existentes no dispositivo. Os pacotes com atualizações incrementais geralmente são menores, pois não precisam incluir arquivos inalterados. Além disso, como os arquivos alterados geralmente são muito semelhantes às versões anteriores, o pacote precisa apenas incluir uma codificação das diferenças entre os dois arquivos.
Você pode instalar um pacote de atualização incremental somente em dispositivos que tenham a compilação de origem usada na construção do pacote. Para construir uma atualização incremental, você precisa do arquivo target_files.zip
da compilação anterior (aquele que você deseja atualizar), bem como do arquivo target_files.zip
da nova compilação. 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
Esta compilação é muito semelhante à compilação anterior, e o pacote de atualização incremental ( incremental_ota_update.zip
) é muito menor 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 a mesma compilação anterior usada como ponto de partida do pacote incremental. Você deve fazer o flash das imagens em PREVIOUS-tardis-target_files.zip
ou PREVIOUS-tardis-img.zip
(ambos construídos com make dist
, para serem flashados com fastboot update
), em vez daqueles sob o diretório PRODUCT_OUT
(construído com make
, que será exibido com fastboot flashall
). A tentativa de instalar o pacote incremental em um dispositivo com alguma outra compilação 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 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 3 a 4 atualizações incrementais. Isso ajuda os usuários a acompanhar a versão mais recente e evitar uma longa sequência de instalação de atualizações incrementais.
Criando pacotes OTA para vários SKUs
O Android 11 ou superior é compatível com o uso de um único pacote OTA para vários dispositivos com diferentes SKUs. Fazer isso requer 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 um SKU é uma variação de valores de parâmetros de compilação combinados e normalmente é um subconjunto não declarado dos parâmetros build_fingerprint
atuais. Os OEMs podem usar qualquer combinação de parâmetros de compilação aprovados pelo CDD para um SKU e, ao mesmo tempo, usar uma única imagem para esses SKUs. Por exemplo, o 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 do país ou idioma (como JPN, ENG ou CHN)
Muitos OEMs usam uma única imagem para vários SKUs e, em seguida, 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 processo de desenvolvimento da plataforma, permitindo que dispositivos com pequenas personalizações, mas com nomes de produtos diferentes, compartilhem imagens comuns (como tardis
e tardispro
).
Usando impressões digitais dinâmicas
Uma impressão digital é uma concatenação definida de parâmetros de construção 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 obter o valor das variáveis do carregador de inicialização no momento da inicialização do dispositivo e, em seguida, use esses dados para criar uma impressão digital dinâmica para esse dispositivo.
Por exemplo, para usar impressões digitais dinâmicas para dispositivos tardis
e tardispro
, atualize os seguintes arquivos conforme mostrado abaixo.
Atualize o arquivo
odm/etc/build_std.prop
para conter a seguinte linha.ro.odm.product.device=tardis
Atualize o arquivo
odm/etc/build_pro.prop
para conter 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 os valores de nome do dispositivo, impressão digital e ro.build.fingerprint
com base no valor da propriedade do carregador de inicialização ro.boot.product.hardware.sku
(que é somente leitura).
Atualizando 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 deve ter antes que o pacote OTA possa ser instalado. Os valores post-build-incremental
e post-build
definem o estado que se espera que um dispositivo tenha após a instalação do pacote OTA. Os valores dos campos pre-
e post-
são derivados das seguintes propriedades de construção correspondentes.
- O valor
pre-device
é derivado da propriedade de construçãoro.product.device
. - Os valores
pre-build-incremental
epost-build-incremental
são derivados da propriedade de compilaçãoro.build.version.incremental
. - Os valores
pre-build
epost-build
são derivados da propriedade de compilaçãoro.build.fingerprint
.
Em dispositivos que executam o Android 11 ou superior, você pode usar o sinalizador --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 então usados para atualizar os metadados OTA para incluir o nome do dispositivo e a impressão digital nas pre-
e post-
condições (usando a barra vertical | como delimitador). O sinalizador --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 impressões digitais de tempo de execução possíveis quando algumas propriedadesro.product.*
são substituídas pela instrução de importação. O arquivo espera uma propriedade por linha onde 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 que executam o Android 10, consulte a implementação de referência . Essa lista de alterações analisa condicionalmente as instruções de import
no arquivo build.prop
, o que permite que as substituições de propriedade sejam reconhecidas e refletidas nos metadados OTA finais.