Linker-Namespace

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

Der dynamische Linker bewältigt zwei Herausforderungen im Treble VNDK-Design:

  • Gemeinsam genutzte SP-HAL-Bibliotheken und ihre Abhängigkeiten, einschließlich VNDK-SP-Bibliotheken, werden in Framework-Prozesse geladen. Es sollte einige Mechanismen geben, um Symbolkonflikte zu verhindern.
  • dlopen() und android_dlopen_ext() können einige Laufzeitabhängigkeiten einführen, die zur Buildzeit nicht sichtbar sind und mit statischer Analyse schwer zu erkennen sein können.

Diese beiden Herausforderungen können durch den Linker-Namespace- Mechanismus gelöst werden. Dieser Mechanismus wird durch den dynamischen Linker bereitgestellt. Es kann die gemeinsam genutzten Bibliotheken in verschiedenen Linker-Namespaces isolieren, sodass Bibliotheken mit demselben Bibliotheksnamen, aber mit unterschiedlichen Symbolen nicht in Konflikt geraten.

Andererseits bietet der Linker-Namespace-Mechanismus die Flexibilität, dass einige gemeinsam genutzte Bibliotheken von einem Linker-Namespace exportiert und von einem anderen Linker-Namespace verwendet werden können. Diese exportierten gemeinsam genutzten Bibliotheken können zu Anwendungsprogrammierschnittstellen werden, die für andere Programme öffentlich sind, während sie ihre Implementierungsdetails in ihren Linker-Namespaces verbergen.

Beispielsweise sind /system/lib[64]/libcutils.so und /system/lib[64]/vndk-sp-${VER}/libcutils.so zwei gemeinsam genutzte Bibliotheken. Diese beiden Bibliotheken können unterschiedliche Symbole haben. Sie werden in verschiedene Linker-Namespaces geladen, sodass Framework-Module von /system/lib[64]/libcutils.so abhängen können und gemeinsam genutzte SP-HAL-Bibliotheken von /system/lib[64]/vndk-sp-${VER}/libcutils.so abhängen können /system/lib[64]/vndk-sp-${VER}/libcutils.so .

Andererseits ist /system/lib[64]/libc.so ein Beispiel für eine öffentliche Bibliothek, die von einem Linker-Namespace exportiert und in viele Linker-Namespaces importiert wird. Die Abhängigkeiten von /system/lib[64]/libc.so , wie etwa libnetd_client.so , werden in den Namespace geladen, in dem sich /system/lib[64]/libc.so befindet. Andere Namespaces haben keinen Zugriff auf diese Abhängigkeiten. Dieser Mechanismus kapselt die Implementierungsdetails ein, während er die öffentlichen Schnittstellen bereitstellt.

Wie funktioniert es?

Der dynamische Linker ist verantwortlich für das Laden der gemeinsam genutzten Bibliotheken, die in DT_NEEDED Einträgen angegeben sind, oder der gemeinsam genutzten Bibliotheken, die durch das Argument von dlopen() oder android_dlopen_ext() angegeben sind. In beiden Fällen findet der dynamische Linker den Linker-Namespace, in dem sich der Aufrufer befindet, und versucht, die Abhängigkeiten in denselben Linker-Namespace zu laden. Wenn der dynamische Linker die gemeinsam genutzte Bibliothek nicht in den angegebenen Linker-Namespace laden kann, fragt er den verknüpften Linker-Namespace nach exportierten gemeinsam genutzten Bibliotheken ab.

Konfigurationsdateiformat

Das Format der Konfigurationsdatei basiert auf dem INI-Dateiformat. Eine typische Konfigurationsdatei sieht so aus:

dir.system = /system/bin
dir.system = /system/xbin
dir.vendor = /vendor/bin

[system]
additional.namespaces = sphal,vndk

namespace.default.isolated = true
namespace.default.search.paths = /system/${LIB}
namespace.default.permitted.paths = /system/${LIB}/hw
namespace.default.asan.search.paths = /data/asan/system/${LIB}:/system/${LIB}
namespace.default.asan.permitted.paths = /data/asan/system/${LIB}/hw:/system/${LIB}/hw

namespace.sphal.isolated = true
namespace.sphal.visible = true
namespace.sphal.search.paths = /odm/${LIB}:/vendor/${LIB}
namespace.sphal.permitted.paths = /odm/${LIB}:/vendor/${LIB}
namespace.sphal.asan.search.paths  = /data/asan/odm/${LIB}:/odm/${LIB}
namespace.sphal.asan.search.paths += /data/asan/vendor/${LIB}:/vendor/${LIB}
namespace.sphal.asan.permitted.paths  = /data/asan/odm/${LIB}:/odm/${LIB}
namespace.sphal.asan.permitted.paths += /data/asan/vendor/${LIB}:/vendor/${LIB}
namespace.sphal.links = default,vndk
namespace.sphal.link.default.shared_libs = libc.so:libm.so
namespace.sphal.link.vndk.shared_libs = libbase.so:libcutils.so

namespace.vndk.isolated = true
namespace.vndk.search.paths = /system/${LIB}/vndk-sp-29
namespace.vndk.permitted.paths = /system/${LIB}/vndk-sp-29
namespace.vndk.links = default
namespace.vndk.link.default.shared_libs = libc.so:libm.so

[vendor]
namespace.default.isolated = false
namespace.default.search.paths = /vendor/${LIB}:/system/${LIB}

Die Konfigurationsdatei enthält:

  • Mehrere Verzeichnisabschnittszuordnungseigenschaften am Anfang, damit der dynamische Linker den effektiven Abschnitt auswählen kann.
  • Mehrere Konfigurationsabschnitte für Linker-Namespaces:
    • Jeder Abschnitt enthält mehrere Namespaces (Grapheckpunkte) und mehrere Fallback-Links zwischen Namespaces (Graphbögen).
    • Jeder Namespace hat seine eigene Isolation, Suchpfade, erlaubte Pfade und Sichtbarkeitseinstellungen.

Die folgenden Tabellen beschreiben die Bedeutung jeder Eigenschaft im Detail.

Zuordnungseigenschaft für Verzeichnisabschnitte

Eigentum Beschreibung Beispiel

dir. name

Ein Pfad zu einem Verzeichnis, für das der Abschnitt [ name ] gilt.

Jede Eigenschaft ordnet die ausführbaren Dateien unter dem Verzeichnis einem Linker-Namespaces-Konfigurationsabschnitt zu. Möglicherweise gibt es zwei (oder mehr) Eigenschaften, die denselben name haben, aber auf unterschiedliche Verzeichnisse verweisen.

dir.system = /system/bin
dir.system = /system/xbin
dir.vendor = /vendor/bin

Dies zeigt an, dass die im Abschnitt [system] angegebene Konfiguration für die ausführbaren Dateien gilt, die entweder aus /system/bin oder /system/xbin .

Die im Abschnitt [vendor] angegebene Konfiguration gilt für die ausführbaren Dateien, die aus /vendor/bin geladen werden.

Beziehungseigenschaften

Eigentum Beschreibung Beispiel
additional. namespaces

Eine durch Kommas getrennte Liste zusätzlicher Namespaces (zusätzlich zum default -Namespace) für den Abschnitt.

additional. namespaces = sphal, vndk

Dies zeigt an, dass es drei Namespaces ( default , sphal und vndk ) in der [system] -Konfiguration gibt.

namespace. name . links

Eine durch Kommas getrennte Liste von Fallback-Namespaces.

Wenn eine gemeinsam genutzte Bibliothek im aktuellen Namespace nicht gefunden werden kann, versucht der dynamische Linker, die gemeinsam genutzte Bibliothek aus den Fallback-Namespaces zu laden. Der am Anfang der Liste angegebene Namensraum hat höhere Priorität.

namespace. sphal. links = default, vndk

Wenn eine gemeinsam genutzte Bibliothek oder eine ausführbare Datei eine gemeinsam genutzte Bibliothek anfordert, die nicht in den sphal Namespace geladen werden kann, versucht der dynamische Linker, die gemeinsam genutzte Bibliothek aus dem default -Namespace zu laden.

Und wenn die gemeinsam genutzte Bibliothek auch nicht aus dem default -Namespace geladen werden kann, versucht der dynamische Linker, die gemeinsam genutzte Bibliothek aus dem vndk Namespace zu laden.

Wenn schließlich alle Versuche fehlschlagen, gibt der dynamische Linker einen Fehler zurück.

namespace. name . link. other . shared_libs

Eine durch Doppelpunkte getrennte Liste von gemeinsam genutzten Bibliotheken, die in den other Namensräumen durchsucht werden können, wenn diese Bibliotheken im Namensraum des name nicht gefunden werden können.

Diese Eigenschaft kann nicht mit namespace. name . link. other . allow_all_shared_libs .

namespace. sphal. link. default. shared_libs = libc.so: libm.so

Dies zeigt an, dass der Fallback-Link nur libc.so oder libm.so als angeforderten Bibliotheksnamen akzeptiert. Der dynamische Linker ignoriert den Fallback-Link von sphal zum default -Namespace, wenn der angeforderte Bibliotheksname nicht libc.so oder libm.so .

namespace. name . link. other . allow_all_shared_libs

Ein boolescher Wert, der angibt, ob alle gemeinsam genutzten Bibliotheken im other Namensraum durchsucht werden können, wenn diese Bibliotheken im Namensraum des name nicht gefunden werden können.

Diese Eigenschaft kann nicht mit namespace. name . link. other . shared_libs .

namespace. vndk. link. sphal. allow_all_shared_libs = true

Dies zeigt an, dass alle Bibliotheksnamen den Fallback-Link von vndk zum sphal Namespace durchlaufen können.

Namespace-Eigenschaften

Eigentum Beschreibung Beispiel
namespace. name . isolated

Ein boolescher Wert, der angibt, ob der dynamische Linker prüfen soll, wo sich die gemeinsam genutzte Bibliothek befindet.

Wenn isolated true gesetzt ist, können nur die gemeinsam genutzten Bibliotheken geladen werden, die sich in einem der search.paths Verzeichnisse (ohne Unterverzeichnisse) oder unter einem der permitted.paths -Verzeichnisse (einschließlich Unterverzeichnisse) befinden.

Wenn isolated auf false gesetzt ist (Standardeinstellung), überprüft der dynamische Linker den Pfad der gemeinsam genutzten Bibliotheken nicht.

namespace. sphal. isolated = true

Dies zeigt an, dass nur die gemeinsam genutzten Bibliotheken in search.paths oder unter permitted.paths in den sphal Namespace geladen werden können.

namespace. name . search.paths

Eine durch Doppelpunkte getrennte Liste von Verzeichnissen, in denen nach gemeinsam genutzten Bibliotheken gesucht werden soll.

Die in search.paths angegebenen Verzeichnisse werden dem angeforderten Bibliotheksnamen vorangestellt, wenn Funktionsaufrufe von dlopen() oder DT_NEEDED Einträgen nicht den vollständigen Pfad angeben. Das am Anfang der Liste angegebene Verzeichnis hat höhere Priorität.

Wenn isolated true gesetzt ist, können gemeinsam genutzte Bibliotheken, die sich in einem der search.paths Verzeichnisse (mit Ausnahme von Unterverzeichnissen) befinden, unabhängig von der permitted.paths -Eigenschaft geladen werden.

Wenn beispielsweise search.paths /system/${LIB} und permitted.paths leer ist, kann /system/${LIB}/libc.so geladen werden, aber /system/${LIB}/vndk/libutils.so kann nicht geladen werden.

namespace. default. search.paths = /system/${LIB}

Dies zeigt an, dass der dynamische Linker /system/${LIB} nach gemeinsam genutzten Bibliotheken durchsucht.

namespace. name . asan.search.paths

Eine durch Doppelpunkte getrennte Liste von Verzeichnissen, die nach gemeinsam genutzten Bibliotheken durchsucht werden sollen, wenn AddressSanitizer (ASan) aktiviert ist.

namespace. name . search.paths wird ignoriert, wenn ASan aktiviert ist.

namespace. default. asan.search.paths = /data/asan/system/${LIB}: /system/${LIB}

Dies zeigt an, dass der dynamische Linker bei aktiviertem ASan zuerst nach /data/asan/system/${LIB} und dann nach /system/${LIB} sucht.

namespace. name . permitted.paths

Eine durch Doppelpunkte getrennte Liste von Verzeichnissen (einschließlich Unterverzeichnissen), in die der dynamische Linker die gemeinsam genutzten Bibliotheken (zusätzlich zu search.paths ) laden kann, wenn isolated true ist.

Die gemeinsam genutzten Bibliotheken, die sich in den Unterverzeichnissen von permitted.paths befinden, können ebenfalls geladen werden. Wenn „ permitted.paths “ beispielsweise /system/${LIB} ist, können sowohl /system/${LIB}/libc.so als auch /system/${LIB}/vndk/libutils.so geladen werden.

Wenn isolated auf false gesetzt ist, werden die permitted.paths Pfade ignoriert und eine Warnung ausgegeben.

namespace. default. permitted.paths = /system/${LIB}/hw

Dies zeigt an, dass die gemeinsam genutzten Bibliotheken unter /system/${LIB}/hw in den isolierten default -Namespace geladen werden können.

Beispielsweise kann /system/${LIB}/hw/audio.a2dp.default.so ohne permitted.paths libaudiohal.so nicht in den default -Namespace laden.

namespace. name . asan.permitted.paths

Eine durch Doppelpunkte getrennte Liste von Verzeichnissen, in die der dynamische Linker die gemeinsam genutzten Bibliotheken laden kann, wenn ASan aktiviert ist.

namespace. name . permitted.paths wird ignoriert, wenn ASan aktiviert ist.

namespace. default. asan.permitted.paths = /data/asan/system/${LIB}/hw: /system/${LIB}/hw

Dies zeigt an, dass gemeinsam genutzte Bibliotheken unter /data/asan/system/${LIB}/hw oder /system/${LIB}/hw in den isolierten default -Namespace geladen werden können, wenn ASan aktiviert ist.

namespace. name . visible

Ein boolescher Wert, der angibt, ob das Programm (außer libc ) ein Linker-Namespace-Handle mit android_get_exported_namespace() erhalten und eine gemeinsam genutzte Bibliothek im Linker-Namespace öffnen kann, indem es das Handle an android_dlopen_ext() .

Wenn visible true ist, gibt android_get_exported_namespace() immer das Handle zurück, wenn der Namespace existiert.

Wenn visible false ist (Standard), android_get_exported_namespace() immer NULL zurück, unabhängig davon, ob der Namespace vorhanden ist. Gemeinsam genutzte Bibliotheken können nur in diesen Namespace geladen werden, wenn (1) sie von einem anderen Linker-Namespace angefordert werden, der einen Fallback-Link zu diesem Namespace hat, oder (2) sie von anderen gemeinsam genutzten Bibliotheken oder ausführbaren Dateien in diesem Namespace angefordert werden.

namespace. sphal. visible = true

Dies zeigt an, dass android_get_exported_namespace("sphal") ein gültiges Linker-Namespace-Handle zurückgeben kann.

Linker-Namespace-Erstellung

In Android 11 wird die Linker-Konfiguration zur Laufzeit unter /linkerconfig anstatt einfache Textdateien in ${android-src}/system/core/rootdir/etc . Die Konfiguration wird beim Booten basierend auf der Laufzeitumgebung generiert, die folgende Elemente umfasst:

  • Wenn das Gerät VNDK unterstützt
  • VNDK-Zielversion der Anbieterpartition
  • VNDK-Version der Produktpartition
  • Installierte APEX-Module

Die Linkerkonfiguration wird erstellt, indem Abhängigkeiten zwischen Linker-Namespaces aufgelöst werden. Wenn es beispielsweise Updates für die APEX-Module gibt, die Abhängigkeitsupdates enthalten, wird eine Linkerkonfiguration generiert, die diese Änderungen widerspiegelt. Weitere Details zum Erstellen einer Linker-Konfiguration finden Sie in ${android-src}/system/linkerconfig .

Linker-Namespace-Isolierung

Es gibt drei Konfigurationstypen. Abhängig vom Wert von PRODUCT_TREBLE_LINKER_NAMESPACES und BOARD_VNDK_VERSION in BoardConfig.mk wird die entsprechende Konfiguration beim Booten generiert.

PRODUCT_TREBLE_
LINKER_NAMESPACES
BOARD_VNDK_
VERSION
Ausgewählte Konfiguration VTS-Anforderung
true current VNDK Obligatorisch für Geräte, die mit Android 9 oder höher gestartet wurden
Leer VNDK Lite Obligatorisch für Geräte, die mit Android 8.x gestartet wurden
false Leer Legacy Für Nicht-Treble-Geräte

Die VNDK Lite-Konfiguration isoliert gemeinsam genutzte SP-HAL- und VNDK-SP-Bibliotheken. In Android 8.0 muss dies die Konfigurationsdatei für den dynamischen Linker sein, wenn PRODUCT_TREBLE_LINKER_NAMESPACES true ist .

Die VNDK-Konfiguration isoliert auch gemeinsam genutzte Bibliotheken von SP-HAL und VNDK-SP. Darüber hinaus bietet diese Konfiguration die vollständige dynamische Linker-Isolation. Es stellt sicher, dass Module in der Systempartition nicht von den gemeinsam genutzten Bibliotheken in den Herstellerpartitionen abhängen und umgekehrt.

In Android 8.1 oder höher ist die VNDK-Konfiguration die Standardkonfiguration und es wird dringend empfohlen, die vollständige dynamische Linker-Isolation zu aktivieren, indem BOARD_VNDK_VERSION auf current setzen.

VNDK-Konfiguration

Die VNDK-Konfiguration isoliert die Abhängigkeiten der gemeinsam genutzten Bibliotheken zwischen der Systempartition und den Herstellerpartitionen. Im Vergleich zu den im vorherigen Unterabschnitt erwähnten Konfigurationen werden die Unterschiede wie folgt skizziert:

  • Framework-Prozesse

    • Die Namespaces default , vndk , sphal und rs werden erstellt.
    • Alle Namespaces sind isoliert.
    • Gemeinsam genutzte Systembibliotheken werden in den default geladen.
    • SP-HALs werden in den sphal -Namespace geladen.
    • Gemeinsam genutzte VNDK-SP-Bibliotheken, die in den vndk -Namespace geladen werden.
  • Lieferantenprozesse

    • default , vndk und system namespaces werden erstellt.
    • Der default ist isoliert.
    • Gemeinsam genutzte Bibliotheken des Anbieters werden in den default -Namespace geladen.
    • Gemeinsame VNDK- und VNDK-SP-Bibliotheken werden in den vndk -Namespace geladen.
    • LL-NDK und seine Abhängigkeiten werden in den system geladen.

Die Beziehung zwischen den Linker-Namespaces ist unten dargestellt.

Linker-Namespace-Diagramm, das in der VNDK-Konfiguration beschrieben wird
Abbildung 1. Linker-Namespace-Isolierung (VNDK-Konfiguration)

In der obigen Abbildung stehen LL-NDK und VNDK-SP für die folgenden gemeinsam genutzten Bibliotheken:

  • LL-NDK
    • libEGL.so
    • libGLESv1_CM.so
    • libGLESv2.so
    • libGLESv3.so
    • libandroid_net.so
    • libc.so
    • libdl.so
    • liblog.so
    • libm.so
    • libnativewindow.so
    • libneuralnetworks.so
    • libsync.so
    • libvndksupport.so
    • libvulkan.so
  • VNDK-SP
    • android.hardware.graphics.common@1.0.so
    • android.hardware.graphics.mapper@2.0.so
    • android.hardware.renderscript@1.0.so
    • android.hidl.memory@1.0.so
    • libRSCpuRef.so
    • libRSDriver.so
    • libRS_internal.so
    • libbase.so
    • libbcinfo.so
    • libc++.so
    • libcutils.so
    • libhardware.so
    • libhidlbase.so
    • libhidlmemory.so
    • libhidltransport.so
    • libhwbinder.so
    • libion.so
    • libutils.so
    • libz.so

Weitere Details finden Sie in /linkerconfig/ld.config.txt des Geräts.

VNDK Lite-Konfiguration

Ab Android 8.0 ist der dynamische Linker so konfiguriert, dass er die gemeinsam genutzten Bibliotheken SP-HAL und VNDK-SP so isoliert, dass ihre Symbole nicht mit anderen gemeinsam genutzten Framework-Bibliotheken in Konflikt geraten. Die Beziehung zwischen den Linker-Namespaces ist unten dargestellt.

Linker-Namespace-Diagramm, beschrieben in VNDK Lite-Konfiguration
Abbildung 2. Linker-Namespace-Isolierung (VNDK Lite-Konfiguration)

LL-NDK und VNDK-SP stehen für folgende gemeinsam genutzte Bibliotheken:

  • LL-NDK
    • libEGL.so
    • libGLESv1_CM.so
    • libGLESv2.so
    • libc.so
    • libdl.so
    • liblog.so
    • libm.so
    • libnativewindow.so
    • libstdc++.so (nicht in der Konfiguration)
    • libsync.so
    • libvndksupport.so
    • libz.so (in der Konfiguration nach VNDK-SP verschoben )
  • VNDK-SP
    • android.hardware.graphics.common@1.0.so
    • android.hardware.graphics.mapper@2.0.so
    • android.hardware.renderscript@1.0.so
    • android.hidl.memory@1.0.so
    • libbase.so
    • libc++.so
    • libcutils.so
    • libhardware.so
    • libhidlbase.so
    • libhidlmemory.so
    • libhidltransport.so
    • libhwbinder.so
    • libion.so
    • libutils.so

Die folgende Tabelle listet die Namespaces-Konfiguration für Framework-Prozesse auf, die aus dem Abschnitt [system] in der VNDK Lite-Konfiguration entnommen ist.

Namensraum Eigentum Wert
default search.paths /system/${LIB}
/odm/${LIB}
/vendor/${LIB}
/product/${LIB}
isolated false
sphal search.paths /odm/${LIB}
/vendor/${LIB}
permitted.paths /odm/${LIB}
/vendor/${LIB}
isolated true
visible true
links default,vndk,rs
link.default.shared_libs LL-NDK
link.vndk.shared_libs VNDK-SP
link.rs.shared_libs libRS_internal.so
vndk (für VNDK-SP) search.paths /odm/${LIB}/vndk-sp
/vendor/${LIB}/vndk-sp
/system/${LIB}/vndk-sp-${VER}
permitted.paths /odm/${LIB}/hw
/odm/${LIB}/egl
/vendor/${LIB}/hw
/vendor/${LIB}/egl
/system/${LIB}/vndk-sp-${VER}/hw
isolated true
visible true
links default
link.default.shared_libs LL-NDK
rs (für RenderScript) search.paths /odm/${LIB}/vndk-sp
/vendor/${LIB}/vndk-sp
/system/${LIB}/vndk-sp-${VER}
/odm/${LIB}
/vendor/${LIB}
permitted.paths /odm/${LIB}
/vendor/${LIB}
/data (für kompilierten RS-Kernel)
isolated true
visible true
links default,vndk
link.default.shared_libs LL-NDK
libmediandk.so
libft2.so
link.vndk.shared_libs VNDK-SP

Die folgende Tabelle zeigt die Namespaces-Konfiguration für Anbieterprozesse, die aus dem Abschnitt [vendor] in der VNDK Lite-Konfiguration entnommen ist.

Namensraum Eigentum Wert
default search.paths /odm/${LIB}
/odm/${LIB}/vndk
/odm/${LIB}/vndk-sp
/vendor/${LIB}
/vendor/${LIB}/vndk
/vendor/${LIB}/vndk-sp
/system/${LIB}/vndk-${VER}
/system/${LIB}/vndk-sp-${VER}
/system/${LIB} (veraltet)
/product/${LIB} (veraltet)
isolated false

Weitere Details finden Sie in /linkerconfig/ld.config.txt des Geräts.

Dokumentenverlauf

Android 11-Änderungen

  • In Android 11 werden die statischen ld.config.*.txt Dateien aus der Codebasis entfernt und LinkerConfig generiert sie stattdessen zur Laufzeit.

Android 9 ändert sich

  • In Android 9 wird der vndk Linker-Namespace zu Anbieterprozessen hinzugefügt und gemeinsam genutzte VNDK-Bibliotheken werden vom standardmäßigen Linker-Namespace isoliert.
  • Ersetzen Sie PRODUCT_FULL_TREBLE durch spezifischere PRODUCT_TREBLE_LINKER_NAMESPACES .
  • Android 9 ändert die Namen der folgenden Konfigurationsdateien für dynamische Linker.
    Android 8.x Android 9 Beschreibung
    ld.config.txt.in ld.config.txt Für Geräte mit Runtime-Linker-Namespace-Isolation
    ld.config.txt ld.config.vndk_lite.txt Für Geräte mit VNDK-SP-Linker-Namespace-Isolierung
    ld.config.legacy.txt ld.config.legacy.txt Für ältere Geräte mit Android 7.x oder niedriger
  • Entfernen Sie android.hardware.graphics.allocator@2.0.so .
  • product und odm Partitionen werden hinzugefügt.