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
NDK dostawcy 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 VNDK APEX 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 dostawcy.
- 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.
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.versionro.product.vndk.version
- Optymalizacje VNDK nie będą dostępne, ponieważ nie ma VNDK:
TARGET_VNDK_USING_CORE_VARIANTw przypadku urządzeń z Androidem Go;use_vndk_as_stablew 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 partycja systemowa może zostać uaktualniona do najnowszej wersji platformy, a partycja dostawcy pozostaje bez zmian. Mimo że pliki binarne w każdej partycji są tworzone w różnych momentach, 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, flashowanie partycji systemowej za pomocą standardowego obrazu 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 platformy są powiązane z partycją
system: - Pliki wykonywalne platformy to pliki wykonywalne w
/system/binlub/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 wywoływane z plików wykonywalnych platformy, np.
/system/bin/app_process. - Terminy kwalifikowane przez dostawcę są powiązane z
vendorpartycjami: - 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 wygenerowane z plików wykonywalnych 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ę okazać, że stabilne, publiczne interfejsy API z bibliotek udostępnianych przez platformę nie są wystarczające dla deweloperów modułów dostawców (chociaż interfejsy API mogą się zmieniać między wersjami Androida), co wymaga, aby część bibliotek udostępnianych przez platformę 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 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:
- 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ć wykorzystanie pamięci i rozmiar pamięci. Unikalna biblioteka współużytkowana pozwala też uniknąć kilku problemów związanych z podwójnym ładowaniem. Koszt utrzymania stabilnych interfejsów ABI/API jest jednak wysoki i nie da się ustabilizować wszystkich interfejsów ABI/API eksportowanych przez każdą bibliotekę udostępnianą w ramach.
- 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, np. 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. Ich deweloperzy 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.soilibvulkan.so.
- LL-NDK zawiera te biblioteki:
- 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ą być połączone 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 w niestabilnych formatach.
- Nie ma specjalnej licencji na oprogramowanie, która wymagałaby weryfikacji prawnej.
- Właściciel kodu nie ma zastrzeżeń co do jego wykorzystania przez dostawców.
- Biblioteki tylko z platformą (FWK-ONLY) to biblioteki współdzielone 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 przez dostawcę i załadowanych do procesów platformy. SP-HAL są odseparowane 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 upewnić się, ż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 bibliotekami SP-HAL:
libGLESv1_CM_${driver}.solibGLESv2_${driver}.solibGLESv3_${driver}.solibEGL_${driver}.sovulkan.${driver}.soandroid.hardware.renderscript@1.0-impl.soandroid.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.versionjest automatycznie dodawana do/vendor/default.prop. - Biblioteki współdzielone VNDK i VNDK-SP są instalowane jako pakiet APEX 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 algorytm w sposób opisany poniżej:
- Jeśli
BOARD_VNDK_VERSIONnie jest równecurrent, użyjBOARD_VNDK_VERSION. - Jeśli
BOARD_VNDK_VERSIONjest równecurrent: - Jeśli
PLATFORM_VERSION_CODENAMEma wartośćREL, użyjPLATFORM_SDK_VERSION(np.28). - W przeciwnym razie użyj znaku
PLATFORM_VERSION_CODENAME(np.P).
Vendor Test Suite (VTS)
Pakiet Android Vendor Test Suite (VTS) wymaga, aby właściwość ro.vndk.version nie była pusta. Zarówno nowo wprowadzone na rynek urządzenia, jak i urządzenia, które są uaktualniane, muszą określać wartość 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ę zbiory danych bibliotek VNDK.