VNDK-Erweiterungen

Hersteller von Android-Geräten ändern den Quellcode von AOSP-Bibliotheken aus verschiedenen Gründen. Einige Anbieter implementieren Funktionen in AOSP-Bibliotheken neu, um die Leistung zu steigern, während andere Anbieter AOSP-Bibliotheken neue Hooks, neue APIs oder neue Funktionen hinzufügen. Dieser Abschnitt enthält Richtlinien zum Erweitern von AOSP-Bibliotheken so, dass CTS / VTS nicht beschädigt wird.

Drop-In-Ersatz

Alle modifizierten Shared Libraries müssen binärkompatibel, Drop-in Ersatz ihrer AOSP Gegenstück sein. Alle vorhandenen AOSP-Benutzer müssen in der Lage sein, die geänderte gemeinsam genutzte Bibliothek ohne Neukompilierung zu verwenden. Diese Anforderung impliziert Folgendes:

  • AOSP-Funktionen dürfen nicht entfernt werden.
  • Strukturen dürfen nicht verändert werden, wenn solche Strukturen ihren Benutzern ausgesetzt sind.
  • Die Vorbedingung von Funktionen darf nicht gestärkt werden.
  • Funktionen müssen gleichwertige Funktionen bereitstellen.
  • Der Nachzustand von Funktionen darf nicht geschwächt werden.

Erweiterte Modulklassifikationen

Klassifizieren Sie Module nach den Funktionen, die sie definieren und verwenden .

Hinweis : Hier werden anstelle von API / ABI Funktionen verwendet, da Funktionen hinzugefügt werden können, ohne dass API / ABI geändert werden müssen.

Abhängig von den in einem Modul definierten Funktionen können Module in DA-Module und DX-Module unterteilt werden :

  • Das Definieren von Nur-AOSP-Modulen (DA-Modul) definiert keine neuen Funktionen, die nicht im AOSP-Gegenstück enthalten waren.
    • Beispiel 1. Eine intakte, nicht modifizierte AOSP-Bibliothek ist ein DA-Modul.
    • Beispiel 2. Wenn ein Anbieter die Funktionen in libcrypto.so mit SIMD-Anweisungen neu schreibt (ohne neue Funktionen hinzuzufügen), ist das geänderte libcrypto.so ein DA-Modul.
  • Definitionserweiterungsmodule (DX-Modul) definieren entweder neue Funktionen oder haben kein AOSP-Gegenstück.
    • Beispiel 1. Wenn ein Anbieter libjpeg.so eine libjpeg.so um auf einige interne Daten zuzugreifen, ist die geänderte libjpeg.so eine DX-Lib und die neu hinzugefügte Funktion der erweiterte Teil der Bibliothek.
    • Beispiel 2. Wenn ein Anbieter eine Nicht-AOSP-Bibliothek mit dem Namen libfoo.so , ist libfoo.so eine DX-Lib.

Abhängig von den von einem Modul verwendeten Funktionen können Module in UA-Module und UX-Module unterteilt werden .

  • Nur-Verwenden-AOSP-Module (UA-Modul) verwenden in ihren Implementierungen nur AOSP-Funktionen. Sie sind nicht auf Nicht-AOSP-Erweiterungen angewiesen.
    • Beispiel 1. Eine intakte, nicht modifizierte AOSP-Bibliothek ist ein UA-Modul.
    • Beispiel 2. Wenn eine modifizierte gemeinsam genutzte Bibliothek libjpeg.so nur auf anderen AOSP-APIs basiert, handelt es sich um ein UA-Modul.
  • Die Verwendung von Erweiterungsmodulen (UX-Module) stützt sich bei ihren Implementierungen auf einige Nicht-AOSP-Funktionen.
    • Beispiel 1. Wenn eine modifizierte libjpeg.so auf einer anderen Nicht-AOSP-Bibliothek namens libjpeg_turbo2.so , ist die modifizierte libjpeg.so ein UX-Modul.
    • Beispiel 2. Wenn ein Anbieter seiner modifizierten libexif.so eine neue Funktion libexif.so und seine modifizierte libjpeg.so die neu hinzugefügte Funktion von libexif.so , ist seine modifizierte libjpeg.so ein UX-Modul.

Definitionen und Verwendungen sind unabhängig voneinander:

Verwendete Funktionen
Nur AOSP (UA) Erweitert (UX)
Definierte Funktionen Nur AOSP (DA) DAUA DAUX
Erweitert (DX) DXUA DXUX

VNDK-Erweiterungsmechanismus

Herstellermodule, die auf erweiterten Funktionen basieren, funktionieren nicht, da die gleichnamige AOSP-Bibliothek nicht über die erweiterten Funktionen verfügt. Wenn Anbietermodule direkt oder indirekt von erweiterten Funktionen abhängen, sollten Anbieter gemeinsam genutzte DAUX-, DXUA- und DXUX-Bibliotheken auf die Anbieterpartition kopieren (Herstellerprozesse suchen immer zuerst nach gemeinsam genutzten Bibliotheken in der Anbieterpartition). LL-NDK-Bibliotheken dürfen jedoch nicht kopiert werden, sodass Herstellermodule nicht auf den erweiterten Funktionen basieren dürfen, die durch die geänderten LL-NDK-Bibliotheken definiert sind.

Gemeinsame DAUA-Bibliotheken können auf der Systempartition verbleiben, wenn die entsprechende AOSP-Bibliothek dieselbe Funktionalität bietet und Herstellermodule weiterhin funktionieren, wenn die Systempartition von einem generischen Systemabbild (GSI) überschrieben wird.

Das Ersetzen von Drop-Ins ist wichtig, da die nicht geänderten VNDK-Bibliotheken in der GSI bei einer Namenskollision mit den geänderten gemeinsam genutzten Bibliotheken verknüpft werden. Wenn die AOSP-Bibliotheken auf eine API / ABI-inkompatible Weise geändert werden, können die AOSP-Bibliotheken in der GSI möglicherweise keine Verknüpfung herstellen oder zu undefiniertem Verhalten führen.