Diese Seite wurde von der Cloud Translation API übersetzt.

Ladefähige Kernelmodule

Als Teil der Modul-Kernel-Anforderungen, die mit Android 8.0 eingeführt wurden, SoC-Kernel (System-on-Chip) müssen ladbare Kernel-Module unterstützen.

Kernel-Konfigurationsoptionen

Zur Unterstützung ladebarer Kernelmodule android-base.config enthält in allen gängigen Kerneln den folgenden Kernel-config-Optionen (oder deren Kernel-Version-Entsprechung):

CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODVERSIONS=y

Alle Geräte-Kernels müssen diese Optionen aktivieren. Kernelmodule sollten auch wann immer möglich das Entladen und Neuladen unterstützen.

Hinweis: CONFIG_MODULE_SRCVERSION_ALL ist optional und wird nicht getestet zu vergleichen.

Modulsignatur

Die Modulsignierung wird für GKI-Anbietermodule nicht unterstützt. Auf Geräten, die für Folgendes erforderlich sind: unterstützen Verified Boot, Android erfordert Kernelmodule in den Partitionen für die dm-verity aktiviert ist. Sie müssen dann keine Person mehr signieren. Module auf ihre Authentizität. Mit Android 13 wurde das Konzept der GKI-Module eingeführt. GKI-Module nutzen die Build-Zeit des Kernels Signaturinfrastruktur, um zwischen GKI und anderen Modulen während der Laufzeit zu unterscheiden. Nicht signierte Module dürfen geladen werden, solange sie nur Symbole verwenden, die auf der Zulassungsliste stehen oder von anderen nicht signierten Modulen bereitgestellt werden. Um das Signieren von GKI-Modulen während des GKI-Builds mit dem Build-Zeit-Schlüsselpaar des Kernels zu erleichtern, Die GKI-Kernel-Konfiguration hat CONFIG_MODULE_SIG_ALL=y aktiviert. Um zu vermeiden, dass während der Build-Kernel-Builds für Geräte Nicht-GKI-Module signiert werden, müssen Sie # CONFIG_MODULE_SIG_ALL is not set als Teil Ihrer Kernel-Konfiguration Fragmenten.

Dateispeicherorte

Bei Android 7.x und niedriger sind hingegen keine Kernel-Module (und Unterstützung für insmod und rmmod), Android 8.x und empfehlen den Einsatz von Kernelmodulen. Die folgenden Die Tabelle zeigt die mögliche Unterstützung von boardspezifischen Peripheriegeräten über drei Android-Bootmodi

Bootmodus	Speicher	Anzeige	Wähltastatur	Akku	PMIC	Touchscreen	NFC, WLAN, Bluetooth	Sensoren	Kamera
Recovery
Ladegerät
Android

Neben der Verfügbarkeit im Android-Bootmodus können Kernelmodule auch kategorisiert nach ihrer Inhaberschaft (SoC-Anbieter oder ODM) Wenn Kernelmodule sind die Anforderungen für ihre Platzierung im Dateisystem folgt:

Alle Kernel sollten integrierte Unterstützung für das Booten und Bereitstellen haben Partitionen.
Kernelmodule müssen aus einer schreibgeschützten Partition geladen werden.
Für Geräte mit verifiziertem Bootmodus sollten die Kernelmodule aus geprüften Partitionen geladen.
Die Kernelmodule sollten sich nicht in /system befinden.
Für das Gerät erforderliche GKI-Module sollten über /system/lib/modules, ein symbolischer Link zu /system_dlkm/lib/modules.
Kernelmodule vom SoC-Anbieter, die für vollständige Android- oder Die Modi für das Ladegerät müssen sich in /vendor/lib/modules befinden.
Wenn eine ODM-Partition vorhanden ist: erforderliche Kernelmodule aus der ODM für den vollen Android- oder Ladegerätmodus befinden, /odm/lib/modules Andernfalls sollten sich diese Module /vendor/lib/modules
Kernelmodule vom SoC-Anbieter und ODM, die für die Wiederherstellung erforderlich sind Modus sollte sich im ramfs für die Wiederherstellung unter /lib/modules.
Kernelmodule, die sowohl für den Wiederherstellungsmodus als auch für die Vollversion von Android oder Ladegerätmodi sollten sowohl im Wiederherstellungs-rootfs als auch im entweder die /vendor- oder /odm-Partition (wie beschrieben oben).
Die im Wiederherstellungsmodus verwendeten Kernelmodule sollten nicht von Modulen abhängig sein, die sich im nur in /vendor oder /odm, da diese Partitionen nicht im Wiederherstellungsmodus bereitgestellt.
Die Kernelmodule von SoC-Anbietern sollten nicht von ODM-Kernelmodulen abhängig sein.

Unter Android 7.x und niedriger: /vendor und /odm Partitionen werden nicht vorzeitig bereitgestellt. Unter Android 8.x und höher um das Laden von Modulen aus diesen Partitionen zu ermöglichen, wurden Vorkehrungen um Partitionen frühzeitig bereitzustellen, Nicht-A/B- und A/B-Geräte. Dies gilt auch für sorgt dafür, dass die Partitionen sowohl im Android- als auch im Charger-Modus bereitgestellt werden.

Android-Build-Systemunterstützung

In BoardConfig.mk definiert der Android-Build ein BOARD_VENDOR_KERNEL_MODULES, die eine vollständige Liste liefert der für das Anbieter-Image vorgesehenen Kernelmodule. Die in den Diese Variable wird unter /lib/modules/ in das Anbieter-Image kopiert. und nach der Bereitstellung in Android /vendor/lib/modules (gemäß den oben genannten Anforderungen). Beispielkonfiguration der Kernel-Module des Anbieters:

vendor_lkm_dir := device/$(vendor)/lkm-4.x
BOARD_VENDOR_KERNEL_MODULES := \
  $(vendor_lkm_dir)/vendor_module_a.ko \
  $(vendor_lkm_dir)/vendor_module_b.ko \
  $(vendor_lkm_dir)/vendor_module_c.ko

In diesem Beispiel wird ein vordefiniertes Repository des Anbieter-Kernelmoduls den Android-Build unter dem oben angegebenen Speicherort ab.

Das Wiederherstellungsabbild kann einen Teil der Anbietermodule enthalten. Das Android- Build definiert die Variable BOARD_RECOVERY_KERNEL_MODULES für dieser Module. Beispiel:

vendor_lkm_dir := device/$(vendor)/lkm-4.x
BOARD_RECOVERY_KERNEL_MODULES := \
  $(vendor_lkm_dir)/vendor_module_a.ko \
  $(vendor_lkm_dir)/vendor_module_b.ko

Der Android-Build führt depmod aus, um den Erforderliche modules.dep-Dateien in /vendor/lib/modules und /lib/modules (recovery ramfs).

Laden und Versionsverwaltung des Moduls

Alle Kernelmodule in einem Durchlauf von init.rc* durch folgenden Aufruf laden modprobe -a. Dadurch wird der Aufwand für eine wiederholte Initialisierung vermieden. der C-Laufzeitumgebung für das modprobe-Binärprogramm. Die Sie können das early-init-Ereignis ändern, um modprobe aufzurufen:

on early-init
    exec u:r:vendor_modprobe:s0 -- /vendor/bin/modprobe -a -d \
        /vendor/lib/modules module_a module_b module_c ...

Normalerweise muss ein Kernelmodul mit dem Kernel kompiliert werden, den das Modul verwendet werden soll (andernfalls verweigert der Kernel, das Modul zu laden). CONFIG_MODVERSIONS erkennt Schwachstellen und bietet so eine Abhilfe. in der Binärschnittstelle (Application binary Interface, ABI) aus. Diese Funktion berechnet einen zyklischen für den Prototyp jedes exportierten Symbols im und speichert die Werte als Teil des Kernels. für Symbole, die von einem werden die Werte auch im Kernelmodul gespeichert. Wenn der Parameter Modul geladen wird, werden die Werte für die vom Modul verwendeten Symbole verglichen. mit denen im Kernel. Wenn die Werte übereinstimmen, wird das Modul geladen. sonst schlägt das Laden fehl.

So aktivieren Sie die Aktualisierung des Kernel-Images getrennt vom Anbieter-Image: CONFIG_MODVERSIONS aktivieren. Dadurch werden kleine Aktualisierungen Kernel (z. B. Fehlerbehebungen im Langzeitsupport) unter Aufrechterhaltung der Kompatibilität mit vorhandenen Kernel-Modulen im Anbieter-Image. Sie können jedoch CONFIG_MODVERSIONS behebt einen ABI-Fehler nicht selbst. Wenn die eines exportierten Symbols in den Kernel-Änderungen, entweder aufgrund von oder die Kernel-Konfiguration geändert hat, beeinträchtigt die Kompatibilität mit Kernelmodulen, die dieses Symbol verwenden. In solchen Fällen muss das Kernelmodul neu kompiliert werden.

Zum Beispiel ist die task_struct-Struktur im Kernel (definiert in include/linux/sched.h) enthält viele Felder, die bedingt je nach Kernel-Konfiguration. Das sched_info ist nur vorhanden, wenn CONFIG_SCHED_INFO aktiviert ist (was tritt auf, wenn CONFIG_SCHEDSTATS oder CONFIG_TASK_DELAY_ACCT aktiviert sind). Wenn diese Konfiguration Status der Optionen ändert sich, das Layout der task_struct-Struktur und alle exportierten Schnittstellen aus dem Kernel, die task_struct geändert werden (z. B. set_cpus_allowed_ptr in kernel/sched/core.c). Kompatibilität mit zuvor kompilierten Kernelmodulen, die diese Schnittstellen funktionieren nicht mehr, sodass diese Module mit dem neuen Kernel neu erstellt werden müssen. Konfiguration.

Weitere Informationen zu CONFIG_MODVERSIONS finden Sie in der in der Kernel-Baumstruktur unter Documentation/kbuild/modules.rst.