Les modules GKI et GKI peuvent être mis à jour indépendamment du reste de la partition car les modules GKI résident sur une partition dynamique distincte dans la super image appelée system_dlkm
. Les modules GKI sont signés par Google à l'aide de la paire de clés de construction du noyau et ne sont compatibles qu'avec le GKI avec lequel ils sont construits. Il n'y a pas de stabilité ABI entre les modules GKI et GKI ; pour que les modules se chargent correctement pendant l'exécution, les modules GKI et GKI doivent être construits et mis à jour ensemble.
Implémenter la prise en charge de la partition system_dklm
La partition system_dlkm
se trouve dans la super partition en tant qu'autre partition dynamique. Cette partition peut contenir :
- Modules de noyau signés au moment de la construction de Google
- artefacts
depmod
Construire system_dlkm
La construction system_dlkm
est un processus similaire à la construction d'autres partitions dynamiques. Effectuez les étapes suivantes pour ajouter system_dlkm
à votre build :
Dans
BoardConfig.mk
, ajoutez les entrées suivantes :BOARD_USES_SYSTEM_DLKMIMAGE := true BOARD_SYSTEM_DLKMIMAGE_FILE_SYSTEM_TYPE := $(TARGET_RO_FILE_SYSTEM_TYPE) TARGET_COPY_OUT_SYSTEM_DLKM := system_dlkm
Dans la liste des partitions, ajoutez
system_dlkm
:BOARD_GOOGLE_SYSTEM_DYNAMIC_PARTITIONS_PARTITION_LIST := system_dlkm
(Facultatif) Pour les appareils A/B et A/B virtuels, ajoutez la ligne suivante dans le fichier
device.mk
de votre appareil :AB_OTA_PARTITIONS += system_dlkm
Identifiez les modules du noyau à copier dans system_dlkm
Pour que les modules se chargent correctement au moment de l'exécution, les modules GKI et GKI doivent être construits ensemble. Par conséquent, vous devez identifier les modules du noyau dans la construction GKI pour l'architecture cible et les fournir comme source pour la partition system_dlkm
lors de la construction de la plateforme.
Pour Android 13
Pointez BOARD_SYSTEM_DLKM_SRC
vers un dossier contenant les fichiers objet du noyau des modules GKI requis pour le périphérique en tant qu'entrée du système de construction pour générer la partition system_dlkm
. Par exemple:
Fournissez la source des modules GKI dans un dossier et pointez BOARD_SYSTEM_DLKM_SRC
vers ce dossier. Par exemple:
BOARD_SYSTEM_DLKM_SRC := kernel/prebuilts/5.10/arm64/system_dlkm_staging
Au moment de la construction, les modules répertoriés dans BOARD_SYSTEM_DLKM_SRC
sont installés dans $ANDROID_PRODUCT_OUT/system_dlkm
.
Pour Android 14
Nous avons rationalisé l'implémentation avec les macros ( BOARD_*_KERNEL_MODULES
) utilisées pour d'autres partitions *_dlkm
. La liste des modules GKI requis pour le périphérique doit être référencée par la macro BOARD_SYSTEM_KERNEL_MODULES
. Au moment de la construction, ces modules sont installés dans le $ANDROID_PRODUCT_OUT/system_dlkm
. Tout module de la partition vendor_dlkm
qui a des dépendances sur les modules de la partition system_dlkm
génère des références correctes dans le fichier modules.dep
pour la partition vendor_dlkm
. En raison de ces dépendances entre partitions représentées par modules.dep
, lorsqu'un module fournisseur est chargé, tout module GKI requis est chargé automatiquement.
Par exemple, pour installer tous les modules GKI sur la partition system_dlkm
pour le noyau GKI arm64
5.15
à partir des versions prédéfinies :
BOARD_SYSTEM_KERNEL_MODULES := $(wildcard kernel/prebuilts/5.15/arm64/*.ko)
Monter system_dlkm
au moment de l'exécution
En fonction du système de fichiers utilisé comme système de fichiers en lecture seule, ajoutez ce qui suit dans votre fstab
pour monter la partition system_dlkm
au moment de l'exécution :
ext4
comme système de fichiers en lecture seule
system_dlkm /system_dlkm ext4 noatime,ro,errors=panic wait,logical,first_stage_mount,slotselect,avb
erofs
comme système de fichiers en lecture seule
system_dlkm /system_dlkm erofs ro wait,logical,first_stage_mount,slotselect,avb
Montage de partitions et chargement de modules
Pendant first_stage_init
, la partition system_dlkm
est montée dans /system_dlkm
en tant que système de fichiers en lecture seule. En cas de montage réussi, des liens symboliques sur /system/lib/modules
pointant vers /system_dlkm/lib/modules
sont disponibles.
Un processus fournisseur, tel qu'un script .rc
, peut ensuite charger les modules du noyau en fonction de l'ordre spécifié dans modules.load
. Le processus fournisseur doit utiliser le lien symbolique /system/lib/modules
pour charger les modules. Si nécessaire, le processus fournisseur peut également charger les modules ultérieurement.
SELinux
Chaque fichier de la partition system_dlkm
est étiqueté avec le contexte de fichier system_dlkm_file
. Pour charger le fichier des modules GKI dans la partition system_dlkm
, le processus fournisseur responsable du chargement des modules a besoin d'une sepolicy
dans le domaine du fournisseur.
Par exemple, dlkm_loader
utilisé par Cuttlefish pour charger les modules GKI dispose des autorisations suivantes dans le fichier de stratégie sur shared/sepolicy/vendor/dlkm_loader.te
:
allow dlkm_loader self:capability sys_module;
allow dlkm_loader system_dlkm_file:dir r_dir_perms;
allow dlkm_loader system_dlkm_file:file r_file_perms;
allow dlkm_loader system_dlkm_file:system module_load;
Valider la partition system-dlkm
Google fournit un scénario de test GKI VTS pour vérifier la partition system_dlkm
. Pour appeler manuellement le test, utilisez la commande atest
suivante :
atest -c vts_dlkm_partition_test