मिडलवेयर वेंडर के लिए सलाह

एनडीके (NDK) की मदद से बनाए गए मिडलवेयर को डिस्ट्रिब्यूट करने से, कुछ अन्य समस्याओं का सामना करना पड़ता है उन्हें इस बारे में चिंता करने की ज़रूरत नहीं है. पहले से बनी लाइब्रेरी में कुछ चीज़ें लागू होती हैं लागू करने के विकल्पों को अपने उपयोगकर्ताओं की ज़रूरतों को ध्यान में रखकर बनाया जा सकता है.

एपीआई लेवल और एनडीके वर्शन चुनना

आपके उपयोगकर्ता आपसे पहले के minSdkVersion का इस्तेमाल नहीं कर सकते. अगर आपके उपयोगकर्ताओं की देखें एपीआई 21 पर चलाने की ज़रूरत नहीं है, लेकिन एपीआई 24 के लिए बिल्ड नहीं किया जा सकता. अपने ऑडियंस को आपके उपयोगकर्ताओं की तुलना में निम्न API स्तर की लाइब्रेरी उपलब्ध है. एपीआई के लिए बिल्ड बनाया जा सकता है 16 और आपके एपीआई 21 के उपयोगकर्ताओं के साथ काम करता रहेगा.

एनडीके वर्शन काफ़ी हद तक एक-दूसरे के साथ काम करते हैं. हालांकि, कभी-कभी कुछ ऐसे बदलाव जो काम करने की क्षमता को भंग करते हैं. अगर आपको पता है कि आपके सभी उपयोगकर्ता एनडीके (NDK) वाले वर्शन की तरह ही, उसी वर्शन का इस्तेमाल करें जो वे इस्तेमाल करते हैं. अगर ऐसा नहीं है, तो नया वर्शन इस्तेमाल करें.

एसटीएल का इस्तेमाल करना

अगर C++ लिखा जा रहा है और STL का इस्तेमाल किया जा रहा है, तो libc++_shared और अगर आप शेयर की गई लाइब्रेरी शेयर करते हैं, तो libc++_static आपके उपयोगकर्ताओं पर असर डालता है. अगर आपको कोई शेयर की गई लाइब्रेरी वितरित करने के लिए, आपको या तो libc++_shared का उपयोग करना होगा या यह पक्का करना होगा कि libc++ के सिंबल आपकी लाइब्रेरी में नहीं दिखेंगे. ऐसा करने का सबसे अच्छा तरीका यह है कि वर्शन स्क्रिप्ट के साथ आपके एबीआई सरफ़ेस के बारे में साफ़ तौर पर जानकारी देगा (इससे यह भी रखने में मदद मिलती है आपकी लागू करने की जानकारी को निजी रखा जाता है). उदाहरण के लिए, अंकगणित की एक सरल लाइब्रेरी इनमें वर्शन स्क्रिप्ट हो सकती है:

ध्यान दें: अगर स्टैटिक लाइब्रेरी डिस्ट्रिब्यूट की जाती है, तो इससे कोई फ़र्क़ नहीं पड़ता कि आपने एक स्टैटिक या शेयर किया गया STL, क्योंकि स्टैटिक लाइब्रेरी में कुछ भी लिंक नहीं किया गया है. किसी उपयोगकर्ता उनके ऐप्लिकेशन में मौजूद किसी भी विकल्प को लिंक कर सकते हैं. उन्हें कुछ लिंक करना होगा, यहां तक कि सिर्फ़ 'सी' कैटगरी वाले उपभोक्ताओं के लिए भी, इसलिए यह पक्का करें कि यह ज़रूरी है और एनडीके के वर्शन का इस्तेमाल इसलिए किया गया था, ताकि एसटीएल वर्शन के साथ काम न करने की स्थिति में उसे बनाया जा सके.

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:
    *;
};

वर्शन स्क्रिप्ट को प्राथमिकता दी जानी चाहिए, क्योंकि यह सबसे मज़बूत सिंबल की विज़िबिलिटी को कंट्रोल करने का तरीका है. यह सभी शेयर किए गए उपयोगकर्ताओं के लिए सबसे सही तरीका है लाइब्रेरी, मिडलवेयर या नहीं भेज सकते, क्योंकि यह आपके लागू करने के ब्यौरे को और लोड होने में लगने वाले समय को कम करता है.

एक और कम मज़बूत विकल्प, खाते को लिंक करते समय -Wl,--exclude-libs,libc++_static.a -Wl,--exclude-libs,libc++abi.a का इस्तेमाल करना है. यह कम असरदार होता है, क्योंकि सिर्फ़ लाइब्रेरी में उन चिह्नों को छिपा देगा जिनके नाम साफ़ तौर पर दिए गए हैं, और उन लाइब्रेरी के लिए निदान रिपोर्ट किए जाते हैं जिनका उपयोग नहीं किया जाता (लाइब्रेरी में टाइपिंग की गलती नाम की वजह से कोई गड़बड़ी नहीं होती है और लाइब्रेरी की सूची को अप-टू-डेट रखने की ज़रूरत पड़ती है आज तक). यह तरीका, लागू करने की आपकी जानकारी को भी नहीं छिपाता.

एएआर में नेटिव लाइब्रेरी डिस्ट्रिब्यूट करना

ध्यान दें: इस सेक्शन में, उपयोगकर्ताओं को C/C++ एपीआई डिस्ट्रिब्यूट करने का तरीका बताया गया है. अगर आपके नेटिव लाइब्रेरी आपके Java API को लागू करने की जानकारी होती हैं. इसके लिए, Java जेएनआई लाइब्रेरी वाला मिडलवेयर सेक्शन.

'Android Gradle प्लग इन', डिलीवर की गई नेटिव डिपेंडेंसी इंपोर्ट कर सकता है एएआर. अगर आपके उपयोगकर्ता 'Android Gradle प्लग इन' का इस्तेमाल कर रहे हैं, तो यह इससे वे आसानी से आपकी लाइब्रेरी का इस्तेमाल कर सकते हैं.

नेटिव लाइब्रेरी को एएआर में पैकेज एजीपी. यह अगर आपकी लाइब्रेरी पहले से ही externalNativeBuild की मदद से बनाई गई है, तो इस विकल्प का इस्तेमाल करना सबसे आसान है.

गैर-एजीपी बिल्ड में ndkports का इस्तेमाल किया जा सकता है या इनकी मदद से मैन्युअल पैकेजिंग की जा सकती है: AAR की prefab/ सबडायरेक्ट्री बनाने के लिए, प्रीफ़ैब दस्तावेज़.

JNI लाइब्रेरी के साथ Java मिडलवेयर

ऐसी Java लाइब्रेरी जिनमें JNI लाइब्रेरी शामिल हों (दूसरे शब्दों में, AAR jniLibs) को सावधान रहना होगा कि जिन JNI लाइब्रेरी को शामिल किया गया है वे उपयोगकर्ता के ऐप्लिकेशन में अन्य लाइब्रेरी को टक्कर देता है. उदाहरण के लिए, अगर AAR में libc++_shared.so, लेकिन ऐप्लिकेशन से अलग libc++_shared.so का वर्शन इस्तेमाल करता है, तो APK पर सिर्फ़ एक को इंस्टॉल किया जाएगा और जिसकी वजह से व्यवहार.

चेतावनी: गड़बड़ी 141758241: 'Android Gradle प्लग इन' के पुराने वर्शन अभी इस गड़बड़ी की स्थिति का निदान करें. समान नाम वाली लाइब्रेरी में से एक APK में पैकेजिंग के लिए अपने-आप चुना जा सकता है.

इसका सबसे भरोसेमंद समाधान है कि Java लाइब्रेरी में, ज़्यादा से ज़्यादा एक JNI लाइब्रेरी (यह ऐप्लिकेशन के लिए भी अच्छी सलाह है). सभी डिपेंडेंसी, जिनमें एसटीएल, लागू करने वाली लाइब्रेरी और किसी वर्शन से स्टैटिक रूप से लिंक होना चाहिए स्क्रिप्ट का इस्तेमाल, एबीआई प्लैटफ़ॉर्म को लागू करने के लिए किया जाना चाहिए. उदाहरण के लिए, Java लाइब्रेरी com.example.foo जिसमें JNI लाइब्रेरी शामिल है libfooimpl.so उसका उपयोग करना चाहिए वर्शन स्क्रिप्ट का पालन करें:

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

इस उदाहरण में, JNI_OnLoad के ज़रिए registerNatives का इस्तेमाल किया गया है, जैसा कि जेएनआई सलाह में बताया गया है यह पक्का किया जा सकेगा कि एबीआई की कम से कम सतह खुल गई है और लाइब्रेरी के लोड होने में लगने वाला समय है छोटा किया गया.