Layout de partição

No Android 10, o sistema de arquivos raiz não é mais incluído em ramdisk.img e, em vez disso, integrado system.img (ou seja, system.img é sempre criado como se BOARD_BUILD_SYSTEM_ROOT_IMAGE estiver definido). Dispositivos com o Android 10:

  • Usar um layout de sistema como partição raiz (aplicado automaticamente pelo criar sem opções para mudar o comportamento).
  • É necessário usar um ramdisk, que é necessário para dm linear.
  • É preciso definir BOARD_BUILD_SYSTEM_ROOT_IMAGE como false. Esta configuração é usada apenas para diferenciar dispositivos que usam ramdisk e dispositivos que não usam ramdisk e montam system.img diretamente).

O significado de uma configuração de sistema como raiz é diferente no Android 9 e Android 10 Em um sistema Android 9, como raiz, definida, BOARD_BUILD_SYSTEM_ROOT_IMAGE é definida como true, que força o build a mesclar o sistema de arquivos raiz na system.img e, em seguida, ativar system.img como o arquivo raiz. do Compute Engine (rootfs). Esta configuração é obrigatória para dispositivos lançados com o Android 9, mas é opcional para dispositivos que passam por upgrade para Android 9 e para dispositivos com versões anteriores do Android. Em um ambiente 10 configuração do sistema como raiz, o build sempre mescla $TARGET_SYSTEM_OUT e $TARGET_ROOT_OUT em system.img essa configuração é o comportamento padrão para todos os dispositivos com o Android 10.

O Android 10 faz mais mudanças no suporte partições dinâmicas, um sistema de particionamento de espaço do usuário que permite atualizações over the air (OTA) para criar, redimensionar ou destruir partições. Como parte dessa mudança, o Linux o kernel não consegue mais montar a partição lógica do sistema em dispositivos em execução Android 10, portanto, essa operação é processada pela primeira inicialização do estágio.

As seções a seguir descrevem os requisitos do sistema como raiz para OTAs somente do sistema, orientações sobre como atualizar dispositivos para usar o sistema como raiz (incluindo alterações de layout de partição e requisitos de kernel dm-verity). Para detalhes sobre as mudanças no ramdisk, consulte Ramdisk Partições.

Sobre OTAs somente no sistema

OTAs somente do sistema, que permitem que as versões do Android sejam atualizadas system.img e product.img sem mudar as outras as partições precisam de um layout de sistema como partição raiz. Todos os dispositivos com Android 10 precisa usar um layout de sistema como partição raiz para ativar OTAs somente no sistema.

  • Dispositivos A/B, que montam a partição system como rootfs. já usam o sistema como raiz e não exigem alterações para dar suporte a OTAs do sistema.
  • Dispositivos não A/B, que montam a partição system em /system precisa ser atualizado para usar um layout de partição raiz para dar suporte a atualizações OTA do sistema.

Para detalhes sobre dispositivos A/B e não A/B, consulte Atualizações do Sistema A/B (Contínuas).

Usar sobreposição de fornecedor (<=AOSP 14)

A sobreposição de fornecedor permite sobrepor mudanças no vendor na inicialização do dispositivo. Uma sobreposição de fornecedor é um conjunto de módulos de fornecedor em da partição product que são sobrepostas no vendor partição quando o dispositivo é inicializado, substituindo e adicionando aos módulos existentes.

Quando o dispositivo é inicializado, o processo init conclui a primeira montagem de cenário e lê as propriedades padrão. Depois, pesquisa /product/vendor_overlay/<target_vendor_version> e suportes cada subdiretório no diretório de partição vendor correspondente, se as seguintes condições forem atendidas:

  • /vendor/<overlay_dir> já existe.
  • /product/vendor_overlay/<target_vendor_version>/<overlay_dir> tem o mesmo contexto de arquivo que /vendor/<overlay_dir>.
  • init tem permissão para ser montado no contexto do arquivo de /vendor/<overlay_dir>.

Implementar a sobreposição de fornecedores

Instalar os arquivos de sobreposição de fornecedores em /product/vendor_overlay/<target_vendor_version>: Esses arquivos sobrepor a partição vendor quando o dispositivo for inicializado, substituindo os arquivos com o mesmo nome e adicionar novos arquivos. A sobreposição do fornecedor não pode remover os arquivos da partição vendor.

Os arquivos de sobreposição do fornecedor precisam ter o mesmo contexto de arquivo que os arquivos de destino que eles vão substituir na partição vendor. Por padrão, os arquivos na pasta Diretório /product/vendor_overlay/<target_vendor_version> têm o contexto vendor_file. Se houver incompatibilidades de contexto de arquivo entre os arquivos de sobreposição do fornecedor e os arquivos que eles substituem, especifique no sepolicy específica do dispositivo. O contexto do arquivo é definido no nível do diretório. Se o o contexto do arquivo de um diretório de sobreposição de fornecedor não corresponde ao diretório de destino, e o contexto de arquivo correto não for especificado na sepolicy específica do dispositivo, que o diretório de sobreposição do fornecedor não seja sobreposto ao diretório de destino.

Para usar a sobreposição de fornecedor, o kernel precisa ativar a OverlayFS configurando CONFIG_OVERLAY_FS=y: Além disso, o kernel deve ser mesclado kernel comum 4.4 ou posterior ou corrigido com "overlayfs: override_creds=off option bypass creator_cred".

Exemplo de implementação de sobreposição do fornecedor

Este procedimento demonstra a implementação de uma sobreposição de fornecedor que se sobrepõe à diretórios /vendor/lib/*, /vendor/etc/* e /vendor/app/*

  1. Adicione arquivos de fornecedores pré-criados no device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/:

    device/google/device/vendor_overlay/28/lib/libfoo.so
device/google/device/vendor_overlay/28/lib/libbar.so
device/google/device/vendor_overlay/28/etc/baz.xml
device/google/device/vendor_overlay/28/app/qux.apk

  2. Instale os arquivos de fornecedor pré-criados no product/vendor_overlay pol. device/google/device/device.mk:

    PRODUCT_COPY_FILES += \
    $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)

  3. Defina contextos de arquivo se os arquivos de partição vendor de destino tenham contextos diferentes de vendor_file. Devido ao /vendor/lib/* usa o contexto vendor_file, esse não inclua esse diretório.

    Adicione o seguinte a device/google/device-sepolicy/private/file_contexts:

    /(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)?   u:object_r:vendor_configs_file:s0
/(product|system/product)/vendor_overlay/[0-9]+/app(/.*)?   u:object_r:vendor_app_file:s0

  4. Permitir que o processo init monte a sobreposição do fornecedor no arquivo contextos diferentes de vendor_file. Como o init processo já tem permissão para montar no contexto vendor_file, este exemplo não define a política para vendor_file.

    Adicione o seguinte a device/google/device-sepolicy/public/init.te:

    allow init vendor_configs_file:dir mounton;
allow init vendor_app_file:dir mounton;

Validar sobreposição do fornecedor

Para validar a configuração da sobreposição do fornecedor, adicione arquivos ao /product/vendor_overlay/<target_vendor_version>/<overlay_dir> e verificar se os arquivos estão sobrepostos nos arquivos /vendor/<overlay_dir>.

Para builds userdebug, há um módulo de teste para Atest:

$ atest -v fs_mgr_vendor_overlay_test

Atualizar para sistema como raiz

Para atualizar dispositivos não A/B para usar o sistema como raiz, atualize o de particionamento para boot.img e system.img, definido até o dm-verity e remova todas as dependências de inicialização da raiz específica do dispositivo. do Google Cloud.

Atualizar partições

Ao contrário de dispositivos A/B que reutilizam /boot como o recovery, Os dispositivos não A/B precisam manter a partição /recovery separados porque não têm a partição de slot de fallback (por exemplo, de boot_a a boot_b). Se /recovery for removido em um dispositivo não A/B e semelhante ao esquema A/B, o modo de recuperação pode ser interrompido durante uma atualização com falha na partição /boot. Para Por isso, a partição /recovery precisa ser uma separada de /boot para dispositivos não A/B, o que implica que a imagem de recuperação continue a ser atualizada de forma adiada (que é o mesmo que em dispositivos com Android 8.1.0 ou versões anteriores).

A tabela a seguir lista as diferenças da partição de imagens para dispositivos não A/B antes e depois do Android 9.

Imagem Ramdisk (antes das 9) Sistema como raiz (após 9)
boot.img Contém um kernel e um ramdisk.img: 
ramdisk.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/ (mount point)
    - vendor/ (mount point)
    - odm/ (mount point)
    ...
 Contém apenas um kernel de inicialização normal.
recovery.img Contém um kernel de recuperação e um código de recuperação ramdisk.img:
system.img Contém o seguinte: 
system.img
  -/
    - bin/
    - etc
    - vendor -> /vendor
    - ...
 Contém o conteúdo mesclado do original system.img e ramdisk.img: 
system.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/
      - bin/
      - etc/
      - vendor -> /vendor
      - ...
    - vendor/ (mount point)
    - odm/ (mount point)
    ...

As partições não mudam. tanto no ramdisk quanto no uso do sistema como raiz o seguinte esquema de partição:

  • /boot
  • /system
  • /system
  • /recovery
  • /vendor etc.

Configurar dm-verity

No sistema como raiz, o kernel precisa ativar system.img em / (ponto de montagem) com dm-verity. O AOSP oferece suporte aos seguintes dm-verity: implementações para system.img.

vboot 1.0

Para a vboot 1.0, o kernel precisa analisar Específico para Android metadados em /system e converter para dm-verity params para configurar o dm-verity (requer esses patches de kernel). O exemplo a seguir mostra as configurações relacionadas a dm-verity para sistema como raiz em linha de comando do kernel: 

ro root=/dev/dm-0 rootwait skip_initramfs init=/init
dm="system none ro,0 1 android-verity /dev/sda34"
veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f

vboot 2.0

Para vboot 2.0 (AVB), é necessário que o carregador de inicialização se integre external/avb/libavb, que analisa o Descritor de hashtree para /system, converte para dm-verity params e transmite os parâmetros para o pela linha de comando do kernel. (Descritores de hashtree de /system pode estar no /vbmeta ou no próprio /system.

O vboot 2.0 requer os seguintes patches de kernel:

.

O exemplo a seguir mostra as configurações relacionadas a dm-verity para sistema como raiz em linha de comando do kernel: 

ro root=/dev/dm-0 rootwait  skip_initramfs init=/init

dm="1 vroot none ro 1,0 5159992 verity 1
PARTUUID=00000016-0000-0000-0000-000000000000
PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999
sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2
8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption
ignore_zero_blocks use_fec_from_device
PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks
650080 fec_start 650080"

Usar pastas raiz específicas do dispositivo

Com o sistema como raiz, depois da imagem genérica do sistema (GSI) é atualizada no dispositivo (e antes da execução). testes do conjunto de testes de fornecedor), todos Pastas raiz específicas do dispositivo adicionadas com BOARD_ROOT_EXTRA_FOLDERS sumiram porque todo o conteúdo do diretório raiz foi substituído por a GSI do sistema como raiz. A remoção dessas pastas pode fazer com que o dispositivo se tornar não inicializável se existir uma dependência nas pastas raiz específicas do dispositivo Por exemplo, são usados como pontos de montagem.

Para evitar esse problema, não use BOARD_ROOT_EXTRA_FOLDERS para adicionar pastas raiz específicas do dispositivo. Se for necessário especificar o suporte específico do dispositivo pontos, use /mnt/vendor/<mount point> (adicionado a esses listas de mudanças). Esses pontos de montagem específicos do fornecedor podem ser especificados diretamente na árvore de dispositivos fstab (para o estágio mount) e o arquivo /vendor/etc/fstab.{ro.hardware} sem configuração adicional (já que o fs_mgr as cria em /mnt/vendor/* automaticamente).