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

No Android 12, a imagem de boot genérica contém o ramdisk de boot genérico e a imagem de kernel genérica (GKI) . 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 o init do primeiro estágio e um arquivo de propriedades que contenha informações de carimbo de data/hora.

Em dispositivos que:

  • Não use uma partição de recovery dedicada, todos os bits de recuperação se movem do disco de inicialização para o disco de inicialização do vendor_boot .

  • Use uma partição de recovery dedicada, nenhuma alteração no disco ram de recovery é necessária porque o disco ram de recovery é independente.

Arquitetura

Os diagramas a seguir ilustram a arquitetura para dispositivos que executam o Android 12.

Inicie ou atualize para o Android 12, sem recuperação dedicada

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

Figura 1. 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 (disco ram dedicado)

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

Figura 2a. Dispositivos iniciando ou atualizando para o Android 12, com GKI, dedicado e recuperação A/B

Consulte esta figura se a recovery for A/B; ou seja, o dispositivo tem partições recovery_a e recovery_b .

Inicie ou atualize para o Android 12, recuperação dedicada e não A/B (disco ram dedicado)

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

Figura 2b. Dispositivos iniciando ou atualizando para o Android 12, com GKI, recuperação dedicada e não A/B

Consulte esta figura se a recovery não for A/B; ou seja, o dispositivo tem uma partição chamada recovery sem sufixo de slot.

Atualize para o Android 12, recuperação como inicialização (recuperação como disco ram)

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

Figura 3. Dispositivos atualizados para o Android 12, sem GKI, recuperação como inicialização

Atualize para o Android 12, recuperação dedicada (disco ram dedicado)

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

Figura 4. Dispositivos atualizados para Android 12, sem GKI, recuperação dedicada

Conteúdo das imagens de inicialização

No Android 12, as imagens de inicialização contêm o seguinte.

  • Imagem boot genérica
    • Versão do cabeçalho V3 ou V4
      • Um boot_signature para certificação GKI boot.img (somente v4). O GKI boot.img certificado não está assinado para inicialização verificada. Os OEMs ainda devem assinar o boot.img pré-compilado com uma chave AVB específica do dispositivo.
      • Linha GENERIC_KERNEL_CMDLINE cmdline
      • Imagem genérica do kernel
    • Imagem genérica do disco ram boot
  • imagem vendor_boot (para obter detalhes, consulte Partições de inicialização do fornecedor )
    • cabeçalho vendor_boot
      • Linha de BOARD_KERNEL_CMDLINE cmdline
    • imagem de disco ram vendor_boot
      • 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 partição de recuperação não A/B, o conteúdo do cabeçalho deve ser autônomo; consulte Imagens de Recuperação . Por exemplo:
      • cmdline não é concatenado para boot e vendor_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 e vendor_boot . Por exemplo:
      • cmdline é concatenado para boot e vendor_boot cmdline .
      • DTBO pode ser inferido do cabeçalho vendor_boot .
    • imagem de disco ram de recovery
      • Recursos de recuperação
      • Para partição de recuperação não A/B, o conteúdo do ramdisk deve ser autônomo; consulte 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 disco ram de recuperação é anexado ao disco ram boot e vendor_boot , portanto, não precisa ser autônomo. Por exemplo:
      • lib/modules pode conter apenas módulos de kernel adicionais necessários para inicializar o modo de recuperação além dos módulos de kernel em vendor_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.

Conteúdo genérico da imagem do disco ram de inicialização

No Android 12, o ramdisk de boot 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/

Integração de imagem de inicialização

Os sinalizadores de compilação controlam como as imagens boot , recovery e vendor_boot são criadas. O valor de uma variável booleana de placa 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 como true , defina BOARD_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 imagem de recovery como a imagem de boot . Ao usar o GKI, essa variável está vazia e os recursos de recuperação devem ser movidos para vendor_boot .

  • BOARD_USES_GENERIC_KERNEL_IMAGE . Essa variável indica que a placa usa GKI e imagem de boot genérica. Esta variável não afeta sysprops ou PRODUCT_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 criados para vendor_boot .

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

    • Quando vazios, os recursos de recuperação são compilados 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 GSI AVB 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 .

      • Não está definido, as chaves GSI AVB sã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 .

      • Não está definido, 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 imagem de recovery contém um kernel ou não. Dispositivos iniciados com Android 12 e usando partição de recovery A/B devem definir essa variável como true . Os dispositivos iniciados com o Android 12 e que não usam A/B devem definir essa variável como false para manter a imagem de recuperação independente.

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

    • aosp_arm64 deve definir esta variável como true .

    • Outros dispositivos devem deixar esta variável vazia.

Combinações permitidas

Componente ou variável Atualizando dispositivo sem partição de recovery Atualizando dispositivo com partição de recovery Iniciar dispositivo sem partição de recovery Inicie o dispositivo com partição de recovery A/B Iniciar dispositivo com partição de recovery não A/B aosp_arm64
Contém boot sim sim 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_RESOURCE_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 de recovery dedicada podem definir PRODUCT_BUILD_RECOVERY_IMAGE como true ou vazio. Para esses dispositivos, se BOARD_RECOVERYIMAGE_PARTITION_SIZE estiver definido, uma imagem de recovery será criada.

Ativar vbmeta encadeado para inicialização

O vbmeta encadeado deve ser habilitado para a imagem de 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

Para obter um exemplo, consulte esta alteração .

Sistema como raiz

O sistema como raiz não é compatível com dispositivos que usam GKI e a imagem de inicialização genérica, independentemente de o dispositivo oferecer suporte ao módulo GKI atualizável. Nesses dispositivos, BOARD_BUILD_SYSTEM_ROOT_IMAGE deve estar vazio. System-as-root também não é compatível com dispositivos que usam partições dinâmicas, o que é um requisito para o uso do módulo GKI atualizável.

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 atualizados para o Android 12 e iniciados com o Android 12.

  • Dispositivos atualizados 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 compilação devem estar vazias. Se tais dispositivos:

      • Defina BOARD_USES_RECOVERY_AS_BOOT como true , a arquitetura é conforme mostrado na Figura 3 .

      • Defina BOARD_USES_RECOVERY_AS_BOOT para vazio, a arquitetura é conforme mostrado na Figura 4 .

    • Pode definir BOARD_USES_RECOVERY_AS_BOOT como vazio. Se o fizerem, estarão usando novas configurações. Se tais dispositivos:

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

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

  • Dispositivos iniciados com Android 12 devem definir BOARD_USES_RECOVERY_AS_BOOT como vazio e usar novas configurações. Se tais dispositivos:

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

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

Como o aosp_arm64 constrói apenas o GKI e a imagem de boot genérica (e não o vendor_boot ou a recuperação), 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 partição de recovery contêm a imagem de boot genérica na partição de 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 é herdada de generic_ramdisk.mk .

Configurando 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 disco RAM de boot é concatenado após o disco vendor_boot , o link simbólico /init é substituído. Quando o dispositivo inicializa na 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 + boot ramdisks é o seguinte:

  • /init (do ramdisk, construído a partir de init_first_stage )
  • /system/bin/init (de vendor_ramdisk , construído a partir de init_second_stage.recovery )

Movendo arquivos fstab

Mova todos os arquivos fstab que foram instalados no ramdisk de boot 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 no 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ós o init mudar o root para /first_stage_ramdisk mas antes do init mudar o root para /system . Para obter exemplos, consulte Somas de verificação de metadados e compactação A/B virtual .

  • Use a variante de recovery do módulo quando o módulo for instalado em / . Este módulo deve estar disponível antes que o init mude o root para /first_stage_ramdisk . Para obter detalhes sobre a instalação de módulos em / , consulte Console do primeiro estágio .

Console do primeiro estágio

Como o console do primeiro estágio é iniciado antes que o init alterne a raiz para /first_stage_ramdisk , você precisa instalar a variante de recovery dos módulos. Por padrão, ambas as variantes de 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 precisa instalar explicitamente a variante de 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 instalados em $ANDROID_PRODUCT_OUT/recovery/root/system/bin , que será instalado em /system/bin sob o vendor_ramdisk .

Para adicionar módulos necessários para o console do 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 será instalado em /system/bin sob o vendor_ramdisk .

Somas de verificação de metadados

Para dar suporte a somas de verificação de metadados durante a montagem do primeiro estágio, os dispositivos que não são compatíveis com GKI instalam a variante 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 \
    resizefs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Para obter um exemplo, consulte esta lista de alterações .

Compressão A/B virtual

Para dar 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 do snapuserd .

Alterações no processo de inicialização

O processo de inicialização na recuperação ou no Android não muda, com a seguinte exceção:

  • Ramdisk build.prop move-se para /second_stage_resources para que o init do segundo estágio possa ler o timestamp de inicialização.

Como os recursos são movidos de boot ramdisk para vendor_boot ramdisk, o resultado da concatenação de boot para vendor_boot ramdisk não muda.

Disponibilizando o e2fsck

Os makefiles do dispositivo podem herdar de:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk se o dispositivo for compatível com A/B virtual, mas não com 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/first_stage_ramdisk/system/bin/e2fsck . Em tempo de execução, o init do primeiro estágio alterna a raiz para /first_stage_ramdisk e executa /system/bin/e2fsck .

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

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

  • Arquivos fstab específicos do dispositivo

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

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

Configurando valores de BOARD

Defina os seguintes valores para dispositivos com partição de 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 de recovery pode conter um link simbólico /init -> /system/bin/init e init_second_stage.recovery em /system/bin/init . No entanto, como o disco ram de inicialização é concatenado após o disco ram de 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 + boot ramdisks é o seguinte:

  • /init (do ramdisk, construído a partir de init_first_stage )
  • /system/bin/init (do disco ram de recovery , construído a partir de init_second_stage.recovery e executado a partir de /init )

Quando o dispositivo inicializa no Android, o conteúdo de vendor_boot + boot ramdisks é o seguinte:

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

Movendo arquivos fstab

Mova quaisquer arquivos fstab que foram instalados no ramdisk de boot para o vendor_ramdisk . Para obter um exemplo, consulte esta alteração .

Instalando módulos

Se desejar, você pode instalar módulos específicos do dispositivo no vendor_ramdisk (pule esta etapa se não tiver nenhum módulo específico do dispositivo para instalar). Init não muda o root. A variante de módulos vendor_ramdisk é instalada na raiz de vendor_ramdisk . Para obter exemplos de instalação de módulos no vendor_ramdisk , consulte Console do 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 instalados em $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , que será instalado em /system/bin sob o vendor_ramdisk .

Para adicionar módulos necessários para o console do primeiro estágio (por exemplo, adbd), habilite a variante vendor_ramdisk desses módulos fazendo upload de patches relevantes para o AOSP e 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 estiver carregado no modo de recuperação, o dispositivo também pode opcionalmente instalar o adbd.recovery .

Somas de verificação de metadados

Para dar suporte a somas de verificação de metadados durante a montagem do primeiro estágio, os dispositivos que não são compatíveis com GKI instalam a variante 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 \
    resizefs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Para obter um exemplo, consulte esta lista de alterações .

Compressão A/B virtual

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 do snapuserd .

Alterações no processo de inicialização

Ao inicializar no Android, o processo de inicialização não muda. O vendor_boot + boot ramdisk é semelhante ao processo de inicialização existente, exceto que o fstab é carregado de vendor_boot . Como system/bin/recovery não existe, first_stage_init o trata como uma inicialização normal.

Ao inicializar no modo de recuperação, o processo de inicialização muda. O recovery + vendor_boot + boot ramdisk é semelhante ao processo de recuperação existente, mas o kernel é carregado a partir da imagem de boot em vez da imagem de recovery . O processo de inicialização para o modo de recuperação é o seguinte.

  1. Bootloader é iniciado e, em seguida, faz o seguinte:

    1. Empurra recovery + vendor_boot + boot ramdisk 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 a partir da partição de boot .

  2. O kernel monta o ramdisk em / e depois executa /init a partir do ramdisk de boot .

  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 ignora a montagem porque IsRecoveryMode() == true . (O dispositivo não libera ramdisk (porque / ainda é o mesmo), mas chama SetInitAvbVersionInRecovery() .)
    4. Inicia a inicialização do segundo estágio a partir de /system/bin/init do disco ram de recovery .

Disponibilizando o e2fsck

Os makefiles do dispositivo podem herdar de:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk se o dispositivo for compatível com A/B virtual, mas não com 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 . Em 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 de recovery não A/B; ou seja, o dispositivo tem uma partição chamada recovery sem sufixo de slot. Tais dispositivos incluem:

  • dispositivos não A/B;
  • Dispositivos A/B e Virtual A/B, dos quais a partição de recuperação não é atualizável. (Isso é incomum.)

O ramdisk vendor_boot contém os bits do fornecedor dos módulos do ramdisk e do kernel do fornecedor, incluindo o seguinte:

  • Arquivos fstab específicos do dispositivo
  • lib/modules (inclui módulos de kernel do fornecedor)

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

  • A imagem do núcleo
  • A imagem 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 segundo estágio /system/bin/init
  • Arquivos fstab específicos do dispositivo
  • Todos os outros recursos de recuperação, incluindo o binário de recovery , etc.
  • etc.

Nesses dispositivos, a configuração do produto é herdada de generic_ramdisk.mk .

Configurando 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 de recovery deve 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 dar suporte ao init de primeiro e segundo estágio.

Quando o dispositivo é inicializado em recovery , o conteúdo dos ramdisks de recovery é o seguinte:

  • /init -> /system/bin/init (do disco ram de recovery )
  • /system/bin/init (do disco ram de recovery , construído a partir de init_second_stage.recovery e executado a partir de /init )

Quando o dispositivo inicializa no Android, o conteúdo de vendor_boot + boot ramdisks é o seguinte:

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

Movendo arquivos fstab

Mova todos os arquivos fstab que foram instalados no ramdisk de boot para o vendor_ramdisk e o recovery ramdisk. Para obter um exemplo, consulte esta alteração .

Instalando módulos

Se desejar, você pode instalar módulos específicos do dispositivo no vendor_ramdisk e no recovery ramdisk (pule esta etapa se você 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 de recovery de módulos é instalada na raiz do disco ram de recovery . Para obter exemplos de instalação de módulos em vendor_ramdisk e recovery ramdisk, 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 instalados em $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin , que será instalado em /system/bin sob o vendor_ramdisk .

Para adicionar módulos necessários para o console do primeiro estágio (por exemplo, adbd), habilite a variante vendor_ramdisk desses módulos fazendo upload de patches relevantes para o AOSP e 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 de 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 somas de verificação de metadados durante a montagem do primeiro estágio, os dispositivos que não são compatíveis com GKI instalam a variante 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 \
    resizefs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

Para dar 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 + boot ramdisk é semelhante ao processo de inicialização existente, exceto que o fstab é carregado de vendor_boot . Como system/bin/recovery não existe, first_stage_init o trata 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 de recovery . O processo de inicialização para o modo de recuperação é o seguinte.

  1. Bootloader é iniciado e, em seguida, faz o seguinte:

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

  2. O kernel monta o ramdisk para / então executa /init , que é um link simbólico para /system/bin/init do ramdisk de 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 ignora a montagem porque IsRecoveryMode() == true . (O dispositivo não libera ramdisk (porque / ainda é o mesmo), mas chama SetInitAvbVersionInRecovery() .)
    4. Inicia a inicialização do segundo estágio a partir de /system/bin/init do disco ram de recovery .

Carimbos de data e hora da imagem de inicialização

O código a seguir é um arquivo de carimbo de data/hora de imagem de boot de exemplo.

####################################
# 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 da imagem de boot genérica. Este arquivo contém informações de carimbo de data/hora da compilação.

  • Em tempo de execução, o init do primeiro estágio copia os arquivos do ramdisk para o tmpfs antes de liberar o ramdisk para que o init do segundo estágio possa ler esse arquivo para definir as propriedades de registro de data e hora da imagem de boot .