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

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 de forma 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 ramdisk vendor_boot.

  • Usar uma partição recovery dedicada (sem mudanças no ramdisk recovery). é necessário porque o ramdisk recovery é 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

Iniciar/atualizar dispositivo, GKI, 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)

Inicie/atualize o dispositivo, GKI, dedicado e recuperação A/B

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)

Lançamento/upgrade de dispositivo, GKI, recuperação dedicada e não A/B

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

Iniciar/atualizar dispositivo, GKI, 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)

Inicie/atualize o dispositivo, GKI, dedicado e recuperação A/B

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)

Lançamento/upgrade de dispositivo, GKI, recuperação dedicada e não A/B

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)

Iniciar/atualizar dispositivo, sem GKI, recuperação como inicialização

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)

Lançamento/upgrade do dispositivo, sem GKI, recuperação dedicada

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 certificada boot.img não está assinada para inicialização verificada. Os OEMs ainda precisam assinar o boot.img pré-criado com uma cláusula AVB (link em inglês) de dados.
      • Genérica cmdline (GENERIC_KERNEL_CMDLINE)
      • Kernel de GKI
    • Imagem genérica do ramdisk
      • Incluídas apenas em boot imagens do Android 12 e anteriores

  • 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 ramdisk
      • lib/modules
      • Recursos de recuperação (se não houver recuperação dedicada)
    • Imagem dtb

  • 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 a boot e vendor_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 e vendor_boot. Exemplo:
      • cmdline é concatenado com boot e vendor_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 ramdisk vendor_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.

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/ de metadata/
  • first_stage_ramdisk/
    • Diretórios vazios duplicados para pontos de montagem: debug_ramdisk/, mnt/, dev/, sys/, proc/ e metadata/

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 como true, defina BOARD_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 imagem recovery como a imagem boot. Ao usar a GKI, essa variável é vazio, e os recursos de recuperação precisam ser movidos para vendor_boot.

  • BOARD_USES_GENERIC_KERNEL_IMAGE: Essa variável indica que o quadro usa GKI. Essa variável não afeta sysprops ou PRODUCT_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 para vendor_boot.

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

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

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT: Essa variável controla se a GSI As chaves AVB são criadas para vendor_boot.

    • Quando definido como true, se BOARD_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 imagem recovery contém ou não um kernel. Dispositivos lançados com o Android 12 e usando a partição recovery A/B precisam definir essa como true. Dispositivos lançados com o Android 12 e usar um valor diferente de A/B precisa definir essa variável como false 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 para IMAGES/ nos arquivos de destino.

    • aosp_arm64 precisa definir essa variável como true.

    • Outros dispositivos precisam deixar essa variável em branco.

  • 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 do boot.img e requer o BOARD_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:

      • Defina BOARD_USES_RECOVERY_AS_BOOT como true. A arquitetura é mostrados na Figura 3.

      • Defina BOARD_USES_RECOVERY_AS_BOOT como vazio. A arquitetura vai ficar assim: Figura 4.

    • Pode definir BOARD_USES_RECOVERY_AS_BOOT como vazio. Se eles fizerem isso, estão usando para criar novas configurações. Se esses dispositivos:

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

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

  • Os dispositivos lançados com o Android 12 precisam configurar BOARD_USES_RECOVERY_AS_BOOT para esvaziar e usar novas configurações. Se dispositivos:

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

    • Use uma partição recovery dedicada. A arquitetura é a mostrada em Figura 2a ou Figura 2b e a 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 objetivo completo. Para conferir as aosp_arm64configuraçõ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

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 de init_first_stage)
  • /system/bin/init (a partir de vendor_ramdisk, criado a partir de init_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ós init alterna raiz para /first_stage_ramdisk mas antes de init 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 que init 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ágio init 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 dispositivo

  • lib/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

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 de init_first_stage)
  • /system/bin/init (do ramdisk de recovery, criado a partir de init_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 genérico, criado a partir de init_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.

  1. O carregador de inicialização é iniciado e, em seguida, faz o seguinte:

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

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

  3. O init do primeiro estágio é iniciado e, em seguida, faz o seguinte:

    1. Define IsRecoveryMode() == true e ForceNormalBoot() == false.
    2. Carrega os 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 inicialização do segundo estágio de /system/bin/init no ramdisk recovery.

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

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 de recovery)
  • /system/bin/init (do ramdisk de recovery, criado a partir de init_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, criado a partir de init_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.

  1. O carregador de inicialização é iniciado e, em seguida, 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 para / e executa /init, que é um link simbólico para /system/bin/init do ramdisk recovery.

  3. O init do primeiro estágio é iniciado e, em seguida, faz o seguinte:

    1. Define IsRecoveryMode() == true e ForceNormalBoot() == false.
    2. Carrega os 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 inicialização do segundo estágio de /system/bin/init no ramdisk recovery.

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 para tmpfs antes de liberar o ramdisk para que o segundo estágio init pode ler neste arquivo para definir boot propriedades de carimbo de data/hora da imagem.