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

Montando partições antecipadamente

Dispositivos Treble habilitados deve habilitar primeira etapa de montagem para se certificar init pode carregar Security-Enhanced Linux (SELinux) fragmentos de política que estão espalhados por todo system e vendor partições. Este acesso também permite o carregamento de módulos do kernel assim que possível após a inicialização do kernel.

Para realizar a montagem antecipada, o Android deve ter acesso aos sistemas de arquivos nos quais residem os módulos. Android 8,0 e mais altos suportes de montagem /system , /vendor , ou /odm tão cedo quanto init da primeira fase (isto é, antes de o SElinux é inicializado).

Entradas Fstab

Em Android 9 e inferior, dispositivos pode especificar fstab entradas para o início de partições montadas usando sobreposições árvore de dispositivos (DTOs) . Em Android 10 e superior, os dispositivos devem especificar fstab entradas para montado início de partições usando uma fstab arquivo na primeira etapa ramdisk . Android 10 introduz as seguintes fs_mgr bandeiras para uso no fstab arquivo:

  • first_stage_mount indica que uma divisória vai ser montado pela primeira fase de inicialização.
  • logical indica que esta é uma partição dinâmica .
  • avb= vbmeta-partition-name especifica o vbmeta partição. O primeiro estágio init inicializa esta partição antes de montar outras partições. O argumento para esta bandeira pode ser omitido se o vbmeta partição para a entrada já foi especificado por outra fstab entrada em uma linha anterior.

O exemplo a seguir mostra fstab entradas para definir as system , vendor , e product partições como partições lógicas (dinâmico).

#<dev>  <mnt_point> <type>  <mnt_flags options> <fs_mgr_flags>
system   /system     ext4    ro,barrier=1     wait,slotselect,avb=vbmeta_system,logical,first_stage_mount
vendor   /vendor     ext4    ro,barrier=1     wait,slotselect,avb=vbmeta,logical,first_stage_mount
product  /product    ext4    ro,barrier=1     wait,slotselect,avb,logical,first_stage_mount

Neste exemplo, especifica fornecedores do vbmeta partição usando o fs_mgr bandeira avb=vbmeta , mas product omite o vbmeta argumento porque fornecedor já adicionou vbmeta à lista de partições.

Dispositivos rodando o Android 10 e superior deve colocar o fstab arquivo no disco RAM e no vendor de partição.

Ramdisk

O fstab local do arquivo no disco em memória depende de como um dispositivo usa ramdisk.

Dispositivos com um ramdisk de arranque tem de colocar o fstab arquivo na raiz ramdisk boot. Se o dispositivo tiver um ramdisk de inicialização e um ramdisk de recuperação, nenhuma alteração será necessária no ramdisk de recuperação. Exemplo:

PRODUCT_COPY_FILES +=  device/google/<product-name>/fstab.hardware:$(TARGET_COPY_OUT_RAMDISK)/fstab.$(PRODUCT_PLATFORM)

Dispositivos que usam recuperação como uma ramdisk deve usar o comando do kernel parâmetro da linha de androidboot.force_normal_boot=1 para decidir se inicie no Android ou continuar arrancar em recuperação. Dispositivos de lançamento com Android 12 ou superior com o kernel versão 5.10 ou posterior deve usar bootconfig para passar o androidboot.force_normal_boot=1 parâmetro. Nestes dispositivos, a primeira inicialização estágio faz uma operação da chave raiz para /first_stage_ramdisk antes de montar o início montar partições, por isso os dispositivos deve colocar o fstab arquivo em $(TARGET_COPY_OUT_RECOVERY)/root/first_stage_ramdisk . Exemplo:

PRODUCT_COPY_FILES +=  device/google/<product-name>/fstab.hardware:$(TARGET_COPY_OUT_RECOVERY)/root/first_stage_ramdisk/fstab.$(PRODUCT_PLATFORM)

Fornecedor

Todos os dispositivos devem colocar uma cópia do fstab arquivo em /vendor/etc . Isso ocorre porque os primeiros liberta fase de inicialização do disco em memória após completar o início de montagem de divisórias e executa uma operação interruptor de raiz para mover a montar em /system para / . As operações subsequentes, que necessitam de acesso fstab arquivos deve, portanto, utilizar a cópia em /vendor/etc . Exemplo:

PRODUCT_COPY_FILES +=  device/google/<product-name>/fstab.hardware:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.$(PRODUCT_PLATFORM)

Montando partições antecipadamente, VBoot 1.0

Os requisitos para a montagem antecipada de partições com VBoot 1.0 incluem:

  1. Caminhos nó do dispositivo deve usar seus by-name links simbólicos no fstab e entradas devicetree. Por exemplo, em vez de especificar partições usando /dev/block/mmcblk0pX , assegurar que as partições são nomeados e o nó do dispositivo é /dev/block/…./by-name/{system,vendor,odm} .
  2. Caminhos dadas para PRODUCT_{SYSTEM,VENDOR}_VERITY_PARTITION e CUSTOM_IMAGE_VERITY_BLOCK_DEVICE na configuração do dispositivo para o produto (isto é, em device/ oem / project /device.mk ) devem coincidir com os nós de dispositivo de bloco correspondente especificados by-name no fstab / devicetree entradas. Exemplo:
    PRODUCT_SYSTEM_VERITY_PARTITION := /dev/block/…./by-name/system
    PRODUCT_VENDOR_VERITY_PARTITION := /dev/block/…./by-name/vendor
    CUSTOM_IMAGE_VERITY_BLOCK_DEVICE := /dev/block/…./by-name/odm
    
  3. Entradas fornecidas através de sobreposições de árvores dispositivo não deve repetir nas fstab fragmentos de arquivos. Por exemplo, ao especificar uma entrada para montar /vendor no devicetree, o fstab arquivo não deve repetir essa entrada.
  4. Partições que requerem verifyatboot não deve ser montado mais cedo (fazê-lo não é suportado).
  5. O modo de verdade / estado para partições verificados deve ser especificado no kernel_cmdline usando androidboot.veritymode (requisito existente) opção.

Montagem do dispositivo; árvore antecipada, VBoot 1.0

Em 8.x Android e superior, init analisa o devicetree e cria fstab entradas para montar a partição cedo durante sua primeira fase. Um fstab entrada assume a forma:

src mnt_point type mnt_flags fs_mgr_flags

As propriedades do dispositivo são definidas para imitar esse formato:

  • fstab entradas devem estar sob /firmware/android/fstab na devicetree e deve ter um conjunto corda compatível para android,fstab .
  • Cada nó sob /firmware/android/fstab é tratado como um único precoce montagem fstab entrada. Um nó deve ter as seguintes propriedades definidas:
    • dev deve apontar para o nó de dispositivo que representa a partição by-name
    • type deve ser o tipo de sistema de arquivos (como nos fstab arquivos)
    • mnt_flags deve ser a lista separada por vírgulas de montar bandeiras (como fstab arquivos)
    • fsmgr_flags deve ser a lista de Android fs_mgr flags (como no fstab arquivos)
  • A partições / B deve ter um slotselect fs_mgr opção.
  • dm-verdade habilitado partições deve ter um verify fs_mgr opção.

Exemplo: sistema de / e / fornecedor em N6P

O exemplo a seguir mostra devicetree cedo para montar system e vendor partições no Nexus 6P:

/ {
  firmware {
    android {
      compatible = "android,firmware";
      fstab {
        compatible = "android,fstab";
        system {
          compatible = "android,system";
          dev = "/dev/block/platform/soc.0/f9824900.sdhci/by-name/system";
          type = "ext4";
          mnt_flags = "ro,barrier=1,inode_readahead_blks=8";
          fsmgr_flags = "wait,verify";
        };
        vendor {
          compatible = "android,vendor";
          dev = "/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor";
          type = "ext4";
          mnt_flags = "ro,barrier=1,inode_readahead_blks=8";
          fsmgr_flags = "wait";
        };
      };
    };
  };
};

Exemplo: fornecedor / em pixel

O exemplo a seguir mostra devicetree montagem cedo para /vendor on Pixel (lembre-se de adicionar slotselect para partições sujeitas a A / B):

/ {
  firmware {
    android {
      compatible = "android,firmware";
      fstab {
        compatible = "android,fstab";
        vendor {
          compatible = "android,vendor";
          dev = "/dev/block/platform/soc/624000.ufshc/by-name/vendor";
          type = "ext4";
          mnt_flags = "ro,barrier=1,discard";
          fsmgr_flags = "wait,slotselect,verify";
        };
      };
    };
  };
};

Montando partições antecipadamente, VBoot 2.0

VBoot 2.0 é Android Verificado Bota (AVB) . Os requisitos para montar partições antecipadamente com VBoot 2.0 são:

  1. Os caminhos de nó dispositivo deve utilizar os seus by-name simbólicos em fstab e entradas devicetree. Por exemplo, em vez de especificar partições usando /dev/block/mmcblk0pX , garantir que as partições são nomeados e o nó do dispositivo é /dev/block/…./by-name/{system,vendor,odm} .
  2. Variáveis do sistema de construção (como PRODUCT_{SYSTEM,VENDOR}_VERITY_PARTITION e CUSTOM_IMAGE_VERITY_BLOCK_DEVICE ) utilizados para VBoot 1.0 não são necessários para VBoot 2.0. Em vez disso, as variáveis de compilação introduzido em VBoot 2.0 (incluindo BOARD_AVB_ENABLE := true ) deve ser definido; para uma configuração completa, consulte a construção de integração de sistema para AVB .
  3. Entradas fornecidas através de sobreposições de árvores dispositivo não deve repetir nas fstab fragmentos de arquivos. Por exemplo, se você especificar uma entrada para montar /vendor no devicetree, o fstab arquivo não deve repetir essa entrada.
  4. Não VBoot 2.0 não suporta verifyatboot , quer montar início está habilitado ou não.
  5. O modo de verdade / estado para partições verificados deve ser especificado no kernel_cmdline usando o androidboot.veritymode opção (requisito existente). Certifique-se de incluir as seguintes correções para AVB:

Montagem do dispositivo; árvore antecipada, VBoot 2.0

A configuração em devicetree para VBoot 2,0 é o mesmo que o da VBoot 1,0 , com as seguintes excepções:

  • O fsmgr_flag é alternado de verify a avb .
  • Todas as partições com BVA metadados deve estar na entrada VBMeta na devicetree, mesmo quando a partição não está montando cedo (por exemplo, /boot ).

Exemplo: sistema de / e / fornecedor em N5X

O exemplo a seguir mostra uma devicetree início de montagem para o system e vendor partições no Nexus 5X. Observe que:

  • /system é montado com BVA e /vendor é montado sem verificação de integridade.
  • Como o Nexus 5X não tem /vbmeta partição, de modo que os reside vbmeta de nível superior no final da /boot da partição (para mais pormenores, consulte o Changelist AOSP ).
    / {
      firmware {
        android {
          compatible = "android,firmware";
          vbmeta {
            compatible = "android,vbmeta";
            parts = "boot,system,vendor";
          };
          fstab {
            compatible = "android,fstab";
            system {
              compatible = "android,system";
              dev = "/dev/block/platform/soc.0/f9824900.sdhci/by-name/system";
              type = "ext4";
              mnt_flags = "ro,barrier=1,inode_readahead_blks=8";
              fsmgr_flags = "wait,avb";
            };
            vendor {
              compatible = "android,vendor";
              dev = "/dev/block/platform/soc.0/f9824900.sdhci/by-name/vendor";
              type = "ext4";
              mnt_flags = "ro,barrier=1,inode_readahead_blks=8";
              fsmgr_flags = "wait";
            };
          };
        };
      };
    };
    

Exemplo: fornecedor / em pixel

O exemplo a seguir mostra a montagem /vendor cedo num pixel. Observe que:

  • Mais partições são especificados na entrada vbmeta porque essas partições são protegidos pela AVB .
  • Todas as partições AVB deve ser incluída, mesmo que apenas /vendor é cedo montado.
  • Lembre-se de adicionar slotselect para partições sujeitas a A / B.
    / {
      vbmeta {
        compatible = "android,vbmeta";
        parts = "vbmeta,boot,system,vendor,dtbo";
      };
      firmware {
        android {
          compatible = "android,firmware";
          fstab {
            compatible = "android,fstab";
            vendor {
              compatible = "android,vendor";
              dev = "/dev/block/platform/soc/624000.ufshc/by-name/vendor";
              type = "ext4";
              mnt_flags = "ro,barrier=1,discard";
              fsmgr_flags = "wait,slotselect,avb";
            };
          };
        };
      };
    };