Omówienie pakietu VNDK (Vendor Native Development Kit)

Natywny pakiet do programowania dla sprzedawców (VNDK) to zestaw bibliotek używanych przez inne biblioteki lub pliki binarne w partycji dostawcy lub produktu w czasie wykonywania funkcji dlopen().

Wycofanie

Dostawca NDK został wprowadzony w Androidzie 8.0 w celu zapewnienia interfejsów API między platformą a kodem dostawcy. Chociaż VNDK jest używany od wielu lat, ma pewne wady:
  • Miejsce na dane
    • Pojedynczy pakiet VNDK APEX zawiera wszystkie biblioteki VNDK, niezależnie od tego, czy są używane na urządzeniu.
    • GSI zawiera wiele wersji VNDK APEX, aby obsługiwać wiele wersji obrazów dostawcy.
  • Możliwość aktualizacji
    • Trudno jest aktualizować APEX-y VNDK oddzielnie od aktualizacji platformy.
    • Obrazy dostawcy są często aktualizowane bezprzewodowo (OTA), co zmniejsza korzyści płynące z zapakowania VNDK w obraz systemu.
Ze względu na te problemy zdecydowaliśmy się wycofać pakiet VNDK z Androidem 15.

Szczegóły dotyczące wycofania VNDK

Wszystkie biblioteki VNDK są pakowane w VNDK APEX i instalowane w ramach obrazu systemu (-ext). W związku z wycofaniem VNDK biblioteki VNDK są instalowane w ramach obrazu dostawcy (lub produktu) tak samo jak inne biblioteki dostępne dla dostawcy. Te funkcje są usuwane wraz z wycofaniem VNDK:
  • VNDK APEX na Androida 15
  • Właściwości systemowe wskazujące wersję docelowego VNDK są usuwane, jeśli partycje dostawcy lub produktu są kompilowane na potrzeby 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 na urządzeniach z Androidem Go
    • use_vndk_as_stable dla grup APEX dostawcy
  • migawka dostawcy, która jest silnie zależna od VNDK;

Wyjątki od wycofania

Po wycofaniu VNDK te funkcje nie ulegną zmianie:
  • VNDK APEX w wersji 14 lub starszej, która jest wymagana do obsługi dotychczasowych obrazów dostawcy.
  • LL-NDK nie jest częścią VNDK.

Dlaczego VNDK?

AOSP umożliwia aktualizacje tylko frameworku, w których partycja systemu może zostać zaktualizowana do najnowszej wersji frameworku, a partycja dostawcy pozostaje bez zmian. Chociaż pliki binarne w każdej partycji są tworzone w różnych momentach, muszą ze sobą współpracować.

Aktualizacje dotyczące tylko frameworka obejmują te problemy:

  • Zależność między modułami platformy a modułami dostawców. Przed Androidem 8.0 moduły na partycji dostawcy i systemu mogły się ze sobą łączyć. Zależności od modułów dostawców nałożyły jednak niepożądane ograniczenia na tworzenie modułów platformy.
  • Rozszerzenia bibliotek AOSP. Android wymaga, aby wszystkie urządzenia z Androidem przeszły test CTS, gdy partycja systemowa zostanie zastąpiona standardowym obrazem systemu GSI. Jednak ponieważ producenci rozszerzają biblioteki AOSP, aby zwiększyć wydajność lub dodać dodatkowe funkcje do swoich implementacji HIDL, przeflashowanie partycji systemowej za pomocą standardowego GSI może spowodować uszkodzenie implementacji HIDL przez producenta. Wskazówki zapobiegania takim awariom 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ądzeń i nakładka sepolicy.

Warunki dotyczące VNDK

W dokumentach związanych z VNDK używana jest ta terminologia:
  • Moduły odnoszą się do bibliotek udostępnionych lub plików wykonywalnych. moduły tworzą zależności na etapie kompilacji;
  • Procesy to zadania systemu operacyjnego utworzone z plików wykonywalnych. Procesy tworzą zależności w czasie wykonywania.
  • Terminy kwalifikowane przez platformy są związane z partycją system:
    • Pliki wykonywalne frameworka to pliki wykonywalne w folderze /system/bin lub /system/xbin.
    • Biblioteki udostępnione frameworku to zasoby wspólne w sekcji /system/lib[64].
    • Moduły frameworku odnoszą się zarówno do bibliotek udostępnionych frameworku, jak i plików wykonywalnych frameworku.
    • Procesy związane z ramami to procesy utworzone z wykonalnych plików ramowych, takich jak /system/bin/app_process.
  • Warunki kwalifikowania się do dostawcy dotyczą następujących podziałów:vendor
    • Pliki wykonywalne dostawcy to pliki wykonywalne w folderze /vendor/bin
    • Biblioteki udostępnione dostawców odnoszą się do bibliotek udostępnionych w sekcji /vendor/lib[64].
    • Moduły dostawcy odnoszą się zarówno do plików wykonywalnych dostawcy, jak i do bibliotek wspólnych dostawcy.
    • Procesy dostawcy to procesy utworzone z plików wykonywalnych dostawcy, takich jak /vendor/bin/android.hardware.camera.provider@2.4-service.

Pojęcia związane z VNDK

W idealnym świecie w systemie Android 8.0 lub nowszym procesy frameworku nie wczytują bibliotek współdzielonych dostawcy, wszystkie procesy dostawcy wczytują tylko biblioteki współdzielone dostawcy (oraz część bibliotek współdzielonych frameworku), a komunikacja między procesami frameworku a procesami dostawcy jest regulowana przez HIDL i binder sprzętowy.

W takim świecie stabilne, publiczne interfejsy API z bibliotek współdzielonych frameworku mogą nie wystarczyć deweloperom modułów dostawców (chociaż interfejsy API mogą się zmieniać między wersjami Androida), co wymaga, aby część bibliotek współdzielonych frameworku była dostępna dla procesów dostawców. Dodatkowo, ponieważ wymagania dotyczące wydajności mogą prowadzić do kompromisów, niektóre HAL-e o krytycznym czasie odpowiedzi muszą być traktowane inaczej.

W następnych sekcjach opisano szczegółowo, jak VNDK obsługuje biblioteki udostępniane przez framework dla dostawców i interfejsy HAL w ramach tego samego procesu (SP-HAL).

Biblioteki udostępnione w ramach frameworku dla dostawcy

W tej sekcji opisano kryteria klasyfikacji udostępnionych bibliotek, które są dostępne dla procesów dostawców. Istnieją 2 metody obsługi modułów dostawców w różnych wersjach Androida:

  1. Stabilizacja ABI-ów/interfejsów API bibliotek udostępnionych frameworka. Nowe moduły frameworku i starsze moduły dostawców mogą korzystać z tej samej wspólnej biblioteki, aby zmniejszyć obciążenie pamięci i rozmiar pamięci masowej. Unikalna biblioteka współdzielona zapobiega też kilku problemom związanym z podwójnym wczytywaniem. Jednak koszty rozwoju i utrzymania stabilnych ABI/interfejsów API są wysokie, a stabilizacja wszystkich ABI/interfejsów API eksportowanych przez każdą bibliotekę wspólną frameworku jest nierealna.
  2. Skopiuj biblioteki udostępnione starego frameworka. Oznacza to silne ograniczenie dotyczące kanałów bocznych, czyli wszystkich mechanizmów komunikacji między modułami frameworku i modułami dostawców, w tym między innymi binder, socket, pipe, współdzielona pamięć, współdzielony plik i właściwości systemu. Nie może być żadnej komunikacji, chyba że protokół komunikacji jest zamrożony i stabilny (np. HIDL przez hwbinder). Podwójne wczytywanie bibliotek współdzielonych może też powodować problemy. Jeśli na przykład obiekt utworzony przez nową bibliotekę zostanie przekazany do funkcji ze starej biblioteki, może wystąpić błąd, ponieważ te biblioteki mogą interpretować obiekt w inny sposób.

W zależności od właściwości komponentów wspólnych stosuje się różne podejścia. W związku z tym biblioteki udostępnione w ramach są podzielone na 3 podkategorie:

  • Biblioteki LL-NDK to biblioteki udostępnione w ramach platformy, o których wiadomo, że są stabilne. Ich deweloperzy są zobowiązani do utrzymywania stabilności interfejsu API i 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.
  • Odpowiednie biblioteki VNDK (VNDK) to biblioteki udostępnione w ramach frameworka, które można bezpiecznie skopiować dwukrotnie. Moduły frameworka i Moduły dostawcy mogą łączyć się z własnymi kopiami. Biblioteka współdzielona frameworku może stać się odpowiednią biblioteką VNDK tylko wtedy, gdy spełnia te kryteria:
    • Nie wysyła ani nie odbiera IPC do lub z ramy.
    • Nie jest to związane z maszyną wirtualną ART.
    • Nie obsługuje odczytu ani zapisu plików/partycji o niestabilnych formatach.
    • Nie ma specjalnej licencji na oprogramowanie, która wymaga sprawdzenia pod kątem zgodności z prawem.
    • Właściciel kodu nie ma zastrzeżeń do używania kodu przez dostawców.
  • Biblioteki tylko dla platformy (FWK-ONLY) to biblioteki udostępnione przez platformę, które nie należą do wymienionych powyżej kategorii. Te biblioteki:
    • są uważane za szczegóły implementacji wewnętrznej frameworka;
    • Nie mogą być dostępne dla modułów dostawców.
    • mieć niestabilne interfejsy ABI/API i nie są gwarantowane zgodności z tymi interfejsami;
    • nie są kopiowane.

Same-Process HAL (SP-HAL)

HAL w tym samym procesie (SP-HAL) to zestaw wstępnie określonych bibliotek HAL, które są implementowane jako biblioteki współdzielone dostawcy i ładowane do procesów frameworka. Pliki SP-HAL są izolowane za pomocą przestrzeni nazw linkera (kontroluje biblioteki i symbole widoczne dla zasobów wspólnych). Listy SP-HAL zależą tylko od LL-NDK i VNDK-SP.

VNDK-SP to wstępnie zdefiniowany 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 frameworku nie powoduje problemów. Zarówno interfejsy SP-HAL, jak i VNDK-SP są definiowane przez Google.

Te biblioteki są zatwierdzonymi bibliotekami HAL dla usług płatnych:

  • 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}, biblioteki te są wywoływane jako VNDK-SP-Private i są niewidoczne dla SP-HALS.

Oto biblioteki wyłącznie ramowe z wyjątkami RS (FWK-ONLY-RS):

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

Wersje VNDK

Biblioteki udostępnione VNDK są powiązane z wersjami:

  • Właściwość systemowa ro.vndk.version zostanie automatycznie dodana do elementu /vendor/default.prop.
  • Biblioteki udostępnione VNDK i VNDK-SP są instalowane jako szczyt 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 ten sposób:

  • Jeśli BOARD_VNDK_VERSION nie równa się current, użyj BOARD_VNDK_VERSION.
  • Jeśli BOARD_VNDK_VERSION równa się 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).

Vendor Test Suite (VTS)

Android Vendor Test Suite (VTS) wymaga niepustej właściwości ro.vndk.version. Zarówno nowo wprowadzone urządzenia, jak i urządzenia uaktualniające muszą definiować zasadę ro.vndk.version. Niektóre przypadki testów VNDK (np. VtsVndkFilesTest i VtsVndkDependencyTest) polegają na wczytaniu przez usługę ro.vndk.version odpowiednich zestawów danych bibliotek VNDK.