No Android 12, a imagem boot
genérica, conhecida como Generic Kernel Image (GKI) , contém o ramdisk genérico e o kernel GKI.
Para dispositivos iniciados com o Android 13, o ramdisk genérico é removido da imagem boot
e colocado em uma imagem init_boot
separada. Essa alteração deixa a imagem boot
apenas com o kernel GKI.
Para atualizar dispositivos que continuam a usar o Android 12 ou versões mais antigas do kernel, o ramdisk genérico permanece onde estava sem a necessidade de uma nova imagem init_boot
.
Para construir um ramdisk genérico, mova os recursos específicos do fornecedor para fora do ramdisk de forma que o ramdisk genérico contenha apenas init
de primeiro estágio e um arquivo de propriedades que contenha informações de registro de data e hora.
Em dispositivos que:
Não use uma partição
recovery
dedicada, todos os bits de recuperação se movem do ramdisk genérico para o ramdiskvendor_boot
.Use uma partição
recovery
dedicada, nenhuma alteração no ramdiskrecovery
é necessária porque o ramdiskrecovery
é independente.
Arquitetura
Os diagramas a seguir ilustram a arquitetura para dispositivos com Android 12 e superior. A inicialização do dispositivo com o Android 13 tem uma nova imagem init_boot
contendo o ramdisk genérico. Os dispositivos atualizados do Android 12 para o Android 13 usam a mesma arquitetura do Android 12.
Lançamento com Android 13, sem recuperação dedicada
Figura 1. Dispositivos iniciando ou atualizando para o Android 13, com GKI, sem recuperação dedicada
Lançamento com Android 13, dedicado e recuperação A/B (ramdisk dedicado)
Figura 2. Dispositivos iniciando ou atualizando para o Android 13, com GKI, dedicado e recuperação A/B
Consulte esta figura se o dispositivo tiver partições recovery_a
e recovery_b
.
Lançamento com Android 13, recuperação dedicada e não A/B (ramdisk dedicado)
Figura 3. Dispositivos iniciando ou atualizando para o Android 13, com GKI, recuperação dedicada e não A/B
Consulte esta figura se o dispositivo tiver uma partição denominada recovery
sem um sufixo de slot.
Inicie ou atualize para o Android 12, sem recuperação dedicada
Figura 4. Dispositivos iniciando ou atualizando para o Android 12, com GKI, sem recuperação dedicada
Inicie ou atualize para o Android 12, dedicado e recuperação A/B (ramdisk dedicado)
Figura 5. Dispositivos iniciando ou atualizando para o Android 12, com GKI, dedicado e recuperação A/B
Consulte esta figura se o dispositivo tiver partições recovery_a
e recovery_b
.
Inicie ou atualize para o Android 12, recuperação dedicada e não A/B (ramdisk dedicado)
Figura 6. Dispositivos iniciando ou atualizando para o Android 12, com GKI, recuperação dedicada e não A/B
Consulte esta figura se o dispositivo tiver uma partição denominada recovery
sem um sufixo de slot.
Atualize para o Android 12, recuperação como inicialização (recuperação como ramdisk)
Figura 7. Dispositivos atualizando para o Android 12, sem GKI, recuperação como inicialização
Atualize para o Android 12, recuperação dedicada (ramdisk dedicado)
Figura 8. Dispositivos atualizando para 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.
imagem
init_boot
adicionada para dispositivos lançados com o Android 13- Versão do cabeçalho V4
- Imagem de disco RAM genérica
imagem
boot
genérica- Versão do cabeçalho V3 ou V4
- Uma
boot_signature
para certificação GKI boot.img (somente v4). O GKIboot.img
certificado não está assinado para inicialização verificada. Os OEMs ainda devem assinar oboot.img
pré-criado com uma chave AVB específica do dispositivo. -
cmdline
genérica (GENERIC_KERNEL_CMDLINE
) - Kernel GKI
- Uma
- Imagem de disco RAM genérica
- Incluído apenas em imagens
boot
do Android 12 e anteriores
- Incluído apenas em imagens
- Versão do cabeçalho V3 ou V4
imagem
vendor_boot
(para detalhes, consulte Vendor Boot Partitions )- cabeçalho
vendor_boot
-
cmdline
específica do dispositivo (BOARD_KERNEL_CMDLINE
)
-
- imagem de disco RAM
vendor_boot
-
lib/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ífica do dispositivo para recuperação, se necessário - Para partição de recuperação não A/B, o conteúdo do cabeçalho deve ser autônomo; veja Imagens de Recuperação . Por exemplo:
-
cmdline
não é concatenado comboot
evendor_boot
cmdline
. - O cabeçalho especifica o DTBO de recuperação, se necessário.
- Para partição de recuperação A/B, o conteúdo pode ser concatenado ou inferido de
boot
evendor_boot
. Por exemplo: -
cmdline
é concatenado comboot
evendor_boot
cmdline
. - DTBO pode ser inferido do cabeçalho
vendor_boot
.
-
- imagem de disco ram
recovery
- Recursos de recuperação
- Para partição de recuperação não A/B, o conteúdo do ramdisk deve ser autônomo; veja Imagens de Recuperação . Por exemplo:
-
lib/modules
deve conter todos os módulos do kernel necessários para inicializar o modo de recuperação - O ramdisk de recuperação deve conter
init
. - Para a partição de recuperação A/B, o ramdisk de recuperação é anexado ao ramdisk genérico e
vendor_boot
, portanto, não precisa ser autônomo. Por exemplo: -
lib/modules
podem conter apenas módulos de kernel adicionais necessários para inicializar o modo de recuperação, além dos módulos de kernel emvendor_boot
ramdisk. - O link simbólico em
/init
pode existir, mas é ofuscado pelo 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 seguintes componentes.
-
init
- Adicionado
system/etc/ramdisk/build.prop
-
ro. PRODUCT .bootimg.* build
- Diretórios vazios para pontos de montagem:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
,metadata/
-
first_stage_ramdisk/
- Diretórios vazios duplicados para pontos de montagem:
debug_ramdisk/
,mnt/
,dev/
,sys/
,proc/
,metadata/
- Diretórios vazios duplicados para pontos de montagem:
Integração da imagem de inicialização
Os sinalizadores de construção controlam como as imagens init_boot
, boot
, recovery
e vendor_boot
são construídas. O valor de uma variável de quadro booleano deve ser a string true
ou estar vazia (que é o padrão).
TARGET_NO_KERNEL
. Essa variável indica se a compilação usa uma imagem de inicialização pré-compilada. Se esta variável for definida comotrue
, definaBOARD_PREBUILT_BOOTIMAGE
para o local da imagem de inicialização pré-construída (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img
)BOARD_USES_RECOVERY_AS_BOOT
. Essa variável indica se o dispositivo usa a imagemrecovery
como imagemboot
. Ao usar o GKI, essa variável fica vazia e os recursos de recuperação devem ser movidos paravendor_boot
.BOARD_USES_GENERIC_KERNEL_IMAGE
. Essa variável indica que a placa usa GKI. Esta variável não afeta sysprops ouPRODUCT_PACKAGES
.Este é o switch GKI no nível da placa; todas as variáveis listadas abaixo são restritas por esta variável.
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
. Essa variável controla se os recursos de recuperação de ramdisk são construídos paravendor_boot
.Quando definido como
true
, os recursos de recuperação são criados apenas paravendor-ramdisk/
e não são criados pararecovery/root/
.Quando vazios, os recursos de recuperação são criados apenas para
recovery/root/
e não são criados paravendor-ramdisk/
.
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT
. Essa variável controla se as chaves GSI AVB são criadas paravendor_boot
.Quando definido como
true
, seBOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT
:estiver definido, as chaves GSI AVB são criadas para
$ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb
.Se não estiver definido, as chaves GSI AVB são criadas para
$ANDROID_PRODUCT_OUT/vendor-ramdisk/avb
.
Quando vazio, se
BOARD_RECOVERY_AS_ROOT
:estiver definido, as chaves GSI AVB são criadas para
$ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb
.Se não estiver definido, as chaves GSI AVB são criadas para
$ANDROID_PRODUCT_OUT/ramdisk/avb
.
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE
. Esta variável controla se a imagemrecovery
contém um kernel ou não. Os dispositivos iniciados com o Android 12 e usando a partiçãorecovery
A/B devem definir essa variável comotrue
. Os dispositivos iniciados com o Android 12 e usando não A/B devem definir essa variável comofalse
para manter a imagem de recuperação independente.BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES
. Esta variável controla se$OUT/boot*.img
é copiado paraIMAGES/
nos arquivos de destino.aosp_arm64
deve definir esta variável comotrue
.Outros dispositivos devem deixar esta variável vazia.
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 deboot.img
e requer que as variáveisBOARD_AVB_INIT_BOOT*
sejam definidas para vbmeta encadeado
Combinações permitidas
Componente ou variável | Atualizando dispositivo sem partição recovery | Atualizando dispositivo com partição recovery | Inicie o dispositivo sem partição recovery | Inicie o dispositivo com a partição recovery A/B | Inicie o dispositivo com partição recovery não A/B | aosp_arm64 |
---|---|---|---|---|---|---|
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 |
Os dispositivos com uma partição recovery
dedicada podem definir PRODUCT_BUILD_RECOVERY_IMAGE
como true
ou vazio. Para esses dispositivos, se BOARD_RECOVERYIMAGE_PARTITION_SIZE
for definido, uma imagem recovery
será criada.
Ativar vbmeta encadeado para inicialização
O vbmeta encadeado deve ser ativado para as imagens boot
e init_boot
. Especifique 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 obter um exemplo, consulte esta alteração .
Sistema como raiz
O sistema como raiz não é compatível com dispositivos que usam GKI. Nesses dispositivos, BOARD_BUILD_SYSTEM_ROOT_IMAGE
deve estar vazio. O 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 devem instalar uma lista de arquivos que podem ser instalados no ramdisk. Para fazer isso, especifique o seguinte em device.mk
:
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
O arquivo generic_ramdisk.mk
também evita que outros makefiles instalem acidentalmente outros arquivos no ramdisk (em vez disso, mova esses arquivos para vendor_ramdisk
).
Configurando dispositivos
As instruções de configuração diferem entre os dispositivos que iniciam com o Android 13, atualizam para o Android 12 e iniciam com o Android 12. O Android 13 é configurado de maneira semelhante à do Android 12
Dispositivos atualizando para o Android 12:
Pode preservar o valor de
BOARD_USES_RECOVERY_AS_BOOT
. Se fizerem isso, estarão usando configurações herdadas e as novas variáveis de construção devem estar vazias. Se tais dispositivos:Defina
BOARD_USES_RECOVERY_AS_BOOT
comotrue
, a arquitetura é mostrada na Figura 3 .Defina
BOARD_USES_RECOVERY_AS_BOOT
como vazio, a arquitetura é mostrada na Figura 4 .
Pode definir
BOARD_USES_RECOVERY_AS_BOOT
como vazio. Se o fizerem, estarão usando novas configurações. Se tais dispositivos:
Os dispositivos iniciados com o Android 12 devem definir
BOARD_USES_RECOVERY_AS_BOOT
como vazio e usar novas configurações. Se tais dispositivos:
Como aosp_arm64
cria apenas GKI (e não vendor_boot
ou recovery), ele não é um destino completo. Para configurações de compilação aosp_arm64
, consulte generic_arm64
.
Opção 1: Nenhuma partição de recuperação dedicada
Os dispositivos sem uma partição recovery
contêm a imagem boot
genérica na partição boot
. O ramdisk vendor_boot
contém todos os recursos de recuperação, incluindo lib/modules
(com módulos do kernel do fornecedor). Nesses dispositivos, a configuração do produto herda de generic_ramdisk.mk
.
Definindo os valores da PLACA
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 de inicialização e links simbólicos
O ramdisk vendor_boot
pode conter um link simbólico /init
para /system/bin/init
e init_second_stage.recovery
em /system/bin/init
. No entanto, como o ramdisk genérico é concatenado após o ramdisk vendor_boot
, o link simbólico /init
é substituído. Quando o dispositivo inicializa em recuperação, o binário /system/bin/init
é necessário para dar suporte ao init de segundo estágio. O conteúdo de vendor_boot
+ ramdisks genéricos é o seguinte:
-
/init
(de ramdisk genérico, construído a partir deinit_first_stage
) -
/system/bin/init
(devendor_ramdisk
, criado a partir deinit_second_stage.recovery
)
Movendo arquivos fstab
Mova quaisquer arquivos fstab
que foram instalados no ramdisk genérico para vendor_ramdisk
. Para obter um exemplo, consulte esta alteração .
Instalando módulos
Se desejar, você pode instalar módulos específicos do dispositivo para vendor_ramdisk
(pule esta etapa se não tiver nenhum módulo específico do dispositivo para instalar).
Use a variante
vendor_ramdisk
do módulo quando o módulo for instalado no/first_stage_ramdisk
. Este módulo deve estar disponível apósinit
alternar o root para/first_stage_ramdisk
, mas antesinit
alternar para o root em/system
. Para obter exemplos, consulte Somas de verificação de metadados e compactação A/B virtual .Use a variante
recovery
do módulo quando o módulo for instalado em/
. Este módulo deve estar disponível antes queinit
mude para/first_stage_ramdisk
. Para obter detalhes sobre a instalação de módulos em/
, consulte Console de primeiro estágio .
Console do primeiro estágio
Como o console do primeiro estágio começa antes init
mudar para /first_stage_ramdisk
, você precisa instalar a variante recovery
dos módulos. Por padrão, ambas as variantes do módulo são instaladas em build/make/target/product/base_vendor.mk
, portanto, se o makefile do dispositivo herdar desse arquivo, você não precisará instalar explicitamente a variante recovery
.
Para instalar explicitamente os módulos de recuperação, use o seguinte.
PRODUCT_PACKAGES += \
linker.recovery \
shell_and_utilities_recovery \
Isso garante que o linker
, sh
e toybox
sejam instalados em $ANDROID_PRODUCT_OUT/recovery/root/system/bin
, que então é instalado em /system/bin
sob o vendor_ramdisk
.
Para adicionar módulos necessários para o console de primeiro estágio (por exemplo, adbd), use o seguinte.
PRODUCT_PACKAGES += adbd.recovery
Isso garante que os módulos especificados sejam instalados em $ANDROID_PRODUCT_OUT/recovery/root/system/bin
, que então é instalado em /system/bin
sob o vendor_ramdisk
.
Somas de verificação de metadados
Para oferecer suporte a somas de verificação de metadados durante a montagem do primeiro estágio, os dispositivos que não oferecem suporte a GKI instalam a variante de ramdisk dos módulos a seguir. Para adicionar suporte para 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 obter um exemplo, consulte esta lista de alterações .
Compressão virtual A/B
Para oferecer suporte à compactação A/B virtual, snapuserd
deve ser instalado em vendor_ramdisk
. O dispositivo deve herdar de virtual_ab_ota/compression.mk
, que instala a variante vendor_ramdisk
de snapuserd
.
Alterações no processo de inicialização
O processo de inicialização em recuperação ou no Android não muda, com a seguinte exceção:
- Ramdisk
build.prop
se move para/second_stage_resources
para queinit
do segundo estágio possa ler o carimbo de data/hora de compilação da inicialização.
Como os recursos se movem do ramdisk genérico para o ramdisk vendor_boot
, o resultado da concatenação do ramdisk genérico para o ramdisk vendor_boot
não muda.
Disponibilizando o e2fsck
Os makefiles do dispositivo podem herdar de:
virtual_ab_ota/launch_with_vendor_ramdisk.mk
se o dispositivo suportar A/B virtual, mas não compressão.virtual_ab_ota/compression.mk
se o dispositivo suportar compactação A/B virtual.
Os makefiles do produto instalam $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck
. No tempo de execução, o init
do primeiro estágio alterna o root para /first_stage_ramdisk
e executa /system/bin/e2fsck
.
Opção 2a: Partição dedicada e de recuperação A/B
Use esta opção para dispositivos com partições recovery
A/B; ou seja, o dispositivo possui uma recovery_b partition
recovery_a
e recovery_b . Tais dispositivos incluem dispositivos A/B e A/B virtuais cuja partição de recuperação é atualizável, com a seguinte configuração:
AB_OTA_PARTITIONS += recovery
O ramdisk vendor_boot
contém os bits do fornecedor do ramdisk e dos módulos do kernel do fornecedor, 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, a configuração do produto herda de generic_ramdisk.mk
.
Definindo os valores da PLACA
Defina os seguintes valores para dispositivos com partição recovery
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 := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true
Binários de inicialização e links simbólicos
O ramdisk recovery
pode conter um link simbólico /init -> /system/bin/init
e init_second_stage.recovery
em /system/bin/init
. No entanto, como o ramdisk de inicialização é concatenado após o ramdisk recovery
, o link simbólico /init
é substituído. Quando o dispositivo inicializa no modo de recuperação, o binário /system/bin/init
é necessário para dar suporte ao init de segundo estágio.
Quando o dispositivo inicializa em recovery
, o conteúdo de recovery
+ vendor_boot
+ ramdisks genéricos é o seguinte:
-
/init
(de ramdisk, criado a partir deinit_first_stage
) -
/system/bin/init
(do ramdiskrecovery
, criado a partir deinit_second_stage.recovery
e executado a partir de/init
)
Quando o dispositivo inicializa no Android, o conteúdo de vendor_boot
+ ramdisks genéricos é o seguinte:
-
/init
(de ramdisk genérico, construído a partir deinit_first_stage
)
Movendo arquivos fstab
Mova quaisquer arquivos fstab
que foram instalados no ramdisk genérico para vendor_ramdisk
. Para obter um exemplo, consulte esta alteração .
Instalando módulos
Se desejar, você pode instalar módulos específicos do dispositivo para vendor_ramdisk
(pule esta etapa se não tiver nenhum módulo específico do dispositivo para instalar). Init
não muda de root. A variante de módulos vendor_ramdisk
é instalada na raiz de vendor_ramdisk
. Para obter exemplos sobre a instalação de módulos em vendor_ramdisk
, consulte Console de primeiro estágio , somas de verificação de metadados e compactação A/B virtual .
Console do 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 o linker
, sh
e toybox
sejam instalados em $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
, que então é instalado em /system/bin
sob o vendor_ramdisk
.
Para adicionar módulos necessários para o console de primeiro estágio (por exemplo, adbd), habilite a variante vendor_ramdisk
desses módulos carregando patches relevantes para o AOSP e, em seguida, use o seguinte,
PRODUCT_PACKAGES += adbd.vendor_ramdisk
Isso garante que os módulos especificados sejam instalados em $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
. Se o ramdisk vendor_boot
for carregado no modo de recuperação, o módulo também estará disponível no recovery
. Se o ramdisk vendor_boot
não for carregado no modo de recuperação, o dispositivo também pode instalar opcionalmente adbd.recovery
.
Somas de verificação de metadados
Para oferecer suporte a somas de verificação de metadados durante a montagem do primeiro estágio, os dispositivos que não oferecem suporte a GKI instalam a variante de ramdisk dos módulos a seguir. Para adicionar suporte para 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 obter um exemplo, consulte esta lista de alterações .
Compressão virtual A/B
Para oferecer suporte à compactação A/B virtual, snapuserd
deve ser instalado em vendor_ramdisk
. O dispositivo deve herdar de virtual_ab_ota/compression.mk
, que instala a variante vendor_ramdisk
de snapuserd
.
Alterações no processo de inicialização
Ao inicializar no Android, o processo de inicialização não muda. O vendor_boot
+ ramdisk genérico é semelhante ao processo de inicialização existente, exceto que fstab
carrega de vendor_boot
. Como system/bin/recovery
não existe, first_stage_init
lida com isso como uma inicialização normal.
Ao inicializar no modo de recuperação, o processo de inicialização muda. A recuperação + vendor_boot
+ ramdisk genérico é semelhante ao processo de recuperação existente, mas o kernel é carregado a partir da imagem boot
em vez da imagem recovery
. O processo de inicialização para o modo de recuperação é o seguinte.
O bootloader é iniciado e faz o seguinte:
- Envia recuperação +
vendor_boot
+ ramdisk genérico para/
. (Se o OEM duplicar os módulos do kernel no ramdisk de recuperação adicionando-os aBOARD_RECOVERY_KERNEL_MODULES
),vendor_boot
é opcional.) - Executa o kernel da partição
boot
.
- Envia recuperação +
O kernel monta o ramdisk em
/
então executa/init
a partir do 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 ignora a montagem porqueIsRecoveryMode() == true
. (O dispositivo não libera ramdisk (porque/
ainda é o mesmo), mas chamaSetInitAvbVersionInRecovery()
.) - Inicia o segundo estágio init de
/system/bin/init
do ramdiskrecovery
.
- Define
Disponibilizando o e2fsck
Os makefiles do dispositivo podem herdar de:
virtual_ab_ota/launch_with_vendor_ramdisk.mk
se o dispositivo suportar A/B virtual, mas não compactação.virtual_ab_ota/compression.mk
se o dispositivo suportar compactação A/B virtual.
Os makefiles do produto instalam $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck
. No tempo 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 esta opção para dispositivos com uma partição recovery
não A/B; ou seja, o dispositivo possui uma partição chamada recovery
sem um sufixo de slot. Tais dispositivos incluem:
- dispositivos não A/B;
- Dispositivos A/B e A/B virtuais, dos quais 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 dos módulos do kernel do fornecedor, incluindo o seguinte:
- Arquivos
fstab
específicos do dispositivo -
lib/modules
(inclui módulos do kernel do fornecedor)
A imagem recovery
deve ser independente. Ele deve conter todos os recursos necessários para inicializar o modo de recuperação, incluindo:
- a imagem do kernel
- A imagem DTBO
- Módulos do kernel em
lib/modules
- Primeiro estágio init 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
, etc. - etc.
Nesses dispositivos, a configuração do produto herda de generic_ramdisk.mk
.
Definindo os valores da PLACA
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 de inicialização e links simbólicos
O ramdisk recovery
deve conter um link simbólico /init -> /system/bin/init
e init_second_stage.recovery
em /system/bin/init
. Quando o dispositivo inicializa no modo de recuperação, o binário /system/bin/init
é necessário para suportar o init de primeiro e segundo estágio.
Quando o dispositivo inicializa em recovery
, o conteúdo dos ramdisks recovery
são os seguintes:
-
/init -> /system/bin/init
(do ramdiskrecovery
) -
/system/bin/init
(do ramdiskrecovery
, criado a partir deinit_second_stage.recovery
e executado a partir de/init
)
Quando o dispositivo inicializa no Android, o conteúdo de vendor_boot
+ ramdisks genéricos é o seguinte:
-
/init
(de ramdisk, criado a partir deinit_first_stage
)
Movendo arquivos fstab
Mova quaisquer arquivos fstab
que foram instalados no ramdisk genérico para o vendor_ramdisk
e o ramdisk recovery
. Para obter um exemplo, consulte esta alteração .
Instalando módulos
Se desejar, você pode instalar módulos específicos do dispositivo para vendor_ramdisk
e ramdisk recovery
(pule esta etapa se não tiver nenhum módulo específico do dispositivo para instalar). init
não muda de root. A variante de módulos vendor_ramdisk
é instalada na raiz de vendor_ramdisk
. A variante recovery
dos módulos é instalada na raiz do ramdisk recovery
. Para obter exemplos sobre a instalação de módulos em vendor_ramdisk
e ramdisk recovery
, consulte First stage console and Metadata checksums .
Console do 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 o linker
, sh
e toybox
sejam instalados em $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin
, que então é instalado em /system/bin
sob o vendor_ramdisk
.
Para adicionar módulos necessários para o console de primeiro estágio (por exemplo, adbd), habilite a variante vendor_ramdisk
desses módulos carregando patches relevantes para o AOSP e, em seguida, use o seguinte,
PRODUCT_PACKAGES += adbd.vendor_ramdisk
Isso garante que os módulos especificados sejam instalados em $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 oferecer suporte a somas de verificação de metadados durante a montagem do primeiro estágio, os dispositivos que não oferecem suporte a GKI instalam a variante de ramdisk dos módulos a seguir. Para adicionar suporte para 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, habilite a variante de recuperação desses módulos e instale-os também.
Alterações no processo de inicialização
Ao inicializar no Android, o processo de inicialização não muda. O vendor_boot
+ ramdisk genérico é semelhante ao processo de inicialização existente, exceto que fstab
carrega de vendor_boot
. Como system/bin/recovery
não existe, first_stage_init
lida com isso como uma inicialização normal.
Ao inicializar no modo de recuperação, o processo de inicialização não muda. O ramdisk de recuperação é carregado da mesma forma que o processo de recuperação existente. O kernel é carregado a partir da imagem recovery
. O processo de inicialização para o modo de recuperação é o seguinte.
O bootloader é iniciado e 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
/
então 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 ignora a montagem porqueIsRecoveryMode() == true
. (O dispositivo não libera ramdisk (porque/
ainda é o mesmo), mas chamaSetInitAvbVersionInRecovery()
.) - Inicia o segundo estágio init de
/system/bin/init
do ramdiskrecovery
.
- Define
Carimbos de data/hora da imagem de inicialização
O código a seguir é um exemplo de arquivo de 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 momento da compilação, um arquivo
system/etc/ramdisk/build.prop
é adicionado ao ramdisk genérico. Este arquivo contém informações de carimbo de data/hora da compilação.No tempo de execução,
init
do primeiro estágio copia os arquivos do ramdisk para otmpfs
antes de liberar o ramdisk para queinit
do segundo estágio possa ler esse arquivo para definir as propriedades de registro de data e hora da imagemboot
.