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 neue Hooks, neue APIs oder neue Funktionalitäten zu AOSP-Bibliotheken hinzufügen. Dieser Abschnitt enthält Richtlinien für die Erweiterung von AOSP-Bibliotheken auf eine Weise, die CTS/VTS nicht beeinträchtigt.

Drop-In-Ersatz

Alle geänderten gemeinsam genutzten Bibliotheken müssen binärkompatibel sein und ihre AOSP-Gegenstücke ersetzen . Alle bestehenden AOSP-Benutzer müssen in der Lage sein, die geänderte gemeinsam genutzte Bibliothek ohne Neukompilierungen zu verwenden. Diese Anforderung impliziert Folgendes:

• AOSP-Funktionen dürfen nicht entfernt werden.
• Bauwerke dürfen nicht verändert werden, wenn sie ihren Nutzern zugänglich sind.
• Voraussetzung für Funktionen darf nicht gestärkt werden.
• Funktionen müssen gleichwertige Funktionalitäten bereitstellen.
• Nachzustand der Funktionen darf nicht geschwächt werden.

Erweiterte Modulklassifizierungen

Klassifizieren Sie Module nach den Funktionalitäten, die sie definieren und verwenden .

Hinweis : Funktionalitäten werden hier anstelle von API/ABI verwendet, da es möglich ist, Funktionen hinzuzufügen, ohne API/ABI zu ändern.

Abhängig von den in einem Modul definierten Funktionalitäten können Module in DA-Module und DX-Module eingeteilt werden:

• Nur-AOSP-Module (DA-Module) definieren keine neuen Funktionalitäten, die nicht im AOSP-Gegenstück enthalten waren.
  • Beispiel 1. Eine intakte, unveränderte AOSP-Bibliothek ist ein DA-Modul.
  • Beispiel 2. Wenn ein Anbieter die Funktionen in libcrypto.so mit SIMD-Anweisungen umschreibt (ohne neue Funktionen hinzuzufügen), dann ist das geänderte libcrypto.so ein DA-Modul.
• Definierende Erweiterungsmodule (DX-Module) definieren entweder neue Funktionalitäten oder haben kein AOSP-Gegenstück.
  • Beispiel 1. Wenn ein Anbieter eine Hilfsfunktion zu libjpeg.so hinzufügt, um auf einige interne Daten zuzugreifen, dann ist die geänderte libjpeg.so eine DX-Lib und die neu hinzugefügte Funktion ist der erweiterte Teil der Bibliothek.
  • Beispiel 2. Wenn ein Anbieter eine Nicht-AOSP-Bibliothek mit dem Namen libfoo.so definiert, dann ist libfoo.so eine DX-Lib.

Abhängig von den von einem Modul verwendeten Funktionalitäten können Module in UA-Module und UX-Module klassifiziert werden.

• Using-only-AOSP-Module (UA-Module) verwenden in ihren Implementierungen nur AOSP-Funktionalitäten. Sie verlassen sich nicht auf Nicht-AOSP-Erweiterungen.
  • Beispiel 1. Eine intakte, unveränderte AOSP-Bibliothek ist ein UA-Modul.
  • Beispiel 2. Wenn eine modifizierte gemeinsam genutzte Bibliothek libjpeg.so nur auf andere AOSP-APIs angewiesen ist, handelt es sich um ein UA-Modul.
• Using-Extension-Module (UX-Module) stützen sich in ihren Implementierungen auf einige Nicht-AOSP-Funktionalitäten.
  • Beispiel 1. Wenn eine geänderte libjpeg.so auf einer anderen Nicht-AOSP-Bibliothek namens libjpeg_turbo2.so basiert, dann ist die geänderte libjpeg.so ein UX-Modul.
  • Beispiel 2. Wenn ein Anbieter seiner geänderten libexif.so eine neue Funktion hinzufügt und seine geänderte libjpeg.so die neu hinzugefügte Funktion von libexif.so verwendet, dann wird seine geänderte libjpeg.so ein UX-Modul sein.

Definitionen und Verwendungen sind unabhängig voneinander:

VNDK-Erweiterungsmechanismus

Anbietermodule, 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 Funktionalitäten abhängen, sollten Anbieter die gemeinsam genutzten Bibliotheken DAUX, DXUA und DXUX in die Anbieterpartition kopieren (Anbieterprozesse suchen immer zuerst nach gemeinsam genutzten Bibliotheken in der Anbieterpartition). Allerdings dürfen LL-NDK-Bibliotheken nicht kopiert werden, sodass Herstellermodule nicht auf den erweiterten Funktionalitäten basieren dürfen, die durch die geänderten LL-NDK-Bibliotheken definiert werden.

Gemeinsam genutzte DAUA-Bibliotheken können auf der Systempartition verbleiben, wenn die entsprechende AOSP-Bibliothek die gleiche Funktionalität bereitstellen kann und Herstellermodule weiterhin funktionieren, wenn die Systempartition durch ein Generic System Image (GSI) überschrieben wird.

Der Drop-in-Ersatz ist wichtig, da die unveränderten VNDK-Bibliotheken im GSI bei Namenskonflikten mit den geänderten gemeinsam genutzten Bibliotheken verknüpft werden. Wenn die AOSP-Bibliotheken auf eine API/ABI-inkompatible Weise geändert werden, kann es sein, dass die AOSP-Bibliotheken im GSI nicht verknüpft werden können oder es zu undefiniertem Verhalten kommt.