NDK ile oluşturulan ara katman yazılımlarının dağıtılması, endişelenmesine gerek yok. Önceden oluşturulmuş kitaplıklar hakkında daha fazla bilgi edindiniz.
API seviyelerini ve NDK sürümlerini seçme
Kullanıcılarınız sizinkinden daha düşük bir minSdkVersion kullanamaz. Kullanıcılarınızın uygulamalar API 21'de çalıştırmanız gerekiyorsa API 24 için derleme yapamazsınız. Kendilerinizi kullanıcılarınıza göre daha düşük API düzeyi için sunulur. API için 16'yı kullanmaya devam edebilir ve API 21 kullanıcılarınızla uyumlu olmaya devam edebilirsiniz.
NDK sürümleri birbirleriyle büyük ölçüde uyumludur, ancak zaman zaman veya uyumluluğu bozan değişiklikler olabilir. Tüm kullanıcılarınızın ile aynı sürümü kullanmak en iyisidir. Aksi takdirde en yeni sürümü kullanın.
STL'yi kullanma
C++ yazıyor ve STL kullanıyorsanız libc++_shared ve STL
Paylaşılan bir kitaplık dağıtıyorsanız libc++_static kullanıcılarınızı etkiler. Şu durumda:
paylaşılan bir kitaplığı dağıtıyorsanız libc++_shared kullanmanız veya
libc++ simgeleri kitaplığınızda gösterilmez. Bunu yapmanın en iyi yolu
ABI yüzeyinizi bir sürüm komut dosyasıyla açıkça bildirin (bu aynı zamanda
uygulama ayrıntılarınızı gizli tutabilirsiniz). Örneğin, basit bir aritmetik kütüphanesi
aşağıdaki sürüm komut dosyasına sahip olabilir:
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:
*;
};
En sağlam seçenek olduğu için tercih edilen seçenek, sürüm komut dosyasıdır. kontrol etmenin bir yoludur. Bu, paylaşılan tüm kullanıcılar için en iyi uygulamadır arasında bağlantı oluşturarak, uygulama ayrıntılarınızın ve yükleme süresini kısaltır.
Daha az güvenilir başka bir seçenek de bağlantı oluştururken -Wl,--exclude-libs,libc++_static.a
-Wl,--exclude-libs,libc++abi.a kullanmaktır. Bu yaklaşım daha az güvenilirdir çünkü
yalnızca açıkça adlandırılmış kitaplıklardaki simgeleri gizler ve
kullanılmayan kitaplıklar için teşhisler raporlanır (kitaplıkta bir yazım hatası vardır)
ad bir hata değildir ve kullanıcının kütüphane listesini güncel tutma sorumluluğudur
) sağlar. Bu yaklaşım, kendi uygulama ayrıntılarınızı da gizlemez.
AAR'larda yerel kitaplıkları dağıtma
Android Gradle eklentisi şurada dağıtılan yerel bağımlılıkları içe aktarabilir: AAR'ler. Kullanıcılarınız Android Gradle eklentisini kullanıyorsa bu eklenti, en kolay yolunu sunuyor.
Yerel kitaplıklar, AAR içine paketlenebilir AGP. Bu, kitaplığınız zaten externalNativeBuild tarafından oluşturulmuşsa en kolay seçenektir.
AGP olmayan derlemeler ndkport kullanabilir veya aşağıdaki adımları uygulayarak manuel paketleme gerçekleştirebilir:
AAR'lerinin prefab/ alt dizinini oluşturmak için Prefab belgesini kullanmalıdır.
JNI kitaplıklarıyla Java ara katman yazılımları
JNI kitaplıkları (başka bir deyişle,
jniLibs) kullanıyorsanız, bu sonuçlardaki JNI kitaplıklarının
kullanıcının uygulamasındaki diğer kitaplıklarla çakışır. Örneğin, AAR
libc++_shared.so, ancak uygulamadan farklı bir libc++_shared.so sürümü
bu durumlardan biri APK'ya yüklenir ve bu durum,
gösterir.
En güvenilir çözüm, Java kitaplıklarının en fazla bir kod içermesidir
JNI kitaplığı (bu, uygulamalar için de iyi bir öneridir). dahil olmak üzere tüm bağımlılıklar
STL, uygulama kitaplığına statik olarak bağlı olmalıdır. Ayrıca,
komut dosyası, ABI yüzeyini uygulamak için kullanılmalıdır. Örneğin, bir Java kitaplığının
libfooimpl.so JNI kitaplığını içeren com.example.foo şunları kullanmalıdır:
aşağıdaki sürüm komut dosyası:
LIBFOOIMPL {
global:
JNI_OnLoad;
local:
*;
};
Bu örnekte, JNI İpuçları'nda açıklandığı gibi JNI_OnLoad aracılığıyla registerNatives kullanılmaktadır
minimum ABI yüzeyinin açığa çıkmasını ve kitaplık yükleme süresinin
simge durumuna küçültülmüştür.