Rozpowszechnianie oprogramowania pośredniczącego utworzonego za pomocą NDK powoduje dodatkowe problemy, o które programiści aplikacji nie muszą się martwić. Gotowe biblioteki nakładają niektóre decydowania o wdrożeniu rozwiązań przez użytkowników.
Wybieranie poziomów interfejsu API i wersji NDK
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 C++ i używasz STL, wybór między libc++_shared a libc++_static wpływa na użytkowników, jeśli rozpowszechniasz współdzieloną bibliotekę. Jeśli rozpowszechniasz bibliotekę współdzieloną, musisz użyć libc++_shared lub upewnić się, że biblioteka nie udostępnia symboli z libc++. Aby to zrobić,
jawnie zadeklaruj interfejs ABI za pomocą skryptu wersji.
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 plikach AAR
Wtyczka Androida do obsługi Gradle może importować zależność natywną rozpowszechnianą w plikach 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 za pomocą 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.
Java middleware z bibliotekami JNI
Biblioteki Java, które zawierają biblioteki JNI (czyli pliki AAR zawierającejniLibs), muszą być tak zaprojektowane, aby biblioteki JNI, które zawierają, nie kolidowały z innymi bibliotekami w aplikacji użytkownika. Jeśli na przykład plik AAR zawieralibc++_shared.so, ale inną wersję niż ta używana w aplikacji, w pliku APK zostanie zainstalowana tylko jedna z nich, co może spowodować niestabilne działanie aplikacji.
Najbardziej niezawodne rozwiązanie polega na tym, aby biblioteki Java zawierały co najwyżej jedną bibliotekę JNI (ta rada dotyczy też aplikacji). Wszystkie zależności, w tym
Plik STL powinien być statycznie połączony z biblioteką implementacji, a wersja
do wymuszania interfejsu ABI. Na przykład biblioteka Javacom.example.foo, która zawiera bibliotekę JNI libfooimpl.so, powinna używać tego skryptu wersji:
LIBFOOIMPL {
global:
JNI_OnLoad;
local:
*;
};
W tym przykładzie używamy registerNatives przez JNI_OnLoad zgodnie z opisem w Wskazówki dotyczące JNI, aby zapewnić minimalną powierzchnię ABI i zminimalizować czas wczytywania biblioteki.