Omówienie natywnego pakietu do programowania dla sprzedawców (VNDK)

Natywny pakiet do programowania dla sprzedawców (VNDK) to zestaw bibliotek używanych przez inne biblioteki lub pliki binarne w przestrzeni sprzedawcy lub produktu w czasie działania na potrzeby dlopen.

Wycofanie

Interfejs Vendor NDK został wprowadzony w Androidzie 8.0, aby udostępniać interfejsy API między platformą a kodem dostawcy. VNDK jest z powodzeniem używany od wielu lat, ale ma pewne wady:

• Miejsce na dane
• Pojedynczy pakiet APEX VNDK zawiera wszystkie biblioteki VNDK, niezależnie od tego, czy są one używane na urządzeniu.
• GSI zawiera wiele wersji pakietów APEX VNDK, aby obsługiwać różne wersje obrazów dostawców.
• Możliwość aktualizacji
• Trudno jest aktualizować pakiety APEX VNDK oddzielnie od aktualizacji platformy.
• Obrazy dostawcy są często aktualizowane bezprzewodowo (OTA), co zmniejsza korzyści z pakowania VNDK w obrazie systemu.

Z tych powodów zdecydowaliśmy się wycofać VNDK począwszy od Androida 15.

Szczegóły wycofania VNDK

Wszystkie biblioteki VNDK są spakowane w APEX VNDK i zainstalowane w obrazie systemu (-ext). Wraz z wycofaniem VNDK poprzednie biblioteki VNDK są instalowane w obrazie dostawcy (lub produktu), tak samo jak inne biblioteki dostępne dla dostawcy. Te funkcje zostaną usunięte wraz z wycofaniem VNDK:

• VNDK APEX na Androida 15
• Właściwości systemu wskazujące wersję docelowego VNDK są usuwane, jeśli partycje dostawcy lub produktu są tworzone dla Androida 15:
  • ro.vndk.version
  • ro.product.vndk.version
• Optymalizacje VNDK nie będą dostępne, ponieważ nie ma VNDK:
  • TARGET_VNDK_USING_CORE_VARIANT w przypadku urządzeń z Androidem Go;
  • use_vndk_as_stable w przypadku APEX-ów dostawcy
• migawka dostawcy, która w dużym stopniu zależy od VNDK;

Wyjątki od wycofania

Wycofanie VNDK nie wpłynie na te funkcje:

• Pliki APEX VNDK w wersji 14 lub starszej, które są wymagane do obsługi istniejących obrazów dostawców.
• LL-NDK nie jest częścią VNDK.

Dlaczego VNDK?

AOSP umożliwia aktualizacje tylko platformy, w których partycję systemową można uaktualnić do najnowszej wersji platformy, a partycja dostawcy pozostaje bez zmian. Mimo że pliki binarne w każdej partycji są tworzone w różnym czasie, muszą ze sobą współpracować.

Aktualizacje obejmujące tylko platformę wiążą się z tymi problemami:

• Zależność między modułami platformy a modułami dostawcy. W wersjach Androida starszych niż 8.0 moduły w partycjach dostawcy i systemowej mogły się ze sobą łączyć. Zależności od modułów dostawców nałożyły jednak niepożądane ograniczenia na rozwój modułów platformy.
• Rozszerzenia bibliotek AOSP. Android wymaga, aby wszystkie urządzenia z Androidem przechodziły testy CTS, gdy partycja systemowa jest zastępowana standardowym podstawowym obrazem systemu (GSI). Jednak gdy dostawcy rozszerzają biblioteki AOSP, aby zwiększyć wydajność lub dodać dodatkowe funkcje do implementacji HIDL, wgranie partycji systemowej ze standardowym obrazem GSI może spowodować uszkodzenie implementacji HIDL dostawcy. Wskazówki dotyczące zapobiegania takim problemom znajdziesz w sekcji Rozszerzenia VNDK.

Aby rozwiązać te problemy, Android zawiera kilka funkcji, takich jak VNDK (opisany w tej sekcji), HIDL, hwbinder, nakładka drzewa urządzenia i nakładka sepolicy.

Warunki dotyczące VNDK

W dokumentach dotyczących VNDK używamy tych terminów:

• Moduły to biblioteki udostępnione lub pliki wykonywalne. Moduły tworzą zależności w czasie kompilacji.
• Procesy to zadania systemu operacyjnego wywoływane z plików wykonywalnych. Przetwarza zależności w czasie działania.
• Terminy kwalifikujące się do metodologii są powiązane z partycją system:
• Pliki wykonywalne platformy to pliki wykonywalne w /system/bin lub /system/xbin.
• Biblioteki udostępnione platformy to biblioteki udostępnione w sekcji/system/lib[64].
• Moduły platformy to zarówno biblioteki udostępnione platformy, jak i pliki wykonywalne platformy.
• Procesy platformy to procesy uruchamiane z plików wykonywalnych platformy, takich jak /system/bin/app_process.
• Terminy kwalifikowane przez dostawcę są powiązane z vendor partycjami:
• Pliki wykonywalne dostawcy to pliki wykonywalne w /vendor/bin
• Biblioteki udostępnione dostawcy to biblioteki udostępnione w sekcji /vendor/lib[64].
• Moduły dostawcy to zarówno pliki wykonywalne dostawcy, jak i biblioteki udostępnione dostawcy.
• Procesy dostawcy to procesy wywoływane przez pliki wykonywalne dostawcy, np. /vendor/bin/android.hardware.camera.provider@2.4-service.

Pojęcia związane z VNDK

W idealnym świecie Androida 8.0 i nowszych procesy platformy nie wczytują bibliotek współdzielonych dostawcy, wszystkie procesy dostawcy wczytują tylko biblioteki współdzielone dostawcy (i część bibliotek współdzielonych platformy), a komunikacja między procesami platformy i procesami dostawcy jest regulowana przez HIDL i binder sprzętowy.

W takim świecie może się zdarzyć, ż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 część bibliotek współdzielonych platformy była dostępna dla procesów dostawców. Ponadto wymagania dotyczące wydajności mogą prowadzić do kompromisów, dlatego niektóre interfejsy HAL, w przypadku których czas reakcji ma kluczowe znaczenie, muszą być traktowane inaczej.

W sekcjach poniżej opisano, jak VNDK obsługuje biblioteki współdzielone platformy dla dostawców i interfejsy HAL działające w tym samym procesie (SP-HAL).

Biblioteki udostępnione platformy dla dostawcy

W tej sekcji opisujemy kryteria klasyfikacji bibliotek współdzielonych, które są dostępne dla procesów dostawcy. Istnieją 2 sposoby obsługi modułów dostawcy w wielu wersjach Androida:

1. Stabilizacja interfejsów ABI/API bibliotek udostępnionych platformy. Nowe moduły platformy i stare moduły dostawcy mogą korzystać z tej samej biblioteki współdzielonej, aby zmniejszyć zajętość pamięci i rozmiar pamięci masowej. Unikalna biblioteka współużytkowana pozwala też uniknąć kilku problemów związanych z podwójnym ładowaniem. Jednak koszt utrzymania stabilnych interfejsów ABI/API jest wysoki i nie da się ustabilizować wszystkich interfejsów ABI/API eksportowanych przez każdą bibliotekę współdzieloną platformy.
2. Skopiuj biblioteki udostępnione starszej wersji platformy. Wprowadza silne ograniczenie dotyczące kanałów bocznych, czyli wszystkich mechanizmów komunikacji między modułami platformy a modułami dostawcy, w tym (między innymi) mechanizmów binder, socket, pipe, pamięci współdzielonej, pliku współdzielonego i właściwości systemu. Nie może być żadnej komunikacji, chyba że protokół komunikacyjny jest zamrożony i stabilny (np. HIDL przez hwbinder). Podwójne wczytywanie bibliotek współdzielonych może również 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ą interpretować obiekt w różny sposób.

W zależności od charakterystyki bibliotek udostępnionych stosuje się różne podejścia. W związku z tym biblioteki udostępnione platformy są podzielone na 3 podkategorie:

• Biblioteki LL-NDK to biblioteki współdzielone platformy, które są stabilne. Deweloperzy tych systemów dokładają wszelkich starań, aby zachować stabilność interfejsu API/ABI.
  • LL-NDK zawiera te 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 to biblioteki współdzielone platformy, które można bezpiecznie skopiować 2 razy. Moduły platformy i moduły dostawcy mogą się łączyć z własnymi kopiami. Biblioteka współdzielona frameworka może stać się kwalifikującą się biblioteką VNDK tylko wtedy, gdy spełnia te kryteria:
  • Nie wysyła ani nie odbiera komunikatów IPC do/z platformy.
  • Nie jest powiązana z maszyną wirtualną ART.
  • Nie odczytuje ani nie zapisuje plików/partycji o niestabilnych formatach.
  • Nie ma specjalnej licencji na oprogramowanie, która wymagałaby analizy prawnej.
  • Właściciel kodu nie ma zastrzeżeń co do wykorzystania go przez dostawców.
• Biblioteki tylko z platformą (FWK-ONLY) to biblioteki udostępniane w ramach platformy, które nie należą do kategorii wymienionych powyżej. Te biblioteki:
  • są uważane za wewnętrzne szczegóły implementacji platformy.
  • Nie może być dostępny dla modułów dostawcy.
  • mają niestabilne interfejsy ABI/API i nie gwarantują zgodności interfejsów API/ABI;
  • nie są kopiowane.

Warstwa HAL w tym samym procesie (SP-HAL)

HAL w tym samym procesie (SP-HAL) to zestaw predefiniowanych interfejsów HAL wdrożonych jako biblioteki współdzielone dostawcy i załadowanych do procesów platformy. SP-HAL są odseparowane przez przestrzeń nazw linkera (określa 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 wczytywanie bibliotek VNDK-SP do procesów frameworka nie powoduje problemów. Zarówno SP-HAL, jak i VNDK-SP są zdefiniowane przez Google.

Te biblioteki są zatwierdzonymi 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 plikach Android.bp. Jeśli określono też vndk: {private:true}, te biblioteki są nazywane VNDK-SP-Private i są niewidoczne dla SP-HALS.

Poniżej znajdziesz biblioteki tylko z platformą z wyjątkami RS (FWK-ONLY-RS):

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

Wersje VNDK

Biblioteki udostępnione VNDK są wersjonowane:

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

Wartość ro.vndk.version jest wybierana przez algorytm w sposób opisany poniżej:

• Jeśli BOARD_VNDK_VERSION nie jest równe current, użyj BOARD_VNDK_VERSION.
• Jeśli BOARD_VNDK_VERSION jest równe current:
• Jeśli PLATFORM_VERSION_CODENAME ma wartość REL, użyj PLATFORM_SDK_VERSION (np. 28).
• W przeciwnym razie użyj znaku PLATFORM_VERSION_CODENAME (np. P).

Vendor Test Suite (VTS)

Pakiet testów dostawcy Androida (VTS) wymaga niepustej właściwości ro.vndk.version. Zarówno nowo wprowadzone urządzenia, jak i urządzenia, które są uaktualniane, muszą definiować ro.vndk.version. Niektóre przypadki testowe VNDK (np. VtsVndkFilesTest i VtsVndkDependencyTest) korzystają z właściwości ro.vndk.version, aby wczytać pasujące kwalifikujące się zestawy danych bibliotek VNDK.