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 dans 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 (le cas échéant) 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'équipement d'origine (ODM) pour les packages de prise en charge de la carte (BSP) des fournisseurs de système sur puce (SoC). Ces 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 aux cartes, 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 sous la forme d'un disque RAM 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 depuis le 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 Partitions de 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 over-the-air (OTA). 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:

    • Étendre 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.

    • Bundle de modules OEM ou SoC spécifiques. Nous vous recommandons de dégrouper ces modules pour pouvoir les installer sur la partition product ou vendor.

  • Partition system. Image système commune utilisée pour les produits OEM. Nous vous recommandons de retirer les modules propriétaires de la partition system, soit en les mettant à niveau 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çu exclusivement pour permettre aux fournisseurs d'implémenter leurs HAL.

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

  • Sous Android 11 ou version ultérieure, les partitions product et vendor peuvent être associées à des bibliothèques VNDK dans la partition system, mais pas à d'autres bibliothèques de 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 fournisseur en définissant vendor_available: true dans ses fichiers Android.bp. Cela permet aux modules de fournisseurs d'être associés à des modules système. Les bibliothèques VNDK, qui sont des variantes de fournisseurs des bibliothèques system, peuvent également créer des variantes de fournisseur pour les modules de fournisseur en définissant vendor_available: true dans ses fichiers Android.bp (voir l'exemple).

  • Dans Android 11, un module système peut également créer une variante de produit (en plus des variantes principales et de fournisseurs) 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.