Os dispositivos Android incluem várias partições que executam funções diferentes na o processo de inicialização.
Partições padrão
boot
. Essa partição contém uma imagem de kernel e é criada usandomkbootimg
. É possível usar uma partição virtual para atualizar as imagens diretamente sem atualizar uma nova partição de inicialização. Esta partição também contém o ramdisk genérico nos dispositivos iniciados antes Android 13kernel. A partição
kernel
virtual substitui o kernel (zImage
,zImage-dtb
,Image.gz-dtb
) ao gravar a nova imagem do kernel sobre a antiga. imagem do kernel. Se o kernel de desenvolvimento fornecido for incompatível, talvez é necessário atualizar a partiçãovendor
,system
oudtb
(se houver) com módulos do kernel associados.ramdisk, A partição
ramdisk
virtual substitui o ramdisk pela gravar a nova imagem do ramdisk sobre a imagem antiga.
A operação de substituição determina o local de início da imagem atual no eMMC e copia a nova imagem para esse local. A nova imagem (kernel ou ramdisk) pode ser maior que o atual. para liberar espaço, o carregador de inicialização pode mover os dados após a imagem ou abandonar a operação com um erro.
init_boot
. Essa partição contém o ramdisk genérico para dispositivos lançados com o Android 13 e versões mais recentes.system
. Essa partição contém o framework do Android.odm
. Esta partição contém o fabricante de design original (ODM) personalizações em pacotes de suporte de placa do fornecedor (BSPs, na sigla em inglês) do system on chip (SoC). Essas personalizações permitem que ODMs substituam ou personalizem componentes do SoC. implementar módulos do kernel para componentes específicos da placa, daemons e Recursos específicos de ODM em camadas de abstração de hardware (HALs). Esta partição está 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 mais detalhes, consulte ODM Partições.odm_dlkm
. Essa partição é dedicada ao armazenamento do kernel ODM módulos. Armazenar módulos do kernel ODM na partiçãoodm_dlkm
(e não na partiçãoodm_dlkm
). para a partiçãoodm
), possibilita a atualização dos módulos do kernel ODM sem atualizar a partiçãoodm
.recovery
. Essa partição armazena a imagem de recuperação, que é inicializados durante o processo de OTA. Dispositivos com suporte a integridade de código atualizações podem armazenar as imagens de recuperação como um no ramdisk da imagemboot
ouinit_boot
(em vez de um arquivo imagem).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 no carregador de inicialização, mas precisa ser apagada. A partição O tamanho depende do tipo do dispositivo e da disponibilidade de espaço nouserdata
. em geral, de 50 MB a 100 MB é suficiente.misc
. Ela é usada pela partição de recuperação 4 KB ou maior.userdata
. Ela contém apps instalados pelo usuário e incluindo dados de personalização.metadata
. Ela é usada para armazenar os metadados quando o dispositivo usa metadados criptografia. O tamanho é ter 16 MB ou mais; Ele não é criptografado, e os dados não são snapshots. Os dados são apagados quando o dispositivo é redefinido para a configuração original. O uso desta partição está estritamente limitadas.vendor
. Esta 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, é possível omitir essa partição.vendor_dlkm
. Essa partição é dedicada ao armazenamento módulos do kernel. Como armazenar módulos do kernel do fornecedor na partiçãovendor_dlkm
(ao contrário da partiçãovendor
), possibilita atualizar o kernel módulos sem atualizar a partiçãovendor
.radio
. Essa partição contém a imagem de rádio e é necessária somente para dispositivos que incluem um rádio com software específico para rádio uma partição dedicada.tos
. Esta partição armazena a imagem binária do sistema operacional Trusty e é usado apenas quando o dispositivo inclui o Trusty. Para mais detalhes, consulte os TOS Partições.pvmfw
. Essa partição armazena a máquina virtual protegida Firmware (pvmfw), que é o primeiro código executado em VMs protegidas. Consulte Firmware de máquina virtual protegida para mais detalhes.
Partições dinâmicas
Dispositivos com o Android 11 e versões mais recentes têm suporte partições dinâmicas, que são um sistema de particionamento do espaço do usuário para Android que permite criar, redimensionar ou destruir partições durante o evento over the air (OTA) atualizações. Para mais detalhes, consulte Dinâmico partições diferentes.
Designar partições críticas
Se o dispositivo exigir partições ou dados específicos para ser executado, você deverá designar
essas partições ou dados como totalmente protegidos ou atualizáveis, ou seja,
eles podem ser recompilados, 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 calibragem e muito mais.
Mudanças no Android 11
O Android 11 inclui várias mudanças nas partições, incluindo restrições à vinculação a bibliotecas e às novas variantes de imagem do Soong.
Figura 1. Layout de partição no Android 11
Imagem de sistema única (SSI). Uma nova imagem conceitual que contém
system
esystem_ext
imagens. Quando essas partições são comuns para um conjunto de dispositivos de destino, eles podem compartilhar a SSI e ignorar a criação dasystem
esystem_ext
imagens.system_ext
. Uma nova partição que pode usar recursossystem
e podem incluir módulos de sistema que:Estender os módulos do sistema AOSP na partição
system
. Recomendamos fazer o upstreaming desses módulos para o AOSP para que eles possam ser instalados nosystem
partição mais tarde.Pacote de módulos específicos para OEM ou SoC. Recomendamos separar esses módulos para que possam ser instalados na partição
product
ouvendor
.
system
. Imagem comum do sistema usada para produtos OEM. Qa recomendamos remover os módulos reservados da partiçãosystem
fazendo o upstreaming deles para o AOSP ou movendo-os para a partiçãosystem_ext
.product
. Esta partição agora pode usar interfaces permitidas para instalar módulos específicos do produto que não sejam agrupados com nenhum outro partições diferentes.
Mudanças no VNDK
O Kit de desenvolvimento nativo do fornecedor (VNDK)
é um conjunto de bibliotecas instaladas na partição system
e projetadas
exclusivamente para fornecedores implementarem suas HALs.
No Android 10 e versões anteriores, a partição
vendor
pode se vincular a bibliotecas VNDK na na partiçãosystem
, mas não é possível vincular a outras bibliotecas na partiçãosystem
partição. Os módulos nativos na partiçãoproduct
podem ser vinculados a qualquer biblioteca. na partiçãosystem
.No Android 11 e versões mais recentes, a
product
e ovendor
partições podem ser vinculadas a bibliotecas VNDK na partiçãosystem
, mas não podem vincular a outras bibliotecas na partiçãosystem
.
Variantes do produto Soong
O sistema de build Soong usa variantes de imagem para dividir
dependências de build. Os módulos nativos (/build/soong/cc
) podem modificar o sistema
módulos de processo 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 no
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 de fornecedores definindo
vendor_available: true
na própria arquivosAndroid.bp
; Isso permite que os módulos do fornecedor sejam vinculados aos módulos do sistema. As bibliotecas VNDK, que são variantes de fornecedores das bibliotecassystem
, também podem criar variantes de fornecedores para módulos de fornecedores definindovendor_available: true
nos arquivosAndroid.bp
(consulte exemplo).No Android 11, um módulo de sistema também pode criar uma variante do 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 O
vendor_available: true
cria uma variante do fornecedor além da principal variante. Para criar uma variante do produto,product_available: true
precisa ser definido. Algumas bibliotecas do VNDK semproduct_available: true
não estão disponíveis para os módulos do produto.