Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Verzeichnisse, Regeln und SEPolicy
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite wird das Verzeichnislayout für Geräte mit Android 8.0 und höher, VNDK-Regeln und die zugehörige SEPolicy beschrieben.

Verzeichnislayout

Das degenerierte Verzeichnislayout besteht aus den folgenden Verzeichnissen:

/system/lib[64] enthält alle gemeinsam genutzten Framework-Bibliotheken, einschließlich LL-NDK-, VNDK- und nur Framework-Bibliotheken (einschließlich LL-NDK-Private und einiger Bibliotheken mit denselben Namen wie die in VNDK-SP).
/system/lib[64]/vndk-sp enthält VNDK-SP-Bibliotheken für HALs mit demselben Prozess.
/vendor/lib[64] enthält die vom Anbieter erweiterten VNDK-Bibliotheken (entweder DXUA- oder DXUX-VNDK-Bibliotheken), HAL-Implementierungen für denselben Prozess und andere vom Anbieter gemeinsam genutzte Bibliotheken.
/vendor/lib[64]/vndk-sp kann die vom Anbieter erweiterten VNDK-SP-Bibliotheken enthalten.

Anbietermodule laden die VNDK-Bibliotheken von /system/lib[64].

VNDK-Regeln

Dieser Abschnitt enthält eine umfassende Liste der VNDK-Regeln:

Framework-Prozesse dürfen keine nicht SP-HAL-gemeinsam genutzten Bibliotheken aus Anbieterpartitionen laden (ab Android 8.1 streng erzwungen).
Anbieterprozesse dürfen keine Nicht-LL-NDK-, Nicht-VNDK-SP- und Nicht-VNDK-Bibliotheken von der Systempartition laden. (wird in Android OS derzeit nicht strikt erzwungen, wird aber in einer zukünftigen Version eingeführt).

Die installierten VNDK-Bibliotheken müssen eine Teilmenge der von Google definierten infrage kommenden VNDK-Bibliotheken sein.
Die externen Abhängigkeiten von SP-HAL und SP-HAL-Dep müssen auf LL-NDK- oder von Google definierte VNDK-SP-Bibliotheken beschränkt sein.
- Die Abhängigkeiten einer gemeinsam genutzten SP-HAL-Bibliothek müssen auf LL-NDK-Bibliotheken, von Google definierte VNDK-SP-Bibliotheken, andere SP-HAL-Bibliotheken und/oder andere gemeinsam genutzte Bibliotheken von Anbietern beschränkt sein, die als SP-HAL-Dep-Bibliotheken gekennzeichnet werden können.
- Eine gemeinsam genutzte Bibliothek eines Anbieters kann nur dann als SP-HAL-Dep-Bibliothek gekennzeichnet werden, wenn sie keine AOSP-Bibliothek ist und ihre Abhängigkeiten auf LL-NDK-Bibliotheken, von Google definierte VNDK-SP-Bibliotheken, SP-HAL-Bibliotheken und/oder andere SP-HAL-Dep-Bibliotheken beschränkt sind.
VNDK-SP muss eigenständig sein. libRS_internal.so wird in Android 8.0 besonders behandelt, wird aber in einer zukünftigen Version noch einmal überarbeitet.
Keine Kommunikation zwischen Framework und Anbieter über nicht HIDL-Schnittstellen, einschließlich (aber nicht beschränkt auf) Binder, Sockets, freigegebenen Speichern, Dateien usw.
Die Größe der Systempartition muss groß genug sein, um zwei Kopien aller infrage kommenden VNDK-Bibliotheken und eine Kopie der nicht infrage kommenden freigegebenen Framework-Bibliotheken zu enthalten.

sepolicy

Die in diesem Abschnitt beschriebenen Framework-Prozesse entsprechen coredomain in sepolicies, während Anbieterprozesse non-coredomain entsprechen. Beispiel: Auf /dev/binder kann nur in coredomain zugegriffen werden und auf /dev/vndbinder nur außerhalb von coredomain.

Ähnliche Richtlinien schränken den Zugriff auf die freigegebenen Bibliotheken auf System- und Anbieterpartitionen ein. In der folgenden Tabelle sind die Zugriffsrechte für freigegebene Bibliotheken verschiedener Kategorien aufgeführt:

Kategorie	Partition	Zugänglich über coredomain	Zugänglich über eine nicht zur Kerndomain gehörende Domain
LL-NDK	System	J	J
LL-NDK-Private	System	J	J
VNDK-SP/VNDK-SP-Private	System	J	J
VNDK-SP-Ext	Vendor	J	J
VNDK	System	J	J
VNDK-Ext	Vendor	N	J
FWK-ONLY	System	J	N
FWK-ONLY-RS	System	J	N
SP-HAL	Vendor	J	J
SP-HAL-Dep	Vendor	J	J
NUR VND	Vendor	N	J

Auf LL-NDK-Private und VNDK-SP-Private muss von beiden Domains aus zugegriffen werden können, da nicht coredomain-Geräte indirekt darauf zugreifen. Ebenso muss auf SP-HAL-Dep voncoredomain aus zugegriffen werden können, da SP-HAL darauf angewiesen ist.

same_process_hal_file label

Die folgenden Bibliotheken befinden sich in der Anbieterpartition. Diese Bibliotheken müssen sowohl über coredomain als auch über nicht coredomain-Seiten zugänglich sein.

VNDK-SP-Ext in /vendor/lib[64]/vndk-sp
SP-HAL in /vendor/lib[64] oder /vendor/lib[64]/hw
SP-HAL-Dep in /vendor/lib[64] oder /vendor/lib[64]/hw

Labeln Sie diese Dateien explizit als same_process_hal_file, da auf alle Elemente in der vendor-Partition standardmäßig nicht von coredomain aus zugegriffen werden kann. Fügen Sie der anbieterspezifischen file_contexts-Datei Zeilen hinzu, die der folgenden ähneln.

/vendor/lib(64)?/hw/libMySpHal\.so        u:object_r:same_process_hal_file:s0
/vendor/lib(64)?/vndk-sp/libBase\.so      u:object_r:same_process_hal_file:s0
/vendor/lib(64)?/libBaseInternal\.so      u:object_r:same_process_hal_file:s0