Partição de inicialização genérica

No Android 12, a imagem genérica boot, chamada de imagem genérica do kernel (GKI), contém o ramdisk genérico e o kernel 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 do GKI.

Para fazer upgrade de dispositivos que continuam usando 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 criar um ramdisk genérico, remova os recursos específicos do fornecedor do ramdisk de modo que ele contenha apenas init do primeiro estágio e um arquivo de propriedade com informações de carimbo de data/hora.

Em dispositivos que:

  • Não use uma partição recovery dedicada. Todos os bits de recuperação são movidos do ramdisk genérico para o ramdisk vendor_boot.

  • Use uma partição recovery dedicada. Não é necessário fazer mudanças no ramdisk recovery porque ele é independente.recovery

Arquitetura

Os diagramas a seguir ilustram a arquitetura para dispositivos com o Android 12 e versões mais recentes. Os dispositivos lançados com o Android 13 têm uma nova imagem init_boot que contém o ramdisk genérico. Os dispositivos que fazem upgrade do Android 12 para o Android 13 usam a mesma arquitetura do Android 12.

Lançamento com o Android 13, sem recuperação dedicada

Dispositivo de inicialização/upgrade, GKI, sem recuperação dedicada

Figura 1. Dispositivos que estão sendo lançados ou sendo atualizados para o Android 13, com GKI, sem recuperação dedicada.

Lançamento com o Android 13, dedicado e recuperação A/B (ramdisk dedicado)

Iniciar/atualizar o dispositivo, GKI, recuperação dedicada e A/B

Figura 2. Dispositivos lançados ou atualizados para o Android 13, com GKI, dedicados e recuperação A/B.

Consulte esta figura se o dispositivo tiver partições recovery_a e recovery_b.

Lançamento com o Android 13, recuperação dedicada e não A/B (ramdisk dedicado)

Dispositivo de inicialização/upgrade, GKI, recuperação dedicada e não A/B

Figura 3. Dispositivos que estão sendo lançados ou sendo 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 um sufixo de slot.

Inicialização ou upgrade para o Android 12, sem recuperação dedicada

Dispositivo de inicialização/upgrade, GKI, sem recuperação dedicada

Figura 4. Dispositivos que iniciam ou fazem upgrade para o Android 12, com GKI, sem recuperação dedicada.

Inicialização ou upgrade para o Android 12, recuperação dedicada e A/B (ramdisk dedicado)

Iniciar/atualizar o dispositivo, GKI, recuperação dedicada e A/B

Figura 5. Dispositivos lançados ou atualizados para o Android 12, com GKI, dedicados e recuperação A/B.

Consulte esta figura se o dispositivo tiver partições recovery_a e recovery_b.

Inicialização ou upgrade para o Android 12, recuperação dedicada e não A/B (ramdisk dedicado)

Inicialização/upgrade do dispositivo, GKI, recuperação dedicada e não A/B

Figura 6. Dispositivos 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 um sufixo de slot.

Fazer upgrade para o Android 12, recovery-as-boot (recovery-as-ramdisk)

Dispositivo de inicialização/upgrade, sem GKI, recuperação como inicialização

Figura 7. Dispositivos que estão fazendo upgrade para o Android 12, sem GKI, recovery-as-boot.

Upgrade para o Android 12, recuperação dedicada (ramdisk dedicado)

Iniciar/atualizar o dispositivo, sem GKI, recuperação dedicada

Figura 8. Dispositivos que fazem 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.

  • Imagem init_boot adicionada para dispositivos lançados com o Android 13

    • Versão do cabeçalho V4
    • Imagem genérica do ramdisk

  • Imagem genérica boot

    • Versão do cabeçalho V3 ou V4
      • Um boot_signature para a certificação boot.img do GKI (somente v4). O GKI boot.img certificado não está assinado para inicialização verificada. Os OEMs ainda precisam assinar o boot.img pré-criado com uma chave AVB específica do dispositivo.
      • cmdline genérico (GENERIC_KERNEL_CMDLINE)
      • Kernel de GKI
    • Imagem genérica de ramdisk
      • Incluído apenas nas imagens boot do Android 12 e versões anteriores

  • Imagem vendor_boot (para detalhes, consulte Partições de inicialização do fornecedor).

    • Cabeçalho vendor_boot
      • cmdline específico do dispositivo (BOARD_KERNEL_CMDLINE)
    • Imagem de ramdisk vendor_boot
      • lib/modules
      • Recursos de recuperação (se não houver recuperação dedicada)
    • dtb imagem

  • recovery imagem

    • Versão do cabeçalho V2
      • cmdline específico do dispositivo para recuperação, se necessário
      • Para partições de recuperação que não sejam A/B, o conteúdo do cabeçalho precisa ser independente. Consulte Imagens de recuperação. Exemplo:
      • cmdline não é concatenado a boot e vendor_boot cmdline.
      • O cabeçalho especifica o DTBO de recuperação, se necessário.
      • Para a partição de recuperação A/B, o conteúdo pode ser concatenado ou inferido de boot e vendor_boot. Exemplo:
      • cmdline é concatenado a boot e vendor_boot cmdline.
      • A DTBO pode ser inferida do cabeçalho vendor_boot.
    • Imagem de ramdisk recovery
      • Recursos de recuperação
      • Para partições de recuperação não A/B, o conteúdo do ramdisk precisa ser independente. Consulte Imagens de recuperação. Exemplo:
      • lib/modules precisa conter todos os módulos do kernel necessários para inicializar o 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 é adicionado ao ramdisk genérico e vendor_boot. Portanto, ele não precisa ser independente. Exemplo:
      • O lib/modules pode conter apenas outros módulos do kernel necessários para iniciar o modo de recuperação, além dos módulos do kernel no ramdisk vendor_boot.
      • O link simbólico em /init pode existir, mas é ofuscado pelo binário /init da primeira fase na imagem de inicialização.

Conteúdo genérico da imagem do ramdisk

O ramdisk genérico contém os seguintes componentes.

  • init
  • system/etc/ramdisk/build.prop
  • Propriedades 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/

Integração de imagens de inicialização

As flags de build controlam como as imagens init_boot, boot, recovery e vendor_boot são criadas. O valor de uma variável de placa booleana precisa ser a string true ou estar vazia (padrão).

  • TARGET_NO_KERNEL. Essa variável indica se o build usa uma imagem de inicialização pré-criada. Se essa variável for definida como true, defina BOARD_PREBUILT_BOOTIMAGE como o local do boot image pré-criado (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img).

  • BOARD_USES_RECOVERY_AS_BOOT. Essa variável indica se o dispositivo usa a imagem recovery como a imagem boot. Ao usar o GKI, essa variável fica vazia, e os recursos de recuperação precisam ser movidos para vendor_boot.

  • BOARD_USES_GENERIC_KERNEL_IMAGE. Essa variável indica que o dispositivo usa a GKI. Essa variável não afeta sysprops ou PRODUCT_PACKAGES.

    Essa é a chave GKI no nível do conselho. Todas as variáveis a seguir são restringidas por essa variável.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT. Essa variável controla se os recursos de recuperação de ramdisk são criados para vendor_boot.

    • Quando definido como true, os recursos de recuperação são criados apenas para vendor-ramdisk/ e não para recovery/root/.

    • Quando vazio, os recursos de recuperação são criados apenas para recovery/root/ e não para vendor-ramdisk/.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT. Essa variável controla se as chaves AVB do GSI são criadas para vendor_boot.

    • Quando definido como true, se BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

      • Está 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 serão criadas para $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.

    • Quando vazio, se BOARD_RECOVERY_AS_ROOT:

      • Está 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 serão criadas para $ANDROID_PRODUCT_OUT/ramdisk/avb.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE. Essa variável controla se a imagem recovery contém um kernel ou não. Os dispositivos lançados com o Android 12 e que usam a partição recovery A/B precisam definir essa variável como true. Os dispositivos lançados com o Android 12 e que usam não A/B precisam definir essa variável como false para manter a imagem de recuperação independente.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES. Essa variável controla se $OUT/boot*.img é copiado para IMAGES/ nos arquivos de destino.

    • aosp_arm64 precisa definir essa variável como true.

    • Outros dispositivos precisam deixar essa variável vazia.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. Essa variável controla se init_boot.img é gerado e define o tamanho. Quando definido, o ramdisk genérico é adicionado ao init_boot.img em vez de boot.img e exige que as variáveis BOARD_AVB_INIT_BOOT* sejam definidas para vbmeta encadeada.

Combinações permitidas

Componente ou variável Fazer upgrade do dispositivo sem partição de recuperação Fazer upgrade do dispositivo com a partição de recuperação Iniciar o dispositivo sem partição de recuperação Iniciar o dispositivo com a partição de recuperação A/B Iniciar o dispositivo com uma partição de recuperação 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

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 estiver definido, uma imagem recovery será criada.

Ativar o vbmeta em cadeia para inicialização

O vbmeta encadeado precisa 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 conferir um exemplo, consulte esta mudança.

Sistema como raiz

O sistema como raiz não é compatível com dispositivos que usam a GKI. Nesses dispositivos, BOARD_BUILD_SYSTEM_ROOT_IMAGE precisa 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 precisam 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 impede que outros makefiles instalem acidentalmente outros arquivos no ramdisk. Em vez disso, mova esses arquivos para vendor_ramdisk.

Configurar dispositivos

As instruções de configuração são diferentes entre dispositivos lançados com o Android 13, atualizados para o Android 12 e lançados com o Android 12. Android 13, são configurados de forma semelhante ao Android 12

  • Dispositivos que estão fazendo upgrade para o Android 12:

    • Pode preservar o valor de BOARD_USES_RECOVERY_AS_BOOT. Se isso acontecer, elas estarão usando configurações legadas, e as novas variáveis de build precisarão estar vazias. Se esses dispositivos:

      • Defina BOARD_USES_RECOVERY_AS_BOOT como true. 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 isso acontecer, eles estarão usando novas configurações. Se esses dispositivos:

      • Não use uma partição recovery dedicada. A arquitetura é mostrada na Figura 1, e a opção de configuração do dispositivo é Opção 1.

      • Use uma partição recovery dedicada. A arquitetura é mostrada na Figura 2a ou Figura 2b, e a opção de configuração do dispositivo é Opção 2a ou Opção 2b.

  • Os dispositivos lançados com o Android 12 precisam definir BOARD_USES_RECOVERY_AS_BOOT como vazio e usar novas configurações. Se esses dispositivos:

    • Não use uma partição recovery dedicada. A arquitetura é mostrada na Figura 1, e a opção de configuração do dispositivo é Opção 1.

    • Use uma partição recovery dedicada. A arquitetura é mostrada na Figura 2a ou Figura 2b, e a opção de configuração do dispositivo é Opção 2a ou Opção 2b.

Como aosp_arm64 cria apenas GKI (e não vendor_boot ou recuperação), ele não é um destino completo. Para configurações de build aosp_arm64, consulte generic_arm64.

Opção 1: sem partição de recuperação dedicada

Os dispositivos sem uma partição recovery contêm a imagem genérica boot na partição 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, a configuração do produto herda o 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

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 é inicializado na recuperaçã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 é o seguinte:

  • /init (de ramdisk genérico, criado a partir de init_first_stage)
  • /system/bin/init (de vendor_ramdisk, criado a partir de init_second_stage.recovery)

Mover arquivos fstab

Mova todos os arquivos fstab que foram instalados no ramdisk genérico para vendor_ramdisk. Para conferir um exemplo, consulte esta mudança.

Instalar módulos

É possível instalar módulos específicos do dispositivo em vendor_ramdisk. Pule esta etapa se você não tiver módulos específicos do dispositivo para instalar.

  • Use a variante vendor_ramdisk do módulo quando ele for instalado no /first_stage_ramdisk. Esse módulo precisa estar disponível depois que init mudar a raiz para /first_stage_ramdisk, mas antes que init mude a raiz para /system. Para conferir exemplos, consulte Verificações de soma de verificação de metadados e Compressão A/B virtual.

  • Use a variante recovery do módulo quando ele for instalado em /. Esse módulo precisa estar disponível antes que init mude a raiz para /first_stage_ramdisk. Para detalhes sobre como instalar módulos no /, consulte Console da primeira fase.

Console da primeira fase

Como o console da primeira fase é iniciado antes que init mude a raiz para /first_stage_ramdisk, é necessário instalar a variante recovery dos módulos. Por padrão, as duas variantes do módulo são instaladas em build/make/target/product/base_vendor.mk. Portanto, se o makefile do dispositivo herdar desse arquivo, não será necessário 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 linker, sh e toybox sejam instalados em $ANDROID_PRODUCT_OUT/recovery/root/system/bin, que depois é instalado em /system/bin no vendor_ramdisk.

Para adicionar os módulos necessários ao console de primeira fase (por exemplo, adbd), use o seguinte procedimento.

PRODUCT_PACKAGES += adbd.recovery

Isso garante que os módulos especificados sejam instalados em $ANDROID_PRODUCT_OUT/recovery/root/system/bin, que depois é instalado em /system/bin no vendor_ramdisk.

Somas de verificação de metadados

Para oferecer suporte a checksums de metadados durante a montagem do primeiro estágio, os dispositivos que não oferecem suporte ao GKI instalam a variante ramdisk dos seguintes módulos. Para adicionar suporte ao 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 conferir um exemplo, consulte esta lista de mudanças.

Compactação A/B virtual

Para oferecer suporte à compactação A/B virtual, o snapuserd precisa ser instalado em vendor_ramdisk. O dispositivo precisa 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, com a seguinte exceção:

  • O Ramdisk build.prop é movido para /second_stage_resources para que o segundo estágio init possa ler o carimbo de data/hora do build da inicialização.

Como os recursos são movidos de um ramdisk genérico para um vendor_boot, o resultado da concatenação de um ramdisk genérico para um vendor_boot não muda.

Disponibilizar o e2fsck

Os makefiles do dispositivo podem herdar de:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk se o dispositivo oferece suporte a A/B virtual, mas não à compactação.

  • virtual_ab_ota/compression.mk se o dispositivo oferece suporte à compressã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 primeiro estágio init muda a raiz para /first_stage_ramdisk e, em seguida, executa /system/bin/e2fsck.

Opção 2a: partição dedicada e de recuperação A/B

Use essa opção para dispositivos com partições recovery A/B, ou seja, o dispositivo tem uma recovery_a e uma recovery_b partition. Esses 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 dos módulos do kernel do fornecedor, incluindo o seguinte:

  • Arquivos fstab específicos do dispositivo

  • lib/modules (inclui módulos de kernel do fornecedor)

O ramdisk recovery contém todos os recursos de recuperação. Nesses dispositivos, a configuração do produto herda o generic_ramdisk.mk.

Definir valores de BOARD

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

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 é sobrescrito. Quando o dispositivo é inicializado no modo de recuperação, o binário /system/bin/init é necessário para oferecer suporte à inicialização do segundo estágio.

Quando o dispositivo é inicializado em recovery, o conteúdo de recovery + vendor_boot + ramdisks genéricas é o seguinte:

  • /init (do ramdisk, criado a partir de init_first_stage)
  • /system/bin/init (do ramdisk recovery, criado a partir de init_second_stage.recovery e executado a partir de /init)

Quando o dispositivo é inicializado no Android, o conteúdo de vendor_boot + ramdisks genéricos é o seguinte:

  • /init (de ramdisk genérico, criado a partir de init_first_stage)

Mover arquivos fstab

Mova todos os arquivos fstab que foram instalados no ramdisk genérico para o vendor_ramdisk. Para conferir um exemplo, consulte esta mudança.

Instalar módulos

Opcionalmente, é possível instalar módulos específicos do dispositivo em vendor_ramdisk. Pule esta etapa se você não tiver módulos específicos do dispositivo para instalar. Init não muda a raiz. A variante vendor_ramdisk dos módulos é instalada na raiz de vendor_ramdisk. Para conferir exemplos de instalação de módulos em vendor_ramdisk, consulte Console de primeira fase, Checksums de metadados e Compressão A/B virtual.

Console da primeira fase

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 em $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, que depois é instalado em /system/bin no vendor_ramdisk.

Para adicionar módulos necessários ao console de primeiro estágio (por exemplo, adbd), ative a variante vendor_ramdisk desses módulos fazendo upload de patches relevantes para o AOSP e depois 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 em recovery. Se o ramdisk vendor_boot não for carregado no modo de recuperação, o dispositivo também poderá instalar o adbd.recovery.

Somas de verificação de metadados

Para oferecer suporte a checksums de metadados durante a montagem do primeiro estágio, os dispositivos que não oferecem suporte ao GKI instalam a variante ramdisk dos seguintes módulos. Para adicionar suporte ao 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 conferir um exemplo, consulte esta lista de mudanças.

Compactação A/B virtual

Para oferecer suporte à compactação A/B virtual, snapuserd precisa ser instalado em vendor_ramdisk. O dispositivo precisa herdar de virtual_ab_ota/compression.mk, que instala a variante vendor_ramdisk de snapuserd.

Mudanças no processo de inicialização

Ao inicializar o Android, o processo de inicialização não muda. O vendor_boot + ramdisk genérico é semelhante ao processo de inicialização atual, exceto que fstab carrega de vendor_boot. Como system/bin/recovery não existe, first_stage_init o processa como uma inicialização normal.

Quando o modo de recuperação é ativado, o processo de inicialização muda. A recuperação + vendor_boot + ramdisk genérico é semelhante ao processo de recuperação atual, mas o kernel é carregado da imagem boot, e não da imagem recovery. O processo de inicialização para o modo de recuperação é o seguinte.

  1. O gerenciador de inicialização é iniciado e faz o seguinte:

    1. A recuperação é enviada + vendor_boot + ramdisk genérico para /. Se o OEM duplicar os módulos do kernel no ramdisk de recuperação adicionando-os a BOARD_RECOVERY_KERNEL_MODULES, vendor_boot é opcional.)
    2. Executa o kernel da partição boot.

  2. O kernel monta o ramdisk em / e depois executa /init no ramdisk genérico.

  3. A inicialização do primeiro estágio é iniciada e faz o seguinte:

    1. Define IsRecoveryMode() == true e ForceNormalBoot() == false.
    2. Carrega módulos do kernel do fornecedor de /lib/modules.
    3. Chama DoFirstStageMount(), mas pula a montagem porque IsRecoveryMode() == true. O dispositivo não libera o ramdisk porque / ainda é o mesmo, mas chama SetInitAvbVersionInRecovery().
    4. Inicia a segunda etapa de inicialização de /system/bin/init do recovery ramdisk.

Disponibilizar o e2fsck

Os makefiles do dispositivo podem herdar de:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk se o dispositivo oferece suporte a A/B virtual, mas não à compactação.

  • virtual_ab_ota/compression.mk se o dispositivo oferece suporte à compressã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 essa opção para dispositivos com uma partição recovery não 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 virtual, em que a partição de recuperação não pode ser atualizada. 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 de kernel do fornecedor)

A imagem recovery precisa ser independente. Ele precisa conter todos os recursos necessários para inicializar o modo de recuperação, incluindo:

  • A imagem do kernel
  • A imagem da DTBO
  • Módulos do kernel em lib/modules
  • Inicialização de primeiro estágio como um link simbólico /init -> /system/bin/init
  • Binário de inicialização de segunda fase /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 generic_ramdisk.mk.

Definir valores de BOARD

Defina os seguintes valores para dispositivos que não sã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

O ramdisk recovery precisa conter um link simbólico /init -> /system/bin/init e init_second_stage.recovery em /system/bin/init. Quando o dispositivo é inicializado no modo de recuperação, o binário /system/bin/init é necessário para oferecer suporte à inicialização do primeiro e do segundo estágio.

Quando o dispositivo é inicializado no recovery, o conteúdo das ramdisks recovery é o seguinte:

  • /init -> /system/bin/init (de recovery ramdisk)
  • /system/bin/init (do ramdisk recovery, criado a partir de init_second_stage.recovery e executado a partir de /init)

Quando o dispositivo é inicializado no Android, o conteúdo de vendor_boot + ramdisks genéricos é o seguinte:

  • /init (do ramdisk, criado a partir de init_first_stage)

Mover arquivos fstab

Mova todos os arquivos fstab que foram instalados no ramdisk genérico para o vendor_ramdisk e recovery. Para conferir um exemplo, consulte esta mudança.

Instalar módulos

É possível instalar módulos específicos do dispositivo em vendor_ramdisk e recovery ramdisk. Pule esta etapa se você não tiver módulos específicos do dispositivo para instalar. init não muda a raiz. A variante vendor_ramdisk dos módulos é instalada na raiz de vendor_ramdisk. A variante recovery dos módulos é instalada na raiz do ramdisk recovery. Para exemplos de instalação de módulos no vendor_ramdisk e no ramdisk recovery, consulte Console de primeiro estágio e Chaves de somatório de metadados.

Console da primeira fase

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 em $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, que depois é instalado em /system/bin no vendor_ramdisk.

Para adicionar módulos necessários ao console de primeiro estágio (por exemplo, adbd), ative a variante vendor_ramdisk desses módulos fazendo upload de patches relevantes para o AOSP e depois 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 checksums de metadados durante a montagem do primeiro estágio, os dispositivos que não oferecem suporte ao GKI instalam a variante ramdisk dos seguintes módulos. Para adicionar suporte ao 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

Ao inicializar o Android, o processo de inicialização não muda. O vendor_boot + ramdisk genérico é semelhante ao processo de inicialização atual, exceto que fstab carrega de vendor_boot. Como system/bin/recovery não existe, first_stage_init o processa 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 atual. O kernel é carregado da imagem recovery. O processo de inicialização para o modo de recuperação é o seguinte.

  1. O gerenciador de inicialização é iniciado e faz o seguinte:

    1. Envia o ramdisk de recuperação para /.
    2. Executa o kernel da partição recovery.

  2. O kernel monta o ramdisk em / e executa /init, que é um link simbólico para /system/bin/init do ramdisk recovery.

  3. A inicialização do primeiro estágio é iniciada e faz o seguinte:

    1. Define IsRecoveryMode() == true e ForceNormalBoot() == false.
    2. Carrega módulos do kernel do fornecedor de /lib/modules.
    3. Chama DoFirstStageMount(), mas pula a montagem porque IsRecoveryMode() == true. O dispositivo não libera o ramdisk porque / ainda é o mesmo, mas chama SetInitAvbVersionInRecovery().
    4. Inicia a segunda etapa de inicialização de /system/bin/init do recovery ramdisk.

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 momento do build, um arquivo system/etc/ramdisk/build.prop é adicionado ao ramdisk genérico. Este arquivo contém informações de carimbo de data/hora do build.

  • No momento da execução, a init da primeira etapa copia arquivos do ramdisk para tmpfs antes de liberar o ramdisk para que a init da segunda etapa possa ler esse arquivo para definir as propriedades do carimbo de data/hora da imagem boot.