Porady dla dostawców oprogramowania pośredniczącego

Dystrybucja oprogramowania pośredniczącego utworzonego za pomocą NDK rodzi dodatkowe problemy, deweloperzy aplikacji nie muszą się martwić. Gotowe biblioteki nakładają niektóre decydowania o wdrożeniu rozwiązań przez użytkowników.

Wybór poziomów API i wersji NDK

Twoi użytkownicy nie mogą używać wartości minSdkVersion niższej niż Twoja. Jeśli użytkownicy aplikacje musi działać na interfejsie API 21, nie możesz kompilować dla API 24. Ciesz się tym, że na niższym poziomie interfejsu API niż użytkownicy. Możesz tworzyć pod kątem interfejsu API 16 i zachować zgodność z użytkownikami interfejsu API 21.

Wersje NDK są ze sobą w dużej mierze zgodne, ale czasami zdarzają się które zakłócają zgodność. Jeśli wiesz, że wszyscy użytkownicy dlatego zalecamy korzystanie z tej samej wersji co NDK. W przeciwnym razie użyj najnowszej wersji.

Korzystanie z STL

Jeśli piszesz w języku C++ i używasz języka STL, możesz wybrać między libc++_shared a Jeśli rozpowszechniasz bibliotekę udostępnioną, libc++_static ma wpływ na użytkowników. Jeśli rozpowszechniasz bibliotekę udostępnioną, musisz użyć narzędzia libc++_shared lub upewnić się, że Symbole libc++ nie są widoczne w Twojej bibliotece. Aby to zrobić, jawnie zadeklaruj interfejs ABI za pomocą skryptu wersji (pomoże to również prywatne informacje o implementacji). Może to być na przykład prosta biblioteka arytmetyczna może zawierać następujący skrypt wersji:

LIBMYMATH {
global:
    add;
    sub;
    mul;
    div;
    # C++ symbols in an extern block will be mangled automatically. See
    # https://stackoverflow.com/a/21845178/632035 for more examples.
    extern "C++" {
        "pow(int, int)";
    }
local:
    *;
};

Skrypt wersji powinien być preferowaną opcją, ponieważ jest najbardziej niezawodną opcją aby kontrolować widoczność symboli. Jest to sprawdzona metoda w przypadku wszystkich udostępnionych za pomocą bibliotek oprogramowania pośredniczącego, ponieważ uniemożliwia to szczegóły implementacji są lepiej widoczne i przyspieszają wczytywanie.

Inną, mniej zaawansowaną opcją jest użycie do łączenia kont interfejsu -Wl,--exclude-libs,libc++_static.a -Wl,--exclude-libs,libc++abi.a. Jest to mniej niezawodne, ponieważ ukrywa tylko symbole w bibliotekach, które mają jawne nazwy. w przypadku nieużywanych bibliotek (błędna literówka w bibliotece) nie jest błędem, a ciężar spoczywa na użytkowniku, który musi dbać o aktualność listy biblioteki. do chwili obecnej). To podejście nie ukrywa też szczegółów Twojej implementacji.

Dystrybucja bibliotek natywnych w aplikacjach AAR

Wtyczka Androida do obsługi Gradle może importować zależności natywne rozproszone w AAR. Jeśli użytkownicy używają wtyczki Androida do obsługi Gradle, będzie to To najprostszy sposób na korzystanie z Twojej biblioteki.

Biblioteki natywne można spakować do pliku AAR przez AGP. Będzie to Najłatwiejsza opcja, jeśli biblioteka została już utworzona przez externalNativeBuild.

Kompilacje inne niż AGP mogą używać polecenia ndkports lub ręcznie pakować się zgodnie z Dokumentacja Prefab pozwalająca utworzyć podkatalog prefab/ dla AAR.

Oprogramowanie pośredniczące Java z bibliotekami JNI

biblioteki Java, które obejmują biblioteki JNI (czyli biblioteki AAR zawierające jniLibs) pamiętaj, że biblioteki JNI, które do nich należą, nie będą powodują konflikt z innymi bibliotekami w aplikacji użytkownika. Na przykład, jeśli raport AAR zawiera libc++_shared.so, ale inna wersja libc++_shared.so niż aplikacja tylko jeden z nich zostanie zainstalowany w pakiecie APK, co może prowadzić do niestabilności zachowanie użytkownika.

Najbardziej niezawodnym rozwiązaniem jest dodanie do bibliotek Javy maksymalnie jednego Biblioteka JNI (jest to także dobra porada w przypadku aplikacji). Wszystkie zależności, w tym Plik STL powinien być statycznie połączony z biblioteką implementacji, a wersja do wymuszania interfejsu ABI. Może to być np. biblioteka Java, Komponent com.example.foo, który zawiera bibliotekę JNI libfooimpl.so, powinien korzystać z biblioteki następujący skrypt wersji:

LIBFOOIMPL {
global:
    JNI_OnLoad;
local:
    *;
};

W tym przykładzie użyto registerNatives za pomocą JNI_OnLoad, jak opisano w wskazówkach JNI. aby minimalna powierzchnia ABI była widoczna, a czas wczytywania biblioteki zminimalizowane.