Visão geral

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 usando mkbootimg. É 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 13

  • kernel. 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ção vendor, system ou dtb (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ção odm_dlkm (e não na partição odm_dlkm). para a partição odm), possibilita a atualização dos módulos do kernel ODM sem atualizar a partição odm.

• 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 imagem boot ou init_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 no userdata. 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ção vendor_dlkm (ao contrário da partição vendor), possibilita atualizar o kernel módulos sem atualizar a partição vendor.

• 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 e system_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 da system e system_ext imagens.

• system_ext. Uma nova partição que pode usar recursos system 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 no system 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 ou vendor.

• system. Imagem comum do sistema usada para produtos OEM. Qa recomendamos remover os módulos reservados da partição system fazendo o upstreaming deles para o AOSP ou movendo-os para a partição system_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ção system, mas não é possível vincular a outras bibliotecas na partição system partição. Os 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, a product e o vendor partições podem ser vinculadas a bibliotecas VNDK na partição system, mas não podem vincular a outras bibliotecas na partição system.

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 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 fornecedores das bibliotecas system, também podem criar variantes de fornecedores para módulos de fornecedores definindo vendor_available: true nos arquivos Android.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 sem product_available: true não estão disponíveis para os módulos do produto.