Omówienie natywnego zestawu deweloperskiego dostawcy (VNDK).

Vendor Native Development Kit (VNDK) to zestaw bibliotek używanych przez inne biblioteki lub pliki binarne na partycji dostawcy lub produktu w środowisku wykonawczym dlopen.

Dlaczego VNDK?

AOSP umożliwia aktualizacje tylko platformy, w których partycja systemowa może zostać zaktualizowana do najnowszej wersji platformy, podczas gdy partycja dostawcy pozostaje niezmieniona. Pomimo tego, że pliki binarne w każdej partycji były budowane w różnym czasie, muszą ze sobą współpracować.

Aktualizacje tylko platformy obejmują następujące wyzwania:

  • Zależność pomiędzy modułami frameworka i modułami dostawcy . Przed Androidem 8.0 moduły na partycji dostawcy i systemowej mogły się ze sobą łączyć. Jednakże zależności od modułów dostawców nałożyły niepożądane ograniczenia na rozwój modułów frameworku.
  • Rozszerzenia bibliotek AOSP . Android wymaga, aby wszystkie urządzenia z Androidem przeszły CTS, gdy partycja systemowa zostanie zastąpiona standardowym ogólnym obrazem systemu (GSI). Jednakże, ponieważ dostawcy rozszerzają biblioteki AOSP w celu zwiększenia wydajności lub dodania dodatkowych funkcjonalności do swoich implementacji HIDL, flashowanie partycji systemowej za pomocą standardowego GSI może zepsuć implementację HIDL dostawcy. Wytyczne dotyczące zapobiegania takim uszkodzeniom można znaleźć w sekcji Rozszerzenia VNDK .

Aby sprostać tym wyzwaniom, Android zawiera kilka funkcji, takich jak VNDK (opisane w tej sekcji), HIDL , hwbinder, nakładka drzewa urządzeń i nakładka sepolicy.

Warunki specyficzne dla VNDK

W dokumentach związanych z VNDK stosowana jest następująca terminologia:
  • Moduły odnoszą się do bibliotek współdzielonych lub plików wykonywalnych. Moduły tworzą zależności w czasie kompilacji.
  • Procesy to zadania systemu operacyjnego tworzone z plików wykonywalnych. Procesy tworzą zależności w czasie wykonywania.
  • Terminy kwalifikowane Framework dotyczą partycji system :
    • Pliki wykonywalne Framework odnoszą się do plików wykonywalnych w /system/bin lub /system/xbin .
    • Biblioteki współdzielone Framework odnoszą się do bibliotek współdzielonych w katalogu /system/lib[64] .
    • Moduły frameworku odnoszą się zarówno do współdzielonych bibliotek frameworka, jak i plików wykonywalnych frameworku.
    • Procesy frameworkowe to procesy tworzone z plików wykonywalnych frameworku, takich jak /system/bin/app_process .
  • Terminy kwalifikowane przez dostawcę dotyczą partycji vendor :
    • Pliki wykonywalne dostawcy odnoszą się do plików wykonywalnych w /vendor/bin
    • Biblioteki współdzielone dostawców odnoszą się do bibliotek współdzielonych w katalogu /vendor/lib[64] .
    • Moduły dostawcy odnoszą się zarówno do plików wykonywalnych dostawcy, jak i bibliotek współdzielonych dostawcy.
    • Procesy dostawcy to procesy generowane z plików wykonywalnych dostawcy, takie jak /vendor/bin/android.hardware.camera.provider@2.4-service .

Koncepcje VNDK

W idealnym świecie Androida 8.0 i nowszego procesy frameworka nie ładują bibliotek współdzielonych dostawców, wszystkie procesy dostawców ładują tylko biblioteki współdzielone dostawców (i część bibliotek współdzielonych frameworków), a komunikacja między procesami frameworku a procesami dostawców jest zarządzana przez HIDL i sprzęt spoiwo.

W takim świecie istnieje możliwość, że stabilne, publiczne interfejsy API ze współdzielonych bibliotek frameworka mogą nie być wystarczające dla twórców modułów dostawców (chociaż interfejsy API mogą zmieniać się w zależności od wersji Androida), co wymaga, aby pewna część współdzielonych bibliotek frameworków była dostępna dla procesów dostawców. Ponadto, ponieważ wymagania dotyczące wydajności mogą prowadzić do kompromisów, niektóre warstwy HAL, których czas reakcji jest krytyczny, należy traktować inaczej.

W poniższych sekcjach opisano szczegółowo, w jaki sposób VNDK obsługuje współdzielone biblioteki platformy dla dostawców i warstw HAL tego samego procesu (SP-HAL).

Ramowe biblioteki współdzielone dla dostawcy

W tej sekcji opisano kryteria klasyfikacji bibliotek współdzielonych, które są dostępne dla procesów dostawców. Istnieją dwa podejścia do obsługi modułów dostawców w wielu wersjach Androida:

  1. Stabilizuj interfejsy ABI/API bibliotek współdzielonych frameworka . Nowe moduły frameworka i moduły starych dostawców mogą korzystać z tej samej biblioteki współdzielonej, aby zmniejszyć zużycie pamięci i rozmiar pamięci. Unikalna biblioteka współdzielona pozwala również uniknąć kilku problemów z podwójnym ładowaniem. Jednakże koszt rozwoju w celu utrzymania stabilnych interfejsów ABI/API jest wysoki i stabilizacja wszystkich interfejsów ABI/API eksportowanych przez każdą bibliotekę współdzieloną jest nierealistyczna.
  2. Skopiuj stare biblioteki współdzielone frameworka . Zawiera silne ograniczenia dotyczące kanałów bocznych, zdefiniowanych jako wszystkie mechanizmy komunikacji między modułami platformy i modułami dostawców, w tym (ale nie wyłącznie) spoiwo, gniazdo, potok, pamięć współdzielona, ​​współdzielony plik i właściwości systemu. Nie może być żadnej komunikacji, chyba że protokół komunikacyjny jest zablokowany i stabilny (np. HIDL przez hwbinder). Podwójne ładowanie bibliotek współdzielonych również może powodować problemy; na przykład, jeśli obiekt utworzony przez nową bibliotekę zostanie przekazany do funkcji ze starej biblioteki, może wystąpić błąd, ponieważ biblioteki te mogą inaczej interpretować obiekt.

Stosowane są różne podejścia w zależności od charakterystyki bibliotek współdzielonych. W rezultacie biblioteki współdzielone frameworka są podzielone na trzy podkategorie:

  • Biblioteki LL-NDK są bibliotekami współdzielonymi Framework , o których wiadomo, że są stabilne. Ich programiści są zobowiązani do utrzymania stabilności API/ABI.
    • LL-NDK zawiera następujące biblioteki: libEGL.so , libGLESv1_CM.so , libGLESv2.so , libGLESv3.so , libandroid_net.so , libc.so , libdl.so , liblog.so , libm.so , libnativewindow.so , libneuralnetworks.so libsync.so , libvndksupport.so i libvulkan.so ,
  • Kwalifikujące się biblioteki VNDK (VNDK) to Frameworkowe biblioteki współdzielone , które można bezpiecznie skopiować dwukrotnie. Moduły Ramowe i Moduły Dostawcy mogą łączyć się z własnymi kopiami. Biblioteka współdzielona frameworka może stać się kwalifikującą się biblioteką VNDK tylko wtedy, gdy spełnia następujące kryteria:
    • Nie wysyła/nie odbiera IPC do/z frameworka.
    • Nie jest to związane z maszyną wirtualną ART.
    • Nie odczytuje/zapisuje plików/partycji o niestabilnych formatach plików.
    • Nie ma specjalnej licencji na oprogramowanie, która wymaga opinii prawnych.
    • Właściciel kodu nie ma zastrzeżeń do zastosowań dostawców.
  • Biblioteki ramowe (FWK-ONLY) to biblioteki współdzielone ramowe , które nie należą do kategorii wymienionych powyżej. Te biblioteki:
    • Są uważane za szczegóły wewnętrznego wdrożenia ramowego.
    • Nie mogą być dostępne dla modułów dostawcy.
    • Mają niestabilne interfejsy ABI/API i brak gwarancji zgodności API/ABI.
    • Nie są kopiowane.

HAL tego samego procesu (SP-HAL)

HAL tego samego procesu ( SP-HAL ) to zestaw wstępnie określonych warstw HAL zaimplementowanych jako biblioteki współdzielone przez dostawcę i załadowanych do procesów ramowych . SP-HAL są izolowane przez przestrzeń nazw linkera (kontroluje biblioteki i symbole widoczne dla bibliotek współdzielonych). SP-HAL muszą zależeć tylko od LL-NDK i VNDK-SP .

VNDK-SP to predefiniowany podzbiór kwalifikujących się bibliotek VNDK. Biblioteki VNDK-SP są dokładnie sprawdzane, aby mieć pewność, że podwójne ładowanie bibliotek VNDK-SP do procesów frameworka nie spowoduje problemów. Zarówno SP-HAL, jak i VNDK-SP są zdefiniowane przez Google.

Następujące biblioteki są zatwierdzonymi bibliotekami SP-HAL:

  • libGLESv1_CM_${driver}.so
  • libGLESv2_${driver}.so
  • libGLESv3_${driver}.so
  • libEGL_${driver}.so
  • vulkan.${driver}.so
  • android.hardware.renderscript@1.0-impl.so
  • android.hardware.graphics.mapper@2.0-impl.so

Biblioteki VNDK-SP określają vndk: { support_system_process: true } w swoich plikach Android.bp. Jeśli określono również vndk: {private:true} , wówczas biblioteki te nazywane są VNDK-SP-Private i są niewidoczne dla SP-HALS.

Poniżej znajdują się biblioteki przeznaczone tylko dla frameworka z wyjątkami RS (FWK-ONLY-RS) :

  • libft2.so (skrypt renderujący)
  • libmediandk.so (Skrypt renderujący)

Wersja VNDK

Biblioteki współdzielone VNDK są wersjonowane:

  • Właściwość systemowa ro.vndk.version jest automatycznie dodawana do /vendor/default.prop .
  • Biblioteki współdzielone VNDK i VNDK-SP są instalowane jako wierzchołek VNDK com.android.vndk.v${ro.vndk.version} i montowane do /apex/com.android.vndk.v${ro.vndk.version} .

Wartość ro.vndk.version jest wybierana przez poniższy algorytm:

  • Jeśli BOARD_VNDK_VERSION nie jest równa current , użyj BOARD_VNDK_VERSION .
  • Jeśli BOARD_VNDK_VERSION jest równa current :
    • Jeśli PLATFORM_VERSION_CODENAME to REL , użyj PLATFORM_SDK_VERSION (np. 28 ).
    • W przeciwnym razie użyj PLATFORM_VERSION_CODENAME (np. P ).

Zestaw testów dostawców (VTS)

Pakiet testowy dostawcy systemu Android (VTS) wymaga niepustej właściwości ro.vndk.version . Zarówno nowo uruchomione urządzenia, jak i urządzenia aktualizujące muszą definiować ro.vndk.version . Niektóre przypadki testowe VNDK (np. VtsVndkFilesTest i VtsVndkDependencyTest ) korzystają z właściwości ro.vndk.version w celu załadowania pasujących, kwalifikujących się zestawów danych bibliotek VNDK.