एनडीके (NDK) की मदद से बनाए गए मिडलवेयर को डिस्ट्रिब्यूट करने से, कुछ अन्य समस्याओं का सामना करना पड़ता है उन्हें इस बारे में चिंता करने की ज़रूरत नहीं है. पहले से बनी लाइब्रेरी, अपने उपयोगकर्ताओं पर लागू करने के कुछ विकल्पों को लागू करती हैं.
एपीआई लेवल और NDK वर्शन चुनना
आपके उपयोगकर्ता, आपके minSdkVersion से कम वर्शन का इस्तेमाल नहीं कर सकते. अगर आपके उपयोगकर्ताओं के ऐप्लिकेशन को एपीआई 21 पर चलाना ज़रूरी है, तो एपीआई 24 के लिए ऐप्लिकेशन नहीं बनाया जा सकता. उपयोगकर्ताओं के डिवाइसों के एपीआई लेवल से कम एपीआई लेवल के लिए लाइब्रेरी बनाना ठीक है. एपीआई के लिए बिल्ड बनाया जा सकता है 16 और आपके एपीआई 21 के उपयोगकर्ताओं के साथ काम करता रहेगा.
एनडीके वर्शन काफ़ी हद तक एक-दूसरे के साथ काम करते हैं. हालांकि, कभी-कभी कुछ ऐसे बदलाव जो काम करने की क्षमता को भंग करते हैं. अगर आपको पता है कि आपके सभी उपयोगकर्ता एनडीके (NDK) वाले वर्शन की तरह ही, उसी वर्शन का इस्तेमाल करें जो वे इस्तेमाल करते हैं. अगर ऐसा नहीं है, तो नया वर्शन इस्तेमाल करें.
एसटीएल का इस्तेमाल करना
अगर C++ प्रोग्राम लिखते समय STL का इस्तेमाल किया जा रहा है, तो शेयर की गई लाइब्रेरी को डिस्ट्रिब्यूट करने पर, libc++_shared
और libc++_static
में से किसी एक विकल्प को चुनने से आपके उपयोगकर्ताओं पर असर पड़ता है. अगर आपको
कोई शेयर की गई लाइब्रेरी वितरित करने के लिए, आपको या तो libc++_shared
का उपयोग करना होगा या यह पक्का करना होगा कि
libc++ के सिंबल आपकी लाइब्रेरी में नहीं दिखेंगे. ऐसा करने का सबसे अच्छा तरीका यह है कि वर्शन स्क्रिप्ट की मदद से, अपने एबीआई प्लैटफ़ॉर्म के बारे में साफ़ तौर पर बताएं.
लिंक करते समय -Wl,--exclude-libs,libc++_static.a
-Wl,--exclude-libs,libc++abi.a
का इस्तेमाल करना, एक और कम असरदार विकल्प है. यह कम असरदार होता है, क्योंकि
सिर्फ़ लाइब्रेरी में उन चिह्नों को छिपा देगा जिनके नाम साफ़ तौर पर दिए गए हैं, और
उन लाइब्रेरी के लिए निदान रिपोर्ट किए जाते हैं जिनका उपयोग नहीं किया जाता (लाइब्रेरी में टाइपिंग की गलती
नाम की वजह से कोई गड़बड़ी नहीं होती है और लाइब्रेरी की सूची को अप-टू-डेट रखने की ज़रूरत पड़ती है
आज तक). इस तरीके से, लागू करने की जानकारी भी छिपी नहीं रहती.
AAR में नेटिव लाइब्रेरी उपलब्ध कराना
'Android Gradle प्लग इन', यहां दी गई नेटिव डिपेंडेंसी इंपोर्ट कर सकता है एएआर. अगर आपके उपयोगकर्ता 'Android Gradle प्लग इन' का इस्तेमाल कर रहे हैं, तो यह इससे वे आसानी से आपकी लाइब्रेरी का इस्तेमाल कर सकते हैं.
नेटिव लाइब्रेरी को एएआर में पैकेज एजीपी. यह अगर आपकी लाइब्रेरी पहले से ही externalNativeBuild की मदद से बनाई गई है, तो इस विकल्प का इस्तेमाल करना सबसे आसान है.
नॉन-एजीपी बिल्ड, ndkports का इस्तेमाल कर सकते हैं. इसके अलावा, Prefab दस्तावेज़ में दिए गए निर्देशों का पालन करके, मैन्युअल तरीके से पैकेजिंग भी की जा सकती है. इससे, AAR की prefab/
सबडायरेक्ट्री बनाई जा सकती है.
JNI लाइब्रेरी के साथ Java मिडलवेयर
जिन Java लाइब्रेरी में JNI लाइब्रेरी शामिल होती हैं (दूसरे शब्दों में, जिन AAR में jniLibs
शामिल होता है) उन्हें इस बात का ध्यान रखना चाहिए कि उनमें शामिल JNI लाइब्रेरी, उपयोगकर्ता के ऐप्लिकेशन में मौजूद अन्य लाइब्रेरी से मेल न खाएं. उदाहरण के लिए, अगर AAR में libc++_shared.so
शामिल है, लेकिन वह libc++_shared.so
का कोई ऐसा वर्शन है जिसका इस्तेमाल ऐप्लिकेशन में नहीं किया जाता, तो APK में सिर्फ़ एक ही लाइब्रेरी इंस्टॉल होगी. इससे, ऐप्लिकेशन के सही तरीके से काम न करने की समस्या हो सकती है.
इसका सबसे भरोसेमंद समाधान है कि Java लाइब्रेरी में, ज़्यादा से ज़्यादा एक
JNI लाइब्रेरी (यह ऐप्लिकेशन के लिए भी अच्छी सलाह है). सभी डिपेंडेंसी, जिनमें
एसटीएल, लागू करने वाली लाइब्रेरी और वर्शन से स्टैटिक रूप से लिंक होना चाहिए
स्क्रिप्ट का इस्तेमाल, एबीआई प्लैटफ़ॉर्म को लागू करने के लिए किया जाना चाहिए. उदाहरण के लिए, JNI लाइब्रेरी libfooimpl.so
वाली Java लाइब्रेरी com.example.foo
को, वर्शन स्क्रिप्ट के तौर पर इस स्क्रिप्ट का इस्तेमाल करना चाहिए:
LIBFOOIMPL {
global:
JNI_OnLoad;
local:
*;
};
इस उदाहरण में, JNI_OnLoad
के ज़रिए registerNatives
का इस्तेमाल किया गया है, जैसा कि JNI के बारे में सलाह में बताया गया है. इससे यह पक्का किया जा सकता है कि कम से कम ABI प्लैटफ़ॉर्म को दिखाया जाए और लाइब्रेरी लोड होने में लगने वाला समय कम हो.