Android.mk

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

खास जानकारी

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

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

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

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

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

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

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

LOCAL_PATH := $(call my-dir)

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

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

include $(CLEAR_VARS)

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

इसके बाद, 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 फ़ाइल के बारे में पूरी जानकारी देता है. आखिर में, वैरिएबल और मैक्रो, इस सेक्शन में वैरिएबल के बारे में ज़्यादा जानकारी देते हैं.

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

बिल्ड सिस्टम, 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)

BUILD_EXECUTABLE

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

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

include $(BUILD_EXECUTABLE)

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

बिल्ड

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

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

include $(BUILD_SHARED_LIBRARY)

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

BUILD_आंकड़े_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.

टारगेट प्लैटफ़ॉर्म

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 में, काम करने वाले हर सीपीयू और आर्किटेक्चर के लिए इस्तेमाल की जाने वाली एबीआई सेटिंग दिखती है.

टेबल 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 वैरिएबल का इस्तेमाल करके, मॉड्यूल के लिए सही बिल्ड स्क्रिप्ट का इस्तेमाल करने के लिए, NDK बिल्ड सिस्टम सेट करें.

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_फ़ाइलें

इस वैरिएबल में उन सोर्स फ़ाइलों की सूची होती है जिनका इस्तेमाल, मॉड्यूल जनरेट करने के लिए, बिल्ड सिस्टम करता है. सिर्फ़ उन फ़ाइलों की सूची बनाएं जिन्हें बिल्ड सिस्टम, कंपाइलर को भेजता है. ऐसा इसलिए, क्योंकि बिल्ड सिस्टम, उनसे जुड़ी सभी डिपेंडेंसी का हिसाब अपने-आप लगा लेता है. ध्यान दें कि 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++ की कुछ खास सुविधाओं पर निर्भर है. यह बिल्ड प्रोसेस के दौरान, सही कंपाइलर और लिंकर फ़्लैग चालू करता है. पहले से बनी बाइनरी के लिए, यह वैरिएबल यह भी बताता है कि बाइनरी किन सुविधाओं पर निर्भर है. इससे यह पक्का करने में मदद मिलती है कि फ़ाइनल लिंकिंग सही तरीके से काम कर रही है. हमारा सुझाव है कि आप अपनी LOCAL_CPPFLAGS परिभाषा में सीधे -frtti और -fexceptions को चालू करने के बजाय, इस वैरिएबल का इस्तेमाल करें.

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

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

LOCAL_CPP_FEATURES := rtti

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

LOCAL_CPP_FEATURES := exceptions

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

LOCAL_CPP_FEATURES := rtti features

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

LOCAL_C_INCLUDES

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

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 से अलग है. LOCAL_ASFLAGS का इस्तेमाल, Yasm के अलावा दूसरे सोर्स के लिए किया जाता है.

स्थानीय_सीएफ़एलएजीएस

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 के उलट, C++ या असेंबली सोर्स को कंपाइल करते समय LOCAL_CONLYFLAGS को Clang में पास नहीं किया जाएगा.

LOCAL_CPPFLAGS

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

स्थानीय_स्टेटिक_LIBRARIES

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

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

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

LOCAL_SHARED_LIBRARIES

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

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

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

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

LOCAL_LDLIBS

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

LOCAL_LDLIBS := -lz

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

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

LOCAL_LDFLAGS

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

LOCAL_LDFLAGS += -fuse-ld=bfd

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

LOCAL_ALLOW_UNDEFINED_SYMBOLS

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

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

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

LOCAL_ARM_MODE

बिल्ड सिस्टम डिफ़ॉल्ट रूप से, थंब मोड में ARM टारगेट बाइनरी जनरेट करता है. इसमें हर निर्देश 16 बिट चौड़ा होता है और 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

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

LOCAL_ARM_NEON

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

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

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

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

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

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 वैरिएबल की वैल्यू में इंपोर्ट किए गए लिंकर फ़्लैग जोड़ता है. ऐसा, Unix लिंकर के काम करने के तरीके की वजह से होता है.

यह वैरिएबल आम तौर पर तब काम आता है, जब मॉड्यूल 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)

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

LOCAL_SHORT_COMMANDS

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

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

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

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

LOCAL_THIN_ARCHIVE

स्टैटिक लाइब्रेरी बनाते समय, इस वैरिएबल को 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 की डायरेक्ट्री होती है. आपकी Android.mk फ़ाइल की शुरुआत में LOCAL_PATH की जानकारी देने के लिए, my-dir का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

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/foo को $PATH के तौर पर परिभाषित करता है. ऐसा इसलिए, क्योंकि सबसे हाल के कॉल में पॉइंट शामिल किए गए थे.

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

all-subdir-makefiles

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

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

यह-मेकफ़ाइल

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

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

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

grand-parent-makefile

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

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

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

$(call import-module,<name>)

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