Rozszerzenia VNDK

Producenci urządzeń z Androidem zmieniają kod źródłowy bibliotek AOSP z różnych powodów. Niektórzy dostawcy ponownie implementują funkcje w bibliotekach AOSP, aby zwiększyć wydajność, a inni dodają do nich nowe elementy, nowe interfejsy API lub nowe funkcje. W tej sekcji znajdziesz wskazówki dotyczące rozszerzania bibliotek AOSP w sposób, który nie narusza zasad CTS/VTS.

Wymiana bezpośrednia

Wszystkie zmodyfikowane biblioteki udostępnione muszą być kompatybilne z binarnymi wersjami, zastępować swoje odpowiedniki w AOSP. Wszyscy dotychczasowi użytkownicy AOSP muszą mieć możliwość korzystania z zmodyfikowanej wspólnej biblioteki bez konieczności ponownego kompilowania. To wymaganie oznacza:

  • Funkcji AOSP nie można usuwać.
  • Struktury nie mogą być zmieniane, jeśli są widoczne dla użytkowników.
  • Warunek wstępny funkcji nie może być wzmocniony.
  • Funkcje muszą zapewniać równoważne możliwości.
  • Warunek końcowy funkcji nie może być osłabiony.

Klasyfikacje rozszerzonych modułów

Klasyfikuj moduły według funkcji, które określają i wykorzystują.

Uwaga: zamiast określenia „interfejs API/ABI” użyto tutaj określenia „funkcje”, ponieważ można dodać funkcje bez zmiany interfejsu API/ABI.

W zależności od funkcji zdefiniowanych w module, moduły można podzielić na moduł DA i moduł DX:

  • Defining-only-AOSP Modules (DA-Module) nie definiują nowych funkcji, które nie były dostępne w odpowiedniku AOSP.
    • Przykład 1. Niezmieniona biblioteka AOSP jest modułem DA.
    • Przykład 2. Jeśli dostawca przepisze funkcje w libcrypto.so za pomocą instrukcji SIMD (bez dodawania nowych funkcji), zmodyfikowany moduł libcrypto.so stanie się modułem DA.
  • Moduły definiujące rozszerzenia (DX-Module) definiują nowe funkcje lub nie mają odpowiednika w AOSP.
    • Przykład 1. Jeśli dostawca doda do biblioteki libjpeg.so funkcję pomocniczą, aby uzyskać dostęp do niektórych danych wewnętrznych, zmodyfikowana biblioteka libjpeg.so stanie się biblioteką DX-Lib, a dodana funkcja będzie stanowić rozszerzenie biblioteki.
    • Przykład 2. Jeśli dostawca zdefiniuje bibliotekę niezgodną z AOSP o nazwie libfoo.so, libfoo.so będzie biblioteką DX-Lib.

W zależności od funkcji używanych przez moduł można je podzielić na moduł UA i moduł UX.

  • Moduły korzystające tylko z AOSP (UA-Module) mogą używać tylko funkcji AOSP w swoich implementacjach. Nie korzystają z rozszerzeń innych niż AOSP.
    • Przykład 1. Niezmieniona biblioteka AOSP jest UA-Module.
    • Przykład 2. Jeśli zmodyfikowana biblioteka współdzielona libjpeg.sokorzysta tylko z innych interfejsów API AOSP, będzie to moduł UA.
  • Moduły interfejsu użytkownika (UX-Module) korzystają w swoich implementacjach z niektórych funkcji niezgodnych z AOSP.
    • Przykład 1. Jeśli zmodyfikowany moduł libjpeg.so korzysta z innej biblioteki o nazwie libjpeg_turbo2.so, która nie jest biblioteką AOSP, zmodyfikowany moduł libjpeg.so będzie modułem UX.
    • Przykład 2. Jeśli dostawca doda nową funkcję do zmodyfikowanego libexif.so, a zmodyfikowany libjpeg.so będzie używać nowo dodanej funkcji z libexif.so, zmodyfikowany libjpeg.so będzie modułem UX.

Definicje i zastosowania są od siebie niezależne:

Używane funkcje
Tylko AOSP (UA) Rozszerzony (UX)
Zdefiniowane funkcje Tylko AOSP (DA) DAUA DAUX
Rozszerzony (DX) DXUA DXUX

Mechanizm rozszerzenia VNDK

Moduły dostawców, które korzystają z rozszerzonych funkcji, nie będą działać, ponieważ biblioteka AOSP o tej samej nazwie nie ma rozszerzonych funkcji. Jeśli moduły dostawcy są bezpośrednio lub pośrednio zależne od rozszerzonych funkcji, dostawcy powinni skopiować biblioteki współdzielone DAUX, DXUA i DXUX do partycji dostawcy (procesy dostawcy zawsze najpierw szukają współdzielonych bibliotek w partycji dostawcy). Bibliotek LL-NDK nie można jednak kopiować, więc moduły dostawcy nie mogą korzystać z rozszerzonych funkcji zdefiniowanych przez zmodyfikowane biblioteki LL-NDK.

Biblioteki udostępnione DAUA mogą pozostać na partycji systemowej, jeśli odpowiadająca im biblioteka AOSP może zapewnić te same funkcje, a moduły dostawcy nadal działają, gdy partycja systemowa zostanie zastąpiona przez ogólny obraz systemu (GSI).

Zastąpienie jest ważne, ponieważ niezmodyfikowane biblioteki VNDK w GSI będą się łączyć ze zmodyfikowanymi bibliotekami wspólnymi w przypadku kolizji nazw. Jeśli biblioteki AOSP zostaną zmodyfikowane w sposób niezgodny z interfejsem API lub ABI, biblioteki AOSP w GSI mogą nie zostać połączone lub mogą powodować nieokreślone działanie.