Vista geral

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

Partições padrão

• partição de boot . Esta partição contém uma imagem do kernel e é criada usando mkbootimg . Você pode usar uma partição virtual para fazer o flash de qualquer imagem diretamente sem fazer o flash de 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 do kernel sobrescreve o kernel ( zImage , zImage-dtb , Image.gz-dtb ) escrevendo a nova imagem do kernel sobre a imagem do kernel antigo. Se o kernel de desenvolvimento fornecido for incompatível, talvez seja necessário atualizar a partição vendor , system ou dtb (se houver) com módulos de kernel associados.

  • disco ram. A partição ramdisk virtual substitui 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 um erro.

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

• partição system . Esta partição contém a estrutura do 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 do sistema no chip (SoC). Essas personalizações permitem que os ODMs substituam ou personalizem componentes do SoC e implementem módulos do 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, é 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 ) possibilita atualizar os módulos do kernel ODM sem atualizar a partição odm .

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

• partição de cache . Essa 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 a partir do carregador de inicialização, mas precisa ser apagável. O tamanho da partição depende do tipo de dispositivo e da disponibilidade de espaço em userdata ; normalmente, 50 MB–100 MB são suficientes.

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

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

• partição metadata . Essa partição é usada para armazenar a chave de criptografia de metadados quando o dispositivo usa criptografia de metadados . O tamanho é 16 MB ou maior. Ele não é criptografado e seus dados não são instantâneos. Ele é apagado quando o dispositivo é redefinido 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 de kernel do fornecedor. Armazenar módulos do kernel do fornecedor na partição vendor_dlkm (em oposição à partição do vendor ) torna possível atualizar os módulos do kernel sem atualizar a partição do vendor .

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

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

Partições dinâmicas

Os dispositivos que executam o Android 11 e superior 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 OTA (over-the-air). Para obter detalhes, consulte Partições dinâmicas .

Designando partições críticas

Se o dispositivo requer partições ou dados específicos para ser executado, você deve 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 várias alterações nas partições, incluindo restrições de vinculação a bibliotecas e novas variantes de imagem Soong.

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 pular a criação das imagens system e system_ext .

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

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

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

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

• partição do product . Essa partição agora pode usar interfaces permitidas para instalar módulos específicos do produto que não são empacotados com outras partições.

Alterações do VNDK

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

• No Android 10 e inferior, a partição do vendor pode ser vinculada a bibliotecas VNDK na partição do system , mas não pode ser vinculada a outras bibliotecas na partição do system . Os módulos nativos na partição do product podem ser vinculados a qualquer biblioteca na partição do system .

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

Variantes de produtos Soong

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 alterar os módulos de processo do sistema para a variante principal e os módulos de processo do fornecedor para a variante do fornecedor; um módulo em uma variante de imagem não pode vincular a outros módulos em uma variante de imagem diferente.

• No Android 10 ou inferior, um módulo do sistema cria automaticamente variantes principais. Ele também pode criar variantes de fornecedor 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 de system , também podem criar variantes de fornecedor para módulos de fornecedor definindo vendor_available: true em seus arquivos Android.bp (consulte 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 de fornecedor além da variante principal. Para criar uma variante de produto, product_available: true deve ser definido. Algumas bibliotecas do VNDK sem product_available: true não estão disponíveis para módulos do produto.