OEMs e fornecedores de SoC que quiserem implementar atualizações do sistema A/B precisam garantir o carregador de inicialização implementa a HAL boot_control e passa os parâmetros corretos para a grão
Implementar a HAL de controle de inicialização
Os carregadores de inicialização com recursos A/B precisam implementar a HAL boot_control
em
hardware/libhardware/include/hardware/boot_control.h
. É possível testar implementações usando o
system/extras/bootctl
concessionária de serviço público e
system/extras/tests/bootloader/
.
Também é necessário implementar a máquina de estado mostrada abaixo:
Configurar o kernel
Para implementar atualizações do sistema A/B:
-
Selecione as seguintes séries de patches de kernel (se necessário):
- Ao inicializar sem o ramdisk e usar "boot asrecovery", escolha android-review.googlesource.com/#/c/158491/
- Para configurar dm-verity sem ramdisk, escolha android-review.googlesource.com/#/q/status:merged+project:kernel/common+branch:android-3.18+topic:A_B_Changes_3.18.
-
Verifique se os argumentos de linha de comando do kernel contêm os seguintes argumentos extras:
... em que o valorskip_initramfs rootwait ro init=/init root="/dev/dm-0 dm=system none ro,0 1 android-verity <public-key-id> <path-to-system-partition>"
<public-key-id>
é o ID da chave pública usada para verificar a assinatura da tabela de verdade (para mais detalhes, consulte dm-verity). -
Adicione o certificado .X509 que contém a chave pública ao keyring do sistema:
-
Copie o certificado .X509 formatado no formato
.der
para a raiz dokernel
. Se o certificado .X509 estiver formatado como um.pem
, use o seguinte comandoopenssl
para converter do Formato de.pem
a.der
:openssl x509 -in <x509-pem-certificate> -outform der -out <x509-der-certificate>
-
Crie o
zImage
para incluir o certificado como parte do keyring do sistema. Para verificar,confira a entradaprocfs
(requerKEYS_CONFIG_DEBUG_PROC_KEYS
para ativar): A inclusão bem-sucedida do certificado .X509 indica a presença da chave pública no keyring do sistema (destaque indica o ID da chave pública).angler:/# cat /proc/keys 1c8a217e I------ 1 perm 1f010000 0 0 asymmetri Android: 7e4333f9bba00adfe0ede979e28ed1920492b40f: X509.RSA 0492b40f [] 2d454e3e I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1/4
-
Substitua o espaço por
#
e transmita-o como<public-key-id>
na linha de comando do kernel. Por exemplo, transmitaAndroid:#7e4333f9bba00adfe0ede979e28ed1920492b40f
no lugar de<public-key-id>
.
-
Copie o certificado .X509 formatado no formato
Definir variáveis de build
Os carregadores de inicialização com recursos A/B precisam atender aos seguintes critérios de variáveis de build:
Precisa definir para a meta A/B |
/device/google/marlin/+/android-7.1.0_r1/device-common.mk . Você pode realizar a etapa de dex2oat pós-instalação (mas antes da reinicialização) descrita em
Compilação.
|
---|---|
Recomendado para a meta A/B |
|
Não foi possível definir para a meta A/B |
|
Opcional para builds de depuração | PRODUCT_PACKAGES_DEBUG += update_engine_client |
Definir partições (slots)
Os dispositivos A/B não precisam de uma partição de recuperação ou de cache porque o Android não usa mais
essas partições. A partição de dados agora é usada para o pacote OTA baixado, e a
o código da imagem de recuperação
está na partição de inicialização. Todas as partições A/B-ed devem ser nomeadas
da seguinte maneira (os slots sempre são chamados de a
, b
etc.): boot_a
,
boot_b
, system_a
, system_b
e vendor_a
.
vendor_b
.
Cache
Para atualizações não A/B, a partição de cache era usada para armazenar os pacotes OTA baixados e para bloquear temporariamente ao aplicar atualizações. Nunca havia uma boa maneira de dimensionar o cache partição: o tamanho precisava depender das atualizações que você queria aplicar. As piores nesse caso seria uma partição de cache do tamanho da imagem do sistema. Com as atualizações A/B, você não precisa para armazenar blocos (porque você está sempre gravando em uma partição que não é usada atualmente) e com o streaming A/B, não será necessário fazer o download do pacote OTA inteiro antes de aplicá-lo.
Recuperação
O disco RAM de recuperação agora está contido no arquivo boot.img
. Ao entrar em
de recuperação, o carregador de inicialização não pode colocar a opção skip_initramfs
a linha de comando do kernel.
Para atualizações não A/B, a partição de recuperação contém o código usado para aplicar as atualizações. A/B
as atualizações são aplicadas por update_engine
em execução na imagem inicial do sistema normal.
Ainda há um modo de recuperação usado para implementar a redefinição para configuração original e o sideload de atualização
(que é de onde veio o nome “recovery”. O código e os dados do modo de recuperação
é armazenado na partição de inicialização normal em um ramdisk; para inicializar a imagem do sistema,
o carregador de inicialização instrui o kernel a pular o ramdisk (caso contrário, o dispositivo inicializa na etapa de recuperação
modo O modo de recuperação é pequeno (e grande parte dele já estava na partição de inicialização), portanto,
partição não aumenta de tamanho.
Fstab
O argumento slotselect
precisa estar na linha do argumento A/B
partições diferentes. Exemplo:
<path-to-block-device>/vendor /vendor ext4 ro wait,verify=<path-to-block-device>/metadata,slotselect
Nenhuma partição pode ser nomeada como vendor
. Em vez disso, particione vendor_a
ou
vendor_b
será selecionado e montado no ponto de montagem /vendor
.
Argumentos de slot do kernel
O sufixo de slot atual precisa ser transmitido por um nó da árvore de dispositivos (DT) específico
(/firmware/android/slot_suffix
) ou pelo
Linha de comando do kernel androidboot.slot_suffix
ou argumento bootconfig.
Por padrão, o fastboot atualiza o slot atual em um dispositivo A/B. Se o pacote de atualização também contiver imagens para o outro slot não atual, o fastboot também atualiza essas imagens. As opções disponíveis incluem:
-
--slot SLOT
. Modifique o comportamento padrão e solicite que o fastboot atualize o slot do slot um argumento. -
--set-active [SLOT]
. Defina o slot como ativo. Se não houver argumento opcional for especificado, o espaço atual será definido como ativo. fastboot --help
: Veja detalhes sobre os comandos.
Se o carregador de inicialização implementar o fastboot, ele precisará ser compatível com o comando
set_active <slot>
que define o slot ativo atual para o slot especificado (essa
também precisará limpar a sinalização de "não inicializável" desse slot e redefinir a contagem de tentativas para o padrão
). O carregador de inicialização também precisa ser compatível com as seguintes variáveis:
-
has-slot:<partition-base-name-without-suffix>
. Retorna "yes" se o suporte a slots. Caso contrário, retorna o valor "no". current-slot
: Retorna o sufixo de slot que será inicializado a partir do próximo.-
slot-count
. Retorna um número inteiro que representa o número de slots disponíveis. Atualmente, há suporte para dois slots, então esse valor é2
. -
slot-successful:<slot-suffix>
. Retorna "yes" se o espaço fornecido foi marcado como "Inicialização bem-sucedida", "não" caso contrário. -
slot-unbootable:<slot-suffix>
. Retorna "yes" se o espaço fornecido estiver marcado como não inicializável, "não" caso contrário. -
slot-retry-count:<slot-suffix>
. Número de novas tentativas restantes para tentar inicializar o slot especificado.
Para conferir todas as variáveis, execute
fastboot getvar all
:
Gerar pacotes OTA
As ferramentas de pacotes OTA seguem os mesmos comandos das
para dispositivos não A/B. O arquivo target_files.zip
precisa ser gerado por
definindo as variáveis de build para o destino A/B. As ferramentas de pacotes OTA identificam automaticamente
e gerar pacotes no formato do atualizador A/B.
Exemplos:
-
Para gerar um OTA completo:
./build/make/tools/releasetools/ota_from_target_files \ dist_output/tardis-target_files.zip \ ota_update.zip
-
Para gerar um OTA incremental:
./build/make/tools/releasetools/ota_from_target_files \ -i PREVIOUS-tardis-target_files.zip \ dist_output/tardis-target_files.zip \ incremental_ota_update.zip
Configurar partições
O update_engine
pode atualizar qualquer par de partições A/B definidas no mesmo disco.
Um par de partições tem um prefixo comum (como system
ou boot
).
e o sufixo por slot (como _a
). A lista de partições para as quais o payload
generator define que uma atualização é configurada pela variável make do AB_OTA_PARTITIONS
.
Por exemplo, se um par de partições bootloader_a
e
booloader_b
estão incluídos (_a
e _b
são os slots
sufixos), atualize essas partições especificando o seguinte no produto ou na placa
configuração:
AB_OTA_PARTITIONS := \ boot \ system \ bootloader
Todas as partições atualizadas por update_engine
não podem ser modificadas pelo restante do
sistema. Durante atualizações incrementais ou delta, os dados binários do slot atual são
usada para gerar os dados no novo slot. Qualquer modificação pode fazer com que os novos dados de espaço
falhar na verificação durante o processo de atualização e, portanto, falhar na atualização.
Configurar pós-instalação
É possível configurar a etapa pós-instalação de forma diferente para cada partição atualizada usando um conjunto de
pares de chave-valor. Para executar um programa localizado em /system/usr/bin/postinst
em uma nova
imagem, especifique o caminho relativo à raiz do sistema de arquivos na partição do sistema.
Por exemplo, usr/bin/postinst
é system/usr/bin/postinst
(se não for
usando um disco de RAM). Além disso, especifique o tipo do sistema de arquivos a passar para o
mount(2)
. Adicione o seguinte ao produto ou dispositivo
Arquivos .mk
(se aplicável):
AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_system=true \ POSTINSTALL_PATH_system=usr/bin/postinst \ FILESYSTEM_TYPE_system=ext4
Compilar apps
Os apps podem ser compilados em segundo plano antes da reinicialização com a nova imagem do sistema. Para compilar em segundo plano, adicione o seguinte à configuração do dispositivo do produto (na device.mk do produto):
-
Inclua os componentes nativos no build para garantir que o script de compilação e os binários sejam
compilados e incluídos na imagem do sistema.
# A/B OTA dexopt package PRODUCT_PACKAGES += otapreopt_script
-
Conecte o script de compilação a
update_engine
, que é executado como um etapa pós-instalação.# A/B OTA dexopt update_engine hookup AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_system=true \ POSTINSTALL_PATH_system=system/bin/otapreopt_script \ FILESYSTEM_TYPE_system=ext4 \ POSTINSTALL_OPTIONAL_system=true
Para receber ajuda com a instalação dos arquivos pré-aprovados na segunda partição do sistema não utilizada, consulte Primeira instalação de inicialização dos arquivos DEX_PREOPT.