Verknüpfungs-Namespace

Der Dynamic Linker stellt sich zwei Herausforderungen beim Treble VNDK-Design:

  • Freigegebene SP-HAL-Bibliotheken und ihre Abhängigkeiten, einschließlich VNDK-SP in Framework-Prozesse geladen. Es sollte einige Mechanismen zur Vermeidung von Symbolkonflikten.
  • Mit dlopen() und android_dlopen_ext() können Laufzeitabhängigkeiten, die bei der Build-Erstellung nicht sichtbar sind und mit statischer Analyse schwer zu erkennen.

Diese beiden Probleme können durch den Verknüpfungs-Namespace gelöst werden. Mechanismus zur Verfügung. Dieser Mechanismus wird von der dynamischen Verknüpfung bereitgestellt. Es die gemeinsam genutzten Bibliotheken in verschiedenen Verknüpfungs-Namespaces isolieren, Bibliotheken mit demselben Bibliotheksnamen, aber mit unterschiedlichen Symbolen entstehen nicht in Konflikt.

Andererseits bietet der Verknüpfungs-Namespace-Mechanismus die Flexibilität, sodass einige gemeinsam genutzte Bibliotheken über einen Verknüpfungs-Namespace exportiert und von einen anderen Verknüpfungs-Namespace. Diese exportierten gemeinsam genutzten Bibliotheken können APIs, die für andere Programme öffentlich sind, Ausblenden der Implementierungsdetails in ihren Verknüpfungs-Namespaces

Beispiel: /system/lib[64]/libcutils.so und /system/lib[64]/vndk-sp-${VER}/libcutils.so sind zwei geteilte Bibliotheken. Diese beiden Bibliotheken können unterschiedliche Symbole haben. Sie sind geladen in verschiedene Verknüpfungs-Namespaces aufteilen, sodass Framework-Module /system/lib[64]/libcutils.so und gemeinsam genutzte SP-HAL-Bibliotheken können sind von /system/lib[64]/vndk-sp-${VER}/libcutils.so abhängig.

/system/lib[64]/libc.so ist hingegen ein Beispiel für eine öffentliche Bibliothek, die über einen Verknüpfungs-Namespace exportiert und in viele Verknüpfungs-Namespaces nutzen. Die Abhängigkeiten von /system/lib[64]/libc.so, z. B. libnetd_client.so, werden in den Namespace geladen, in dem /system/lib[64]/libc.so sich befindet. Andere Namespaces haben keinen Zugriff auf diese Abhängigkeiten. Dieses kapselt die Implementierungsdetails ein und stellt der Öffentlichkeit Schnittstellen.

Funktionsweise

Die dynamische Verknüpfung ist für das Laden der angegebenen gemeinsam genutzten Bibliotheken zuständig. in DT_NEEDED-Einträgen oder in den freigegebenen Bibliotheken, die durch den Argument von dlopen() oder android_dlopen_ext(). In beiden in den Fällen, sucht die dynamische Verknüpfung nach dem Namespace, in dem der Aufrufer befindet sich und versucht, die Abhängigkeiten in denselben Verknüpfungs-Namespace zu laden. Wenn Die dynamische Verknüpfung kann die gemeinsam genutzte Bibliothek nicht in die angegebene Verknüpfung laden wird der verknüpfte Verknüpfungs-Namespace für exportierte freigegebene Bibliotheken.

Format der Konfigurationsdatei

Das Konfigurationsdateiformat basiert auf dem INI-Dateiformat. Ein typisches wie folgt aussieht:

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 Folgendes:

  • Mehrere Verzeichnisabschnitts-Zuordnungsattribute am Anfang für die um den effektiven Bereich auszuwählen.
  • Konfigurationsabschnitte für mehrere Verknüpfungs-Namespaces: <ph type="x-smartling-placeholder">
      </ph>
    • Jeder Abschnitt enthält mehrere Namespaces (Graph-Scheitelpunkte) und mehrere Fallback-Links zwischen Namespaces (Diagrammbögen).
    • Jeder Namespace hat seine eigene Isolation, Suchpfade, und Sichtbarkeitseinstellungen.

In den folgenden Tabellen wird die Bedeutung der einzelnen Eigenschaften ausführlich beschrieben.

Attribut für die Zuordnung von Verzeichnisabschnitten

Attribut Beschreibung Beispiel

dir.name

Ein Pfad zu einem Verzeichnis, das im Abschnitt [name] enthalten ist gilt.

Jedes Attribut ordnet die ausführbaren Dateien im Verzeichnis einer Verknüpfung zu Abschnitt zur Konfiguration von Namespaces. Es kann zwei (oder mehr) Eigenschaften geben die gleiche name haben, aber auf verschiedene Verzeichnisse enthalten.

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

Dies weist darauf hin, dass die im Der Abschnitt [system] bezieht sich auf ausführbare Dateien, die geladen werden entweder aus /system/bin oder /system/xbin.

Es gilt die im Abschnitt [vendor] angegebene Konfiguration zu den ausführbaren Dateien, die aus /vendor/bin geladen werden.

Beziehungseigenschaften

Attribut 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 weist darauf hin, dass es drei Namespaces gibt (default, sphal und vndk) in [system] Konfiguration.
namespace.name.links

Eine durch Kommas getrennte Liste von Fallback-Namespaces.

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

namespace.sphal.links = default,vndk

Wenn von einer gemeinsam genutzten Bibliothek oder einer ausführbaren Datei eine gemeinsam genutzte Bibliothek angefordert wird, kann nicht in den sphal-Namespace geladen werden, also die dynamische Verknüpfung. versucht, die gemeinsam genutzte Bibliothek aus dem default zu laden. -Namespace auf sie zugegriffen werden.

Wenn die gemeinsam genutzte Bibliothek nicht über die default-Namespace, versucht die dynamische Verknüpfung, den gemeinsam genutzte Bibliothek aus dem Namespace vndk.

Wenn alle Versuche fehlschlagen, gibt die dynamische Verknüpfung einen Fehler zurück.
namespace.name.link.other.shared_libs

Eine durch Doppelpunkte getrennte Liste gemeinsam genutzter Bibliotheken, die in der other Namespaces, wenn diese Bibliotheken im name-Namespace.

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

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

Das bedeutet, dass der Fallback-Link nur libc.so akzeptiert. oder libm.so als angeforderten Bibliotheksnamen. Dynamische Verknüpfung ignoriert den Fallback-Link von sphal zu default-Namespace, wenn der angeforderte Bibliotheksname nicht libc.so oder libm.so.
namespace.name.link.other.allow_all_shared_libs

Boolescher Wert, der angibt, ob alle gemeinsam genutzten Bibliotheken im Namespace other gesucht, wenn diese Bibliotheken im Namespace name enthalten sind.

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

namespace.vndk.link.sphal.allow_all_shared_libs = true

Das bedeutet, dass der Fallback-Link für alle Bibliotheksnamen verwendet werden kann. von vndk in sphal.

Namespace-Attribute

Attribut Beschreibung Beispiel
namespace.name.isolated

Boolescher Wert, der angibt, ob die dynamische Verknüpfung prüfen soll wo sich die gemeinsam genutzte Bibliothek befindet.

Wenn isolated den Wert true hat, sind nur die geteilten Bibliotheken die sich in einem der search.paths-Verzeichnisse befinden (ohne Unterverzeichnisse) oder unter permitted.paths-Verzeichnisse (einschließlich Unterverzeichnisse) können geladen.

Wenn isolated den Wert false (Standardeinstellung) hat, wird die dynamische den Pfad von gemeinsam genutzten Bibliotheken nicht überprüft.

namespace.sphal.isolated = true

Das bedeutet, dass nur die gemeinsam genutzten Bibliotheken in search.paths oder weniger als permitted.paths können sein sphal-Namespace geladen.
namespace.name.search.paths

Eine durch Doppelpunkt getrennte Liste der Verzeichnisse, nach denen gesucht werden soll Bibliotheken.

Die in search.paths angegebenen Verzeichnisse werden vorangestellt zum angeforderten Bibliotheksnamen hinzu, wenn Funktionsaufrufe an dlopen() oder DT_NEEDED-Einträge geben nicht den vollständigen Pfad an. Das Verzeichnis die am Anfang der Liste stehen, hat eine höhere Priorität.

Wenn isolated den Wert true hat, haben geteilte Fotogalerien, die befinden sich in einem der search.paths-Verzeichnisse (ausgenommen Unterverzeichnisse) können unabhängig vom permitted.paths Property.

Beispiel: search.paths ist /system/${LIB} und permitted.paths sind leer, /system/${LIB}/libc.so können geladen werden, aber /system/${LIB}/vndk/libutils.so kann nicht geladen werden.

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

Das bedeutet, dass die dynamische Verknüpfung nach /system/${LIB} für geteilte Fotogalerien.
namespace.name.asan.search.paths

Eine durch Doppelpunkt getrennte Liste von Verzeichnissen, in denen nach gemeinsam genutzten Bibliotheken gesucht wird AddressSanitizer (ASan) ist aktiviert.

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

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

Das bedeutet, dass bei der ASan ist aktiviert, Die dynamische Verknüpfung sucht zuerst in /data/asan/system/${LIB} und sucht dann nach /system/${LIB}.
namespace.name.permitted.paths

Eine durch Doppelpunkte getrennte Liste von Verzeichnissen (einschließlich Unterverzeichnissen), wobei kann die dynamische Verknüpfung die gemeinsam genutzten Bibliotheken laden (zusätzlich zur search.paths) wenn isolated gleich true

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

Wenn isolated den Wert false hat, permitted.paths werden ignoriert und eine Warnung ausgegeben.

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

Das bedeutet, dass die gemeinsam genutzten Bibliotheken /system/${LIB}/hw kann in den isolierten default-Namespace.

Ohne permitted.paths libaudiohal.so kann nicht geladen werden /system/${LIB}/hw/audio.a2dp.default.so in die default.
namespace.name.asan.permitted.paths

Eine durch Doppelpunkt getrennte Liste von Verzeichnissen, in die die dynamische Verknüpfung geladen werden kann die gemeinsam genutzten Bibliotheken nutzen, wenn ASan aktiviert ist.

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

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

Wenn ASan aktiviert ist, geteilte Fotogalerien unter /data/asan/system/${LIB}/hw oder /system/${LIB}/hw kann in den isolierten default-Namespace.
namespace.name.visible

Ein boolescher Wert, der angibt, ob das Programm libc) kann ein Verknüpfungs-Namespace-Handle mit android_get_exported_namespace() und öffnen Sie eine gemeinsam genutzte Bibliothek in den Verknüpfungs-Namespace, indem Sie das Handle an android_dlopen_ext()

Wenn visible den Wert true hat, android_get_exported_namespace() gibt den Alias immer zurück, wenn der Namespace existiert.

Wenn visible den Wert false (Standardeinstellung) hat, „android_get_exported_namespace()“ ist immer zurückgegeben NULL unabhängig vom Namespace. Geteilte Fotogalerien können nur in diesen Namespace geladen werden, wenn (1) sie von einem anderen Linker-Namespace mit einem Fallback-Link zu diesem Namespace, oder (2) von anderen gemeinsam genutzten Bibliotheken oder ausführbaren Dateien in diesem Namespace angefordert werden.

namespace.sphal.visible = true

Dies bedeutet, dass android_get_exported_namespace("sphal") kann ein gültiges Verknüpfungs-Namespace-Handle zurückgeben.

Verknüpfungs-Namespace erstellen

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

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

Zum Erstellen der Verknüpfungskonfiguration werden Abhängigkeiten zwischen Verknüpfungs-Namespaces aufgelöst. Für Wenn es beispielsweise Updates zu den APEX-Modulen gibt, die Abhängigkeitsaktualisierungen enthalten, Konfiguration generiert wird, die diese Änderungen widerspiegelt. Weitere Details zum Erstellen einer Verknüpfungskonfiguration finden Sie unter ${android-src}/system/linkerconfig

Verknüpfungs-Namespace-Isolierung

Es gibt drei Konfigurationstypen. Je nach Wert des PRODUCT_TREBLE_LINKER_NAMESPACES und BOARD_VNDK_VERSION in BoardConfig.mk, der wird beim Booten die entsprechende Konfiguration generiert.

PRODUCT_TREBLE_
LINKER_NAMESPACES		 BOARD_VNDK_
VERSION		 Ausgewählte Konfiguration VTS-Anforderung
true current VNDK Obligatorisch für Geräte mit Android 9 oder höher
Leer VNDK Lite Obligatorisch für Geräte mit Android 8.x
false Leer Legacy Für andere Geräte als Höhen

Die VNDK Lite-Konfiguration isoliert die gemeinsam genutzten SP-HAL- und VNDK-SP-Bibliotheken. In Android 8.0 muss die Konfigurationsdatei für die dynamische Verknüpfung sein, wenn PRODUCT_TREBLE_LINKER_NAMESPACES ist true.

Außerdem werden durch die VNDK-Konfiguration die gemeinsam genutzten SP-HAL- und VNDK-SP-Bibliotheken isoliert. Außerdem Diese Konfiguration bietet die vollständige Isolation der dynamischen Verknüpfungen. Dadurch wird sichergestellt, dass Module in der Systempartition nicht von den freigegebenen in die Anbieterpartitionen ein und umgekehrt.

Ab Android 8.1 ist die VNDK-Konfiguration die Standardkonfiguration Es wird dringend empfohlen, die vollständige Isolierung von dynamischen Links durch folgende Einstellung zu aktivieren: BOARD_VNDK_VERSION in current.

VNDK-Konfiguration

<ph type="x-smartling-placeholder">

VNDK-Konfiguration isoliert die Abhängigkeiten der gemeinsam genutzten Bibliothek zwischen Systempartition und Anbieterpartition. Verglichen mit die im vorherigen Unterabschnitt erwähnten Konfigurationen haben, wie folgt definiert:

  • Framework-Prozesse

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

  • Zulieferunternehmen

    • Die Namespaces default, vndk und system werden erstellt.
    • Der Namespace default ist isoliert.
    • Vom Anbieter freigegebene Bibliotheken werden in den Namespace default geladen.
    • Die gemeinsam genutzten Bibliotheken von VNDK und VNDK-SP werden in den Namespace vndk geladen.
    • LL-NDK und seine Abhängigkeiten werden in den Namespace system geladen.

Die Beziehung zwischen den Verknüpfungs-Namespaces ist unten dargestellt.

Diagramm zum Verknüpfungs-Namespace, das in der VNDK-Konfiguration beschrieben wird

Abbildung 1: Verknüpfungs-Namespace-Isolierung (VNDK-Konfiguration).

Im Bild oben stehen LL-NDK und VNDK-SP für: gemeinsam genutzten Bibliotheken:

  • LL-NDK <ph type="x-smartling-placeholder">
      </ph>
    • 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 <ph type="x-smartling-placeholder">
      </ph>
    • 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 findest du auf dem Gerät unter /linkerconfig/ld.config.txt.

VNDK Lite-Konfiguration

Ab Android 8.0 ist die dynamische Verknüpfung so konfiguriert, dass SP-HAL und Von VNDK-SP freigegebene Bibliotheken, sodass ihre Symbole nicht mit anderen in Konflikt stehen gemeinsam genutzten Framework-Bibliotheken. Die Beziehung zwischen den Verknüpfungs-Namespaces ist wie unten dargestellt.

Diagramm zum Verknüpfungs-Namespace, das in der VNDK Lite-Konfiguration beschrieben wird <ph type="x-smartling-placeholder">
</ph> Abbildung 2: Verknüpfungs-Namespace-Isolation (VNDK Lite-Konfiguration)

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

  • LL-NDK <ph type="x-smartling-placeholder">
      </ph>
    • 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 (verschoben nach VNDK-SP in Konfiguration)
  • VNDK-SP <ph type="x-smartling-placeholder">
      </ph>
    • 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

In der folgenden Tabelle ist die Namespace-Konfiguration für das Framework aufgeführt Prozesse, die aus dem Abschnitt [system] in die VNDK Lite-Konfiguration.

Namensraum Attribut 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 enthält die Namespace-Konfiguration für Anbieterprozesse. Diese ist ein Auszug aus dem Abschnitt [vendor] in die VNDK Lite-Konfiguration.

Namensraum Attribut 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} (eingestellt)
/product/${LIB} (eingestellt)
isolated false

Weitere Details findest du auf dem Gerät unter /linkerconfig/ld.config.txt.

Dokumentverlauf

Änderungen bei Android 11

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

Änderungen bei Android 9

  • In Android 9 wird dem Anbieter der vndk-Verknüpfungs-Namespace hinzugefügt Prozesse und gemeinsam genutzte VNDK-Bibliotheken von der Standardverknüpfung isoliert -Namespace auf sie zugegriffen werden.
  • Ersetzen Sie PRODUCT_FULL_TREBLE durch einen spezifischeren Wert PRODUCT_TREBLE_LINKER_NAMESPACES.
  • Android 9 ändert die Namen der folgenden Konfiguration für dynamische Verknüpfungen Dateien.
    Android 8.x Android 9 Beschreibung
    ld.config.txt.in ld.config.txt Für Geräte mit der Namespace-Isolierung zur Laufzeitverknüpfung
    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
  • android.hardware.graphics.allocator@2.0.so entfernen.
  • Die Partitionen product und odm wurden hinzugefügt.