O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

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

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

No Android 12, a imagem de boot genérica, conhecida como Generic Kernel Image (GKI) , contém o ramdisk genérico e o kernel GKI.

Para dispositivos iniciados com o Android 13, o ramdisk genérico é removido da imagem de boot e colocado em uma imagem init_boot separada. Essa alteração deixa a imagem de boot apenas com o kernel GKI.

Para dispositivos de atualização que continuam a usar o Android 12 ou versões mais antigas do kernel, o ramdisk genérico permanece onde estava, sem a necessidade de uma nova imagem init_boot .

Para construir um ramdisk genérico, mova os recursos específicos do fornecedor para fora do ramdisk de forma que o ramdisk genérico contenha apenas 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 ramdisk genérico para o vendor_boot ramdisk.

  • 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 e superior. A inicialização do dispositivo com o Android 13 tem uma nova imagem init_boot contendo o ramdisk genérico. Os dispositivos atualizados do Android 12 para o Android 13 usam a mesma arquitetura do Android 12.

Inicie com o Android 13, sem recuperação dedicada

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

Figura 1. Dispositivos iniciando ou atualizando para o Android 13, com GKI, sem recuperação dedicada

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

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

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

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

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

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

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

Consulte esta figura se o dispositivo tiver uma partição chamada recovery sem sufixo de slot.

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

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

Figura 4. Dispositivos iniciando ou atualizando para o Android 12, com GKI, sem recuperação dedicada

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

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

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

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

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

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

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

Consulte esta figura se o dispositivo tiver uma partição 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 7. Dispositivos atualizados para 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 8. Dispositivos atualizados para Android 12, sem GKI, recuperação dedicada

Conteúdo das imagens de inicialização

As imagens de inicialização do Android contêm o seguinte.

  • Imagem init_boot adicionada para dispositivos iniciados com Android 13

    • Versão do cabeçalho V4
    • Imagem genérica de ramdisk
  • 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
      • Núcleo GKI
    • Imagem genérica de ramdisk
      • Incluído apenas em imagens de boot do Android 12 e anteriores
  • 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 ramdisk de recuperação é anexado ao ramdisk genérico 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 ramdisk

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

  • init
  • Adicionado system/etc/ramdisk/build.prop
  • ro. PRODUCT .bootimg.* build
  • Diretórios vazios para pontos de montagem: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/
  • first_stage_ramdisk/
    • Diretórios vazios duplicados para pontos de montagem: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/

Integração de imagem de inicialização

Os sinalizadores de compilação controlam como as init_boot , 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 . Esta variável indica que a placa usa GKI. 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.

  • 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 requer que as variáveis BOARD_AVB_INIT_BOOT* sejam definidas para vbmeta encadeado

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 init_boot (Android 13) não não não 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 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 as imagens boot e init_boot . Especifique o seguinte:

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

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

Sistema como raiz

O sistema como raiz não é compatível com dispositivos que usam GKI. Nesses dispositivos, BOARD_BUILD_SYSTEM_ROOT_IMAGE deve estar vazio. O sistema como raiz também não é compatível com dispositivos que usam partições dinâmicas.

Configurações do produto

Os dispositivos que usam o ramdisk genérico devem instalar uma lista de arquivos que podem ser instalados no ramdisk. Para fazer isso, especifique o seguinte em device.mk :

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

O arquivo generic_ramdisk.mk também evita que outros makefiles instalem acidentalmente outros arquivos no ramdisk (em vez disso, mova esses arquivos para vendor_ramdisk ).

Configurando dispositivos

As instruções de configuração diferem entre os dispositivos iniciados com o Android 13, atualizados para o Android 12 e iniciados com o Android 12. O Android 13 é configurado de forma semelhante à do Android 12

  • Atualização de dispositivos 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 aosp_arm64 compila apenas GKI (e não vendor_boot ou 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 ramdisk genérico é concatenado após o ramdisk 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 + ramdisks genéricos são os seguintes:

  • /init (do ramdisk genérico, 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 quaisquer arquivos fstab que foram instalados no ramdisk genérico para vendor_ramdisk . Para obter um exemplo, consulte esta alteração .

Instalando módulos

Se desejar, você pode instalar módulos específicos do dispositivo 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 \
    resize2fs.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 do ramdisk genérico para o ramdisk vendor_boot , o resultado da concatenação do ramdisk genérico para o ramdisk vendor_boot não muda.

Disponibilizando o e2fsck

Os makefiles do dispositivo podem herdar de:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk se o dispositivo 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 + ramdisks genéricos é 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 + ramdisks genéricos é o seguinte:

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

Movendo arquivos fstab

Mova quaisquer arquivos fstab que foram instalados no ramdisk genérico 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 \
    resize2fs.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 + ramdisk genérico é 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 + ramdisk genérico é 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 + 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 a partir da partição de boot .
  2. O kernel monta o ramdisk em / e depois executa /init a partir do 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 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 + ramdisks genéricos é 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 genérico para o vendor_ramdisk e o ramdisk de recovery . 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 \
    resize2fs.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 + ramdisk genérico é 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 genérico. 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 .