Visão geral

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

Partições padrão

• Partição boot. Essa partição contém uma imagem do kernel e é criada usando mkbootimg. É possível usar uma partição virtual para atualizar qualquer imagem diretamente sem atualizar uma nova partição de inicialização. Essa partição também contém o ramdisk genérico em dispositivos lançados antes do Android 13.

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

  • ramdisk. A partição ramdisk virtual substitui o ramdisk gravando a nova imagem sobre a antiga.

  A operação de substituição determina o local de início da imagem existente no eMMC e copia a nova imagem para esse local. A nova imagem (kernel ou ramdisk) pode ser maior do que a atual. Para criar espaço, o bootloader pode mover dados seguindo a imagem ou abandonar a operação com um erro.

• Partição init_boot. Essa partição contém o ramdisk genérico para dispositivos lançados com o Android 13 e versões mais recentes.

• Partição system. Essa partição contém o framework do Android.

• Partição odm. Essa partição contém personalizações do fabricante de design original (ODM, na sigla em inglês) para pacotes de suporte de placa (BSPs, na sigla em inglês) do fornecedor do system on 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 nas camadas de abstração de hardware (HALs). Essa partição é opcional e geralmente é usada para conter personalizações para que os dispositivos possam usar uma única imagem de fornecedor para vários SKUs de hardware. Para detalhes, consulte Partições ODM.

• odm_dlkm. Essa partição é dedicada ao armazenamento de módulos do kernel do ODM. Armazenar módulos do kernel ODM na partição odm_dlkm, em vez da partição odm, permite atualizar módulos do kernel ODM sem atualizar a partição odm.

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

• cache. Essa partição armazena dados temporários e é opcional se um dispositivo usa atualizações perfeitas. A partição de cache não precisa ser gravável pelo 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 a 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 apps e dados instalados pelo usuário, incluindo dados de personalização.

• metadata. Essa partição é usada para armazenar a chave de criptografia de metadados quando o dispositivo usa a criptografia de metadados. O tamanho é 16 MB ou maior. Ele não é criptografado e os dados dele não são capturados. Ele é apagado quando o dispositivo é redefinido para a configuração original. O uso dessa partição é estritamente limitado.

• vendor. Essa partição contém qualquer binário que não seja distribuível para o AOSP. Se o dispositivo não tiver informações reservadas, omita essa partição.

• Partição vendor_dlkm. Essa partição é dedicada ao armazenamento de módulos do kernel do fornecedor. Armazenar módulos de kernel do fornecedor na partição vendor_dlkm (em vez da partição vendor) permite atualizar módulos de kernel sem atualizar a partição vendor.

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

• tos. Essa partição armazena a imagem binária do SO Trusty e é usada apenas se o dispositivo incluir o Trusty. Para mais detalhes, consulte Seções do TOS.

• Partição pvmfw. Essa 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 protegido para mais detalhes.

Partições dinâmicas

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

Designar partições críticas

Se o dispositivo exigir partições ou dados específicos para ser executado, você precisará designar essas partições ou dados como totalmente protegidos ou re-flasháveis, o que significa que eles podem ser recriados, fornecidos ou extraídos 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 mudanças nas partições, incluindo restrições de vinculação a bibliotecas e novas variantes de imagem do Soong.

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

• Imagem única do sistema (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, eles 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:

  • Estender os módulos do sistema AOSP na partição system. Recomendamos enviar esses módulos para o AOSP para que eles possam ser instalados na partição system mais tarde.

  • Agrupar módulos específicos de OEM ou SoC. Recomendamos desempacotar esses módulos para que eles possam ser instalados na partição 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, enviando-os para o AOSP ou movendo-os para a partição system_ext.

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

Mudanças no VNDK

O Kit de desenvolvimento nativo do fornecedor (VNDK) é um conjunto de bibliotecas instaladas na partição system e projetado exclusivamente para que os fornecedores implementem as HALs.

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

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

Variantes de produto do Soong

O sistema de build do Soong usa variantes de imagem para dividir as dependências de build. Módulos nativos (/build/soong/cc) podem mudar 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 versões anteriores, um módulo do sistema cria variantes principais automaticamente. Ele também pode criar variantes do fornecedor definindo vendor_available: true nos arquivos Android.bp. Isso permite que os módulos do fornecedor sejam vinculados aos módulos do sistema. As bibliotecas do VNDK, que são variantes do fornecedor das bibliotecas system, também podem criar variantes do fornecedor para módulos do fornecedor definindo vendor_available: true nos 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 do fornecedor) definindo vendor_available: true.

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