Vue d'ensemble

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'aide mkbootimg . 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 partition vendor , system ou dtb (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 partition odm_dlkm (par opposition à la partition odm ) permet de mettre à jour les modules du noyau ODM sans mettre à jour la partition odm .

• 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'image boot ou init_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 sur userdata ; 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 partition vendor_dlkm (par opposition à la partition vendor ) permet de mettre à jour les modules du noyau sans mettre à jour la partition vendor .

• 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 et system_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 images system et system_ext .

• partition system_ext . Une nouvelle partition pouvant utiliser les ressources system 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 partition system .

  • 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 ou vendor .

• 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 partition system , soit en les amontant vers AOSP, soit en les déplaçant vers la partition system_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 partition system , mais ne peut pas être liée à d'autres bibliothèques de la partition system . Les modules natifs de la partition product peuvent être liés à n'importe quelle bibliothèque de la partition system .

• Sous Android 11 et versions ultérieures, les partitions product et vendor peuvent être liées aux bibliothèques VNDK dans la partition system , mais ne peuvent pas être liées à d'autres bibliothèques dans la partition system .

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 fichiers Android.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èques system , peuvent également créer des variantes fournisseur pour les modules fournisseur en définissant vendor_available: true dans ses fichiers Android.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 sans product_available: true ne sont pas disponibles pour les modules de produit.