GKI und GKI-Module können unabhängig vom Rest der Partition aktualisiert werden, da sich GKI-Module in einer separaten dynamischen Partition im Super-Image namens system_dlkm befinden. GKI-Module werden von Google mit dem Schlüsselpaar für die Kernel-Build-Zeit signiert und sind nur mit dem GKI kompatibel, mit dem sie erstellt wurden.
Es gibt keine ABI-Stabilität zwischen GKI und GKI-Modulen. Damit Module zur Laufzeit korrekt geladen werden, müssen GKI und GKI-Module zusammen erstellt und aktualisiert werden.
Unterstützung für die Partition „system_dklm“ implementieren
Die Partition system_dlkm befindet sich als weitere dynamische Partition in der Superpartition. Diese Partition kann Folgendes enthalten:
- Von Google zur Build-Zeit signierte Kernelmodule
depmodArtefakte
Build system_dlkm
Das Erstellen von system_dlkm ist ein ähnlicher Vorgang wie das Erstellen anderer dynamischer Partitionen. Führen Sie die folgenden Schritte aus, um system_dlkm in Ihren Build einzufügen:
Fügen Sie in
BoardConfig.mkdie 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_dlkmFügen Sie der Partitionsliste
system_dlkmhinzu:BOARD_GOOGLE_SYSTEM_DYNAMIC_PARTITIONS_PARTITION_LIST := system_dlkmOptional: Fügen Sie für A/B- und virtuelle A/B-Geräte die folgende Zeile in die Datei
device.mkfü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 können, müssen GKI und GKI-Module zusammen erstellt werden. Daher müssen Sie Kernelmodule im GKI-Build für die Zielarchitektur identifizieren und diese als Quelle für die Partition system_dlkm während des Plattform-Builds angeben.
Für Android 13
Verweisen Sie mit BOARD_SYSTEM_DLKM_SRC auf einen Ordner, der die erforderlichen GKI-Modul-Kernel-Objektdateien für das Gerät als Eingabe für das Build-System enthält, um die Partition system_dlkm zu generieren. Beispiel:
Geben Sie die Quelle der GKI-Module in einem Ordner an und verweisen Sie mit 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 mit den Makros (BOARD_*_KERNEL_MODULES) optimiert, die für andere *_dlkm-Partitionen verwendet werden. Die Liste der erforderlichen GKI-Module für das Gerät sollte über das Makro BOARD_SYSTEM_KERNEL_MODULES referenziert werden. Zur Build-Zeit werden diese Module im $ANDROID_PRODUCT_OUT/system_dlkm installiert. Für jedes Modul in der Partition vendor_dlkm, das von den Modulen in der Partition system_dlkm abhängt, werden in der Datei modules.dep korrekte Verweise für die Partition vendor_dlkm generiert. Aufgrund der partitionenübergreifenden Abhängigkeiten, die durch modules.dep dargestellt werden, wird jedes erforderliche GKI-Modul automatisch geladen, wenn ein Anbietermodul geladen wird.
Wenn Sie beispielsweise alle GKI-Module auf der Partition system_dlkm für den GKI-Kernel arm64 5.15 aus Prebuilts installieren möchten:
BOARD_SYSTEM_KERNEL_MODULES := $(wildcard kernel/prebuilts/5.15/arm64/*.ko)
system_dlkm zur Laufzeit bereitstellen
Fügen Sie je nach Dateisystem, das als schreibgeschütztes Dateisystem verwendet wird, Folgendes in Ihre fstab ein, um die Partition system_dlkm 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
Partitionen einhängen und Module laden
Während first_stage_init wird die Partition system_dlkm in /system_dlkm als schreibgeschütztes Dateisystem bereitgestellt. Bei erfolgreicher Einbindung sind symbolische Links unter /system/lib/modules verfügbar, die auf /system_dlkm/lib/modules verweisen.
Ein Anbieterprozess, z. B. ein .rc-Skript, kann dann die Kernelmodule in der in modules.load angegebenen Reihenfolge laden. Im Anbietervorgang muss der symbolische Link /system/lib/modules verwendet werden, um die Module zu laden.
Bei Bedarf können die Module auch zu einem späteren Zeitpunkt vom Anbieterprozess geladen werden.
SELinux
Jede Datei in der Partition system_dlkm ist mit dem Dateikontext system_dlkm_file gekennzeichnet. Damit die GKI-Moduldatei in die Partition system_dlkm geladen werden kann, benötigt der für das Laden der Module verantwortliche Anbieterprozess eine sepolicy in der Anbieterdomain.
Beispiel: dlkm_loader, das von Cuttlefish zum Laden von GKI-Modulen verwendet wird, hat 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 validieren
Google stellt einen GKI-VTS-Testfall zur Verfügung, um die system_dlkm-Partition zu überprüfen. Um den Test manuell aufzurufen, verwenden Sie den folgenden atest-Befehl:
atest -c vts_dlkm_partition_test