Omówienie zestawu Vendor Native Development Kit (VNDK)

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

Dlaczego VNDK?

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

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

• Zależność między modułami ramowymi a modułami dostawcy . Przed Androidem 8.0 moduły w partycji dostawcy i systemowej mogły się ze sobą łączyć. Jednak zależności od modułów dostawców nałożyły niepożądane ograniczenia na rozwój modułów ramowych.
• 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 ponieważ dostawcy rozszerzają biblioteki AOSP w celu zwiększenia wydajności lub dodania dodatkowych funkcji do swoich implementacji HIDL, flashowanie partycji systemowej za pomocą standardowego GSI może spowodować uszkodzenie implementacji HIDL dostawcy. Aby uzyskać wskazówki dotyczące zapobiegania takim awariom, zobacz rozszerzenia VNDK .

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

Warunki specyficzne dla VNDK

Dokumenty związane z VNDK używają następującej terminologii:

• 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 zrodzone z plików wykonywalnych. Procesy tworzą zależności w czasie wykonywania.
• Warunki ramowe odnoszą się do partycji system :
• Pliki wykonywalne platformy odnoszą się do plików wykonywalnych w /system/bin lub /system/xbin .
• Biblioteki współdzielone platformy odnoszą się do bibliotek współdzielonych w katalogu /system/lib[64] .
• Moduły frameworka odnoszą się zarówno do współdzielonych bibliotek frameworka, jak i plików wykonywalnych frameworka.
• Procesy ramowe to procesy pochodzące z plików wykonywalnych struktury, takich jak /system/bin/app_process .
• Warunki kwalifikowane dostawcy są powiązane z partycjami vendor :
• Pliki wykonywalne dostawcy odnoszą się do plików wykonywalnych w /vendor/bin
• Biblioteki współdzielone dostawcy 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 udostępnionych przez dostawcę.
• Procesy dostawcy to procesy pochodzące z plików wykonywalnych dostawcy, takie jak /vendor/bin/android.hardware.camera.provider@2.4-service .

Uwaga: Generic System Image (GSI) oznacza standardowy obraz systemu Android zbudowany z odpowiednich gałęzi (podobny do gałęzi wydania, ale z pewnymi poprawkami błędów lub pewnymi uogólnieniami) i wydany przez Google.

Koncepcje VNDK

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

Taki świat obejmuje możliwość, że stabilne, publiczne interfejsy API z bibliotek współdzielonych platformy mogą nie być wystarczające dla programistów modułów dostawców (chociaż interfejsy API mogą się zmieniać między wersjami Androida), co wymaga, aby niektóre części bibliotek współdzielonych struktury były dostępne dla procesów dostawców. Ponadto, ponieważ wymagania dotyczące wydajności mogą prowadzić do kompromisów, niektóre warstwy HAL o krytycznym czasie reakcji muszą być traktowane inaczej.

Poniższe sekcje szczegółowo opisują sposób, w jaki VNDK obsługuje współdzielone biblioteki ramowe dla dostawców i warstwy HAL tego samego procesu (SP-HAL).

Frameworkowe biblioteki współdzielone dla dostawcy

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

1. Ustabilizuj ABI/API współdzielonych bibliotek 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 masowej. Unikalna biblioteka współdzielona pozwala również uniknąć kilku problemów z podwójnym ładowaniem. Jednak koszt rozwoju w celu utrzymania stabilnych ABI/API jest wysoki i nierealne jest stabilizowanie wszystkich ABI/API eksportowanych przez każdą współdzieloną bibliotekę ramową.
2. Skopiuj stare współdzielone biblioteki frameworka . Pochodzi z silnymi ograniczeniami dotyczącymi kanałów bocznych, zdefiniowanych jako wszystkie mechanizmy komunikacji między modułami ramowymi i modułami dostawców, w tym (między innymi) spoiwem, gniazdem, potokiem, współdzieloną pamięcią, współdzielonym plikiem i właściwościami systemu. Nie może być komunikacji, chyba że protokół komunikacyjny jest zamrożony 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ż te biblioteki mogą inaczej interpretować obiekt.

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

• Biblioteki LL-NDK to współdzielone biblioteki ramowe , 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 ,
• Uprawnione biblioteki VNDK (VNDK) to współdzielone biblioteki ramowe , których dwukrotne kopiowanie jest bezpieczne. Moduły ramowe i moduły dostawcy mogą łączyć się z własnymi kopiami. Współdzielona biblioteka ramowa może zostać kwalifikującą się biblioteką VNDK tylko wtedy, gdy spełnia następujące kryteria:
  • Nie wysyła/odbiera IPC do/z frameworka.
  • Nie jest powiązany z maszyną wirtualną ART.
  • Nie odczytuje/zapisuje plików/partycji o niestabilnych formatach plików.
  • Nie posiada specjalnej licencji na oprogramowanie, która wymaga opinii prawnych.
  • Jego właściciel kodu nie ma zastrzeżeń do zastosowań dostawców.
• Biblioteki Framework-Only (FWK-ONLY) to Wspólne Biblioteki Ramowe , które nie należą do wyżej wymienionych kategorii. Te biblioteki:
  • Są uważane za wewnętrzne szczegóły implementacji ram.
  • Moduły dostawców nie mogą mieć do nich dostępu.
  • Mieć niestabilne ABI/API i brak gwarancji kompatybilności API/ABI.
  • Nie są kopiowane.

HAL tego samego procesu (SP-HAL)

Ten sam proces HAL ( SP-HAL ) to zestaw z góry określonych warstw HAL zaimplementowanych jako wspólne biblioteki dostawcy i załadowanych do procesów ramowych . SP-HAL są izolowane przez przestrzeń nazw konsolidatora (steruje bibliotekami i symbolami widocznymi dla bibliotek współdzielonych). SP-HAL muszą zależeć tylko od LL-NDK i VNDK-SP .

VNDK-SP to predefiniowany podzbiór odpowiednich bibliotek VNDK. Biblioteki VNDK-SP są dokładnie sprawdzane, aby upewnić się, że podwójne ładowanie bibliotek VNDK-SP do procesów ramowych nie powoduje problemów. Zarówno SP-HAL, jak i VNDK-SP są definiowane przez Google.

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

• libGLESv1_CM_${driver}.so
• libGLESv2_${driver}.so
• libGLESv3_${driver}.so
• libEGL_${driver}.so
• vulkan.${driver}.so
• [e-mail]
• [e-mail]

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 te biblioteki są nazywane VNDK-SP-Private i są niewidoczne dla SP-HALS.

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

• libft2.so (renderscript)
• libmediandk.so (Renderscript)

Uwaga: począwszy od Androida 12, interfejsy API RenderScript są przestarzałe. Będą nadal działać , ale oczekuje się, że producenci urządzeń i komponentów przestaną z czasem zapewniać obsługę akceleracji sprzętowej. Aby w pełni wykorzystać akcelerację GPU, AOSP zaleca migrację z RenderScript .

Wersjonowanie VNDK

Biblioteki współdzielone VNDK są wersjonowane:

• Właściwość systemowa ro.vndk.version jest automatycznie dodawana do /vendor/default.prop .
• Biblioteki udostępnione VNDK i VNDK-SP są instalowane jako wierzchołek VNDK com.android.vndk.v${ro.vndk.version} i montowane w /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ówne 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 ).

Pakiet testów dostawcy (VTS)

Android Vendor Test Suite (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 ) polegają na właściwości ro.vndk.version w celu załadowania pasujących zestawów danych odpowiednich bibliotek VNDK.