Herstellernatives Entwicklungskit (VNDK)

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

Das Vendor Native Development Kit (VNDK) ist eine Reihe von Bibliotheken, die ausschließlich Anbietern zur Implementierung ihrer HALs zur Verfügung stehen. Das VNDK wird in system.img und zur Laufzeit dynamisch mit dem Anbietercode verknüpft.

Warum VNDK?

Android 8.0 und höher ermöglicht Nur-Framework-Updates, bei denen die Systempartition auf die neueste Version aktualisiert werden kann, während Herstellerpartitionen unverändert bleiben. Dies impliziert, dass Binärdateien, die zu unterschiedlichen Zeiten erstellt wurden, in der Lage sein müssen, miteinander zu arbeiten; VNDK deckt API-/ABI-Änderungen in allen Android-Versionen ab.

Nur-Framework-Updates umfassen die folgenden Herausforderungen:

  • Abhängigkeit zwischen Framework-Modulen und Herstellermodulen . Vor Android 8.0 konnten Module von beiden Seiten mit Modulen von der anderen Seite verknüpft werden. Abhängigkeiten von Herstellermodulen erlegten jedoch der Entwicklung von Framework-Modulen unerwünschte Beschränkungen auf.
  • Erweiterungen der AOSP-Bibliotheken . Android 8.0 und höher erfordert, dass alle Android-Geräte CTS bestehen, wenn die Systempartition durch ein standardmäßiges Generic System Image (GSI) ersetzt wird. Da Anbieter jedoch AOSP-Bibliotheken erweitern, um die Leistung zu steigern oder zusätzliche Funktionen für ihre HIDL-Implementierungen hinzuzufügen, kann das Flashen der Systempartition mit einer Standard-GSI die HIDL-Implementierung eines Anbieters beschädigen. (Richtlinien zum Verhindern solcher Brüche finden Sie unter VNDK-Erweiterungen .)

Um diesen Herausforderungen zu begegnen, führt Android 8.0 verschiedene Techniken wie VNDK (in diesem Abschnitt beschrieben), HIDL , hwbinder, Device Tree Overlay und Sepolicy Overlay ein.

VNDK-Ressourcen

Dieser Abschnitt enthält die folgenden VNDK-Ressourcen:

  • VNDK-Konzepte (unten) beschreiben Framework Shared Libraries, Same-Process-HALs (SP-HALs) und VNDK-Terminologie.
  • VNDK-Erweiterungen klassifizieren anbieterspezifische Änderungen in Kategorien. Beispielsweise müssen Bibliotheken mit erweiterten Funktionalitäten, auf die Herstellermodule angewiesen sind, in die Herstellerpartition kopiert werden, aber ABI-inkompatible Änderungen sind verboten.
  • VNDK Build System Support beschreibt die Buildsystemkonfigurationen und Moduldefinitionssyntaxen, die sich auf VNDK beziehen.
  • Das VNDK-Definitionstool hilft bei der Migration Ihres Quellbaums auf Android 8.0 und höher.
  • Der Linker-Namespace bietet eine feinkörnige Kontrolle über die Verknüpfungen gemeinsam genutzter Bibliotheken.
  • Verzeichnisse, Regeln und sepolicy definieren die Verzeichnisstruktur für Geräte mit Android 8.0 und höher, VNDK-Regeln und zugehörige sepolicy.
  • Die VNDK-Designpräsentation veranschaulicht grundlegende VDNK-Konzepte, die in Android 8.0 und höher verwendet werden.

VNDK-Konzepte

In einer idealen Welt mit Android 8.0 und höher laden Framework-Prozesse keine gemeinsam genutzten Bibliotheken von Anbietern, alle Anbieterprozesse laden nur gemeinsam genutzte Bibliotheken von Anbietern (und einen Teil von gemeinsam genutzten Framework-Bibliotheken) und die Kommunikation zwischen Framework-Prozessen und Anbieterprozessen wird durch HIDL und Hardware geregelt Bindemittel.

Eine solche Welt beinhaltet die Möglichkeit, dass stabile, öffentliche APIs aus gemeinsam genutzten Framework-Bibliotheken für Anbietermodulentwickler möglicherweise nicht ausreichen (obwohl sich APIs zwischen Android-Releases ändern können), was erfordert, dass ein Teil der gemeinsam genutzten Framework-Bibliotheken für Anbieterprozesse zugänglich ist. Da außerdem Leistungsanforderungen zu Kompromissen führen können, müssen einige reaktionszeitkritische HALs anders behandelt werden.

In den folgenden Abschnitten wird detailliert beschrieben, wie VNDK gemeinsam genutzte Frameworkbibliotheken für Anbieter und Same-Process-HALs (SP-HALs) handhabt.

Framework gemeinsam genutzte Bibliotheken für Anbieter

Dieser Abschnitt beschreibt die Kriterien für die Klassifizierung gemeinsam genutzter Bibliotheken, auf die Anbieterprozesse zugreifen können. Es gibt zwei Ansätze, um Anbietermodule über mehrere Android-Versionen hinweg zu unterstützen:

  1. Stabilisieren Sie die ABIs/APIs der gemeinsam genutzten Bibliotheken des Frameworks . Neue Framework-Module und alte Herstellermodule können dieselbe gemeinsam genutzte Bibliothek verwenden, um den Speicherbedarf und die Speichergröße zu reduzieren. Eine einzigartige gemeinsam genutzte Bibliothek vermeidet auch mehrere doppelte Ladeprobleme. Die Entwicklungskosten für die Aufrechterhaltung stabiler ABIs/APIs sind jedoch hoch, und es ist unrealistisch, alle ABIs/APIs zu stabilisieren, die von jeder gemeinsam genutzten Framework-Bibliothek exportiert werden.
  2. Kopieren Sie die gemeinsam genutzten Bibliotheken des alten Frameworks . Kommt mit der starken Einschränkung gegenüber Seitenkanälen, die als alle Mechanismen zur Kommunikation zwischen Framework-Modulen und Herstellermodulen definiert sind, einschließlich (aber nicht beschränkt auf) Binder, Socket, Pipe, gemeinsam genutzten Speicher, gemeinsam genutzte Datei und Systemeigenschaften. Es darf keine Kommunikation stattfinden, es sei denn, das Kommunikationsprotokoll ist eingefroren und stabil (z. B. HIDL über hwbinder). Das doppelte Laden gemeinsam genutzter Bibliotheken kann ebenfalls Probleme verursachen; Wenn beispielsweise ein von der neuen Bibliothek erstelltes Objekt an die Funktionen der alten Bibliothek übergeben wird, kann ein Fehler auftreten, da diese Bibliotheken das Objekt möglicherweise anders interpretieren.

Abhängig von den Merkmalen der gemeinsam genutzten Bibliotheken werden unterschiedliche Ansätze verwendet. Daher werden Framework Shared Libraries in drei Unterkategorien eingeteilt:

  • LL-NDK-Bibliotheken sind gemeinsam genutzte Framework-Bibliotheken , die als stabil bekannt sind. Ihre Entwickler verpflichten sich, ihre API/ABI-Stabilitäten aufrechtzuerhalten.
    • LL-NDK enthält die folgenden Bibliotheken: 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 und libvulkan.so ,
  • Berechtigte VNDK-Bibliotheken (VNDK) sind gemeinsam genutzte Framework-Bibliotheken , die sicher zweimal kopiert werden können. Framework-Module und Herstellermodule können mit ihren eigenen Kopien verknüpft werden. Eine gemeinsam genutzte Framework-Bibliothek kann nur dann eine berechtigte VNDK-Bibliothek werden, wenn sie die folgenden Kriterien erfüllt:
    • Es sendet/empfängt keine IPCs an/von dem Framework.
    • Es hat nichts mit der virtuellen ART-Maschine zu tun.
    • Es liest/schreibt keine Dateien/Partitionen mit instabilen Dateiformaten.
    • Es hat keine spezielle Softwarelizenz, die rechtliche Überprüfungen erfordert.
    • Der Eigentümer des Codes hat keine Einwände gegen die Nutzung durch den Anbieter.
  • Framework-Only Libraries (FWK-ONLY) sind Framework Shared Libraries , die nicht zu den oben genannten Kategorien gehören. Diese Bibliotheken:
    • Als Framework-interne Implementierungsdetails gelten.
    • Darf nicht von Herstellermodulen aufgerufen werden.
    • Instabile ABIs/APIs und keine API/ABI-Kompatibilitätsgarantien haben.
    • Werden nicht kopiert.

Gleicher Prozess-HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) ist ein Satz vorgegebener HALs, die als Vendor Shared Libraries implementiert und in Framework-Prozesse geladen werden. SP-HALs werden durch einen Linker-Namespace isoliert (steuert die Bibliotheken und Symbole, die für die gemeinsam genutzten Bibliotheken sichtbar sind). SP-HALs dürfen nur von LL-NDK und VNDK-SP abhängen.

VNDK-SP ist eine vordefinierte Teilmenge geeigneter VNDK-Bibliotheken. VNDK-SP-Bibliotheken werden sorgfältig überprüft, um sicherzustellen, dass das doppelte Laden von VNDK-SP-Bibliotheken in Framework-Prozesse keine Probleme verursacht. Sowohl SP-HALs als auch VNDK-SPs werden von Google definiert.

Die folgenden Bibliotheken sind zugelassene SP-HALs:

  • libGLESv1_CM_${driver}.so
  • libGLESv2_${driver}.so
  • libGLESv3_${driver}.so
  • libEGL_${driver}.so
  • vulkan.${driver}.so
  • android.hardware.renderscript@1.0-impl.so
  • android.hardware.graphics.mapper@2.0-impl.so

VNDK-SP- Bibliotheken geben vndk: { support_system_process: true } in ihren Android.bp-Dateien an. Wenn vendor_available: false angegeben ist, heißen diese Bibliotheken „ VNDK-SP-Private “ und sind für SP-HALS unsichtbar.

Die folgenden sind Nur-Framework-Bibliotheken mit RS-Ausnahmen (FWK-ONLY-RS) :

  • libft2.so (Renderscript)
  • libmediandk.so (Renderscript)

VNDK-Terminologie

  • Module beziehen sich entweder auf Shared Libraries oder Executables .
  • Prozesse sind Betriebssystemaufgaben, die von Executables hervorgebracht werden.
  • Framework -qualifizierte Begriffe beziehen sich auf die Konzepte, die sich auf die Systempartition beziehen.
  • Anbieterqualifizierte Begriffe beziehen sich auf Konzepte im Zusammenhang mit Anbieterpartitionen .

Beispielsweise:

  • Ausführbare Framework -Dateien beziehen sich auf ausführbare Dateien in /system/bin oder /system/xbin .
  • Framework Shared Libraries beziehen sich auf gemeinsam genutzte Bibliotheken unter /system/lib[64] .
  • Framework-Module beziehen sich sowohl auf gemeinsam genutzte Framework-Bibliotheken als auch auf ausführbare Framework-Dateien .
  • Framework-Prozesse sind Prozesse, die von ausführbaren Framework -Dateien erzeugt werden (z. B. /system/bin/app_process ).
  • Ausführbare Dateien des Anbieters beziehen sich auf ausführbare Dateien in /vendor/bin
  • Vendor Shared Libraries beziehen sich auf gemeinsam genutzte Bibliotheken unter /vendor/lib[64] .
  • Herstellermodule beziehen sich sowohl auf ausführbare Dateien des Herstellers als auch auf gemeinsam genutzte Bibliotheken des Herstellers.
  • Anbieterprozesse sind Prozesse, die von ausführbaren Anbieterdateien (z
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

VNDK-Versionierung

In Android 9 sind gemeinsam genutzte VNDK-Bibliotheken versioniert:

  • Die ro.vndk.version wird automatisch zu /vendor/default.prop hinzugefügt.
  • Gemeinsam genutzte VNDK-Bibliotheken werden unter /system/lib[64]/vndk-${ro.vndk.version} installiert.
  • Gemeinsam genutzte VNDK-SP-Bibliotheken werden unter /system/lib[64]/vndk-sp-${ro.vndk.version} installiert.
  • Die Konfigurationsdatei des dynamischen Linkers wird in /system/etc/ld.config.${ro.vndk.version}.txt installiert.

Der Wert von ro.vndk.version wird durch den folgenden Algorithmus ausgewählt:

  • Wenn BOARD_VNDK_VERSION nicht gleich current ist, verwenden BOARD_VNDK_VERSION .
  • Wenn BOARD_VNDK_VERSION gleich current ist:
    • Wenn PLATFORM_VERSION_CODENAME REL ist, verwenden PLATFORM_SDK_VERSION (z. B. 28 ).
    • Verwenden Sie andernfalls PLATFORM_VERSION_CODENAME (z. B. P ).

Upgrade von Geräten

Wenn ein Android 8.x-Gerät die VNDK-Laufzeitdurchsetzung deaktiviert hat, indem es ohne BOARD_VNDK_VERSION wurde, kann es PRODUCT_USE_VNDK_OVERRIDE := false zu BoardConfig.mk hinzufügen, während es auf Android 9 aktualisiert.

Wenn PRODUCT_USE_VNDK_OVERRIDE false ist, wird die Eigenschaft ro.vndk.lite automatisch zu /vendor/default.prop hinzugefügt und ihr Wert ist true . Folglich lädt der dynamische Linker die Linker-Namespace-Konfiguration aus /system/etc/ld.config.vndk_lite.txt , wodurch nur SP-HAL und VNDK-SP isoliert werden.

Um ein Gerät mit Android 7.0 oder niedriger auf Android 9 zu aktualisieren, fügen PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false zu BoardConfig.mk hinzu.

Anbieter-Test-Suite (VTS)

Die Android 9 Vendor Test Suite (VTS) schreibt eine nicht leere ro.vndk.version -Eigenschaft vor. Sowohl neu gestartete Geräte als auch Upgrade-Geräte müssen ro.vndk.version definieren. Einige VNDK-Testfälle (z. B. VtsVndkFilesTest und VtsVndkDependencyTest ) verlassen sich auf die Eigenschaft ro.vndk.version , um die passenden geeigneten VNDK-Bibliotheken-Datensätze zu laden.

Wenn die Eigenschaft ro.product.first_api_level größer als 27 ist, darf die Eigenschaft ro.vndk.lite nicht definiert werden. VtsTreblePlatformVersionTest fehl, wenn ro.vndk.lite in einem neu eingeführten Android 9-Gerät definiert ist.

Dokumentenverlauf

Dieser Abschnitt verfolgt Änderungen an der VNDK-Dokumentation.

Android 9 ändert sich

  • VNDK-Versionierungsabschnitt hinzufügen.
  • VTS-Abschnitt hinzufügen.
  • Einige VNDK-Kategorien wurden umbenannt:
    • LL-NDK-Indirekt wurde in LL-NDK-Privat umbenannt.
    • VNDK-Indirect wurde in VNDK-Private umbenannt.
    • VNDK-SP-Indirect-Private wurde in VNDK-SP-Private umbenannt.
    • VNDK-SP-Indirekt wurde entfernt.

Android 8.1 ändert sich

  • SP-NDK-Bibliotheken wurden in LL-NDK-Bibliotheken zusammengeführt.
  • Ersetzen Sie libui.so durch libft2.so im RS-Namespace-Abschnitt. Es war ein Fehler, libui.so .
  • Fügen Sie libGLESv3.so und libandroid_net.so zu den LL-NDK-Bibliotheken hinzu.
  • Fügen Sie libion.so zu den VNDK-SP-Bibliotheken hinzu.
  • Entfernen Sie libstdc++.so aus LL-NDK-Bibliotheken. Verwenden Sie stattdessen libc++.so . Einige Versionen eigenständiger Toolchains können -lstdc++ zu den standardmäßigen Linker-Flags hinzufügen. Um die Standardwerte zu deaktivieren, fügen -nodefaultlibs -lc -lm -ldl zu LDFLAGS .
  • Verschieben libz.so von LL-NDK- in VNDK-SP-Bibliotheken. In einigen Konfigurationen kann libz.so weiterhin LL-NDK sein. Es sollten jedoch keine Unterschiede erkennbar sein.