Diese Seite wurde von der Cloud Translation API übersetzt.

Vendor Native Development Kit (VNDK) – Übersicht

Das Vendor Native Development Kit (VNDK) besteht aus einer Reihe von Bibliotheken, die von anderen Bibliotheken verwendet werden. oder Binärdateien, im Anbieter oder in der Produktpartition, zur Laufzeit für dlopen.

Warum VNDK?

AOSP ermöglicht reine Framework-Updates, bei denen die Systempartition auf die neueste Version aktualisiert werden kann. Framework-Version, während die Anbieterpartition unverändert bleibt. Obwohl sie an unterschiedlichen müssen die Binärdateien in jeder Partition miteinander zusammenarbeiten können.

Nur Framework-Updates umfassen die folgenden Herausforderungen:

Abhängigkeit zwischen Framework-Modulen und Anbietermodulen. Vor Android 8.0 konnten Module des Herstellers und der Systempartition verknüpft werden. miteinander kommunizieren. Abhängigkeiten von Anbietermodulen sind jedoch nicht erwünscht. Einschränkungen bei der Entwicklung von Framework-Modulen.
Erweiterungen für AOSP-Bibliotheken. Android-Geräte erfordert, dass alle Android-Geräte CTS bestehen, wenn die Systempartition ersetzt wird mit einem standardmäßigen generischen System-Image (GSI). Da die Anbieter den AOSP-Standard jedoch erweitern, Bibliotheken nutzen, um die Leistung zu steigern oder zusätzliche Funktionen für die HIDL Implementierungen, flashen der Systempartition mit einem Standard-GSI kann die HIDL-Implementierung eines Anbieters beschädigen. Richtlinien zu zu verhindern, siehe VNDK-Erweiterungen.

Um diesen Herausforderungen zu begegnen, bietet Android verschiedene Funktionen wie als VNDK (in diesem Abschnitt beschrieben) HIDL, hwbinder Gerätestruktur-Overlay und sepolicy-Overlay.

VNDK-spezifische Nutzungsbedingungen

In Dokumenten im Zusammenhang mit VNDK wird die folgende Terminologie verwendet: <ph type="x-smartling-placeholder">

Module beziehen sich entweder auf freigegebene Bibliotheken oder ausführbare Dateien. Module machen Build-Zeit Abhängigkeiten.
Prozesse sind Betriebssystemaufgaben, die aus ausführbaren Dateien generiert wurden. Prozesse machen Laufzeit Abhängigkeiten.
Für Framework qualifizierte Begriffe, die sich auf die Partition system beziehen:

Ausführbare Framework-Dateien beziehen sich auf ausführbare Dateien in /system/bin oder /system/xbin.
Freigegebene Framework-Bibliotheken verweisen auf freigegebene Bibliotheken unter /system/lib[64]
Framework-Module verweisen auf beide Frameworks-gemeinsam genutzte Bibliotheken und ausführbaren Frameworks.
Framework-Prozesse sind Prozesse, die aus dem Framework hervorgehen ausführbare Dateien, wie z. B. /system/bin/app_process.

Von Anbietern qualifizierte Begriffe, die sich auf vendor-Partitionen beziehen:

Ausführbare Dateien des Anbieters beziehen sich auf ausführbare Dateien in /vendor/bin
Vom Anbieter freigegebene Bibliotheken beziehen sich auf freigegebene Bibliotheken unter /vendor/lib[64]
Anbietermodule beziehen sich sowohl auf ausführbare Dateien des Anbieters als auch auf gemeinsam genutzte Bibliotheken des Anbieters.
Anbieterprozesse sind Prozesse, die vom Anbieter generiert wurden. Ausführbare Dateien, z. B. /vendor/bin/android.hardware.camera.provider@2.4-service.

VNDK-Konzepte

Unter Android 8.0 und höher werden die Framework-Prozesse nicht geladen. Vom Anbieter freigegebene Bibliotheken; alle Prozesse des Anbieters laden nur gemeinsam genutzte Bibliotheken des Anbieters (und einem Teil der gemeinsam genutzten Framework-Bibliotheken) sowie die Kommunikation zwischen die Framework-Prozesse und Anbieterprozesse von HIDL und der Hardware binder.

In einer solchen Welt besteht die Möglichkeit, dass stabile, öffentliche APIs von gemeinsam genutzte Framework-Bibliotheken für Entwickler von Anbietermodulen möglicherweise nicht aus, APIs können sich von Android-Versionen zu Android-Versionen ändern, es ist jedoch ein Teil der gemeinsam genutzten Framework-Bibliotheken für Prozesse von Anbietern zugänglich sein. Wie Sie wissen, Leistungsanforderungen können zu Kompromittierungen führen, HALs müssen anders behandelt werden.

In den folgenden Abschnitten wird beschrieben, wie VNDK mit gemeinsam genutzten Frameworks-Bibliotheken Anbietern und SP-HALs (Same-Process HALs) zur Verfügung.

Gemeinsam genutzte Framework-Bibliotheken für Anbieter

In diesem Abschnitt werden die Kriterien für die Klassifizierung gemeinsam genutzter Bibliotheken beschrieben, die für Prozesse von Zulieferunternehmen zugänglich sind. Es gibt zwei Ansätze, um Anbieter in verschiedenen Android-Releases:

Stabilisieren Sie die ABIs/APIs der gemeinsam genutzten Framework-Bibliotheken. Neue Framework-Module und alte Anbietermodule können dieselbe gemeinsam genutzte Bibliothek verwenden, und die Speichergröße reduzieren. Eine eindeutige gemeinsam genutzte Bibliothek Probleme beim doppelten Laden haben. Die Entwicklungskosten für die Aufrechterhaltung ABIs/APIs sind hoch und es ist unrealistisch, alle ABIs/APIs zu stabilisieren, die von gemeinsam genutzte Framework-Bibliothek.
Kopieren Sie alte, gemeinsam genutzte Framework-Bibliotheken. Mit dem leistungsstarken Einschränkung von Seitenkanälen, definiert als alle Kommunikationsmechanismen zwischen den Framework-Modulen und Anbietermodulen, einschließlich, aber nicht beschränkt auf binder, Socket, Pipe, Shared Memory, Shared File und Systemeigenschaften. Es darf keine Kommunikation sein, es sei denn, das Kommunikationsprotokoll ist eingefroren und stabil. (z.B. HIDL über HWbinder). Wenn geteilte Bibliotheken doppelt geladen werden, auch Probleme zu lösen; Wenn z. B. ein von der neuen Bibliothek erstelltes Objekt übergeben wird, in die Funktionen der alten Bibliothek importieren, kann ein Fehler auftreten, da diese Bibliotheken kann das Objekt anders interpretieren.

Abhängig von den Eigenschaften der gemeinsamen Daten werden unterschiedliche Ansätze verwendet. Bibliotheken. Daher werden gemeinsam genutzte Framework-Bibliotheken in drei Kategorien eingeteilt: Unterkategorien:

LL-NDK-Bibliotheken sind gemeinsam genutzte Framework-Bibliotheken. die bekanntermaßen stabil sind. Ihre Entwickler sind bestrebt, ihre API/ABI-Stabilitäten
- 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 vom Framework freigegeben. Bibliotheken, die zweimal kopiert werden können. Framework-Module und Anbietermodule können mit eigenen Kopien verknüpft werden. Ein gemeinsames Framework kann nur als VNDK-Mediathek zugelassen werden, wenn sie die folgenden Anforderungen erfüllt: Kriterien: <ph type="x-smartling-placeholder">
- Er sendet/empfangen keine IPCs zum/vom Framework.
- Es hat nichts mit der virtuellen ART-Maschine zu tun.
- Dateien/Partitionen mit instabilen Dateiformaten werden nicht gelesen/geschrieben.
- Es hat keine spezielle Softwarelizenz, für die eine rechtliche Prüfung erforderlich ist.
- Der Codeinhaber hat keine Einwände gegen die Nutzung von Anbietern.
Nur-Framework-Bibliotheken (NUR FWK) sind Frameworks freigegeben Bibliotheken, die nicht zu den oben genannten Kategorien gehören. Diese Bibliotheken: <ph type="x-smartling-placeholder">
- Sie werden als Details zur internen Framework-Implementierung angesehen.
- Darf nicht von Anbietermodulen aufgerufen werden.
- Sie haben instabile ABIs/APIs und keine API/ABI-Kompatibilitätsgarantien.
- Sie werden nicht kopiert.

HAL (Same-Process-HAL) (SP-HAL)

Same-Process-HAL (SP-HAL) besteht aus einer Reihe vordefinierter HALs. werden als vom Anbieter freigegebene Bibliotheken implementiert und in das Framework geladen. Prozesse. SP-HALs werden durch einen Verknüpfungs-Namespace isoliert (steuert die und Symbole, die für die gemeinsam genutzten Bibliotheken sichtbar sind. SP-HALs müssen sind nur von LL-NDK und VNDK-SP abhängig.

VNDK-SP ist eine vordefinierte Teilmenge zulässiger VNDK-Bibliotheken. VNDK-SP-Bibliotheken werden sorgfältig geprüft, damit VNDK-SP-Bibliotheken doppelt in das Framework geladen werden. Prozesse keine Probleme verursachen. Sowohl SP-HAL als auch VNDK-SPs werden durch Google.

Die folgenden Bibliotheken sind genehmigte 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 } an in ihren Android.bp-Dateien. Wenn vndk: {private:true} ebenfalls heißen diese Bibliotheken VNDK-SP-Private unsichtbar für SP-HALS.

Dies sind reine Framework-Bibliotheken mit RS-Ausnahmen. (NUR FWK-RSA):

libft2.so (RenderScript)
libmediandk.so (RenderScript)

VNDK-Versionsverwaltung

Die gemeinsam genutzten Bibliotheken von VNDK haben eine Version:

Die Systemeigenschaft ro.vndk.version wird automatisch zu /vendor/default.prop.
Die gemeinsam genutzten Bibliotheken VNDK und VNDK-SP werden als VNDK-Apex installiert com.android.vndk.v${ro.vndk.version} und bereitgestellt an /apex/com.android.vndk.v${ro.vndk.version}.

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

Wenn BOARD_VNDK_VERSION ungleich ist current, BOARD_VNDK_VERSION verwenden.
Wenn BOARD_VNDK_VERSION gleich ist current:

Wenn PLATFORM_VERSION_CODENAME den Wert REL hat, verwenden Sie PLATFORM_SDK_VERSION (z.B. 28).
Andernfalls verwenden Sie PLATFORM_VERSION_CODENAME (z.B. P).

Anbieter-Test-Suite (VTS)

Die Android Vendor Test Suite (VTS) verlangt eine nicht leeres ro.vndk.version-Attribut. Beide neu auf den Markt gebrachten Geräte und für Upgradegeräte muss ro.vndk.version definiert werden. Einige VNDK-Tests Cases (z.B. VtsVndkFilesTest und VtsVndkDependencyTest) nutzen ro.vndk.version Property verwendet, um die übereinstimmenden Datensätze aus der VNDK-Bibliothek zu laden.