O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Construindo Pacotes OTA

Você pode usar o ota_from_target_files ferramenta fornecida no build/make/tools/releasetools para construir pacotes OTA completos e incrementais para dispositivos que utilizam as actualizações do sistema A / B ou atualizações do sistema não-A / B . A ferramenta leva o target-files.zip arquivo produzido pelo sistema de compilação Android como entrada.

Para dispositivos com Android 11 ou superior, você pode construir um pacote OTA para vários dispositivos com SKUs diferentes. Ao fazê-lo, é necessário configurar os dispositivos de destino para usar impressões digitais dinâmicos e actualizar os metadados OTA para incluir o nome do dispositivo de impressão digital e nas entradas pré e pós-condição.

Android 8.0 obsoleto pacotes OTA baseados em arquivos para dispositivos não-A / B, que deverá usar pacotes OTA baseados em blocos . Para gerar pacotes ou dispositivos OTA baseados em blocos que executam 7.x Android ou diminuir, passar o --block opção para o ota_from_target_files parâmetro.

Criação de atualizações completas

A atualização completa é um pacote OTA que contém todo o estado final do dispositivo (sistema de inicialização e partições de 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 seguintes comandos usar ferramentas de liberação para construir o target-files.zip arquivo para o tardis dispositivo.

. 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 ). A resultante .zip arquivo contém tudo o necessário para construir pacotes de OTA para o tardis dispositivo. Você também pode construir as ota_from_target_files como um binário python e chamá-lo para construir tanto pacotes completos ou incrementais.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

O ota_from_target_files caminho está definido em $PATH , eo binário python resultando está localizado no out/ diretório.

ota_update.zip está agora pronto para ser enviado para dispositivos de teste (tudo é assinado com a chave de teste). Para os dispositivos do usuário, gerar e utilizar suas próprias chaves privadas conforme detalhado na assinatura constrói para a liberação .

Criação de atualizações incrementais

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

Você pode instalar um pacote de atualização incremental apenas em dispositivos que tenham a compilação de origem usada na construção do pacote. Para construir uma atualização incremental, é necessário o target_files.zip arquivo a partir da compilação anterior (aquela que você deseja atualizar), bem como a target_files.zip arquivo a partir da construção de novos. Por exemplo, os seguintes comandos usar ferramentas de liberação para construir uma atualização incremental para o tardis dispositivo.

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

Esta construção é muito semelhante à construção anterior, e o pacote de actualização incremental ( incremental_ota_update.zip ) é muito menor do que o correspondente actualização completa (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ê deve piscar as imagens em PREVIOUS-tardis-target_files.zip ou PREVIOUS-tardis-img.zip (ambos construídos com make dist , a ser brilhou com fastboot update ), em vez dos sob o PRODUCT_OUT diretório (construído com make , que piscará com fastboot flashall ). A tentativa de instalar o pacote incremental em um dispositivo com alguma outra construçã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 que ele atualiza antes de tocá-los, para que o dispositivo não fique preso em um estado parcialmente atualizado.

Para a melhor experiência do usuário, ofereça uma atualização completa para cada 3–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.

Criação de pacotes OTA para vários SKUs

O Android 11 ou superior oferece suporte ao uso de um único pacote OTA para vários dispositivos com SKUs diferentes. Para fazer isso, é necessário configurar os dispositivos alvo 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 combinados de parâmetros de construção valores e é tipicamente um subconjunto não declarado dos actuais build_fingerprint parâmetros. Os OEMs podem usar qualquer combinação de parâmetros de construção aprovados pelo CDD para um SKU, ao mesmo tempo que usam uma única imagem para esses SKUs. Por exemplo, o seguinte SKU tem várias variações:

SKU = <product><device><modifierA><modifierB><modifierC>
  • modifierA é o nível de dispositivo (tais como Pro, premium, ou Plus)
  • modifierB é a variação de hardware (como rádio)
  • modifierC é a região, que podem ser gerais (tais como Na, EMEA, ou CHN) ou específico de idioma país ou (tais 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. Este processo simplifica o processo de desenvolvimento da plataforma, permitindo que dispositivos com personalizações menores, mas diferentes nomes de produtos para compartilhar imagens comuns (como tardis e tardispro ).

Usando impressões digitais dinâmicas

Uma impressão digital é uma concatenação definido de parâmetros de construção , tais 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, a lógica utilização dinâmica do dispositivo build.prop arquivo para obter o valor das variáveis bootloader no momento da inicialização do dispositivo, em seguida, usar esses dados para criar uma impressão digital dinâmico para esse dispositivo.

Por exemplo, para usar impressões digitais dinâmicos para tardis e tardispro dispositivos, atualizar os seguintes arquivos como mostrado abaixo.

  • Atualizar o odm/etc/build_std.prop arquivo para conter a seguinte linha.

    ro.odm.product.device=tardis
    
  • Atualizar o odm/etc/build_pro.prop arquivo para conter a seguinte linha.

    ro.odm.product.device=tardispro
    
  • Atualizar o odm/etc/build.prop arquivo para conter as seguintes linhas.

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

Estas linhas definir dinamicamente o nome do dispositivo, impressão digital, e ro.build.fingerprint valores com base no valor do ro.boot.product.hardware.sku propriedade bootloader (que é somente leitura).

Atualizando metadados do pacote OTA

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

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

O pre-device , pre-build-incremental , e pre-build valores definir o estado de um dispositivo deve ter antes de o pacote OTA pode instalar. Os post-build-incremental e post-build valores definir o estado de um dispositivo deverá ter após as instalações do pacote OTA. Os valores de pre- e post- campos são derivadas a partir das propriedades de construção seguinte correspondentes.

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

Em dispositivos que executam o Android 11 ou superior, você pode usar o --boot_variable_file bandeira em ferramentas de OTA para especificar um caminho para um arquivo que contém os valores das variáveis de tempo de execução utilizados na criação de impressões digitais dinâmica do dispositivo. Os dados são então usados para atualizar os metadados OTA para incluir o nome do dispositivo e impressão digital nos pre- e post- condições (usando o caractere pipe | como delimitador). O --boot_variable_file bandeira 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 de ro.boot.* Propriedades. Usado para calcular as possíveis impressões digitais tempo de execução quando alguns ro.product.* Propriedades são substituídas pela declaraçã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 tardis e tardispro dispositivos é como mostrado 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 suportar essa funcionalidade em dispositivos que executam o Android 10, ver a implementação de referência . Este changelist analisa condicionalmente as import declarações no build.prop arquivo, que permite substituições de propriedades a ser reconhecida e refletida nos metadados OTA final.