Diese Seite wurde von der Cloud Translation API übersetzt.

GKI-Modulpartition implementieren

GKI und GKI-Module können unabhängig vom Rest der Partition aktualisiert werden, da sich GKI-Module auf einer separaten dynamischen Partition im Super-Image namens system_dlkm befinden. GKI-Module werden von Google mit dem Schlüsselpaar zur Kernel-Buildzeit signiert und sind nur mit der GKI kompatibel, mit der sie erstellt wurden. Es gibt keine ABI-Stabilität zwischen GKI- und GKI-Modulen. Damit Module während der Laufzeit korrekt geladen werden können, müssen GKI- und GKI-Module gemeinsam erstellt und aktualisiert werden.

Unterstützung für system_dklm-Partitionen implementieren

Die Partition system_dlkm befindet sich in der Superpartition als weitere dynamische Partition. Diese Partition kann Folgendes enthalten:

Von Google zur Build-Zeit signierte Kernelmodule
depmod Artefakte

Build `system_dlkm`

Das Erstellen von system_dlkm ähnelt dem Erstellen anderer dynamischer Partitionen. Führen Sie die folgenden Schritte aus, um system_dlkm zu Ihrem Build hinzuzufügen:

Fügen Sie BoardConfig.mk die folgenden Einträge hinzu:

BOARD_USES_SYSTEM_DLKMIMAGE := true
BOARD_SYSTEM_DLKMIMAGE_FILE_SYSTEM_TYPE := $(TARGET_RO_FILE_SYSTEM_TYPE)
TARGET_COPY_OUT_SYSTEM_DLKM := system_dlkm

Fügen Sie system_dlkm zur Partitionsliste hinzu: BOARD_GOOGLE_SYSTEM_DYNAMIC_PARTITIONS_PARTITION_LIST := system_dlkm
Optional: Fügen Sie für A/B- und virtuelle A/B-Geräte die folgende Zeile in die Datei device.mk für Ihr Gerät ein:
```
AB_OTA_PARTITIONS += system_dlkm
```

Kernelmodule identifizieren, die in `system_dlkm` kopiert werden sollen

Damit Module zur Laufzeit erfolgreich geladen werden, müssen GKI- und GKI-Module zusammen erstellt werden. Daher müssen Sie Kernelmodule im GKI-Build für die Zielarchitektur identifizieren und diese beim Plattformbuild als Quelle für die system_dlkm-Partition angeben.

Für Android 13

Weisen Sie BOARD_SYSTEM_DLKM_SRC einen Ordner mit den erforderlichen GKI-Modulen und Kernelobjektdateien für das Gerät als Eingabe für das Build-System zu, um die system_dlkm-Partition zu generieren. Beispiel:

Geben Sie die GKI-Modulquelle in einem Ordner an und verweisen Sie BOARD_SYSTEM_DLKM_SRC auf diesen Ordner. Beispiel:

  BOARD_SYSTEM_DLKM_SRC := kernel/prebuilts/5.10/arm64/system_dlkm_staging

Während des Builds werden die in BOARD_SYSTEM_DLKM_SRC aufgeführten Module in $ANDROID_PRODUCT_OUT/system_dlkm installiert.

Für Android 14

Wir haben die Implementierung optimiert, indem die Makros (BOARD_*_KERNEL_MODULES) für andere *_dlkm-Partitionen verwendet werden. Die Liste der erforderlichen GKI-Module für das Gerät sollte über das BOARD_SYSTEM_KERNEL_MODULES-Makro referenziert werden. Diese Module werden während der Buildzeit in der $ANDROID_PRODUCT_OUT/system_dlkm installiert. Jedes Modul in der vendor_dlkm-Partition, das von den Modulen in der system_dlkm-Partition abhängig ist, generiert korrekte Verweise in der modules.dep-Datei für die vendor_dlkm-Partition. Aufgrund der mandantenübergreifenden Abhängigkeiten, die durch modules.dep dargestellt werden, werden beim Laden eines Anbietermoduls automatisch alle erforderlichen GKI-Module geladen.

So installieren Sie beispielsweise alle GKI-Module auf der system_dlkm-Partition für den GKI-arm64-Kernel 5.15 aus Prebuilts:

 BOARD_SYSTEM_KERNEL_MODULES := $(wildcard kernel/prebuilts/5.15/arm64/*.ko)

`system_dlkm` zur Laufzeit bereitstellen

Je nachdem, welches Dateisystem als schreibgeschütztes Dateisystem verwendet wird, fügen Sie Folgendes in fstab ein, um die system_dlkm-Partition zur Laufzeit bereitzustellen:

`ext4` als schreibgeschütztes Dateisystem

  system_dlkm /system_dlkm ext4 noatime,ro,errors=panic wait,logical,first_stage_mount,slotselect,avb

`erofs` als schreibgeschütztes Dateisystem

  system_dlkm /system_dlkm erofs ro wait,logical,first_stage_mount,slotselect,avb

Partitions bereitstellen und Module laden

Während der first_stage_init-Phase wird die Partition system_dlkm im /system_dlkm als schreibgeschütztes Dateisystem bereitgestellt. Nach der erfolgreichen Bereitstellung sind symbolische Links unter /system/lib/modules verfügbar, die auf /system_dlkm/lib/modules verweisen.

Ein Anbieterprozess, z. B. ein .rc-Script, kann die Kernelmodule dann gemäß der in modules.load angegebenen Reihenfolge laden. Der Anbieterprozess muss den symbolischen Link /system/lib/modules verwenden, um die Module zu laden. Bei Bedarf kann der Anbieterprozess die Module auch zu einem späteren Zeitpunkt laden.

SELinux

Jede Datei in der Partition system_dlkm hat den Dateikontext system_dlkm_file. Damit die GKI-Moduldatei in die Partition system_dlkm geladen werden kann, benötigt der für das Laden der Module zuständige Anbieterprozess eine sepolicy in der Anbieterdomain.

Beispielsweise hat dlkm_loader, das von Cuttlefish zum Laden von GKI-Modulen verwendet wird, die folgenden Berechtigungen in der Richtliniendatei unter 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;

System-dlkm-Partition prüfen

Google stellt einen GKI VTS-Testfall zur Verfügung, mit dem die system_dlkm-Partition überprüft werden kann. Wenn Sie den Test manuell ausführen möchten, verwenden Sie den folgenden atest-Befehl:

  atest -c vts_dlkm_partition_test