Rozszerzenia VNDK

Producenci urządzeń z systemem Android zmieniają kod źródłowy bibliotek AOSP z różnych powodów. Niektórzy dostawcy ponownie wdrażają funkcje w bibliotekach AOSP, aby zwiększyć wydajność, podczas gdy inni dostawcy dodają nowe punkty zaczepienia, nowe interfejsy API lub nowe funkcje do bibliotek AOSP. Ta sekcja zawiera wskazówki dotyczące rozszerzania bibliotek AOSP w sposób, który nie łamie CTS / VTS.

Wymiana typu drop-in

Wszystkie zmodyfikowane biblioteki współdzielone muszą być binarnymi kompatybilnymi zamiennikami ich odpowiedników AOSP. Wszyscy istniejący użytkownicy AOSP muszą mieć możliwość korzystania ze zmodyfikowanej biblioteki współdzielonej bez ponownej kompilacji. Z tego wymogu wynika, co następuje:

  • Nie wolno usuwać funkcji AOSP.
  • Nie wolno zmieniać konstrukcji, jeśli takie konstrukcje są narażone na kontakt z ich użytkownikami.
  • Nie należy wzmacniać warunku wstępnego funkcji.
  • Funkcje muszą zapewniać równoważne funkcjonalności.
  • Nie wolno osłabiać późniejszego stanu funkcji.

Rozszerzone klasyfikacje modułów

Klasyfikuj moduły według funkcjonalności, które definiują i wykorzystują .

Uwaga : Funkcjonalności są tutaj używane zamiast API / ABI, ponieważ można dodawać funkcje bez zmiany jakiegokolwiek API / ABI.

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

  • Definiowanie tylko modułów AOSP (Moduł DA) nie definiuje nowych funkcjonalności, których nie było w odpowiedniku AOSP.
    • Przykład 1. Nienaruszona, niezmodyfikowana biblioteka AOSP jest modułem DA.
    • Przykład 2. Jeśli sprzedawca przepisuje funkcje w libcrypto.so z instrukcjami SIMD (bez dodawania nowych funkcji), to zmodyfikowane libcrypto.so będzie modułem DA.
  • Definiowanie modułów rozszerzeń (moduł DX) albo definiuje nowe funkcje, albo nie ma odpowiednika AOSP.
    • Przykład 1. Jeśli dostawca doda funkcję pomocniczą do libjpeg.so aby uzyskać dostęp do niektórych danych wewnętrznych, wówczas zmodyfikowany libjpeg.so będzie DX-Lib, a nowo dodana funkcja będzie rozszerzoną częścią biblioteki.
    • Przykład 2. Jeśli sprzedawca zdefiniuje bibliotekę inną niż AOSP o nazwie libfoo.so , wtedy libfoo.so będzie DX-Lib.

W zależności od funkcjonalności wykorzystywanych przez moduł, moduły można podzielić na UA-Module i UX-Module .

  • Korzystanie tylko z modułów AOSP (moduł UA) wykorzystuje w swoich implementacjach tylko funkcje AOSP. Nie polegają na żadnych rozszerzeniach innych niż AOSP.
    • Przykład 1. Nienaruszona, niezmodyfikowana biblioteka AOSP to moduł UA.
    • Przykład 2. Jeśli zmodyfikowana biblioteka współdzielona libjpeg.so opiera się tylko na innych interfejsach API AOSP, będzie to moduł UA.
  • Korzystanie z modułów rozszerzeń (UX-Module) polega na niektórych funkcjach innych niż AOSP w swoich implementacjach.
    • Przykład 1. Jeśli zmodyfikowany libjpeg.so opiera się na innej bibliotece innej niż AOSP o nazwie libjpeg_turbo2.so , wówczas zmodyfikowany libjpeg.so będzie modułem UX.
    • Przykład 2. Jeśli sprzedawca doda nową funkcję do swojego zmodyfikowanego libexif.so a jego zmodyfikowany libjpeg.so użyje nowo dodanej funkcji z libexif.so , wówczas jego 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 opierają się na rozszerzonych funkcjach, nie będą działać, ponieważ biblioteka AOSP o tej samej nazwie nie ma rozszerzonej funkcjonalności. Jeśli moduły dostawców bezpośrednio lub pośrednio zależą od rozszerzonych funkcji, dostawcy powinni kopiować biblioteki współdzielone DAUX, DXUA i DXUX na partycję dostawcy (procesy dostawcy zawsze najpierw szukają bibliotek współdzielonych w partycji dostawcy). Jednak bibliotek LL-NDK nie wolno kopiować, więc moduły dostawców nie mogą polegać na rozszerzonych funkcjach zdefiniowanych przez zmodyfikowane biblioteki LL-NDK.

Biblioteki współużytkowane DAUA mogą pozostać na partycji systemowej, jeśli odpowiadająca im biblioteka AOSP może zapewniać tę samą funkcjonalność, a moduły dostawców będą nadal działać, gdy partycja systemowa zostanie nadpisana przez Generic System Image (GSI).

Zastępowanie typu drop-in jest ważne, ponieważ niezmodyfikowane biblioteki VNDK w GSI będą łączyć się ze zmodyfikowanymi bibliotekami współdzielonymi w przypadku kolizji nazw. Jeśli biblioteki AOSP zostaną zmodyfikowane w sposób niezgodny z API / ABI, biblioteki AOSP w GSI mogą nie połączyć się lub spowodować niezdefiniowane zachowania.