Les appareils Android incluent plusieurs partitions qui remplissent différentes fonctions dans le processus de démarrage.
Cloisons standards
partition
boot
. Cette partition contient une image du noyau et est créée à l'aidemkbootimg
. Vous pouvez utiliser une partition virtuelle pour flasher l'une ou l'autre image directement sans flasher une nouvelle partition de démarrage. Cette partition contient également le disque virtuel générique dans les appareils lancés avant Android 13.noyau. La partition
kernel
virtuel écrase le noyau (zImage
,zImage-dtb
,Image.gz-dtb
) en écrivant la nouvelle image du noyau sur l'ancienne image du noyau. Si le noyau de développement fourni est incompatible, vous devrez peut-être mettre à jour la partitionvendor
,system
oudtb
(le cas échéant) avec les modules de noyau associés.disque virtuel. La partition
ramdisk
virtuel écrase le disque virtuel en écrivant la nouvelle image du disque virtuel sur l'ancienne image du disque virtuel.
L'opération d'écrasement détermine l'emplacement de départ de l'image existante dans eMMC et copie la nouvelle image à cet emplacement. La nouvelle image (noyau ou disque virtuel) peut être plus grande que l'existante ; pour libérer de l'espace, le chargeur de démarrage peut déplacer les données en suivant l'image ou abandonner l'opération avec une erreur.
partition
init_boot
. Cette partition contient le disque virtuel générique pour les appareils lancés avec Android 13 et au-delà.partition
system
. Cette partition contient le framework Android.partition
odm
. Cette partition contient les personnalisations du fabricant de conception d'origine (ODM) pour les packages de support de carte (BSP) du fournisseur de système sur puce (SoC). De telles personnalisations permettent aux ODM de remplacer ou de personnaliser les composants SoC et d'implémenter des modules de noyau pour les composants spécifiques à la carte, les démons et les fonctionnalités spécifiques à ODM sur les couches d'abstraction matérielle (HAL). Cette partition est facultative ; généralement, il est utilisé pour contenir des personnalisations afin que les appareils puissent utiliser une image de fournisseur unique pour plusieurs SKU de matériel. Pour plus de détails, consultez Partitions ODM .partition
odm_dlkm
. Cette partition est dédiée au stockage des modules du noyau ODM. Le stockage des modules du noyau ODM dans la partitionodm_dlkm
(par opposition à la partitionodm
) 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, qui est démarrée pendant le processus OTA. Les appareils prenant en charge les mises à jour transparentes peuvent stocker les images de récupération sous forme de disque virtuel contenu dans l'imageboot
ouinit_boot
(plutôt que dans une image distincte).partition
cache
. Cette partition stocke les données temporaires et est facultative si un appareil utilise des mises à jour transparentes. La partition de cache n'a pas besoin d'être accessible en écriture à partir du chargeur de démarrage, mais doit être effaçable. La taille de la partition dépend du type de périphérique et de la disponibilité de l'espace suruserdata
; généralement, 50 Mo à 100 Mo suffisent.misc
partitions. Cette partition est utilisée par la partition de récupération et fait 4 Ko ou plus.partition
userdata
. Cette partition contient les applications et les données installées par l'utilisateur, y compris les données de personnalisation.partition
metadata
. Cette partition est utilisée pour stocker la clé de chiffrement des métadonnées lorsque l'appareil utilise le chiffrement des métadonnées . La taille est de 16 Mo ou plus. Il n'est pas chiffré et ses données ne sont pas instantanées. Il est effacé lors de la réinitialisation d'usine de l'appareil. L'utilisation de cette partition est strictement limitée.partition
vendor
. Cette partition contient tout binaire qui n'est pas distribuable à AOSP. Si le périphérique ne contient pas d'informations propriétaires, vous pouvez omettre cette partition.partition
vendor_dlkm
. Cette partition est dédiée au stockage des modules du noyau du fournisseur. Le stockage des modules du noyau du fournisseur dans la partitionvendor_dlkm
(par opposition à la partitionvendor
) permet de mettre à jour les modules du noyau sans mettre à jour la partitionvendor
.cloison
radio
. Cette partition contient l'image radio et est nécessaire uniquement pour les appareils qui incluent une radio avec un logiciel spécifique à la radio dans une partition dédiée.partition
tos
. Cette partition stocke l'image binaire du système d'exploitation Trusty et n'est utilisée que si l'appareil inclut Trusty. Pour plus de détails, consultez Partitions TOS .partition
pvmfw
. Cette partition stocke le micrologiciel de machine virtuelle protégé (pvmfw), qui est le premier code exécuté dans les machines virtuelles protégées. Voir Micrologiciel de machine virtuelle protégée pour plus de détails.
Partitions dynamiques
Les appareils exécutant Android 11 et versions ultérieures peuvent prendre en charge les partitions dynamiques, qui sont un système de partitionnement de l'espace utilisateur pour Android qui permet de créer, de redimensionner ou de détruire des partitions lors des mises à jour en direct (OTA). Pour plus de détails, consultez Partitions dynamiques .
Désignation des partitions critiques
Si le périphérique nécessite l'exécution de partitions ou de données spécifiques, vous devez désigner ces partitions/données comme étant entièrement protégées ou re-flashables, ce qui signifie qu'elles sont reconstructibles, fournies ou extractibles à l'aide d'une commande fastboot oem
. Cela inclut des données telles que les paramètres d'usine spécifiques à chaque appareil, les numéros de série, les données d'étalonnage, etc.
Changements dans Android 11
Android 11 inclut de nombreuses modifications apportées aux partitions, notamment des restrictions sur les liens vers les bibliothèques et de nouvelles variantes d'images Soong.
Figure 1. Disposition des partitions dans Android 11
Image système unique (SSI). Une nouvelle image conceptuelle qui contient les images
system
etsystem_ext
. Lorsque ces partitions sont communes à un ensemble de périphériques cibles, ces périphériques peuvent partager le SSI et ignorer la création des imagessystem
etsystem_ext
.partition
system_ext
. Une nouvelle partition pouvant utiliser les ressourcessystem
et inclure des modules système qui :Étendez les modules système AOSP dans la partition
system
. Nous vous recommandons de mettre en amont ces modules sur AOSP afin qu'ils puissent être installés ultérieurement sur la partitionsystem
.Regroupez des modules spécifiques aux OEM ou aux SoC. Nous vous recommandons de dégrouper ces modules afin qu'ils puissent être installés sur la partition du
product
ouvendor
.
partition
system
. Image système commune utilisée pour les produits OEM. Nous vous recommandons de déplacer les modules propriétaires hors de la partitionsystem
, soit en les amontant vers AOSP, soit en les déplaçant vers la partitionsystem_ext
.partition
product
. Cette partition peut désormais utiliser les interfaces autorisées pour installer des modules spécifiques au produit qui ne sont fournis avec aucune autre partition.
Modifications du VNDK
Le Vendor Native Development Kit (VNDK) est un ensemble de bibliothèques installées dans la partition system
et conçues exclusivement pour que les fournisseurs puissent implémenter leurs HAL.
Sous Android 10 et versions antérieures, la partition
vendor
peut être liée aux bibliothèques VNDK de la partitionsystem
, mais ne peut pas être liée à d'autres bibliothèques de la partitionsystem
. Les modules natifs de la partitionproduct
peuvent être liés à n'importe quelle bibliothèque de la partitionsystem
.Sous Android 11 et versions ultérieures, les partitions
product
etvendor
peuvent être liées aux bibliothèques VNDK dans la partitionsystem
, mais ne peuvent pas être liées à d'autres bibliothèques dans la partitionsystem
.
Variantes de produits Soong
Le système de build Soong utilise des variantes d'image pour diviser les dépendances de build. Les modules natifs ( /build/soong/cc
) peuvent muter les modules de processus système vers la variante principale et les modules de processus fournisseur vers la variante fournisseur ; un module dans une variante d'image ne peut pas être lié à d'autres modules dans une variante d'image différente.
Sous 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 ses fichiersAndroid.bp
; cela permet aux modules du fournisseur de se lier aux modules système. Les bibliothèques VNDK, qui sont des variantes fournisseur des bibliothèquessystem
, peuvent également créer des variantes fournisseur pour les modules fournisseur en définissantvendor_available: true
dans ses fichiersAndroid.bp
(voir exemple ).Dans Android 11, un module système peut également créer une variante de produit (en plus des variantes de base et de fournisseur) en définissant
vendor_available: true
.Sous 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. Pour créer une variante de produit,product_available: true
doit être défini. Certaines bibliothèques VNDK sansproduct_available: true
ne sont pas disponibles pour les modules de produit.