No Android 12, a imagem boot
genérica, conhecida como
Imagem genérica do kernel (GKI, na sigla em inglês),
contém o ramdisk genérico e o kernel de GKI.
Em dispositivos lançados com o Android 13, o ramdisk genérico
é removido da imagem boot
e colocado em uma imagem init_boot
separada. Essa mudança deixa a imagem boot
com apenas o
kernel de GKI.
Para dispositivos de upgrade que continuam usando o Android 12
ou versões mais antigas do kernel, o ramdisk genérico permanece onde estava com
não há requisito para uma nova imagem init_boot
.
Para criar um ramdisk genérico, remova os recursos específicos do fornecedor do ramdisk
para que o ramdisk genérico contenha apenas a init
do primeiro estágio e uma propriedade
que contém informações de carimbo de data/hora.
Em dispositivos que:
Não use uma partição
recovery
dedicada, todos os bits de recuperação serão movidos da ramdisk genérico para o ramdiskvendor_boot
.Usar uma partição
recovery
dedicada (sem mudanças no ramdiskrecovery
). é necessário porque o ramdiskrecovery
é independente.
Arquitetura
Os diagramas a seguir ilustram a arquitetura de dispositivos que executam o Android
12 e superior.
Os dispositivos lançados com o Android 13 têm uma nova
init_boot
imagem contendo o ramdisk genérico.
Dispositivos que estão fazendo upgrade do Android 12 para o Android
13 usam a mesma arquitetura que usaram
Android 12
Lançar com o Android 13, sem recuperação dedicada
Figura 1. Dispositivos que são lançados ou atualizados para o Android 13, com GKI, sem recuperação dedicada.
Iniciar com o Android 13, recuperação dedicada e A/B (ramdisk dedicado)
Figura 2. Dispositivos lançados ou atualizados para o Android 13, com GKI, dedicada e recuperação A/B.
Consulte esta figura se o dispositivo tiver partições recovery_a
e recovery_b
.
Iniciar com o Android 13, recuperação dedicada e não A/B (ramdisk dedicado)
Figura 3. Dispositivos lançados ou atualizados para o Android 13, com GKI, recuperação dedicada e não A/B.
Consulte esta figura se o dispositivo tiver uma partição chamada recovery
sem uma
sufixo de slot.
Lançar ou fazer upgrade para o Android 12, sem recuperação dedicada
Figura 4. Dispositivos que são lançados ou atualizados para o Android 12, com GKI, sem recuperação dedicada.
Iniciar ou fazer upgrade para o Android 12, recuperação dedicada e A/B (ramdisk dedicado)
Figura 5. Dispositivos que são lançados ou atualizados para o Android 12, com GKI, dedicada e recuperação A/B.
Consulte esta figura se o dispositivo tiver partições recovery_a
e recovery_b
.
Iniciar ou fazer upgrade para o Android 12, recuperação dedicada e não A/B (ramdisk dedicado)
Figura 6. Dispositivos que são lançados ou atualizados para o Android 12, com GKI, recuperação dedicada e não A/B.
Consulte esta figura se o dispositivo tiver uma partição chamada recovery
sem uma
sufixo de slot.
Fazer upgrade para o Android 12, recuperação como inicialização (recovery-as-ramdisk)
Figura 7. Dispositivos que passaram por upgrade para o Android 12, sem GKI, recuperação como inicialização.
Upgrade para o Android 12, recuperação dedicada (ramdisk dedicado)
Figura 8. Dispositivos que passaram por upgrade para o Android 12, sem GKI, recuperação dedicada.
Conteúdo das imagens de inicialização
As imagens de inicialização do Android contêm o seguinte:
init_boot
imagem adicionada para dispositivos lançados com o Android 13- Versão do cabeçalho V4
- Imagem genérica do ramdisk
Imagem
boot
genérica- Versão de cabeçalho V3 ou
V4
- Um
boot_signature
para a certificação boot.img de GKI (somente v4). A A GKI certificadaboot.img
não está assinada para inicialização verificada. Os OEMs ainda precisam assinar oboot.img
pré-criado com uma cláusula AVB (link em inglês) de dados. - Genérica
cmdline
(GENERIC_KERNEL_CMDLINE
) - Kernel de GKI
- Um
- Imagem genérica do ramdisk
- Incluídas apenas em
boot
imagens do Android 12 e anteriores
- Incluídas apenas em
- Versão de cabeçalho V3 ou
V4
Imagem
vendor_boot
(para mais detalhes, consulte Inicialização do fornecedor) partições)- Cabeçalho
vendor_boot
cmdline
específico do dispositivo (BOARD_KERNEL_CMDLINE
)
vendor_boot
imagem do ramdisklib/modules
- Recursos de recuperação (se não houver recuperação dedicada)
- Imagem
dtb
- Cabeçalho
Imagem
recovery
- Versão do cabeçalho V2
cmdline
específico do dispositivo para recuperação, se necessário- Para uma partição de recuperação não A/B, o conteúdo do cabeçalho precisa ser independente; ver Imagens de recuperação. Exemplo:
cmdline
não está concatenado aboot
evendor_boot
cmdline
.- O cabeçalho especifica o DTBO de recuperação, se necessário.
- Para uma partição de recuperação A/B, o conteúdo pode ser concatenado ou inferido.
de
boot
evendor_boot
. Exemplo: cmdline
é concatenado comboot
evendor_boot
cmdline
.- O DTBO pode ser inferido do cabeçalho
vendor_boot
.
recovery
imagem do ramdisk- Recursos de recuperação
- Para uma partição de recuperação não A/B, o conteúdo do ramdisk precisa ser independente; ver Imagens de recuperação. Exemplo:
lib/modules
precisa conter todos os módulos do kernel necessários para inicializar modo de recuperação- O ramdisk de recuperação precisa conter
init
. - Para a partição de recuperação A/B, o ramdisk de recuperação é anexado ao
genérico e ramdisk
vendor_boot
, portanto não precisa ser independente. Exemplo: lib/modules
pode conter apenas módulos extras do kernel necessários para modo de recuperação de inicialização, além dos módulos do kernel no ramdiskvendor_boot
.- O link simbólico em
/init
pode existir, mas está ofuscado pela o binário/init
de primeiro estágio na imagem de inicialização.
- Versão do cabeçalho V2
Conteúdo genérico da imagem do ramdisk
O ramdisk genérico contém os componentes abaixo.
init
system/etc/ramdisk/build.prop
ro.PRODUCT.bootimg.* build
acessórios- Diretórios vazios para pontos de montagem:
debug_ramdisk/
,mnt/
,dev/
,sys/
.proc/
demetadata/
first_stage_ramdisk/
- Diretórios vazios duplicados para pontos de montagem:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
emetadata/
- Diretórios vazios duplicados para pontos de montagem:
Integração da imagem de inicialização
As flags de build controlam como init_boot
, boot
, recovery
e vendor_boot
imagens são criadas. O valor de uma variável booleana de quadro precisa ser a string
true
ou estar vazia (que é o padrão).
TARGET_NO_KERNEL
: Essa variável indica se o build usa um código de inicialização imagem. Se essa variável for definida comotrue
, definaBOARD_PREBUILT_BOOTIMAGE
. a imagem de inicialização pré-criada (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img
)BOARD_USES_RECOVERY_AS_BOOT
: Essa variável indica se o dispositivo usa a imagemrecovery
como a imagemboot
. Ao usar a GKI, essa variável é vazio, e os recursos de recuperação precisam ser movidos paravendor_boot
.BOARD_USES_GENERIC_KERNEL_IMAGE
: Essa variável indica que o quadro usa GKI. Essa variável não afeta sysprops ouPRODUCT_PACKAGES
:Essa é a chave de GKI para a placa. todas as variáveis a seguir são restritas por essa variável.
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
: Essa variável controla se os recursos de recuperação do ramdisk são criados paravendor_boot
.Quando definidos como
true
, os recursos de recuperação são criados apenas para ovendor-ramdisk/
e não são criados pararecovery/root/
.Quando vazios, os recursos de recuperação são criados apenas para o
recovery/root/
e não são criado paravendor-ramdisk/
.
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT
: Essa variável controla se a GSI As chaves AVB são criadas paravendor_boot
.Quando definido como
true
, seBOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
:estiver definida, as chaves GSI AVB são criadas para
$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb
:não for definida, as chaves GSI AVB são criadas para
$ANDROID_PRODUCT_OUT/vendor-ramdisk/avb
:
Quando vazio, se
BOARD_RECOVERY_AS_ROOT
:estiver definida, as chaves GSI AVB são criadas para
$ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb
:não for definida, as chaves GSI AVB são criadas para
$ANDROID_PRODUCT_OUT/ramdisk/avb
:
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE
: Essa variável controla se a A imagemrecovery
contém ou não um kernel. Dispositivos lançados com o Android 12 e usando a partiçãorecovery
A/B precisam definir essa comotrue
. Dispositivos lançados com o Android 12 e usar um valor diferente de A/B precisa definir essa variável comofalse
para manter a imagem de recuperação autônomos.BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES
: Essa variável controla se$OUT/boot*.img
é copiado paraIMAGES/
nos arquivos de destino.aosp_arm64
precisa definir essa variável comotrue
.Outros dispositivos precisam deixar essa variável em branco.
BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE
: Essa variável controla seinit_boot.img
é gerado e define o tamanho. Quando definido, o ramdisk genérico é adicionado aoinit_boot.img
em vez doboot.img
e requer oBOARD_AVB_INIT_BOOT*
variáveis a serem definidas para vbmeta encadeada.
Combinações permitidas
Componente ou variável | Fazer upgrade do dispositivo sem a partição de recuperação | Fazer upgrade do dispositivo com partição de recuperação | Iniciar dispositivo sem partição de recuperação | Iniciar dispositivo com partição de recuperação A/B | Iniciar dispositivo com partição de recuperação não A/B | aosp_arm64 (link em inglês) |
---|---|---|---|---|---|---|
Contém boot |
sim | sim | sim | sim | sim | sim |
Contém init_boot (Android 13) |
não | não | sim | sim | sim | sim |
Contém vendor_boot |
opcional | opcional | sim | sim | sim | não |
Contém recovery |
não | sim | não | sim | sim | não |
BOARD_USES_RECOVERY_AS_BOOT |
true |
vazio | vazio | vazio | vazio | vazio |
BOARD_USES_GENERIC_KERNEL_IMAGE |
vazio | vazio | true |
true |
true |
true |
PRODUCT_BUILD_RECOVERY_IMAGE |
vazio | true ou vazio |
vazio | true ou vazio |
true ou vazio |
vazio |
BOARD_RECOVERYIMAGE_PARTITION_SIZE |
vazio | > 0 | vazio | > 0 | > 0 | vazio |
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT |
vazio | vazio | true |
vazio | vazio | vazio |
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT |
vazio | vazio | true |
true |
true |
vazio |
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE |
vazio | vazio | vazio | true |
vazio | vazio |
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES |
vazio | vazio | vazio | vazio | vazio | true |
Dispositivos com uma partição recovery
dedicada podem definir
PRODUCT_BUILD_RECOVERY_IMAGE
a true
ou vazio. Para esses dispositivos, se
BOARD_RECOVERYIMAGE_PARTITION_SIZE
estiver definido, uma imagem recovery
será criada.
Ativar vbmeta encadeada para inicialização
A vbmeta encadeada precisa estar ativada para as imagens boot
e init_boot
. Especificar
o seguinte:
BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2
BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3
Para ver um exemplo, consulte este mudança.
Sistema como raiz
O sistema como raiz não tem suporte em dispositivos que usam GKI. Ativado
nesses dispositivos, o campo BOARD_BUILD_SYSTEM_ROOT_IMAGE
precisa estar vazio. Sistema como raiz
também não é compatível com dispositivos que usam partições dinâmicas.
Configurações do produto
Os dispositivos que usam o ramdisk genérico precisam instalar uma lista de arquivos
com permissão de instalação no ramdisk. Para isso, especifique o seguinte em
device.mk
:
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
O arquivo generic_ramdisk.mk
também impede que outros makefiles sejam acidentalmente
instalar outros arquivos no ramdisk (mova esses arquivos para vendor_ramdisk
)
no lugar).
Configurar dispositivos
As instruções de configuração são diferentes para dispositivos lançados com Android. 13, upgrade para o Android 12 e lançamento com o Android 12. A configuração do Android 13 é parecida com a do Android 12
Dispositivos que estão fazendo upgrade para o Android 12:
Pode preservar o valor de
BOARD_USES_RECOVERY_AS_BOOT
. Se isso for feito, se estão usando configurações legadas e as novas variáveis de build precisam estar vazias. Se dispositivos:Pode definir
BOARD_USES_RECOVERY_AS_BOOT
como vazio. Se eles fizerem isso, estão usando para criar novas configurações. Se esses dispositivos:
Os dispositivos lançados com o Android 12 precisam configurar
BOARD_USES_RECOVERY_AS_BOOT
para esvaziar e usar novas configurações. Se dispositivos:
Como aosp_arm64
cria apenas GKI (e não vendor_boot
ou recuperação), ele
não é um objetivo completo. Para conferir as aosp_arm64
configurações de build, consulte
generic_arm64
.
Opção 1: nenhuma partição de recuperação dedicada
Dispositivos sem uma partição recovery
contêm a imagem boot
genérica na
boot
. O ramdisk vendor_boot
contém todos os recursos de recuperação.
incluindo lib/modules
(com módulos de kernel do fornecedor). Nesses dispositivos, os
a configuração do produto herda do
generic_ramdisk.mk
Definir valores de BOARD
Defina os seguintes valores:
BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true
Binários init e links simbólicos
O ramdisk vendor_boot
pode conter um link simbólico de /init
a /system/bin/init
.
e init_second_stage.recovery
às /system/bin/init
. No entanto, como o
o ramdisk genérico é concatenado após o ramdisk vendor_boot
, o /init
o link simbólico será substituído. Quando o dispositivo
inicializa a recuperação, o
O binário /system/bin/init
é necessário para oferecer suporte à inicialização do segundo estágio. O conteúdo
de vendor_boot
+ ramdisks genéricos são os seguintes:
/init
(do ramdisk genérico, criado a partir deinit_first_stage
)/system/bin/init
(a partir devendor_ramdisk
, criado a partir deinit_second_stage.recovery
)
Mover arquivos fstab
Mova todos os arquivos fstab
instalados no ramdisk genérico para
vendor_ramdisk
. Para ver um exemplo, consulte este
mudança.
Instalar módulos
Você pode instalar módulos específicos do dispositivo no vendor_ramdisk
(pular
esta etapa se você não tiver nenhum módulo específico para o dispositivo para instalar).
Use a variante
vendor_ramdisk
do módulo quando ele for instalado em o/first_stage_ramdisk
. Este módulo estará disponível apósinit
alterna raiz para/first_stage_ramdisk
mas antes deinit
mudar de raiz para/system
Para exemplos, consulte Somas de verificação de metadados e Compactação A/B virtual.Use a variante
recovery
do módulo quando ele for instalado em/
. Este módulo deve estar disponível antes queinit
mude de raiz para/first_stage_ramdisk
. Para obter detalhes sobre como instalar módulos para/
, consulte Primeira console do cenário.
Console de primeiro estágio
Como o primeiro estágio do console começa antes da init
mudar de raiz para
/first_stage_ramdisk
, você precisa instalar a variante recovery
dos módulos.
Por padrão, as duas variantes do módulo são instaladas
build/make/target/product/base_vendor.mk
, portanto, se o makefile do dispositivo herdar
a partir desse arquivo, não é necessário instalar explicitamente a variante recovery
.
Para instalar explicitamente os módulos de recuperação, use o código abaixo.
PRODUCT_PACKAGES += \
linker.recovery \
shell_and_utilities_recovery \
Isso garante que linker
, sh
e toybox
sejam instalados
$ANDROID_PRODUCT_OUT/recovery/root/system/bin
, que é instalado
/system/bin
de acordo com a vendor_ramdisk
.
Para adicionar módulos necessários para o console do primeiro estágio (por exemplo, adbd), use o evento seguindo.
PRODUCT_PACKAGES += adbd.recovery
Isso garante que os módulos especificados sejam instalados
$ANDROID_PRODUCT_OUT/recovery/root/system/bin
, que é instalado
/system/bin
nos vendor_ramdisk
.
Somas de verificação de metadados
Para dar suporte a metadados
somas de verificação
durante a montagem no primeiro estágio, os dispositivos sem suporte à GKI instalam o ramdisk
dos módulos a seguir. Para adicionar suporte à GKI, mova os módulos para
$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin
:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
resize2fs.vendor_ramdisk \
tune2fs.vendor_ramdisk \
Para ver um exemplo, consulte este lista de mudanças (link em inglês).
Compactação A/B virtual
Para oferecer suporte à compactação A/B virtual, o snapuserd
precisa ser instalado no
vendor_ramdisk
. O dispositivo deve herdar de
virtual_ab_ota/compression.mk
,
que instala a variante vendor_ramdisk
de snapuserd
.
Mudanças no processo de inicialização
O processo de inicialização na recuperação ou no Android não muda, e a a seguir:
- O ramdisk
build.prop
é movido para/second_stage_resources
para que o segundo estágioinit
pode ler o carimbo de data/hora do build da inicialização.
Como os recursos são movidos do ramdisk genérico para o ramdisk vendor_boot
, o resultado
de concatenação do ramdisk genérico para o ramdisk vendor_boot
não muda.
Disponibilizar e2fsck
Os makefiles do dispositivo podem herdar de:
virtual_ab_ota/launch_with_vendor_ramdisk.mk
se o dispositivo oferecer suporte a virtualização A/B, mas não compactação.virtual_ab_ota/compression.mk
se o dispositivo oferecer suporte ao A/B virtual compactação.
Os makefiles install do produto
$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck
: Em
ambiente de execução, o primeiro estágio init
muda raiz para /first_stage_ramdisk
e, em seguida,
executa /system/bin/e2fsck
.
Opção 2a: partição de recuperação dedicada e A/B
Use essa opção para dispositivos com partições recovery
A/B. ou seja,
o dispositivo tem um recovery_a
e um recovery_b partition
. Tais dispositivos incluem
Dispositivos A/B e A/B virtuais em que a partição de recuperação pode ser atualizada, com
a seguinte configuração:
AB_OTA_PARTITIONS += recovery
O ramdisk vendor_boot
contém os bits do fornecedor do ramdisk e do fornecedor
módulos do kernel, incluindo o seguinte:
Arquivos
fstab
específicos do dispositivolib/modules
(inclui módulos do kernel do fornecedor)
O ramdisk recovery
contém todos os recursos de recuperação. Nesses dispositivos, os
a configuração do produto herda do
generic_ramdisk.mk
Definir valores de BOARD
Defina os seguintes valores para dispositivos com a partição A/B recovery
:
BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true
Binários init e links simbólicos
O ramdisk recovery
pode conter um link simbólico /init -> /system/bin/init
.
init_second_stage.recovery
às /system/bin/init
. No entanto, como a inicialização
o ramdisk é concatenado após o ramdisk recovery
, o link simbólico /init
é
substituída. Quando o dispositivo inicializa no modo de recuperação, o /system/bin/init
o binário é necessário para dar suporte ao init de segundo estágio.
Quando o dispositivo for inicializado no recovery
, o conteúdo de recovery
+
vendor_boot
+ ramdisks genéricos são os seguintes:
/init
(do ramdisk, criado a partir deinit_first_stage
)/system/bin/init
(do ramdisk derecovery
, criado a partir deinit_second_stage.recovery
e executada em/init
)
Quando o dispositivo for inicializado com o Android, o conteúdo de vendor_boot
+ genérico
ramdisks são os seguintes:
/init
(do ramdisk genérico, criado a partir deinit_first_stage
)
Mover arquivos fstab
Mova todos os arquivos fstab
instalados no ramdisk genérico para
vendor_ramdisk
. Para ver um exemplo, consulte este
mudança.
Instalar módulos
Opcionalmente, você pode instalar módulos específicos do dispositivo no vendor_ramdisk
(pular
esta etapa se você não tiver nenhum módulo específico para o dispositivo para instalar). Init
não muda de raiz. A variante vendor_ramdisk
dos módulos é instalada no
raiz de vendor_ramdisk
. Para exemplos de como instalar módulos no
vendor_ramdisk
, consulte Console do primeiro estágio, Metadados
checksums e A/B virtual
compactação.
Console de primeiro estágio
Para instalar a variante vendor_ramdisk
dos módulos, use o seguinte:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
shell_and_utilities_vendor_ramdisk \
Isso garante que linker
, sh
e toybox
sejam instalados
$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
, que é instalado
/system/bin
de acordo com a vendor_ramdisk
.
Para adicionar módulos necessários para o console do primeiro estágio (por exemplo, adbd), ative
a variante vendor_ramdisk
desses módulos fazendo upload de patches relevantes para
AOSP. Em seguida, use o seguinte:
PRODUCT_PACKAGES += adbd.vendor_ramdisk
Isso garante que os módulos especificados sejam instalados
$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
: Se o ramdisk vendor_boot
for carregado no modo de recuperação, o módulo também ficará disponível em recovery
. Se o
O ramdisk vendor_boot
não está carregado no modo de recuperação. O dispositivo pode, opcionalmente,
também instalar o adbd.recovery
.
Somas de verificação de metadados
Para dar suporte a metadados
somas de verificação
durante a montagem no primeiro estágio, os dispositivos sem suporte à GKI instalam o ramdisk
dos módulos a seguir. Para adicionar suporte à GKI, mova os módulos para
$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
resize2fs.vendor_ramdisk \
tune2fs.vendor_ramdisk \
Para ver um exemplo, consulte este lista de mudanças (link em inglês).
Compactação A/B virtual
Para oferecer suporte à compactação A/B virtual, o snapuserd
precisa ser instalado
vendor_ramdisk
. O dispositivo deve herdar de
virtual_ab_ota/compression.mk
,
que instala a variante vendor_ramdisk
de snapuserd
.
Mudanças no processo de inicialização
O processo de inicialização não muda. O botão vendor_boot
+
o ramdisk genérico é semelhante ao processo de inicialização atual, exceto pelo fato de que fstab
será carregado em vendor_boot
. Como system/bin/recovery
não existe,
O first_stage_init
processa isso como uma inicialização normal.
Ao inicializar no modo de recuperação, o processo muda. O botão de recuperação +
A vendor_boot
+ ramdisk genérico é semelhante ao processo de recuperação atual, mas
o kernel é carregado pela imagem boot
em vez da imagem recovery
.
O processo de inicialização para o modo de recuperação é o seguinte.
O carregador de inicialização é iniciado e, em seguida, faz o seguinte:
- Envia "recuperação" +
vendor_boot
+ ramdisk genérico para/
. Se o OEM duplica módulos do kernel no ramdisk de recuperação adicionando-os aoBOARD_RECOVERY_KERNEL_MODULES
),vendor_boot
é opcional. - Executa o kernel da partição
boot
.
- Envia "recuperação" +
O kernel monta o ramdisk em
/
e executa/init
no ramdisk genérico.O init do primeiro estágio é iniciado e, em seguida, faz o seguinte:
- Define
IsRecoveryMode() == true
eForceNormalBoot() == false
. - Carrega os módulos do kernel do fornecedor de
/lib/modules
. - Chama
DoFirstStageMount()
, mas pula a montagem porqueIsRecoveryMode() == true
. O dispositivo não libera o ramdisk, porque/
ainda é o mesmo), mas chamaSetInitAvbVersionInRecovery()
. - Inicia a inicialização do segundo estágio de
/system/bin/init
no ramdiskrecovery
.
- Define
Disponibilizar e2fsck
Os makefiles do dispositivo podem herdar de:
virtual_ab_ota/launch_with_vendor_ramdisk.mk
se o dispositivo oferecer suporte a virtualização A/B, mas não compactação.virtual_ab_ota/compression.mk
se o dispositivo oferecer suporte ao A/B virtual compactação.
Os makefiles install do produto
$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck
: Em
ambiente de execução, o primeiro estágio init
executa /system/bin/e2fsck
.
Opção 2b: partição de recuperação dedicada e não A/B
Use essa opção para dispositivos com uma partição recovery
que não seja A/B. ou seja,
o dispositivo tem uma partição chamada recovery
sem um sufixo de slot. Esses dispositivos
incluem:
- dispositivos não A/B
- Dispositivos A/B e A/B virtuais em que a partição de recuperação não é. atualizável. Isso é incomum.
O ramdisk vendor_boot
contém os bits do fornecedor do ramdisk e do fornecedor
módulos do kernel, incluindo o seguinte:
- Arquivos
fstab
específicos do dispositivo lib/modules
(inclui módulos do kernel do fornecedor)
A imagem recovery
precisa ser independente. Ela deve conter
todos os recursos necessários para inicializar o modo de recuperação, incluindo:
- A imagem do kernel
- A imagem do DTBO
- Módulos do kernel em
lib/modules
- Inicial de primeiro estágio como um link simbólico
/init -> /system/bin/init
- Binário init de segundo estágio
/system/bin/init
- Arquivos
fstab
específicos do dispositivo - Todos os outros recursos de recuperação, incluindo o binário
recovery
Nesses dispositivos, a configuração do produto herda
de generic_ramdisk.mk
.
Definir valores de BOARD
Defina os seguintes valores para dispositivos não A/B:
BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true
Binários init e links simbólicos
O ramdisk recovery
precisa conter um link simbólico /init -> /system/bin/init
.
init_second_stage.recovery
às /system/bin/init
. Quando o dispositivo for inicializado
modo de recuperação, o binário /system/bin/init
é necessário para oferecer suporte aos dois primeiros
e a inicialização do segundo estágio.
Quando o dispositivo é inicializado no recovery
, o conteúdo dos ramdisks do recovery
é
da seguinte forma:
/init -> /system/bin/init
(do ramdisk derecovery
)/system/bin/init
(do ramdisk derecovery
, criado a partir deinit_second_stage.recovery
e executada em/init
)
Quando o dispositivo for inicializado com o Android, o conteúdo de vendor_boot
+ genérico
ramdisks são:
/init
(do ramdisk, criado a partir deinit_first_stage
)
Mover arquivos fstab
Mova todos os arquivos fstab
instalados no ramdisk genérico para
vendor_ramdisk
e recovery
no ramdisk. Para ver um exemplo, consulte este
mudança.
Instalar módulos
Você pode instalar módulos específicos do dispositivo para vendor_ramdisk
e
recovery
ramdisk (pular
esta etapa se você não tiver nenhum módulo específico para o dispositivo para instalar). init
não muda de raiz. A variante vendor_ramdisk
dos módulos é instalada no
raiz de vendor_ramdisk
. A variante recovery
dos módulos é instalada no
raiz do ramdisk recovery
. Para exemplos de como instalar módulos no
ramdisk vendor_ramdisk
e recovery
, se
Console de primeiro estágio e Metadados
checksums.
Console de primeiro estágio
Para instalar a variante vendor_ramdisk
dos módulos, use o seguinte:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
shell_and_utilities_vendor_ramdisk \
Isso garante que linker
, sh
e toybox
sejam instalados
$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
, que é instalado
/system/bin
de acordo com a vendor_ramdisk
.
Para adicionar módulos necessários para o console do primeiro estágio (por exemplo, adbd), ative
a variante vendor_ramdisk
desses módulos fazendo upload de patches relevantes para
AOSP. Em seguida, use o seguinte:
PRODUCT_PACKAGES += adbd.vendor_ramdisk
Isso garante que os módulos especificados sejam instalados
$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
:
Para instalar a variante recovery
dos módulos, substitua vendor_ramdisk
por
recovery
:
PRODUCT_PACKAGES += \
linker.recovery \
shell_and_utilities_recovery \
adbd.recovery \
Somas de verificação de metadados
Para dar suporte a metadados
somas de verificação
durante a montagem no primeiro estágio, os dispositivos sem suporte à GKI instalam o ramdisk
dos módulos a seguir. Para adicionar suporte à GKI, mova os módulos para
$ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
:
PRODUCT_PACKAGES += \
linker.vendor_ramdisk \
resize2fs.vendor_ramdisk \
tune2fs.vendor_ramdisk \
Para oferecer suporte a somas de verificação de metadados durante a montagem do primeiro estágio na recuperação, ative a variante de recuperação desses módulos e instale-os também.
Mudanças no processo de inicialização
O processo de inicialização não muda. O botão vendor_boot
+
o ramdisk genérico é semelhante ao processo de inicialização atual, exceto pelo fato de que fstab
será carregado em vendor_boot
. Como system/bin/recovery
não existe,
O first_stage_init
processa isso como uma inicialização normal.
Ao inicializar no modo de recuperação, o processo não muda. O processo de recuperação
o ramdisk é carregado da mesma forma que o processo de recuperação.
O kernel é carregado usando a imagem recovery
. A
o processo de inicialização para o modo de recuperação é o seguinte.
O carregador de inicialização é iniciado e, em seguida, faz o seguinte:
- Envia o ramdisk de recuperação para
/
. - Executa o kernel da partição
recovery
.
- Envia o ramdisk de recuperação para
O kernel monta o ramdisk para
/
e executa/init
, que é um link simbólico para/system/bin/init
do ramdiskrecovery
.O init do primeiro estágio é iniciado e, em seguida, faz o seguinte:
- Define
IsRecoveryMode() == true
eForceNormalBoot() == false
. - Carrega os módulos do kernel do fornecedor de
/lib/modules
. - Chama
DoFirstStageMount()
, mas pula a montagem porqueIsRecoveryMode() == true
. O dispositivo não libera o ramdisk, porque/
ainda é o mesmo), mas chamaSetInitAvbVersionInRecovery()
. - Inicia a inicialização do segundo estágio de
/system/bin/init
no ramdiskrecovery
.
- Define
Carimbos de data/hora da imagem de inicialização
O código a seguir é um exemplo de arquivo de carimbo de data/hora de imagem boot
:
####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file
No tempo de build, um arquivo
system/etc/ramdisk/build.prop
é adicionado à no ramdisk. Esse arquivo contém informações de carimbo de data/hora do build.No momento da execução, primeiro estágio
init
cópias arquivos do ramdisk paratmpfs
antes de liberar o ramdisk para que o segundo estágioinit
pode ler neste arquivo para definirboot
propriedades de carimbo de data/hora da imagem.