Aperçu

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 avec mkbootimg. 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 partition vendor, system ou dtb (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 partition odm_dlkm (par opposition à la partition odm), ce qui 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, 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'image boot ou init_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 sur userdata. 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 plus

• Partition 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 partition vendor_dlkm (contrairement à la partition vendor) permet de mettre à jour le noyau modules sans mettre à jour la partition vendor.

• 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 et system_ext. Lorsque ces partitions sont courantes pour un ensemble des appareils cibles, ils peuvent partager le SSI sans avoir à créer Images system et system_ext.

• Partition system_ext. Une nouvelle partition pouvant utiliser des ressources system 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 le system 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 ou vendor.

• Partition system. Image système commune utilisée pour les produits OEM. Mer recommandent de retirer les modules propriétaires de la partition system, les migrer vers AOSP ou les déplacer vers la partition system_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 partition system, mais ne pouvez pas créer de lien vers d'autres bibliothèques dans system partition. Les modules natifs de la partition product peuvent être associés à n'importe quelle bibliothèque dans la partition system.

• Sous Android 11 ou version ultérieure, product et vendor des partitions peuvent être associées à des bibliothèques VNDK dans la partition system, mais ne peuvent pas créer des liens vers d'autres bibliothèques de la partition system.

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