Android.mk

इस पेज पर, उस Android.mk बिल्ड फ़ाइल के सिंटैक्स की जानकारी दी गई है जिसका इस्तेमाल किया जा रहा है ndk-build.

खास जानकारी

Android.mk फ़ाइल, आपके प्रोजेक्ट की jni/ डायरेक्ट्री की सबडायरेक्ट्री में मौजूद होती है. साथ ही, यह बिल्ड सिस्टम को आपके सोर्स और शेयर की गई लाइब्रेरी के बारे में बताती है. यह GNU का एक छोटा मेकफ़ाइल फ़्रैगमेंट है, जिसे बिल्ड सिस्टम एक बार पार्स करता है या वगैरह को कॉपी करने का विकल्प है. Android.mk फ़ाइल, प्रोजेक्ट के लिए ऐसी सेटिंग तय करने में मदद करती है जिन्हें Application.mk, बिल्ड सिस्टम, और आपके एनवायरमेंट वैरिएबल तय नहीं करते. यह किसी खास मॉड्यूल के लिए, प्रोजेक्ट-वाइड सेटिंग को भी बदल सकता है.

Android.mk के सिंटैक्स की मदद से, अपने सोर्स को मॉड्यूल में ग्रुप किया जा सकता है. मॉड्यूल या तो स्टैटिक लाइब्रेरी, शेयर की गई लाइब्रेरी या स्टैंडअलोन होता है एक्ज़ीक्यूट किया जा सकता है. हर Android.mk फ़ाइल में एक या उससे ज़्यादा मॉड्यूल तय किए जा सकते हैं. साथ ही, एक ही सोर्स फ़ाइल का इस्तेमाल कई मॉड्यूल में किया जा सकता है. सिर्फ़ बिल्ड सिस्टम आपके ऐप्लिकेशन पैकेज में शेयर की गई लाइब्रेरी रखता है. इसके अलावा, स्टैटिक लाइब्रेरी, शेयर की गई लाइब्रेरी जनरेट कर सकती हैं.

पैकेजिंग लाइब्रेरी के अलावा, बिल्ड सिस्टम अन्य जानकारी मिलेगी. उदाहरण के लिए, आपको हेडर फ़ाइलों या अश्लील फ़ाइलों की सूची बनाने की ज़रूरत नहीं है आपकी Android.mk फ़ाइल में जनरेट की गई फ़ाइलों के बीच उनकी डिपेंडेंसी. एनडीके बिल्ड सिस्टम आपके लिए इन संबंधों की गणना अपने-आप करता है. इस वजह से, को आने वाले समय में एनडीके से, नए टूलचेन/प्लैटफ़ॉर्म सहायता का फ़ायदा मिल सकता है रिलीज़ कर देता है, वह भी Android.mk फ़ाइल को छुए बिना.

इस फ़ाइल का सिंटैक्स, Android.mk फ़ाइलों में इस्तेमाल किए गए सिंटैक्स के काफ़ी करीब है संपूर्ण Android ओपन सोर्स प्रोजेक्ट के साथ वितरित किया जाता है. बिल्ड सिस्टम उनका इस्तेमाल अलग-अलग तरीके से किया जाता है. उनकी समानता जान-बूझकर डिज़ाइन से जुड़े फ़ैसले का मकसद, ऐप्लिकेशन डेवलपर के लिए ऐप्लिकेशन का दोबारा इस्तेमाल करना आसान बनाना है सोर्स कोड डालें.

बुनियादी जानकारी

सिंटैक्स के बारे में ज़्यादा जानने से पहले, यह समझना ज़रूरी है कि Android.mk फ़ाइल में क्या होता है. यह सेक्शन, Android.mk फ़ाइल को उस सिरे के लिए Hello-JNI सैंपल में डाला गया, जो भूमिका के बारे में जानकारी देता है जिसे फ़ाइल की हर लाइन में चलाया जाता है.

Android.mk फ़ाइल को LOCAL_PATH वैरिएबल से शुरू करना चाहिए:

LOCAL_PATH := $(call my-dir)

यह वैरिएबल, डेवलपमेंट में सोर्स फ़ाइलों की जगह के बारे में बताता है पेड़ यहां, बिल्ड सिस्टम से मिलने वाला मैक्रो फ़ंक्शन my-dir, मौजूदा डायरेक्ट्री (Android.mk फ़ाइल वाली डायरेक्ट्री) का पाथ दिखाता है.

अगली लाइन, CLEAR_VARS वैरिएबल के बारे में बताती है, जिसकी वैल्यू बिल्ड सिस्टम में होती है उपलब्ध कराता है.

include $(CLEAR_VARS)

CLEAR_VARS वैरिएबल, एक खास GNU Makefile पर ले जाता है. यह आपके लिए कई LOCAL_XXX वैरिएबल को हटा देता है. जैसे, LOCAL_MODULE, LOCAL_SRC_FILES, और LOCAL_STATIC_LIBRARIES. ध्यान दें कि इससे LOCAL_PATH नहीं हटता. इस वैरिएबल की वैल्यू में बदलाव नहीं होना चाहिए, क्योंकि सिस्टम सभी बिल्ड कंट्रोल फ़ाइलों को एक ही GNU Make एक्सीक्यूशन कॉन्टेक्स्ट में पार्स करता है. इस कॉन्टेक्स्ट में सभी वैरिएबल ग्लोबल होते हैं. आपको ऐसा ज़रूर करना चाहिए हर मॉड्यूल के बारे में बताने से पहले, इस वैरिएबल के बारे में (फिर से) जानकारी दें.

इसके बाद, LOCAL_MODULE वैरिएबल उस मॉड्यूल के नाम को सेव करता है जिसे आपको सेव करना है बिल्ड. अपने ऐप्लिकेशन में हर मॉड्यूल के लिए, इस वैरिएबल का एक बार इस्तेमाल करें.

LOCAL_MODULE := hello-jni

हर मॉड्यूल का नाम यूनीक होना चाहिए और उसमें कोई स्पेस नहीं होना चाहिए. बिल्ड सिस्टम, जब यह अंतिम शेयर की गई लाइब्रेरी फ़ाइल जनरेट करता है, तो अपने आप उचित उस नाम के प्रीफ़िक्स और सफ़िक्स का इस्तेमाल करें जिसे आपने LOCAL_MODULE को असाइन किया है. उदाहरण के लिए, ऊपर दिए गए उदाहरण से libhello-jni.so नाम की लाइब्रेरी जनरेट होती है.

ध्यान दें: अगर आपके मॉड्यूल का नाम पहले से ही lib से शुरू होता है, तो बिल्ड सिस्टम एक अतिरिक्त lib प्रीफ़िक्स जोड़ें; तो मॉड्यूल का नाम वैसे ही ले लेता है, और .so एक्सटेंशन. इसलिए, मूल रूप से जिस सोर्स फ़ाइल को कॉल किया गया था, उदाहरण के लिए, libfoo.c अब भी शेयर की गई ऑब्जेक्ट वाली फ़ाइल जनरेट करता है, जिसे libfoo.so कहते हैं. यह व्यवहार उन लाइब्रेरी के साथ काम करते हैं जिन्हें Android प्लैटफ़ॉर्म के सोर्स Android.mk से जनरेट करते हैं फ़ाइलें; ऐसी सभी लाइब्रेरी के नाम lib से शुरू होते हैं.

अगली लाइन में सोर्स फ़ाइलों की जानकारी दी गई है. इसमें एक से ज़्यादा फ़ाइलों के बीच स्पेस का इस्तेमाल किया गया है:

LOCAL_SRC_FILES := hello-jni.c

LOCAL_SRC_FILES वैरिएबल में C और/या C++ सोर्स फ़ाइलों की सूची होनी चाहिए जिसे एक मॉड्यूल में बनाया जा सकता है.

आखिरी लाइन, सिस्टम की हर चीज़ को एक साथ जोड़ने में मदद करती है:

include $(BUILD_SHARED_LIBRARY)

BUILD_SHARED_LIBRARY वैरिएबल, GNU Makefile स्क्रिप्ट पर ले जाता है. यह स्क्रिप्ट, सबसे हाल ही के include के बाद से LOCAL_XXX वैरिएबल में तय की गई सारी जानकारी इकट्ठा करती है. इस स्क्रिप्ट से यह तय होता है कि क्या बनाना है और कैसे बनाना है.

सैंपल डायरेक्ट्री में, टिप्पणी वाली Android.mk फ़ाइलों के साथ और भी जटिल उदाहरण हैं. इसके अलावा, सैंपल: नेटिव-ऐक्टिविटी, उस सैंपल की Android.mk फ़ाइल के बारे में पूरी जानकारी देता है. आख़िर में, वैरिएबल और मैक्रो, इस GA4 में लागू होने वाले वैरिएबल के बारे में ज़्यादा जानकारी देते हैं सेक्शन में जाएं.

वैरिएबल और मैक्रो

बिल्ड सिस्टम Android.mk फ़ाइल में इस्तेमाल के लिए, कई संभावित वैरिएबल देता है. इनमें से कई वैरिएबल, पहले से असाइन की गई वैल्यू के साथ आते हैं. अन्य, जिन्हें आपने असाइन किया है.

इन वैरिएबल के अलावा, अपने हिसाब से भी वैरिएबल तय किए जा सकते हैं. ऐसा करने पर, ध्यान रखें कि NDK बिल्ड सिस्टम इन वैरिएबल के नामों को रिज़र्व रखता है:

• LOCAL_ से शुरू होने वाले नाम, जैसे कि LOCAL_MODULE.
• ऐसे नाम जो PRIVATE_, NDK_ या APP से शुरू होते हैं. बिल्ड सिस्टम इनका इस्तेमाल इंटरनल तौर पर करता है.
• छोटे अक्षर, जैसे कि my-dir. बिल्ड सिस्टम इनका इस्तेमाल अंदरूनी तौर पर, इस तरह करता है करते हैं.

अगर आपको किसी Android.mk फ़ाइल में, अपने सुविधा वैरिएबल तय करने हैं, तो हम सुझाव दें कि MY_ से पहले उनके नाम से शुरुआत करें.

एनडीके (NDK) के ज़रिए तय किए गए वैरिएबल

इस सेक्शन में GNU मेक वैरिएबल के बारे में बताया गया है, जिसे बिल्ड सिस्टम तय करता है अपनी Android.mk फ़ाइल को पार्स करने से पहले. कुछ मामलों में, एनडीके किसी और परिभाषा का इस्तेमाल करके, आपकी Android.mk फ़ाइल को कई बार पार्स कर सकता है इनमें से कुछ वैरिएबल के लिए एक बार इस्तेमाल किया जा सकता है.

CLEAR_VARS

यह वैरिएबल, ऐसी बिल्ड स्क्रिप्ट पर ले जाता है जो नीचे दिए गए "डेवलपर के तय किए गए वैरिएबल" सेक्शन में मौजूद, LOCAL_XXX सभी वैरिएबल को अनफ़ाइन करता है. इसका इस्तेमाल करें वैरिएबल जोड़ें, ताकि नए मॉड्यूल के बारे में बताने से पहले इस स्क्रिप्ट को शामिल किया जा सके. इसके लिए सिंटैक्स इसका इस्तेमाल करना:

include $(CLEAR_VARS)

बिल्ड_एक्सईसीयूटेबल

यह वैरिएबल एक ऐसी बिल्ड स्क्रिप्ट पर ले जाता है, जो वह मॉड्यूल जो आपने अपने LOCAL_XXX वैरिएबल में दिया है. साथ ही, यह भी तय करता है कि आपने जिन सोर्स को लिस्ट किया है उनसे एक ऐसा टारगेट बनाएं जिसे एक्ज़ीक्यूटेबल बनाया जा सके. ध्यान दें कि इसका इस्तेमाल करके स्क्रिप्ट के लिए यह ज़रूरी है कि आपने पहले ही LOCAL_MODULE और LOCAL_SRC_FILES, कम से कम (इन वैरिएबल के बारे में ज़्यादा जानकारी के लिए, देखें मॉड्यूल-ब्यौरा वैरिएबल).

इस वैरिएबल का इस्तेमाल करने के लिए सिंटैक्स यह है:

include $(BUILD_EXECUTABLE)

ध्यान दें: ज़्यादातर Android ऐप्लिकेशन में एक्ज़ीक्यूटेबल फ़ाइल नहीं होती है, लेकिन वे यूनिट टेस्ट और अन्य डीबगिंग टूल बनाए जा सकते हैं.

बिल्ड

यह वैरिएबल एक ऐसी बिल्ड स्क्रिप्ट पर ले जाता है, जो वह मॉड्यूल जो आपने अपने LOCAL_XXX वैरिएबल में दिया है. साथ ही, यह भी तय करता है कि आपने जो सोर्स लिस्ट किए हैं उनसे एक टारगेट शेयर की गई लाइब्रेरी बनाएं. ध्यान दें कि इसका इस्तेमाल करके स्क्रिप्ट के लिए यह ज़रूरी है कि आपने पहले ही LOCAL_MODULE और LOCAL_SRC_FILES, कम से कम (इन वैरिएबल के बारे में ज़्यादा जानकारी के लिए, देखें मॉड्यूल-ब्यौरा वैरिएबल).

इस वैरिएबल का इस्तेमाल करने के लिए सिंटैक्स यह है:

include $(BUILD_SHARED_LIBRARY)

शेयर की गई लाइब्रेरी के वैरिएबल की वजह से, बिल्ड सिस्टम .so एक्सटेंशन वाली लाइब्रेरी फ़ाइल जनरेट करता है.

BUILD_STATIC_LIBRARY

BUILD_SHARED_LIBRARY का एक वैरिएंट, जिसका इस्तेमाल एक स्टैटिक लाइब्रेरी बनाने के लिए किया जाता है. बिल्ड सिस्टम, स्टैटिक लाइब्रेरी को आपके प्रोजेक्ट/पैकेज में कॉपी नहीं करता. हालांकि, वह शेयर की गई लाइब्रेरी बनाने के लिए उनका इस्तेमाल कर सकता है. इसके बारे में ज़्यादा जानने के लिए, नीचे LOCAL_STATIC_LIBRARIES और LOCAL_WHOLE_STATIC_LIBRARIES देखें. इस वैरिएबल का इस्तेमाल करने के लिए सिंटैक्स यह है:

include $(BUILD_STATIC_LIBRARY)

स्टैटिक-लाइब्रेरी वैरिएबल की वजह से, बिल्ड सिस्टम .a एक्सटेंशन वाली लाइब्रेरी जनरेट करता है.

PREBUILT_SHARED_LIBRARY

पहले से बनी शेयर की गई लाइब्रेरी की जानकारी देने के लिए इस्तेमाल की जाने वाली बिल्ड स्क्रिप्ट पर ले जाता है. इसमें नापसंद करें BUILD_SHARED_LIBRARY और BUILD_STATIC_LIBRARY के मामले में, यहां LOCAL_SRC_FILES एक सोर्स फ़ाइल नहीं हो सकती. इसके बजाय, यह foo/libfoo.so जैसी पहले से बनी शेयर की गई लाइब्रेरी का एक पाथ होना चाहिए. इस वैरिएबल का इस्तेमाल करने का सिंटैक्स यह है:

include $(PREBUILT_SHARED_LIBRARY)

आप LOCAL_PREBUILTS वैरिएबल. पहले से बनी लाइब्रेरी इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, पहले से बनी लाइब्रेरी इस्तेमाल करना लेख पढ़ें.

PREBUILT_आंकड़े_LIBRARY

PREBUILT_SHARED_LIBRARY जैसा ही, लेकिन पहले से बनी स्टैटिक लाइब्रेरी के लिए. इसके लिए पहले से बनी लाइब्रेरी का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, पहले से बनी लाइब्रेरी इस्तेमाल करना देखें.

टारगेट की जानकारी वाले वैरिएबल

बिल्ड सिस्टम, APP_ABI के बताए गए हर एबीआई के लिए, Android.mk को एक बार पार्स करता है वैरिएबल की जानकारी देता है, जिसकी जानकारी आम तौर पर आपकी Application.mk फ़ाइल में दी जाती है. अगर APP_ABI all है, तो बिल्ड सिस्टम, NDK के साथ काम करने वाले हर एबीआई के लिए, Android.mk को एक बार पार्स करता है. इस सेक्शन में उन वैरिएबल के बारे में बताया गया है जिन्हें हर बार Android.mk को पार्स करने पर, बिल्ड सिस्टम तय करता है.

TARGET_ARCH

बिल्ड सिस्टम, सीपीयू फ़ैमिली को टारगेट कर रहा है, क्योंकि यह इस Android.mk को पार्स करता है फ़ाइल से लिए जाते हैं. यह वैरिएबल इनमें से कोई एक होगा: arm, arm64, x86 या x86_64.

TARGET_PLATFORM

Android एपीआई का वह लेवल जिसे बिल्ड सिस्टम टारगेट कर रहा है, क्योंकि वह इस Android.mk फ़ाइल को पार्स कर रहा है. उदाहरण के लिए, Android 5.1 सिस्टम की इमेज Android एपीआई लेवल 22: android-22. प्लैटफ़ॉर्म के नामों और उनसे जुड़ी Android सिस्टम इमेज की पूरी सूची के लिए, नेटिव एपीआई देखें. कॉन्टेंट बनाने नीचे दिया गया उदाहरण इस वैरिएबल का इस्तेमाल करने के लिए सिंटैक्स दिखाता है:

ifeq ($(TARGET_PLATFORM),android-22)
    # ... do something ...
endif

TARGET_ARCH_ABI

इस Android.mk फ़ाइल को पार्स करते समय, बिल्ड सिस्टम जिस एबीआई को टारगेट कर रहा है. पहली टेबल में, काम करने वाले हर सीपीयू और आर्किटेक्चर के लिए इस्तेमाल की जाने वाली एबीआई सेटिंग दिखाई गई है.

टेबल 1. अलग-अलग सीपीयू और आर्किटेक्चर के लिए एबीआई सेटिंग.

सीपीयू और आर्किटेक्चर	सेटिंग
ARMv7	armeabi-v7a
ARMv8 AArch64	arm64-v8a
i686	x86
x86-64	x86_64

नीचे दिए गए उदाहरण में, टारगेट के तौर पर ARMv8 AArch64 की जांच करने का तरीका बताया गया है सीपीयू और एबीआई का कॉम्बिनेशन:

ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
  # ... do something ...
endif

आर्किटेक्चर एबीआई और उसके साथ काम करने से जुड़ी समस्याओं के बारे में ज़्यादा जानकारी के लिए, Android एबीआई देखें.

आने वाले समय में, नए टारगेट एबीआई की वैल्यू अलग-अलग होंगी.

TARGET_ABI

टारगेट किए गए Android एपीआई लेवल और एबीआई को जोड़ने पर बनने वाला स्ट्रिंग. यह सुविधा खास तौर पर तब काम आती है, जब आपको किसी असल डिवाइस के लिए, किसी खास टारगेट सिस्टम इमेज की जांच करनी हो. उदाहरण के लिए, Android API लेवल 22 पर चलने वाले 64-बिट ARM डिवाइस की जांच करने के लिए:

ifeq ($(TARGET_ABI),android-22-arm64-v8a)
  # ... do something ...
endif

मॉड्यूल-ब्यौरे के वैरिएबल

इस सेक्शन में मौजूद वैरिएबल, बिल्ड सिस्टम को आपके मॉड्यूल के बारे में बताते हैं. हर मॉड्यूल के ब्यौरे को इस बुनियादी फ़्लो के हिसाब से होना चाहिए:

1. इसका इस्तेमाल करके, मॉड्यूल से जुड़े वैरिएबल को शुरू करें या तय करें CLEAR_VARS वैरिएबल.
2. मॉड्यूल के बारे में बताने वाले वैरिएबल के लिए वैल्यू असाइन करें.
3. मॉड्यूल के लिए सही बिल्ड स्क्रिप्ट का इस्तेमाल करने के लिए, एनडीके बिल्ड सिस्टम सेट करें, BUILD_XXX वैरिएबल का इस्तेमाल करके.

LOCAL_PATH

इस वैरिएबल का इस्तेमाल, मौजूदा फ़ाइल का पाथ देने के लिए किया जाता है. आपको इसे अपनी Android.mk फ़ाइल की शुरुआत में तय करना होगा. यहां दिए गए उदाहरण में, ऐसा करने का तरीका बताया गया है:

LOCAL_PATH := $(call my-dir)

वह स्क्रिप्ट जिससे CLEAR_VARS पॉइंट इस वैरिएबल को साफ़ नहीं करते. इसलिए, आपको इसे सिर्फ़ एक बार तय करना होगा, भले ही आपकी Android.mk फ़ाइल कई मॉड्यूल का वर्णन करता है.

LOCAL_MODULE

यह वैरिएबल आपके मॉड्यूल का नाम सेव करता है. यह सभी मॉड्यूल के बीच अलग होना चाहिए नाम और स्पेस का इस्तेमाल नहीं किया जाना चाहिए. आपको CLEAR_VARS के अलावा किसी भी स्क्रिप्ट को शामिल करने से पहले, इसे तय करना होगा. आपको lib प्रीफ़िक्स या .so या .a फ़ाइल एक्सटेंशन जोड़ने की ज़रूरत नहीं है. बिल्ड सिस्टम, ये बदलाव अपने-आप करता है. अपनी सभी Android.mk और Application.mk फ़ाइलों में, अपने मॉड्यूल को उसके मूल नाम से रेफ़र करें. उदाहरण के लिए, नीचे दी गई लाइन से libfoo.so नाम का शेयर की गई लाइब्रेरी मॉड्यूल जनरेट होता है:

LOCAL_MODULE := "foo"

अगर आपको जनरेट किए गए मॉड्यूल का नाम lib + LOCAL_MODULE की वैल्यू के बजाय कुछ और रखना है, तो LOCAL_MODULE_FILENAME वैरिएबल का इस्तेमाल करके, जनरेट किए गए मॉड्यूल को अपनी पसंद का नाम दिया जा सकता है.

LOCAL_MODULE_FILENAME

इस वैकल्पिक वैरिएबल की मदद से, बिल्ड सिस्टम के नामों को बदला जा सकता है डिफ़ॉल्ट रूप से, जनरेट की जाने वाली फ़ाइलों का इस्तेमाल करता है. उदाहरण के लिए, अगर आपके LOCAL_MODULE का नाम foo है, तो सिस्टम को जनरेट की गई फ़ाइल को libnewfoo के तौर पर कॉल करने के लिए मजबूर किया जा सकता है. नीचे दिए गए उदाहरण में, ऐसा करने का तरीका बताया गया है:

LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo

शेयर की गई लाइब्रेरी के मॉड्यूल के लिए, यह उदाहरण libnewfoo.so.

ध्यान दें: फ़ाइल का पाथ या फ़ाइल एक्सटेंशन बदला नहीं जा सकता.

LOCAL_SRC_FILES

इस वैरिएबल में उन सोर्स फ़ाइलों की सूची होती है जिनका इस्तेमाल, मॉड्यूल जनरेट करने के लिए, बिल्ड सिस्टम करता है. सिर्फ़ उन फ़ाइलों की सूची बनाएं जिन्हें बिल्ड सिस्टम असल में पास करता है कंपाइलर में बदल सकते हैं, क्योंकि बिल्ड सिस्टम किसी निर्भरता. ध्यान दें कि आप रिलेटिव (LOCAL_PATH के हिसाब से) और ऐब्सलूट, दोनों का इस्तेमाल कर सकते हैं फ़ाइल पाथ.

हमारा सुझाव है कि ऐब्सलूट फ़ाइल पाथ का इस्तेमाल न करें; रिलेटिव पाथ आपके Android.mk को फ़ाइल को अधिक पोर्टेबल बना सकता है.

ध्यान दें: बिल्ड फ़ाइलों में हमेशा यूनिक्स स्टाइल के फ़ॉरवर्ड स्लैश (/) का इस्तेमाल करें. बिल्ड सिस्टम, Windows-स्टाइल बैकस्लैश (\) को सही तरीके से हैंडल नहीं करता.

LOCAL_CPP_EXTENSION

इस वैकल्पिक वैरिएबल का इस्तेमाल करके, अपनी C++ सोर्स फ़ाइलों के लिए, .cpp के अलावा किसी दूसरे फ़ाइल एक्सटेंशन को दिखाया जा सकता है. उदाहरण के लिए, नीचे दी गई लाइन .cxx के लिए एक्सटेंशन. (सेटिंग में बिंदु शामिल होना चाहिए.)

LOCAL_CPP_EXTENSION := .cxx

इस वैरिएबल का इस्तेमाल, एक से ज़्यादा एक्सटेंशन तय करने के लिए किया जा सकता है. उदाहरण के लिए:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

इस वैकल्पिक वैरिएबल का इस्तेमाल करके यह बताया जा सकता है कि आपका कोड, C++ की कुछ खास सुविधाओं पर निर्भर है. यह बिल्ड प्रोसेस के दौरान, सही कंपाइलर और लिंकर फ़्लैग चालू करता है. पहले से बनी बाइनरी के लिए, यह वैरिएबल यह भी बताता है कि बाइनरी पर निर्भर करती है. इससे यह पक्का करने में मदद मिलती है कि फ़ाइनल लिंकिंग सही तरीके से काम कर रही है. बुध सुझाव है कि आप -frtti को चालू करने के बजाय इस वैरिएबल का इस्तेमाल करें और -fexceptions सीधे आपकी LOCAL_CPPFLAGS परिभाषा में.

इस वैरिएबल का इस्तेमाल करने पर, बिल्ड सिस्टम इनके लिए सही फ़्लैग इस्तेमाल कर पाता है हर मॉड्यूल की ज़रूरत पड़ेगी. LOCAL_CPPFLAGS का इस्तेमाल करने पर, कंपाइलर सभी मॉड्यूल के लिए तय किए गए सभी फ़्लैग का इस्तेमाल करता है. भले ही, असल ज़रूरत न हो.

उदाहरण के लिए, यह बताने के लिए कि आपका कोड RTTI (रनटाइम टाइप की जानकारी) का इस्तेमाल करता है, लिखें:

LOCAL_CPP_FEATURES := rtti

यह बताने के लिए कि आपका कोड C++ अपवादों का इस्तेमाल करता है, यह लिखें:

LOCAL_CPP_FEATURES := exceptions

इस वैरिएबल के लिए, एक से ज़्यादा वैल्यू भी दी जा सकती हैं. उदाहरण के लिए:

LOCAL_CPP_FEATURES := rtti features

वैल्यू का क्रम मायने नहीं रखता.

LOCAL_C_INCLUDES

इस वैकल्पिक वैरिएबल का इस्तेमाल पाथ की सूची तय करने के लिए किया जा सकता है. NDK root डायरेक्ट्री, सभी को कंपाइल करते समय, 'खोज पाथ शामिल करें' में जोड़ने के लिए सोर्स (C, C++, और असेंबली). उदाहरण के लिए:

LOCAL_C_INCLUDES := sources/foo

या यहां तक कि:

LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo

इसके ज़रिए कोई भी संबंधित शामिल किए जाने वाले फ़्लैग सेट करने से पहले यह वैरिएबल तय करें LOCAL_CFLAGS या LOCAL_CPPFLAGS.

ndk-gdb की मदद से नेटिव डीबगिंग शुरू करते समय, बिल्ड सिस्टम भी LOCAL_C_INCLUDES पाथ का अपने-आप इस्तेमाल करता है.

LOCAL_ASFLAGS

.s या .S फ़ाइलें बनाते समय, Clang को भेजे जाने वाले फ़्लैग.

चेतावनी: यह LOCAL_ASMFLAGS, यानी yasm के लिए इस्तेमाल किए जाने वाले नाम से अलग है सोर्स.

LOCAL_ASMFLAGS

.asm फ़ाइलें बनाते समय, yasm को पास किए जाने वाले फ़्लैग.

चेतावनी: यह LOCAL_ASFLAGS से अलग है, जो इसके लिए इस्तेमाल किया जाने वाला नाम है नॉन-Yasm सोर्स का इस्तेमाल किया जाता है.

LOCAL_CFLAGS

C, C++, और कुछ असेम्बली (.s और .S, लेकिन .asm नहीं) सोर्स फ़ाइलों को बिल्ड करते समय, Clang को पास किए जाने वाले फ़्लैग. ऐसा करने से, मैक्रो की अन्य परिभाषाएं तय करने या कंपाइल करने के विकल्पों के बारे में बताने में मदद मिल सकती है. इस्तेमाल की जाने वाली चीज़ें सिर्फ़ C++ के लिए फ़्लैग तय करने के लिए LOCAL_CPPFLAGS. सिर्फ़ C के लिए फ़्लैग तय करने के लिए, LOCAL_CONLYFLAGS का इस्तेमाल करें.

अपनी Android.mk फ़ाइल में ऑप्टिमाइज़ेशन/डीबगिंग लेवल को न बदलने की कोशिश करें. Application.mk फ़ाइल में मौजूद काम की जानकारी का इस्तेमाल करके, बिल्ड सिस्टम इस सेटिंग को आपके लिए अपने-आप मैनेज कर सकता है. इसे इस तरीके से करने से बिल्ड सिस्टम का इस्तेमाल किया जा सकता है, ताकि डीबग करने के दौरान इस्तेमाल की जाने वाली काम की डेटा फ़ाइलें जनरेट की जा सकें.

अतिरिक्त पाथ शामिल करने के बारे में जानकारी देने के लिए, यह जानकारी दी जा सकती है:

LOCAL_CFLAGS += -I<path>,

हालांकि, इस काम के लिए LOCAL_C_INCLUDES का इस्तेमाल करना बेहतर होगा, क्योंकि इसलिए, नेटिव डीबगिंग के लिए उपलब्ध पाथ का इस्तेमाल ndk-gdb.

LOCAL_CONLYFLAGS

ऐसे फ़्लैग जिन्हें C स्रोतों को कंपाइल करते समय Clang को भेजा जाएगा. नापसंद करें कंपाइल करते समय LOCAL_CFLAGS, LOCAL_CONLYFLAGS को Clang को पास नहीं किया जाएगा C++ या असेंबली सोर्स.

LOCAL_CPPFLAGS

कंपाइलर फ़्लैग का एक वैकल्पिक सेट, जो सिर्फ़ C++ सोर्स फ़ाइलें बनाते समय पास किया जाएगा. वे कंपाइलर के LOCAL_CFLAGS के बाद दिखेंगे कमांड लाइन. C और C++, दोनों के लिए फ़्लैग तय करने के लिए LOCAL_CFLAGS का इस्तेमाल करें.

LOCAL_STATIC_LIBRARIES

यह वैरिएबल ऐसे स्टैटिक लाइब्रेरी मॉड्यूल की सूची सेव करता है जिन पर मौजूदा मॉड्यूल निर्भर करता है.

अगर मौजूदा मॉड्यूल कोई शेयर की गई लाइब्रेरी या एक्ज़ीक्यूटेबल है, तो यह वैरिएबल इन लाइब्रेरी को बाइनरी से लिंक करने के लिए कह सकता है.

अगर मौजूदा मॉड्यूल एक स्टैटिक लाइब्रेरी है, तो यह वैरिएबल सिर्फ़ यह बताता है कि मौजूदा मॉड्यूल के आधार पर, अन्य मॉड्यूल की सूची लाइब्रेरी.

LOCAL_SHARED_LIBRARIES

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

लोकल_डब्ल्यूएचओ

यह वैरिएबल LOCAL_STATIC_LIBRARIES का एक वैरिएंट है और इससे पता चलता है कि लिंकर को संबंधित लाइब्रेरी मॉड्यूल के साथ पूरे संग्रह के रूप में इस्तेमाल किया जाना चाहिए. पूरी संग्रह के बारे में ज़्यादा जानकारी के लिए, --whole-archive फ़्लैग के लिए GNU ld दस्तावेज़ देखें.

यह वैरिएबल तब काम आता है, जब कई स्टैटिक लाइब्रेरी के बीच सर्कुलर डिपेंडेंसी होती हैं. शेयर की गई लाइब्रेरी बनाने के लिए इस वैरिएबल का इस्तेमाल करने पर, यह बिल्ड सिस्टम को आपकी स्टैटिक लाइब्रेरी की सभी ऑब्जेक्ट फ़ाइलों को फ़ाइनल बाइनरी में जोड़ने के लिए मजबूर करेगा. हालांकि, एक्सीक्यूटेबल जनरेट करते समय ऐसा नहीं होता.

LOCAL_LDLIBS

इस वैरिएबल में, बिल्डिंग में इस्तेमाल करने के लिए लिंक करने वाले दूसरे फ़्लैग की सूची शामिल है शेयर की गई लाइब्रेरी या एक्ज़ीक्यूटेबल. इसकी मदद से, -l प्रीफ़िक्स का इस्तेमाल करके, किसी खास सिस्टम लाइब्रेरी का नाम पास किया जा सकता है. उदाहरण के लिए, यहां दिए गए उदाहरण में लिंकर को ऐसा मॉड्यूल जनरेट करने के लिए कहा गया है जो लोड होने के समय /system/lib/libz.so से लिंक होता है:

LOCAL_LDLIBS := -lz

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

ध्यान दें: अगर किसी स्टैटिक लाइब्रेरी के लिए यह वैरिएबल तय किया जाता है, तो बिल्ड सिस्टम उसे अनदेखा कर देता है और ndk-build उसे प्रिंट कर देगा.

LOCAL_LDFLAGS

शेयर की गई लाइब्रेरी या एक्सीक्यूटेबल बनाते समय, बिल्ड सिस्टम के लिए इस्तेमाल किए जाने वाले अन्य लिंकर फ़्लैग की सूची. उदाहरण के लिए, ld.bfd लिंकर का इस्तेमाल करके ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

ध्यान दें: अगर किसी स्टैटिक लाइब्रेरी के लिए यह वैरिएबल तय किया जाता है, तो बिल्ड सिस्टम उसे अनदेखा कर देता है उसे क्लिक करता है, और ndk-build एक चेतावनी प्रिंट करता है.

LOCAL_ALLOW_UNDEFINED_SYMBOLS

डिफ़ॉल्ट रूप से, जब बिल्ड सिस्टम को कोई ऐसी पहचान फ़ाइल मिलती है जिसके बारे में कोई जानकारी न दी गई हो शेयर की गई फ़ाइल बनाने की कोशिश करते समय, उससे तय नहीं किया गया निशान की गड़बड़ी दिखेगी. यह गड़बड़ी की जानकारी से आपको सोर्स कोड में आने वाली गड़बड़ियों को पहचानने में मदद मिल सकती है.

इस जांच को बंद करने के लिए, इस वैरिएबल को true पर सेट करें. ध्यान दें कि यह सेटिंग हो सकती है रनटाइम के दौरान शेयर की गई लाइब्रेरी को लोड करने में मदद करता है.

ध्यान दें: अगर इस वैरिएबल को स्टैटिक लाइब्रेरी के लिए तय किया जाता है, तो बिल्ड सिस्टम इस पर ध्यान नहीं देता और ndk-build चेतावनी दिखाता है.

LOCAL_ARM_मोड

बिल्ड सिस्टम डिफ़ॉल्ट रूप से, थंब मोड में ARM टारगेट बाइनरी जनरेट करता है, जिसमें हर निर्देश 16 बिट चौड़ा होता है और STL लाइब्रेरी से thumb/ डायरेक्ट्री. इस वैरिएबल को arm के तौर पर तय करने से, बिल्ड सिस्टम इस पर काम करता है 32-बिट arm मोड में मॉड्यूल की ऑब्जेक्ट फ़ाइलें जनरेट करती हैं. यह उदाहरण दिखाता है कि इसे कैसे किया जा सकता है:

LOCAL_ARM_MODE := arm

बिल्ड सिस्टम को arm में सिर्फ़ खास सोर्स बनाने के लिए निर्देश भी दिए जा सकते हैं सोर्स फ़ाइल नामों में .arm सफ़िक्स जोड़कर मोड का इस्तेमाल करें. उदाहरण के लिए, नीचे दिया गया उदाहरण बिल्ड सिस्टम को यह बताता है कि bar.c को हमेशा ARM मोड में कंपाइल किया जाता है, लेकिन LOCAL_ARM_MODE की वैल्यू के हिसाब से foo.c बनाने के लिए.

LOCAL_SRC_FILES := foo.c bar.c.arm

ध्यान दें: किसी बिल्ड सिस्टम को ARM बाइनरी जनरेट करने के लिए भी कहा जा सकता है. ऐसा करने के लिए, आपको यह सेट करना होगा: APP_OPTIM को आपकी Application.mk फ़ाइल में, debug के लिए सेव किया गया था. debug का इस्तेमाल करने पर, ARM बाइनरी बनाई जाती है, क्योंकि टूलचेन डीबगर, थंब कोड को सही तरीके से मैनेज नहीं करता.

LOCAL_ARM_NEON

यह वैरिएबल सिर्फ़ तब मायने रखता है, जब armeabi-v7a एबीआई को टारगेट किया जा रहा हो. यह यह आपके C और C++ में ARM Advanced SIMD (NEON) कंपाइलर इंट्रिंसिक्स का इस्तेमाल करने की अनुमति देता है और असेंबली फ़ाइलों में NEON निर्देश भी दिए गए हैं.

ध्यान दें कि सभी ARMv7 पर आधारित सीपीयू, NEON निर्देश सेट के एक्सटेंशन के साथ काम नहीं करते. इस वजह से, आपको रनटाइम पर इस कोड का सुरक्षित तरीके से इस्तेमाल करने के लिए, रनटाइम की पहचान करनी होगी. ज़्यादा जानकारी के लिए, Neon सहायता देखें और सीपीयू की सुविधाएं.

इसके अलावा, .neon सफ़िक्स का इस्तेमाल करके यह बताया जा सकता है कि बिल्ड सिस्टम, सिर्फ़ NEON के साथ काम करने वाली खास सोर्स फ़ाइलों को ही कंपाइल करता है. नीचे दिए गए उदाहरण में, बिल्ड सिस्टम, foo.c को थंब और नियॉन सपोर्ट के साथ कंपाइल करता है, bar.c थंब सपोर्ट, और ARM और NEON के लिए समर्थन के साथ zoo.c:

LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon

अगर दोनों सफ़िक्स का इस्तेमाल किया जाता है, तो .neon से पहले .arm होना चाहिए.

LOCAL_ROWS_FORMAT_STRING_CHECKS

डिफ़ॉल्ट रूप से, बिल्ड सिस्टम फ़ॉर्मैट स्ट्रिंग सुरक्षा के साथ कोड को कंपाइल करता है. करना इसलिए अगर किसी नॉन-कॉन्सटेंट फ़ॉर्मैट स्ट्रिंग का इस्तेमाल printf-स्टाइल फ़ंक्शन. यह सुरक्षा डिफ़ॉल्ट रूप से चालू होती है. हालांकि, इस वेरिएबल की वैल्यू को true पर सेट करके, इसे बंद किया जा सकता है. हमारा सुझाव है कि आप ऐसा करने से पहले, अच्छी तरह से सोच-विचार कर लें.

LOCAL_EXPORT_CFLAGS

यह वैरिएबल, C/C++ कंपाइलर फ़्लैग का एक सेट रिकॉर्ड करता है, ताकि LOCAL_STATIC_LIBRARIES या LOCAL_SHARED_LIBRARIES वैरिएबल के ज़रिए इस वैरिएबल का इस्तेमाल करने वाले किसी भी दूसरे मॉड्यूल की LOCAL_CFLAGS परिभाषा में जोड़ा जा सके.

उदाहरण के लिए, यहां दिए गए मॉड्यूल के जोड़े पर विचार करें: foo और bar, जो foo पर निर्भर करता है:

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_CFLAGS := -DFOO=1
include $(BUILD_STATIC_LIBRARY)


include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_CFLAGS := -DBAR=2
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)

यहां, bar.c को बिल्ड करते समय, बिल्ड सिस्टम, कंपाइलर को फ़्लैग -DFOO=1 और -DBAR=2 पास करता है. यह आपके मॉड्यूल के एक्सपोर्ट किए गए फ़्लैग को भी दिखाता है LOCAL_CFLAGS ताकि आप इन्हें आसानी से बदल सकें.

इसके अलावा, मॉड्यूल के बीच संबंध संक्रामक होता है: अगर zoo bar, जो कि foo पर निर्भर करता है. इसके बाद, zoo भी सभी फ़्लैग को इनहेरिट करता है foo से एक्सपोर्ट किया गया.

आखिर में, लोकल नेटवर्क बनाते समय बिल्ड सिस्टम, एक्सपोर्ट किए गए फ़्लैग का इस्तेमाल नहीं करता (जैसे, वह मॉड्यूल बनाना जिसके फ़्लैग को एक्सपोर्ट किया जा रहा है). इसलिए, ऊपर दिए गए उदाहरण में, foo/foo.c को बिल्ड करते समय, कंपाइलर को -DFOO=1 नहीं भेजा जाता. यहां की यात्रा पर हूं स्थानीय रूप से बनाने के लिए, इसके बजाय LOCAL_CFLAGS का उपयोग करें.

LOCAL_EXPORT_CPPFLAGS

यह वैरिएबल LOCAL_EXPORT_CFLAGS जैसा ही है, लेकिन सिर्फ़ C++ फ़्लैग के लिए.

LOCAL_EXPORT_C_INCLUDES

यह वैरिएबल LOCAL_EXPORT_CFLAGS जैसा ही है, लेकिन C में पाथ शामिल हैं. यह उन मामलों में उपयोगी होता है जहां, उदाहरण के लिए, bar.c में मॉड्यूल foo.

लोकल_EXPORT_LDFLAGS

यह वैरिएबल LOCAL_EXPORT_CFLAGS जैसा ही है, लेकिन लिंकर फ़्लैग के लिए भी यही है.

LOCAL_EXPORT_LDLIBS

यह वैरिएबल LOCAL_EXPORT_CFLAGS जैसा ही है. यह बिल्ड सिस्टम को बताता है कि वह कंपाइलर को कुछ सिस्टम लाइब्रेरी के नाम पास करे. -l को आगे जोड़ें दर्ज करें.

ध्यान दें कि बिल्ड सिस्टम, आपके मॉड्यूल के LOCAL_LDLIBS वैरिएबल की वैल्यू में इंपोर्ट किए गए लिंकर फ़्लैग जोड़ता है. ऐसा यूनिक्स लिंकर के काम करने के तरीके की वजह से होता है.

आम तौर पर, यह वैरिएबल तब काम आता है, जब foo मॉड्यूल एक स्टैटिक लाइब्रेरी हो और उसमें जो सिस्टम लाइब्रेरी पर निर्भर करता है. इसके बाद, डिपेंडेंसी को एक्सपोर्ट करने के लिए LOCAL_EXPORT_LDLIBS का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_LDLIBS := -llog
include $(BUILD_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)

इस उदाहरण में, बिल्ड सिस्टम -llog को लिंकर कमांड के आखिर में रखता है जब यह libbar.so बनेगा. ऐसा करने से लिंकर को यह पता चलता है कि, क्योंकि libbar.so foo पर निर्भर करता है. यह सिस्टम लॉगिंग लाइब्रेरी पर भी निर्भर करता है.

LOCAL_SHORT_COMMANDS

जब आपके मॉड्यूल में बहुत ज़्यादा सोर्स हों, तो इस वैरिएबल को true पर सेट करें और/या डिपेंडेंट स्टैटिक या शेयर की गई लाइब्रेरी का इस्तेमाल करें. ऐसा करने से बिल्ड सिस्टम को इंटरमीडिएट ऑब्जेक्ट फ़ाइलों या लिंकिंग वाले संग्रहों के लिए @ सिंटैक्स का उपयोग करें लाइब्रेरी.

यह सुविधा Windows पर उपयोगी हो सकती है, जहां कमांड लाइन अधिकतम सिर्फ़ 8,191 वर्णों का हो सकता है, जो मुश्किल प्रोजेक्ट के लिए बहुत छोटा है. यह भी अलग-अलग सोर्स फ़ाइलों के कंपाइलेशन पर असर डालता है. इस प्रोसेस में करीब-करीब पूरा कंपाइलर फ़्लैग भी शामिल कर सकते हैं.

ध्यान दें कि true के अलावा किसी भी वैल्यू को चुनने पर, डिफ़ॉल्ट सेटिंग लागू हो जाएगी. आपने लोगों तक पहुंचाया मुफ़्त में लागू करने के लिए, अपनी Application.mk फ़ाइल में APP_SHORT_COMMANDS को भी तय कर सकता है यह व्यवहार आपके प्रोजेक्ट के सभी मॉड्यूल के लिए लागू होगा.

हम इस सुविधा को डिफ़ॉल्ट रूप से सक्षम करने की अनुशंसा नहीं करते, क्योंकि इससे बिल्ड धीरे करना होगा.

LOCAL_THIN_संग्रहित

स्टैटिक लाइब्रेरी बनाते समय, इस वैरिएबल को true पर सेट करें. ऐसा करने से एक थिन आर्काइव जनरेट करता है, एक लाइब्रेरी फ़ाइल जिसमें ऑब्जेक्ट फ़ाइलें होती हैं, लेकिन इसके बजाय सिर्फ़ उन असल ऑब्जेक्ट के लिए पाथ फ़ाइल करें जिन्हें वह आम तौर पर करता है शामिल हैं.

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

मान्य वैल्यू true, false या खाली हो सकती हैं. APP_THIN_ARCHIVE वैरिएबल की मदद से, अपनी Application.mk फ़ाइल में डिफ़ॉल्ट वैल्यू सेट की जा सकती है.

ध्यान दें: इसे नॉन-स्टैटिक लाइब्रेरी मॉड्यूल या पहले से बनी स्टैटिक लाइब्रेरी के लिए अनदेखा किया जाता है कुछ.

LOCAL_FILTER_ASM

इस वैरिएबल को शेल कमांड के तौर पर परिभाषित करें. बिल्ड सिस्टम, इनका इस्तेमाल फ़िल्टर करने के लिए करेगा आपके लिए बताई गई फ़ाइलों से एक्सट्रैक्ट की गई या जनरेट की गई असेंबली फ़ाइलें LOCAL_SRC_FILES. इस वैरिएबल को तय करने से ये चीज़ें होती हैं:

1. बिल्ड सिस्टम, किसी भी C या C++ सोर्स से अस्थायी असेंबली फ़ाइल जनरेट करता है .
2. बिल्ड सिस्टम, LOCAL_FILTER_ASM में मौजूद शेल कमांड को किसी भी अस्थायी असेंबली फ़ाइल और LOCAL_SRC_FILES में दी गई किसी भी असेंबली फ़ाइल पर लागू करता है. इससे एक और अस्थायी असेंबली फ़ाइल जनरेट होती है.
3. बिल्ड सिस्टम, फ़िल्टर की गई इन असेंबली फ़ाइलों को ऑब्जेक्ट फ़ाइल में कंपाइल करता है.

उदाहरण के लिए:

LOCAL_SRC_FILES  := foo.c bar.S
LOCAL_FILTER_ASM :=

foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o
bar.S                                 --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o

"1", कंपाइलर से जुड़ा है, "2" फ़िल्टर से जुड़ा है, और "3" असेंबलर से जुड़ा है. फ़िल्टर एक स्टैंडअलोन शेल कमांड होना चाहिए जो इनपुट का नाम लेता हो फ़ाइल को अपने पहले तर्क के रूप में और दूसरे तर्क के रूप में आउटपुट फ़ाइल का नाम डालें. उदाहरण के लिए:

myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S

NDK के फ़ंक्शन मैक्रो

इस सेक्शन में, NDK से मिलने वाले GNU Make फ़ंक्शन मैक्रो के बारे में बताया गया है. इस्तेमाल की जाने वाली चीज़ें इनका आकलन करने के लिए $(call <function>); वे टेक्स्ट वाली जानकारी दिखाते हैं.

मेरी-डायर

यह मैक्रो, शामिल की गई आखिरी मेकफ़ाइल का पाथ दिखाता है. आम तौर पर, यह मौजूदा Android.mk की डायरेक्ट्री होती है. my-dir, Android.mk फ़ाइल की शुरुआत में LOCAL_PATH तय करने के लिए मददगार है. उदाहरण के लिए:

LOCAL_PATH := $(call my-dir)

GNU Make के काम करने के तरीके की वजह से, यह मैक्रो आखिरी मेकफ़ाइल का पाथ दिखाता है. इस मैकफ़ाइल को बिल्ड सिस्टम ने बिल्ड स्क्रिप्ट को पार्स करते समय शामिल किया था. इसके लिए इस कारण से, कोई अन्य फ़ाइल शामिल करने के बाद आपको my-dir को कॉल नहीं करना चाहिए.

नीचे दिए गए उदाहरण पर गौर करें:

LOCAL_PATH := $(call my-dir)

# ... declare one module

include $(LOCAL_PATH)/foo/`Android.mk`

LOCAL_PATH := $(call my-dir)

# ... declare another module

समस्या यह है कि my-dir को किए गए दूसरे कॉल में LOCAL_PATH इस तरह परिभाषित होता है $PATH के बजाय $PATH/foo, क्योंकि हाल ही में इसी जगह पर शामिल किया गया था की ओर इशारा किया.

बाकी सब कुछ के बाद अतिरिक्त चीज़ें शामिल करके आप इस समस्या से बच सकते हैं Android.mk फ़ाइल में. उदाहरण के लिए:

LOCAL_PATH := $(call my-dir)

# ... declare one module

LOCAL_PATH := $(call my-dir)

# ... declare another module

# extra includes at the end of the Android.mk file
include $(LOCAL_PATH)/foo/Android.mk

अगर फ़ाइल को इस तरह से व्यवस्थित नहीं किया जा सकता, तो पहले my-dir कॉल की वैल्यू को किसी दूसरे वैरिएबल में सेव करें. उदाहरण के लिए:

MY_LOCAL_PATH := $(call my-dir)

LOCAL_PATH := $(MY_LOCAL_PATH)

# ... declare one module

include $(LOCAL_PATH)/foo/`Android.mk`

LOCAL_PATH := $(MY_LOCAL_PATH)

# ... declare another module

सभी-सब-दिर-मेकफ़ाइल

मौजूदा my-dir पाथ की सभी सबडायरेक्ट्री में मौजूद Android.mk फ़ाइलों की सूची दिखाता है.

इस फ़ंक्शन का इस्तेमाल, डीप-नेस्ट की गई सोर्स डायरेक्ट्री की हैरारकी देने के लिए किया जा सकता है बिल्ड सिस्टम की ज़रूरत होती है. डिफ़ॉल्ट रूप से, एनडीके सिर्फ़ डायरेक्ट्री में मौजूद फ़ाइलें खोजता है Android.mk फ़ाइल शामिल है.

यह-मेकफ़ाइल

मौजूदा मेकफ़ाइल का पाथ दिखाता है. इसी से बिल़्ड सिस्टम, फ़ंक्शन को कॉल करता है.

पैरंट-मेकफ़ाइल

शामिल करने वाले ट्री में पैरंट मेकफ़ाइल का पाथ दिखाता है. यह उस मेकफ़ाइल का पाथ होता है जिसमें मौजूदा मेकफ़ाइल शामिल होती है.

grand-parent-makefile

शामिल करने वाले ट्री में, ग्रैंडपैरंट मेकफ़ाइल का पाथ दिखाता है. यह उस मेकफ़ाइल का पाथ होता है जिसमें मौजूदा मेकफ़ाइल शामिल होती है.

इंपोर्ट-मॉड्यूल

ऐसा फ़ंक्शन जो आपको मॉड्यूल की Android.mk फ़ाइल को ढूंढने और शामिल करने की सुविधा देता है मॉड्यूल का नाम. इसका एक सामान्य उदाहरण यहां दिया गया है:

$(call import-module,<name>)

इस उदाहरण में, बिल्ड सिस्टम उन डायरेक्ट्री की सूची में <name> टैग किए गए मॉड्यूल को ढूंढता है जिनका रेफ़रंस आपके NDK_MODULE_PATH एनवायरमेंट वैरिएबल में दिया गया है. साथ ही, वह आपके लिए Android.mk फ़ाइल को अपने-आप शामिल कर लेता है.