Aperçu

Les appareils Android incluent plusieurs partitions qui remplissent différentes fonctions dans le processus de démarrage.

Partitions standards

  • Partition boot. Cette partition contient une image de noyau et est créée à l'aide de 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 ramdisk générique sur les appareils lancés avant Android 13.

    • kernel. La partition kernel virtuelle é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 (si elle est présente) avec les modules de noyau associés.

    • ramdisk. La partition ramdisk virtuelle écrase le ramdisk en écrivant la nouvelle image ramdisk sur l'ancienne image ramdisk.

    L'opération d'écrasement détermine l'emplacement de début de l'image existante dans l'eMMC et copie la nouvelle image à cet emplacement. La nouvelle image (kernel ou ramdisk) peut être plus grande que l'image existante. Pour libérer de l'espace, le bootloader peut déplacer les données après l'image ou abandonner l'opération avec une erreur.

  • Partition init_boot. Cette partition contient le ramdisk générique pour les appareils lancés avec Android 13 ou version ultérieure.

  • Partition system. Cette partition contient le framework Android.

  • Partition odm. Cette partition contient les personnalisations du fabricant d'appareils d'origine (ODM) pour les packages de prise en charge de carte (BSP) des fournisseurs de systèmes sur une puce (SoC). Ces personnalisations permettent aux ODM de remplacer ou de personnaliser les composants SoC, et d'implémenter des modules de kernel pour les composants, les daemons et les fonctionnalités spécifiques à l'ODM sur les couches d'abstraction matérielle (HAL). Cette partition est facultative. Elle est généralement utilisée pour contenir des personnalisations afin que les appareils puissent utiliser une seule image du fournisseur pour plusieurs SKU matériels. Pour en savoir plus, consultez la section Partitions ODM.

  • Partition odm_dlkm. Cette partition est dédiée au stockage des modules de kernel ODM. Le stockage des modules de noyau ODM dans la partition odm_dlkm (par opposition à la partition odm) permet de mettre à jour les modules de 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 compatibles avec les mises à jour fluides peuvent stocker les images de récupération en tant que ramdisk contenu dans l'image boot ou init_boot (plutôt qu'une image distincte).

  • Partition cache. Cette partition stocke des données temporaires et est facultative si un appareil utilise des mises à jour fluides. La partition de cache n'a pas besoin d'être accessible en écriture à partir du bootloader, mais elle doit être effaçable. La taille de la partition dépend du type d'appareil et de la disponibilité d'espace sur userdata. En règle générale, 50 Mo à 100 Mo suffisent.

  • Partition misc. Cette partition est utilisée par la partition de récupération et est de 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 permet de 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 enregistrées. Il est effacé lorsque la configuration d'usine de l'appareil est rétablie. L'utilisation de cette partition est strictement limitée.

  • Partition vendor. Cette partition contient tous les binaires non distribuables vers 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 des modules de kernel du fournisseur. Le stockage des modules de kernel du fournisseur dans la partition vendor_dlkm (par opposition à la partition vendor) permet de mettre à jour les modules de kernel sans mettre à jour la partition vendor.

  • Partition radio. Cette partition contient l'image radio et n'est nécessaire que 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 de l'OS Trusty et n'est utilisée que si l'appareil inclut Trusty. Pour en savoir plus, consultez la section Partitions TOS.

  • Partition pvmfw. Cette partition stocke le micrologiciel de la machine virtuelle protégée (pvmfw), qui est le premier code exécuté dans les VM protégées. Pour en savoir plus, consultez la section Micrologiciel de machine virtuelle protégé.

Partitions dynamiques

Les appareils équipés d'Android 11 ou version ultérieure 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 OTA (Over-the-Air). Pour en savoir plus, consultez la section Partitions dynamiques.

Désigner des partitions critiques

Si l'appareil nécessite des partitions ou des données spécifiques pour s'exécuter, vous devez les désigner comme entièrement protégées ou comme pouvant être flashées, ce qui signifie qu'elles peuvent être recréées, fournies ou extraites à l'aide d'une commande fastboot oem. Cela inclut des données telles que les paramètres d'usine par appareil, les 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 l'association à des bibliothèques et de nouvelles variantes d'images Soong.

Mise en page de la partition Android

Figure 1 : Mise en page des partitions sous Android 11

  • Image système unique (SSI) Nouvelle image conceptuelle contenant les images system et system_ext. Lorsque ces partitions sont communes à un ensemble d'appareils cibles, ces appareils peuvent partager la SSI et ignorer la création des images system et system_ext.

  • Partition system_ext. Une nouvelle partition pouvant utiliser des ressources system et pouvant inclure des modules système qui:

    • Étendez les modules système AOSP dans la partition system. Nous vous recommandons de transférer ces modules vers AOSP afin qu'ils puissent être installés dans la partition system plus tard.

    • Regroupez les modules spécifiques à l'OEM ou au SoC. Nous vous recommandons de dissocier ces modules afin qu'ils puissent être installés sur la partition product ou vendor.

  • Partition system. Image système courante utilisée pour les produits OEM. Nous vous recommandons de déplacer les modules propriétaires hors de la partition system, soit en les transférant vers AOSP, soit en les déplaçant vers la partition system_ext.

  • Partition product. Cette partition peut désormais utiliser des interfaces autorisées pour installer des modules spécifiques au produit qui ne sont pas groupés avec d'autres partitions.

Modifications apportées au VNDK

Le kit de développement natif pour les éditeurs (VNDK) est un ensemble de bibliothèques installées dans la partition system et conçues exclusivement pour permettre aux fournisseurs d'implémenter leurs HAL.

  • Sous Android 10 et versions antérieures, la partition vendor peut associer des bibliothèques VNDK dans la partition system, mais ne peut pas associer d'autres bibliothèques dans la partition system. Les modules natifs de la partition product peuvent être associés à n'importe quelle bibliothèque de la partition system.

  • Sous Android 11 et versions ultérieures, les partitions product et vendor peuvent associer des bibliothèques VNDK dans la partition system, mais ne peuvent pas associer d'autres bibliothèques dans la partition system.

Variantes de produits Soong

Le système de compilation Soong utilise des variantes d'images pour diviser les dépendances de compilation. Les modules natifs (/build/soong/cc) peuvent muter les modules de processus système en variante de base et les modules de processus du fournisseur en variante du fournisseur. Un module d'une variante d'image ne peut pas être associé à d'autres modules d'une autre variante d'image.

  • Sous Android 10 ou version antérieure, un module système crée automatiquement des variantes de base. Il peut également créer des variantes de fournisseurs en définissant vendor_available: true dans ses fichiers Android.bp. Cela permet aux modules du fournisseur de s'associer aux modules système. Les bibliothèques VNDK, qui sont des variantes du fournisseur des bibliothèques system, peuvent également créer des variantes du fournisseur pour les modules du fournisseur en définissant vendor_available: true dans ses fichiers Android.bp (voir exemple).

  • Sous Android 11, un module système peut également créer une variante de produit (en plus des variantes de base et du fournisseur) en définissant vendor_available: true.

  • Dans Android 12 ou version ultérieure, un module système avec vendor_available: true crée une variante du fournisseur en plus de la variante de base. 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 produits.