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ść, podczas gdy inni dodają nowe hooki, nowe interfejsy API lub nowe funkcjonalności do bibliotek AOSP. Ta sekcja zawiera wskazówki dotyczące rozszerzania bibliotek AOSP w sposób, który nie psuje CTS/VTS.

Wymiana typu drop-in

Wszystkie zmodyfikowane biblioteki współdzielone muszą być kompatybilne binarnie i stanowić zamienniki ich odpowiedników AOSP. Wszyscy istniejący użytkownicy AOSP muszą mieć możliwość korzystania ze zmodyfikowanej biblioteki współdzielonej bez konieczności ponownej kompilacji. Wymóg ten oznacza, co następuje:

• Nie wolno usuwać funkcji AOSP.
• Konstrukcji nie wolno modyfikować w przypadku narażenia ich użytkowników na działanie.
• Nie należy wzmacniać warunku wstępnego funkcji.
• Funkcje muszą zapewniać równoważne funkcjonalności.
• Nie wolno osłabiać warunku końcowego funkcji.

Rozszerzone klasyfikacje modułów

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

Uwaga : zamiast API/ABI użyto tutaj funkcjonalności , ponieważ możliwe jest dodanie funkcjonalności bez zmiany jakiegokolwiek API/ABI.

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

• Moduły definiujące tylko AOSP (Moduł DA) 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 przepisze funkcje w libcrypto.so za pomocą instrukcji SIMD (bez dodawania nowych funkcji), wówczas zmodyfikowana libcrypto.so będzie modułem DA.
• Moduły definiujące-rozszerzenia (moduł DX) albo definiują nowe funkcjonalności, albo nie mają odpowiednika AOSP.
  • Przykład 1. Jeśli sprzedawca doda funkcję pomocniczą do libjpeg.so w celu uzyskania dostępu do niektórych danych wewnętrznych, wówczas zmodyfikowana libjpeg.so będzie biblioteką DX, 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 , wówczas libfoo.so będzie biblioteką DX.

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

• Moduły Using-only-AOSP (Moduł UA) wykorzystują w swoich implementacjach wyłącznie funkcjonalności AOSP. Nie opierają się 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 (moduł UX) w swoich implementacjach opierają się na niektórych funkcjonalnościach innych niż AOSP.
  • Przykład 1. Jeśli zmodyfikowana libjpeg.so opiera się na innej bibliotece innej niż AOSP o nazwie libjpeg_turbo2.so , wówczas zmodyfikowana libjpeg.so będzie modułem UX.
  • Przykład 2. Jeśli dostawca doda nową funkcję do zmodyfikowanego libexif.so , a zmodyfikowany libjpeg.so korzysta z nowo dodanej funkcji z libexif.so , wówczas zmodyfikowany plik libjpeg.so będzie modułem UX.

Definicje i zastosowania są od siebie niezależne:

Mechanizm przedłużający VNDK

Moduły dostawcy korzystające z rozszerzonych funkcjonalności nie będą działać, ponieważ biblioteka AOSP o tej samej nazwie nie ma rozszerzonych funkcjonalności. Jeśli moduły dostawcy są bezpośrednio lub pośrednio zależne od rozszerzonych funkcjonalności, dostawcy powinni skopiować biblioteki współdzielone DAUX, DXUA i DXUX na partycję dostawcy (procesy dostawcy zawsze najpierw szukają bibliotek współdzielonych na partycji dostawcy). Jednakże bibliotek LL-NDK nie wolno kopiować, zatem moduły dostawców nie mogą polegać na rozszerzonych funkcjonalnościach zdefiniowanych przez zmodyfikowane biblioteki LL-NDK.

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

Wymiana typu drop-in jest ważna, 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 zostać połączone lub skutkować niezdefiniowanym zachowaniem.