Vista geral

Os dispositivos Android incluem várias partições que desempenham funções diferentes no processo de inicialização.

Partições padrão

  • partição boot . Esta partição contém uma imagem do kernel e é criada usando mkbootimg . Você pode usar uma partição virtual para atualizar qualquer imagem diretamente, sem atualizar uma nova partição de inicialização. Esta partição também contém o ramdisk genérico em dispositivos lançados antes do Android 13.

    • núcleo. A partição virtual kernel sobrescreve o kernel ( zImage , zImage-dtb , Image.gz-dtb ) gravando a nova imagem do kernel sobre a imagem antiga do kernel. Se o kernel de desenvolvimento fornecido for incompatível, pode ser necessário atualizar a partição vendor , system ou dtb (se presente) com módulos de kernel associados.

    • disco RAM. A partição ramdisk virtual sobrescreve o ramdisk gravando a nova imagem do ramdisk sobre a antiga imagem do ramdisk.

    A operação de substituição determina o local inicial da imagem existente no eMMC e copia a nova imagem para esse local. A nova imagem (kernel ou ramdisk) pode ser maior que a existente; para liberar espaço, o bootloader pode mover os dados seguindo a imagem ou abandonar a operação com erro.

  • partição init_boot . Esta partição contém o ramdisk genérico para dispositivos lançados com Android 13 e posteriores.

  • partição system . Esta partição contém a estrutura Android.

  • partição odm . Esta partição contém personalizações do fabricante de design original (ODM) para pacotes de suporte de placa (BSPs) do fornecedor de sistema no chip (SoC). Essas personalizações permitem que os ODMs substituam ou personalizem componentes SoC e implementem módulos de kernel para componentes específicos da placa, daemons e recursos específicos do ODM em camadas de abstração de hardware (HALs). Esta partição é opcional; normalmente, ele é usado para conter personalizações para que os dispositivos possam usar uma única imagem de fornecedor para vários SKUs de hardware. Para obter detalhes, consulte Partições ODM .

  • partição odm_dlkm . Esta partição é dedicada ao armazenamento de módulos do kernel ODM. Armazenar módulos do kernel ODM na partição odm_dlkm (em oposição à partição odm ) torna possível atualizar módulos do kernel ODM sem atualizar a partição odm .

  • partição recovery . Esta partição armazena a imagem de recuperação, que é inicializada durante o processo OTA. Os dispositivos que suportam atualizações contínuas podem armazenar as imagens de recuperação como um disco RAM contido na imagem boot ou init_boot (em vez de uma imagem separada).

  • partição cache . Esta partição armazena dados temporários e é opcional se um dispositivo usar atualizações contínuas. A partição de cache não precisa ser gravável no bootloader, mas precisa ser apagável. O tamanho da partição depende do tipo de dispositivo e da disponibilidade de espaço nos userdata ; normalmente, 50 MB–100 MB são suficientes.

  • partição misc . Esta partição é usada pela partição de recuperação e tem 4 KB ou mais.

  • partição userdata . Esta partição contém aplicativos e dados instalados pelo usuário, incluindo dados de personalização.

  • partição metadata . Esta partição é usada para armazenar a chave de criptografia de metadados quando o dispositivo usa criptografia de metadados . O tamanho é 16 MB ou maior. Não é criptografado e seus dados não são capturados. Ele é apagado quando o dispositivo é redefinido para os padrões de fábrica. O uso desta partição é estritamente limitado.

  • partição vendor . Esta partição contém qualquer binário que não seja distribuível ao AOSP. Se o dispositivo não contiver informações proprietárias, você poderá omitir esta partição.

  • partição vendor_dlkm . Esta partição é dedicada ao armazenamento de módulos do kernel do fornecedor. Armazenar módulos do kernel do fornecedor na partição vendor_dlkm (em oposição à partição vendor ) torna possível atualizar os módulos do kernel sem atualizar a partição vendor .

  • partição radio . Esta partição contém a imagem do rádio e é necessária somente para dispositivos que incluem um rádio com software específico de rádio em uma partição dedicada.

  • partição tos . Esta partição armazena a imagem binária do sistema operacional Trusty e é usada somente se o dispositivo incluir o Trusty. Para obter detalhes, consulte Partições TOS .

  • partição pvmfw . Esta partição armazena o firmware da máquina virtual protegida (pvmfw), que é o primeiro código executado em VMs protegidas. Consulte Firmware de máquina virtual protegida para obter mais detalhes.

Partições dinâmicas

Dispositivos com Android 11 e versões posteriores podem oferecer suporte a partições dinâmicas, que são um sistema de particionamento de espaço do usuário para Android que permite criar, redimensionar ou destruir partições durante atualizações over-the-air (OTA). Para obter detalhes, consulte Partições dinâmicas .

Designando partições críticas

Se o dispositivo exigir partições ou dados específicos para execução, você deverá designar essas partições/dados como totalmente protegidos ou re-flashable, o que significa que eles podem ser reconstruídos, fornecidos ou extraíveis usando um comando fastboot oem . Isso inclui dados como configurações específicas de fábrica por dispositivo, números de série, dados de calibração e muito mais.

Mudanças no Android 11

O Android 11 inclui inúmeras alterações nas partições, incluindo restrições à vinculação a bibliotecas e novas variantes de imagens Soong.

Layout de partição Android

Figura 1. Layout de partição no Android 11

  • Imagem de sistema único (SSI). Uma nova imagem conceitual que contém as imagens system e system_ext . Quando essas partições são comuns para um conjunto de dispositivos de destino, esses dispositivos podem compartilhar o SSI e ignorar a construção do system e das imagens system_ext .

  • partição system_ext . Uma nova partição que pode usar recursos system e incluir módulos do sistema que:

    • Estenda os módulos do sistema AOSP na partição system . Recomendamos fazer o upstream de tais módulos para AOSP para que possam ser instalados posteriormente na partição system .

    • Agrupe módulos específicos de OEM ou SoC. Recomendamos desagregar esses módulos para que possam ser instalados na partição do product ou vendor .

  • partição system . Imagem de sistema comum usada para produtos OEM. Recomendamos mover os módulos proprietários para fora da partição system , fazendo upload deles para AOSP ou movendo-os para a partição system_ext .

  • partição product . Esta partição agora pode usar interfaces permitidas para instalar módulos específicos do produto que não estão incluídos em nenhuma outra partição.

Mudanças no VNDK

O Vendor Native Development Kit (VNDK) é um conjunto de bibliotecas instaladas na partição system e projetadas exclusivamente para que os fornecedores implementem seus HALs.

  • No Android 10 e versões anteriores, a partição vendor pode vincular-se a bibliotecas VNDK na partição system , mas não pode vincular-se a outras bibliotecas na partição system . Os módulos nativos na partição product podem ser vinculados a qualquer biblioteca na partição system .

  • No Android 11 e versões posteriores, as partições product e vendor podem ser vinculadas a bibliotecas VNDK na partição system , mas não podem ser vinculadas a outras bibliotecas na partição system .

Variantes de produtos breves

O sistema de compilação Soong usa variantes de imagem para dividir as dependências de compilação. Módulos nativos ( /build/soong/cc ) podem transformar módulos de processo do sistema para a variante principal e módulos de processo do fornecedor para a variante do fornecedor; um módulo em uma variante de imagem não pode ser vinculado a outros módulos em uma variante de imagem diferente.

  • No Android 10 ou inferior, um módulo do sistema cria variantes principais automaticamente. Ele também pode criar variantes de fornecedores definindo vendor_available: true em seus arquivos Android.bp ; isso permite que os módulos do fornecedor sejam vinculados aos módulos do sistema. As bibliotecas VNDK, que são variantes de fornecedor de bibliotecas system , também podem criar variantes de fornecedor para módulos de fornecedor definindo vendor_available: true em seus arquivos Android.bp (veja o exemplo ).

  • No Android 11, um módulo do sistema também pode criar uma variante de produto (além das variantes principais e de fornecedor) definindo vendor_available: true .

  • No Android 12 ou superior, um módulo do sistema com vendor_available: true cria uma variante do fornecedor além da variante principal. Para criar uma variante de produto, product_available: true deve ser definido. Algumas bibliotecas VNDK sem product_available: true não estão disponíveis para módulos de produto.