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 .

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
  • 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 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)

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.

,

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 .

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 dostawców. 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
  • 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 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)

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.

,

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 .

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
  • 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 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)

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.

,

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 .

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 dostawców. 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. A framework shared library can become an eligible VNDK library only if it satisfies the following criteria:
    • It does not send/receive IPCs to/from the framework.
    • It is not related to ART virtual machine.
    • It does not read/write files/partitions with unstable file formats.
    • It does not have special software license which requires legal reviews.
    • Its code owner does not have objections to vendor usages.
  • Framework-Only Libraries (FWK-ONLY) are Framework Shared Libraries that do not belong to the categories mentioned above. These libraries:
    • Are considered framework internal implementation details.
    • Must not be accessed by vendor modules.
    • Have unstable ABIs/APIs and no API/ABI compatibility guarantees.
    • Are not copied.

Same-Process HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) is a set of predetermined HALs implemented as Vendor Shared Libraries and loaded into Framework Processes . SP-HALs are isolated by a linker namespace (controls the libraries and symbols that are visible to the shared libraries). SP-HALs must depend only on LL-NDK and VNDK-SP .

VNDK-SP is a predefined subset of eligible VNDK libraries. VNDK-SP libraries are carefully reviewed to ensure double-loading VNDK-SP libraries into framework processes does not cause problems. Both SP-HALs and VNDK-SPs are defined by Google.

The following libraries are approved SP-HALs:

  • 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

VNDK-SP libraries specify vndk: { support_system_process: true } in their Android.bp files. If vndk: {private:true} is also specified, then these libraries are called VNDK-SP-Private and they are invisible to SP-HALS.

The following are framework-only libraries with RS exceptions (FWK-ONLY-RS) :

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

VNDK versioning

VNDK shared libraries are versioned:

  • The ro.vndk.version system property is automatically added to /vendor/default.prop .
  • VNDK and VNDK-SP shared libraries are installed as a VNDK apex com.android.vndk.v${ro.vndk.version} and mounted to /apex/com.android.vndk.v${ro.vndk.version} .

The value of ro.vndk.version is chosen by the algorithm below:

  • If BOARD_VNDK_VERSION is not equal to current , use BOARD_VNDK_VERSION .
  • If BOARD_VNDK_VERSION is equal to current :
    • If PLATFORM_VERSION_CODENAME is REL , use PLATFORM_SDK_VERSION (eg 28 ).
    • Otherwise, use PLATFORM_VERSION_CODENAME (eg P ).

Vendor Test Suite (VTS)

The Android Vendor Test Suite (VTS) mandates a non-empty ro.vndk.version property. Both newly-launched devices and upgrading devices must define ro.vndk.version . Some VNDK test cases (eg VtsVndkFilesTest and VtsVndkDependencyTest ) rely on the ro.vndk.version property to load the matching eligible VNDK libraries data sets.