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 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 wpuszczana

Wszystkie zmodyfikowane biblioteki współdzielone muszą być kompatybilne z plikami binarnymi i zastępować ich odpowiedniki AOSP. Wszyscy obecni 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.
• Konstrukcji nie wolno modyfikować, jeśli są one wystawione na ich użytkowników.
• Warunek wstępny funkcji nie może być wzmacniany.
• Funkcje muszą zapewniać równoważne funkcje.
• Post-warunek funkcji nie może być osłabiony.

Rozszerzone klasyfikacje modułów

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

Uwaga : Funkcjonalności są tutaj używane zamiast API/ABI, ponieważ możliwe jest dodawanie funkcjonalności bez zmiany API/ABI.

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

• Moduły Defining-only-AOSP (DA-Module) nie definiują 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 za pomocą instrukcji SIMD (bez dodawania nowych funkcji), to zmodyfikowany libcrypto.so będzie modułem DA.
• Moduły definiujące-rozszerzające (DX-Module) albo definiują nowe funkcjonalności, albo nie mają odpowiednika AOSP.
  • Przykład 1. Jeśli sprzedawca doda funkcję pomocniczą do libjpeg.so , aby uzyskać dostęp do niektórych danych wewnętrznych, to zmodyfikowana libjpeg.so będzie DX-Lib, a nowo dodana funkcja będzie rozszerzoną częścią biblioteki.
  • Przykład 2. Jeśli sprzedawca definiuje bibliotekę inną niż AOSP o nazwie libfoo.so , wtedy libfoo.so będzie biblioteką DX-Lib.

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

• Moduły using-only-AOSP (UA-Module) wykorzystują tylko funkcje AOSP w swoich implementacjach. Nie polegają na żadnych rozszerzeniach innych niż AOSP.
  • Przykład 1. Nienaruszona, niezmodyfikowana biblioteka AOSP jest modułem UA.
  • Przykład 2. Jeśli zmodyfikowana biblioteka współdzielona libjpeg.so opiera się tylko na innych API AOSP, będzie to moduł UA.
• Moduły using-Extension (UX-Module) opierają się w swoich implementacjach na niektórych funkcjach innych niż AOSP.
  • Przykład 1. Jeśli zmodyfikowana libjpeg.so opiera się na innej bibliotece innej niż AOSP o nazwie libjpeg_turbo2.so , to zmodyfikowany libjpeg.so będzie modułem UX.
  • Przykład 2. Jeśli sprzedawca doda nową funkcję do zmodyfikowanego libexif.so , a jego zmodyfikowany libjpeg.so użyje nowo dodanej funkcji z libexif.so , to jego zmodyfikowany libjpeg.so będzie modułem UX.

Definicje i zastosowania są od siebie niezależne:

Mechanizm rozszerzenia VNDK

Moduły dostawcy, 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 dostawcy bezpośrednio lub pośrednio zależą od rozszerzonych funkcji, dostawcy powinni skopiować biblioteki współdzielone DAUX, DXUA i DXUX na partycję dostawcy (procesy dostawcy zawsze najpierw szukają bibliotek współdzielonych w partycji dostawcy). Jednak biblioteki LL-NDK nie mogą być kopiowane, więc moduły dostawcy nie mogą polegać na rozszerzonych funkcjach zdefiniowanych przez zmodyfikowane biblioteki LL-NDK.

Biblioteki współdzielone DAUA mogą pozostać na partycji systemowej, jeśli odpowiadająca im biblioteka AOSP może zapewnić taką samą funkcjonalność, a moduły dostawcy będą nadal działać, gdy partycja systemowa zostanie nadpisana przez ogólny obraz systemu (GSI).

Zastąpienie 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.