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

Layout de partição

Em Android 10, o sistema de arquivos raiz não está mais incluído no ramdisk.img e em vez disso é incorporada system.img (isto é, system.img é sempre criada como se BOARD_BUILD_SYSTEM_ROOT_IMAGE foi definido). Dispositivos lançados com Android 10:

  • Use um layout de partição do sistema como raiz (automaticamente reforçado pela construção, sem opções para alterar o comportamento).
  • Deve usar um ramdisk, que é necessário para dm-linear.
  • Deve definir BOARD_BUILD_SYSTEM_ROOT_IMAGE para false . Esta configuração é usada apenas para diferenciar entre dispositivos que utilizam um disco em memória e dispositivos que não usar um disco RAM (e, em vez de montagem system.img diretamente).

O significado de um sistema como root difere de configuração entre Android 9 e Android 10. Em um sistema-as-raiz configuração Android 9, BOARD_BUILD_SYSTEM_ROOT_IMAGE está definido como true , o que obriga a construção de fundir o sistema de arquivos raiz em system.img seguida montar system.img como o sistema de arquivos raiz (rootfs). Esta configuração é obrigatória para dispositivos de lançamento com Android 9, mas é opcional para dispositivos fazendo upgrade para Android 9 e para dispositivos que executam versões mais baixas do Android. Em um sistema-as-raiz configuração Android 10, a compilação sempre funde $TARGET_SYSTEM_OUT e $TARGET_ROOT_OUT em system.img ; esta configuração é o comportamento padrão para todos os dispositivos que executam o Android 10.

Android 10 faz mais alterações para suportar 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 kernel do Linux não pode mais montar a partição lógica do sistema em dispositivos que executam o Android 10, portanto, essa operação é tratada pelo init de primeiro estágio.

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

Sobre OTAs somente do sistema

OTAs única do sistema, que permitem lançamentos Android para atualização system.img e product.img sem alterar outras partições, exigem um sistema-as-raiz layout da partição. Todos os dispositivos que executam o Android 10 devem usar um layout de partição do sistema como raiz para habilitar OTAs apenas do sistema.

  • A Aparelhos / B, que montar o system partição como rootfs, já usam sistema-as-raiz e não exigem alterações para OTAs sistema de apoio.
  • Non-A / dispositivos B, que montar o system partição de /system , devem ser atualizados para usar um sistema-as-raiz layout da partição para OTAs sistema de apoio.

Para mais detalhes sobre A / B e não-A / dispositivos B, referem-se a A / B (Seamless) Atualizações do sistema .

Usando a sobreposição do fornecedor

Sobreposição fornecedor permite sobrepor alterações ao vendor de partição em tempo de inicialização do dispositivo. A sobreposição de fornecedor é um conjunto de módulos de fornecedores no product partição que get sobreposto sobre o vendor partição quando o dispositivo é inicializado, substituindo e acrescentando aos módulos existentes.

Quando o dispositivo é inicializado, a init processo for concluído montar a primeira fase e lê as propriedades padrão. Em seguida, ele procura /product/vendor_overlay/<target_vendor_version> e monta cada subdiretório no seu correspondente vendor diretório partição, se estiverem reunidas as seguintes condições:

  • /vendor/<overlay_dir> existe.
  • /product/vendor_overlay/<target_vendor_version>/<overlay_dir> tem o mesmo contexto de arquivo como /vendor/<overlay_dir> .
  • init tem permissão para montar sobre o contexto de arquivo /vendor/<overlay_dir> .

Implementando a sobreposição do fornecedor

Instalar arquivos de sobreposição de fornecedores em /product/vendor_overlay/<target_vendor_version> . Esses arquivos sobrepor o vendor de partição quando o dispositivo é inicializado, substituindo arquivos com o mesmo nome e adicionando novos arquivos. Sobreposição fornecedor não pode remover arquivos do vendor de partição.

Arquivos de sobreposição fornecedor devem ter o mesmo contexto de arquivo, como os arquivos de destino que eles substituem no vendor de partição. Por padrão, os arquivos do /product/vendor_overlay/<target_vendor_version> diretório têm o vendor_file contexto. Se houver incompatibilidades de contexto de arquivo entre os arquivos de sobreposição do fornecedor e os arquivos que eles substituem, especifique isso na sepolítica específica do dispositivo. O contexto do arquivo é definido no nível do diretório. Se o contexto de arquivo de um diretório de sobreposição de fornecedor não corresponder ao diretório de destino e o contexto de arquivo correto não for especificado na sepolicy específica do dispositivo, esse diretório de sobreposição de fornecedor não será sobreposto ao diretório de destino.

Para usar sobreposição de fornecedor, o kernel deve habilitar OverlayFS definindo CONFIG_OVERLAY_FS=y . Além disso, o kernel deve ser mescladas a partir do kernel comum 4.4 ou posterior, ou remendado com "overlayfs: override_creds=off option bypass creator_cred" .

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

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

  1. Adicionar arquivos de fornecedores pré-construídos 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. Instalar os arquivos de fornecedores pré-construídos para product/vendor_overlay no 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. Definir contextos de arquivos Se o alvo vendor arquivos de partição tem diferentes contextos vendor_file . Porque /vendor/lib/* usos do vendor_file contexto, este exemplo não inclui o diretório.

    Adicione o seguinte ao 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 a init processo para montar a sobreposição fornecedor em diferentes contextos de arquivos vendor_file . Porque a init processo já tem permissão para montar na vendor_file contexto, este exemplo não define a política para vendor_file .

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

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

Validando a sobreposição do fornecedor

Para validar a configuração de sobreposição fornecedor, adicionar arquivos em /product/vendor_overlay/<target_vendor_version>/<overlay_dir> e verificar se os arquivos são sobrepostas sobre os arquivos em /vendor/<overlay_dir> .

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

$ atest -v fs_mgr_vendor_overlay_test

Atualizando para sistema como root

Para atualizar dispositivos não-A / B para o uso do sistema-as-raiz, você deve atualizar o esquema de particionamento para boot.img e system.img , configurar dm-verdade, e remover quaisquer dependências de inicialização nas pastas raiz específicas do dispositivo.

Atualizando partições

Ao contrário de A / B dispositivos que Repurpose /boot como a recuperação de partição, não-A / B dispositivos deve manter o /recovery partição separar como eles não têm a partição ranhura de reversão (por exemplo, a partir de boot_a para boot_b ). Se /recovery é removido em não-Um dispositivo / B e feito semelhante ao esquema A / B, o modo de recuperação pode quebrar durante uma actualização falhou ao /boot da partição. Por esta razão, o /recovery partição deve ser uma partição separada /boot para dispositivos não-A / B, o que implica que a imagem de recuperação continuará a ser atualizado de forma diferida (isto é, o mesmo que em dispositivos que executam o Android 8.1.0 ou inferior).

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

Imagem Ramdisk (antes de 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 uma recuperação ramdisk.img .
system.img Contém o seguinte:
system.img
  -/
    - bin/
    - etc
    - vendor -> /vendor
    - ...
Contém o conteúdo mesclado de originais 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 em si não mudam; ambos ramdisk e system-as-root usam o seguinte esquema de partição:

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

Configurando dm-verity

No sistema-as-raiz, o kernel deve montar system.img sob / (ponto de montagem) com dm-verdade . AOSP suporta os seguintes implementações dm-Verity para system.img .

vboot 1.0

Para vboot 1.0 , o kernel deve analisar específicas do Android metadados on /system , em seguida, converter a DM-Verity parâmetros para configurar dm-verdade (requer estes patches de kernel ). O exemplo a seguir mostra as configurações relacionadas ao dm-verity para system-as-root na 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 ), o carregador de arranque deve integrar externa / BAV / libavb , que, em seguida, analisa o descritor hashtree para /system , converte-a DM-Verity params , e, finalmente, passa os parâmetros para o núcleo através da linha de comando do kernel. (Descritores Hashtree de /system pode estar em /vbmeta ou on /system em si.)

O vboot 2.0 requer os seguintes patches de kernel:

O exemplo a seguir mostra as configurações relacionadas ao dm-verity para system-as-root na 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"

Usando pastas raiz específicas do dispositivo

Com o sistema-as-raiz, após a imagem do sistema genérico (GSI) é brilhou no dispositivo (e antes de executar fornecedor de testes Suíte testes), todas as pastas raiz específica do dispositivo adicionados com BOARD_ROOT_EXTRA_FOLDERS sumiram porque todo o conteúdo do diretório raiz foi substituído pelo GSI do sistema como raiz. A remoção dessas pastas pode fazer com que o dispositivo não possa ser inicializado se houver uma dependência das pastas raiz específicas do dispositivo (por exemplo, elas são usadas como pontos de montagem).

Para evitar esse problema, não use BOARD_ROOT_EXTRA_FOLDERS para adicionar pastas de raiz específicas do dispositivo. Se você precisa especificar montagem específica do dispositivo pontos, uso /mnt/vendor/<mount point> (acrescentado nestes changelists ). Montar esses específica do fornecedor pontos podem ser diretamente especificado em ambos os fstab árvore de dispositivos (para primeira fase de montagem) ea /vendor/etc/fstab.{ro.hardware} arquivo sem configuração adicional (como fs_mgr cria-los sob /mnt/vendor/* automaticamente).