Natives Entwicklungskit (VNDK) des Anbieters

Das Vendor Native Development Kit (VNDK) ist eine Sammlung von Bibliotheken, die ausschließlich Anbietern zur Implementierung ihrer HALs dienen. Die VNDK Schiffe in system.img und wird dynamisch an Lieferantencode zur Laufzeit verbunden.

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 die Herstellerpartitionen unverändert bleiben. Dies impliziert, dass zu unterschiedlichen Zeiten erstellte Binärdateien in der Lage sein müssen, miteinander zu arbeiten; VNDK deckt API/ABI-Änderungen in allen Android-Versionen ab.

Nur Framework-Updates beinhalten die folgenden Herausforderungen:

  • Abhängigkeit zwischen Rahmenmodulen und Lieferantenmodule. Vor Android 8.0 konnten Module von beiden Seiten mit Modulen von der anderen Seite verknüpft werden. Allerdings führten Abhängigkeiten von Anbietermodulen zu unerwünschten Einschränkungen bei der Entwicklung von Framework-Modulen.
  • Erweiterungen zu 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. (Leitlinien für diese Brüche zu verhindern, siehe VNDK Erweiterungen .)

Um diese Herausforderungen zu meistern, Android 8.0 führt mehrere Techniken wie VNDK (in diesem Abschnitt beschrieben), HIDL , hwbinder, Gerätebaum overlay und sepolicy Overlay.

VNDK-Ressourcen

Dieser Abschnitt enthält die folgenden VNDK-Ressourcen:

  • VNDK Konzepte (unten) beschreibt Rahmen gemeinsam genutzten Bibliotheken, am selben Prozess HALS (SP-HALS) und VNDK Terminologie.
  • VNDK Erweiterungen stuft herstellerspezifische Änderungen in Kategorien. Zum Beispiel 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 Build - Systemkonfigurationen und Moduldefinition Syntaxen, die VNDK verwandt sind.
  • Die VNDK Definition - Tool hilft Migrate Sourcen auf Ihrem Android 8.0 und höher.
  • Linkers Namespace bietet feinkörniges Kontrolle über gemeinsam genutzte Bibliothek Verknüpfungen.
  • Verzeichnisse, Regeln und sepolicy definiert die Verzeichnisstruktur für Geräte mit Android 8.0 und höher, VNDK Regeln und die damit verbundene sepolicy.
  • Die VNDK Design - Präsentation zeigt grundlegende VDNK Konzepte verwendet in Android 8.0 und höher.

VNDK-Konzepte

In einer idealen Welt mit Android 8.0 und höher laden Framework-Prozesse keine Shared Libraries von Anbietern, alle Vendor-Prozesse laden nur Shared Libraries von Anbietern (und einen Teil der Shared Libraries des Frameworks) 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 Entwickler von Anbietermodulen möglicherweise nicht ausreichen (obwohl APIs zwischen Android-Versionen wechseln können), sodass ein Teil der gemeinsam genutzten Framework-Bibliotheken für Anbieterprozesse zugänglich sein muss. Da Leistungsanforderungen zu Kompromissen führen können, müssen außerdem einige reaktionszeitkritische HALs anders behandelt werden.

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

Gemeinsam genutzte Framework-Bibliotheken für Anbieter

In diesem Abschnitt werden die Kriterien für die Klassifizierung von gemeinsam genutzten Bibliotheken beschrieben, die für Anbieterprozesse zugänglich sind. Es gibt zwei Ansätze, um Anbietermodule über mehrere Android-Versionen hinweg zu unterstützen:

  1. Stabilisiert die Abis / APIs des Rahmens gemeinsam genutzte Bibliotheken. Neue Framework-Module und alte Anbietermodule können dieselbe gemeinsam genutzte Bibliothek verwenden, um den Speicherbedarf und die Speichergröße zu reduzieren. Eine einzigartige gemeinsam genutzte Bibliothek vermeidet auch mehrere Probleme mit doppeltem Laden. 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 alten Rahmen gemeinsam genutzte Bibliotheken. Kommt mit der starken Einschränkung gegen Seitenkanäle, definiert als alle Mechanismen zur Kommunikation zwischen Framework-Modulen und Anbietermodulen, einschließlich (aber nicht beschränkt auf) Binder, Socket, Pipe, Shared Memory, Shared File und Systemeigenschaften. Es darf keine Kommunikation stattfinden, es sei denn, das Kommunikationsprotokoll ist eingefroren und stabil (zB HIDL über hwbinder). Auch das Doppelladen von Shared Libraries kann zu Problemen führen; 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 Eigenschaften der Shared Libraries werden unterschiedliche Ansätze verwendet. Als Ergebnis werden gemeinsam genutzte Framework-Bibliotheken in drei Unterkategorien eingeteilt:

  • LL-NDK Bibliotheken sind Rahmen Shared Libraries , die bekannt sind als stabil. Ihre Entwickler sind bestrebt, ihre API/ABI-Stabilitäten aufrechtzuerhalten.
    • LL-NDK umfasst 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 ,
  • In Frage kommende VNDK Bibliotheken (VNDK) sind Rahmen Shared Libraries , die sicher zweimal kopiert werden. Rahmenmodule und Vendor - Module können mit einem eigenen Kopie verknüpfen. 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 zum/vom 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 Codebesitzer hat keine Einwände gegen die Verwendung durch den Anbieter.
  • Rahmen-Only Bibliotheken (FWK-ONLY) sind Rahmen Shared Libraries , die dies nicht tun , gehören in den oben genannten Kategorien. Diese Bibliotheken:
    • Gilt als rahmeninterne Implementierungsdetails.
    • Darf nicht von Herstellermodulen aufgerufen werden.
    • Haben instabile ABIs/APIs und keine API/ABI-Kompatibilitätsgarantien.
    • Werden nicht kopiert.

Same-Process-HAL (SP-HAL)

Same-Prozess HAL (SP-HAL) ist ein Satz von vorbestimmten HALs implementiert , wie Vendor gemeinsam genutzte Bibliotheken und geladen in Rahmenverfahren. SP-HALs werden durch einen Linker-Namespace isoliert (steuert die Bibliotheken und Symbole, die für die gemeinsam genutzten Bibliotheken sichtbar sind). SP-HALs darf nur auf LL-NDK und VNDK-SP ab.

VNDK-SP ist eine vordefinierte Untermenge berechtigter 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 angeben vndk: { support_system_process: true } in ihren Android.bp Dateien. Wenn vendor_available: false auch angegeben wird, dann werden diese Bibliotheken genannt VNDK-SP-Privat und sie sind unsichtbar für SP-HALS.

Im Folgenden sind gerüst nur Bibliotheken mit RS Ausnahmen (FWK-ONLY-RS):

  • libft2.so (render)
  • libmediandk.so (render)

VNDK-Terminologie

  • Module beziehen sich entweder auf Shared Libraries oder ausführbare Dateien.
  • Prozesse sind Betriebssystemaufgaben von Executables hervorgebracht.
  • Rahmen , Qualifizierte Bezug auf die Begriffe beziehen sich auf die Systempartition verwandt.
  • Vendor , Qualifizierte Begriffe beziehen sich auf die zu Anbieter Partitionen verwandte Konzepte.

Zum Beispiel:

  • Framework - Executables beziehen sich auf ausführbare Dateien in /system/bin oder /system/xbin .
  • Rahmen Shared Libraries bezieht sich auf gemeinsam genutzte Bibliotheken unter /system/lib[64] .
  • Rahmenmodule beziehen sich auf beide Rahmen Shared Libraries und Framework - Executables.
  • Framework - Prozesse sind Prozesse hervorgebracht von Framework - Executables (zB /system/bin/app_process ).
  • Vendor Executables beziehen sich auf ausführbare Dateien in /vendor/bin
  • Vendor Shared Libraries beziehen sich auf gemeinsam genutzte Bibliotheken unter /vendor/lib[64] .
  • Vendor - Module beziehen sich sowohl auf Vendor Executables und Vendor Shared Libraries.
  • Vendor Prozesse sind Prozesse hervorgebracht von Vendor Executables (zB
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

VNDK-Versionierung

In Android 9 werden gemeinsam genutzte VNDK-Bibliotheken versioniert:

  • Die ro.vndk.version Systemeigenschaft wird automatisch hinzugefügt /vendor/default.prop .
  • VNDK gemeinsam genutzte Bibliotheken installiert sind /system/lib[64]/vndk-${ro.vndk.version} .
  • VNDK-SP gemeinsam genutzte Bibliotheken installiert sind /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • Die dynamische Linker - Konfigurationsdatei wird installiert /system/etc/ld.config.${ro.vndk.version}.txt .

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

  • Wenn BOARD_VNDK_VERSION nicht gleich current , Verwendung BOARD_VNDK_VERSION .
  • Wenn BOARD_VNDK_VERSION gleich current :
    • Wenn PLATFORM_VERSION_CODENAME ist REL , Verwendung PLATFORM_SDK_VERSION (zB 28 ).
    • Andernfalls Verwendung PLATFORM_VERSION_CODENAME (zB P ).

Aktualisieren von Geräten

Wenn ein Android 8.x Gerät deaktiviert VNDK Laufzeit durch Durchsetzung ohne gebaut BOARD_VNDK_VERSION kann es hinzufügen PRODUCT_USE_VNDK_OVERRIDE := false zu BoardConfig.mk während ein Upgrade auf Android 9.

Wenn PRODUCT_USE_VNDK_OVERRIDE ist false , die ro.vndk.lite wird Eigenschaft automatisch hinzugefügt /vendor/default.prop und sein Wert wird true . Folglich wird der dynamische Linker die Linker - Namespace - Konfiguration aus laden /system/etc/ld.config.vndk_lite.txt , die nur SP-HAL und VNDK-SP - Isolaten.

So aktualisieren Sie ein Android 7.0 oder niedriges Gerät Android 9, fügen PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false zu BoardConfig.mk .

Anbieter-Testsuite (VTS)

Die Android 9 Vendor Test Suite (VTS) Mandate eine nicht leere ro.vndk.version Eigenschaft. Beide neu eingeführten Geräte und Modernisierung Geräte müssen definieren ro.vndk.version . Einige VNDK Testfälle (zB VtsVndkFilesTest und VtsVndkDependencyTest ) stützen sich auf die ro.vndk.version Eigenschaft , um die passenden qualifizierten VNDK Bibliotheken Datensätze zu laden.

Wenn die ro.product.first_api_level Eigenschaft größer als 27 ist, die ro.vndk.lite muss Eigenschaft nicht definiert werden. VtsTreblePlatformVersionTest wird scheitern , wenn ro.vndk.lite in einem neu gestarteten Android 9 Gerät definiert ist.

Dokumentenverlauf

In diesem Abschnitt werden Änderungen an der VNDK-Dokumentation verfolgt.

Android 9-Änderungen

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

Android 8.1-Änderungen

  • SP-NDK-Bibliotheken wurden in LL-NDK-Bibliotheken zusammengeführt.
  • Ersetzen libui.so mit libft2.so in RS - Namespace - Seite. Es war ein Fehler enthalten libui.so .
  • In libGLESv3.so und libandroid_net.so zu LL-NDK - Bibliotheken.
  • In libion.so zu VNDK-SP - Bibliotheken.
  • Entfernen Sie libstdc++.so von LL-NDK - Bibliotheken. Verwenden Sie libc++.so statt. Einige Versionen von eigenständigen Werkzeugketten können hinzufügen -lstdc++ auf die Standard Linker - Flags. Um die Standardeinstellungen zu deaktivieren, fügen -nodefaultlibs -lc -lm -ldl zu LDFLAGS .
  • Bewegen Sie libz.so von LL-NDK zu VNDK-SP - Bibliotheken. In einigen Konfigurationen libz.so weiterhin LL-NDK zu sein. Es sollten jedoch keine Unterschiede erkennbar sein.