Les appareils Android comprennent plusieurs partitions qui remplissent différentes fonctions dans le de démarrage rapide.
Partitions standards
Partition
boot
. Cette partition contient une image de noyau et est créée avecmkbootimg
. Vous pouvez utiliser une partition virtuelle pour flasher l'une ou l'autre des images. directement sans flasher une nouvelle partition de démarrage. Cette partition contient également le ramdisk générique dans les appareils lancés avant Android 13.noyau. La partition virtuelle
kernel
écrase le noyau (zImage
,zImage-dtb
,Image.gz-dtb
) en écrivant la nouvelle image de noyau sur l'ancienne de l'image du noyau. Si le noyau de développement fourni est incompatible, vous pouvez devez mettre à jour la partitionvendor
,system
oudtb
(le cas échéant) avec modules du noyau associés.ramdisk. La partition virtuelle
ramdisk
écrase le ramdisk en écrivant la nouvelle image ramdisk sur l'ancienne image ramdisk.
L'opération d'écrasement détermine le point de départ de l'image existante dans eMMC et copie la nouvelle image à cet emplacement. La nouvelle image (noyau ou ramdisk) peut être plus importante que celle existante. pour libérer de l'espace, le bootloader peut déplacer les données qui suivent l'image ou abandonner l'opération avec une erreur.
Partition
init_boot
. Cette partition contient le ramdisk générique pour appareils équipés d'Android 13 ou version ultérieure.Partition
system
. Cette partition contient le framework Android.Partition
odm
. Cette partition contient le fabricant de la conception d'origine (ODM) personnalisations des packages de support de carte de fournisseur (BSP) système sur puce (SoC). Ces personnalisations permettent aux ODM de remplacer ou de personnaliser les composants SoC. des modules de noyau pour les composants, les daemons et les Fonctionnalités propres à l'ODM sur les couches d'abstraction matérielle (HAL). Cette partition est facultatif ; il est généralement utilisé pour contenir des personnalisations afin que les appareils puissent utiliser une image de fournisseur unique pour plusieurs SKU de matériel. Pour plus d'informations, consultez la section ODM Partitions.Partition
odm_dlkm
. Cette partition est dédiée au stockage du noyau ODM. modules. Le stockage des modules du noyau ODM dans la partitionodm_dlkm
(par opposition à la partitionodm
), ce qui permet de mettre à jour les modules du noyau ODM. sans mettre à jour la partitionodm
.Partition
recovery
. Cette partition stocke l'image de récupération, démarré pendant le processus OTA. Des appareils qui prennent en charge "mises à jour" peuvent stocker les images de récupération ramdisk contenu dans l'imageboot
ouinit_boot
(au lieu d'un fichier distinct image).Partition
cache
. Cette partition, facultative, stocke des données temporaires si un appareil utilise des mises à jour fluides. Il n'est pas nécessaire que la partition du cache soit accessible en écriture depuis le bootloader, mais doit être effaçable. La partition la taille dépend du type d'appareil et de l'espace disponible suruserdata
. En général, entre 50 Mo et 100 Mo sont suffisants.Partition
misc
. Cette partition est utilisée par la partition de récupération et est 4 Ko ou plusPartition
userdata
. Cette partition contient les applications installées par l'utilisateur et y compris des données de personnalisation.Partition
metadata
. Cette partition est utilisée pour stocker les métadonnées de chiffrement lorsque l'appareil utilise des métadonnées le chiffrement. La taille est de 16 Mo ou plus Il n'est pas chiffré et ses données ne sont pas capturées. Elles sont effacées lors du rétablissement de la configuration d'usine de l'appareil. L'utilisation de cette partition est est strictement limitée.Partition
vendor
. Cette partition contient un binaire qui n'est pas distribuable à AOSP. Si l’appareil ne contient pas d’informations propriétaires, vous pouvez omettre cette partition.Partition
vendor_dlkm
. Cette partition est dédiée au stockage du fournisseur les modules du noyau. Stockage des modules du noyau du fournisseur dans la partitionvendor_dlkm
(contrairement à la partitionvendor
) permet de mettre à jour le noyau modules sans mettre à jour la partitionvendor
.Partition
radio
. Cette partition contient l'image radio et est nécessaire Uniquement pour les appareils dotés d'une radio dotée d'un logiciel spécifique partition dédiée.Partition
tos
. Cette partition stocke l'image binaire de l'OS Trusty et n'est utilisé que si l'appareil inclut Trusty. Pour en savoir plus, consultez les Conditions d'utilisation Partitions.Partition
pvmfw
. Cette partition stocke la VM protégée Micrologiciel (pvmfw) : premier code exécuté dans les VM protégées. Voir Micrologiciel de machine virtuelle protégée pour en savoir plus.
Partitions dynamiques
Compatibilité avec les appareils équipés d'Android 11 ou version ultérieure les partitions dynamiques, qui sont un système de partitionnement de l'espace utilisateur pour Android qui permet de créer, redimensionner ou détruire des partitions lors d'opérations Over The Air (OTA) mises à jour. Pour en savoir plus, consultez la section Créations dynamiques partitions.
Désigner des partitions critiques
Si l'appareil nécessite des partitions ou des données spécifiques pour s'exécuter, vous devez désigner
ces partitions ou données comme étant entièrement protégées ou reflashables,
ils sont recompilant, fournis ou extraits à l'aide d'une commande fastboot oem
.
Il peut s'agir de paramètres d'usine spécifiques à l'appareil, de numéros de série,
les données de calibrage, etc.
Modifications apportées à Android 11
Android 11 inclut de nombreuses modifications apportées aux partitions, y compris des restrictions sur la association à des bibliothèques et à de nouvelles variantes d'image Soong.
Figure 1 : Disposition des partitions dans Android 11
Image système unique (SSI). Une nouvelle image conceptuelle contenant Images
system
etsystem_ext
. Lorsque ces partitions sont courantes pour un ensemble des appareils cibles, ils peuvent partager le SSI sans avoir à créer Imagessystem
etsystem_ext
.Partition
system_ext
. Une nouvelle partition pouvant utiliser des ressourcessystem
et peuvent inclure des modules système qui:Étendre les modules système AOSP dans la partition
system
Nous vous recommandons le transfert de ces modules vers AOSP afin qu'ils puissent être installés dans lesystem
partitionner plus tard.Bundle de modules OEM ou SoC spécifiques. Nous vous recommandons de dégrouper ces modules afin de pouvoir les installer sur la partition
product
ouvendor
.
Partition
system
. Image système commune utilisée pour les produits OEM. Mer recommandent de retirer les modules propriétaires de la partitionsystem
, les migrer vers AOSP ou les déplacer vers la partitionsystem_ext
.Partition
product
. Cette partition peut désormais utiliser les interfaces autorisées pour installer des modules spécifiques à un produit qui ne sont pas regroupés des partitions.
Modifications apportées au VNDK
Le kit de développement natif pour les fournisseurs (VNDK)
est un ensemble de bibliothèques installées dans la partition system
et conçu
exclusivement pour les fournisseurs
pour mettre en œuvre leurs HAL.
Sous Android 10 et versions antérieures, la partition
vendor
peut être associée à des bibliothèques VNDK dans la partitionsystem
, mais ne pouvez pas créer de lien vers d'autres bibliothèques danssystem
partition. Les modules natifs de la partitionproduct
peuvent être associés à n'importe quelle bibliothèque dans la partitionsystem
.Sous Android 11 ou version ultérieure,
product
etvendor
des partitions peuvent être associées à des bibliothèques VNDK dans la partitionsystem
, mais ne peuvent pas créer des liens vers d'autres bibliothèques de la partitionsystem
.
Variantes de produits Soong
Le système de compilation Soong utilise des variantes d'image pour diviser
créer des dépendances. Les modules natifs (/build/soong/cc
) peuvent modifier le système
des modules de processus à la variante principale et des modules de processus des fournisseurs à la
Variante du fournisseur un module dans une variante d'image ne peut pas être associé à d'autres modules dans
une variante d'image différente.
Sur Android 10 ou version antérieure, un module système crée automatiquement des variantes principales. Il peut également créer des variantes de fournisseur en définissant
vendor_available: true
dans sesAndroid.bp
fichiers ; cela permet aux modules du fournisseur de se connecter à des modules système. Les bibliothèques VNDK, qui sont des variantes de fournisseurs des bibliothèquessystem
, peuvent également créer des variantes de fournisseur pour les modules de fournisseurs en définissantvendor_available: true
dans ses fichiersAndroid.bp
(voir exemple).Sous Android 11, un module système peut également créez une variante de produit (en plus des variantes principales et des variantes du fournisseur) définir
vendor_available: true
.Dans Android 12 ou version ultérieure, un module système avec
vendor_available: true
crée une variante de fournisseur en plus de la variante principale variante d'origine. Pour créer une variante de produit,product_available: true
doit être définis. Certaines bibliothèques VNDK sansproduct_available: true
ne sont pas disponibles pour les modules de produits.