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 मेकफ़ाइल की जानकारी देता है, जो कई फ़ाइलों को मिटा देता है आपके लिए LOCAL_XXX वैरिएबल, जैसे कि LOCAL_MODULE, LOCAL_SRC_FILES, और LOCAL_STATIC_LIBRARIES. ध्यान दें कि यह LOCAL_PATH को साफ़ नहीं करता. यह वैरिएबल में इसका मान बना रहना चाहिए, क्योंकि सिस्टम सभी बिल्ड कंट्रोल फ़ाइलों को पार्स कर देता है लागू करें, जहां सभी वैरिएबल ग्लोबल हों. आपको ऐसा ज़रूर करना चाहिए हर मॉड्यूल के बारे में बताने से पहले, इस वैरिएबल के बारे में (फिर से) जानकारी दें.

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

LOCAL_MODULE := hello-jni

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

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

LOCAL_SRC_FILES := hello-jni.c

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

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

include $(BUILD_SHARED_LIBRARY)

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

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

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

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

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

• 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)

बिल्ड

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

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

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

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

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

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

TARGET_ABI

टारगेट किए गए Android एपीआई लेवल और एबीआई को जोड़ने की प्रोसेस. यह ख़ास तौर पर काम का है जब आपको किसी असली डिवाइस के लिए, किसी टारगेट सिस्टम इमेज से टेस्ट करना हो. उदाहरण के लिए, Android एपीआई लेवल 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_फ़ाइलें

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

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

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 (RunTime Type Information) का इस्तेमाल करता है, लिखें:

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.

लॉन्च होने पर बिल्ड सिस्टम अपने-आप LOCAL_C_INCLUDES पाथ का भी इस्तेमाल करता है ndk-gdb की मदद से नेटिव डीबग करना.

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

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

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

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

LOCAL_CFLAGS += -I<path>,

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

LOCAL_CPPFLAGS

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

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

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

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

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

LOCAL_SHARED_LIBRARIES

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

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

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

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

LOCAL_LDLIBS

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

LOCAL_LDLIBS := -lz

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

लोकल_एलडीएलएजीएस

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

LOCAL_LDFLAGS += -fuse-ld=bfd

LOCAL_ALLOW_UNDEFINED_SYMBOLS

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

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

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

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

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

उदाहरण के लिए, मॉड्यूल के इन जोड़े पर गौर करें: 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)

यहां बिल्ड सिस्टम, कंपाइलर को -DFOO=1 और -DBAR=2 फ़्लैग पास करता है bar.c को सेट अप करने के लिए डिज़ाइन किया गया है. यह आपके मॉड्यूल के एक्सपोर्ट किए गए फ़्लैग को भी दिखाता है 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 के काम करने के तरीके की वजह से यह मैक्रो असल में जो दिखाता है वह वह आखिरी Makefile जिसे बिल्ड सिस्टम में बिल्ड स्क्रिप्ट पार्स करते समय शामिल किया गया था. इसके लिए इस कारण से, कोई अन्य फ़ाइल शामिल करने के बाद आपको 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

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

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

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

यह-मेकफ़ाइल

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

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

शामिल किए जाने वाले ट्री में पैरंट मेकफ़ाइल का पाथ लौटाता है (इसका पाथ createfile जिसमें मौजूदा वाला शामिल है).

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

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

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

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

$(call import-module,<name>)

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