หน้านี้อธิบายไวยากรณ์ของไฟล์บิลด์ Android.mk ที่ ndk-build ใช้
ภาพรวม
ไฟล์ Android.mk อยู่ในไดเรกทอรีย่อยของไดเรกทอรี jni/ ของโปรเจ็กต์ และอธิบายแหล่งที่มาและไลบรารีที่แชร์ไปยังระบบบิลด์
โดยเป็นชิ้นส่วนไฟล์ GNU ขนาดเล็กที่ระบบบิลด์จะแยกวิเคราะห์อย่างน้อย 1 ครั้ง ไฟล์ Android.mk มีประโยชน์สำหรับการกำหนดการตั้งค่าของทั้งโปรเจ็กต์ซึ่ง Application.mk, ระบบบิลด์ และตัวแปรสภาพแวดล้อมจะไม่ระบุ นอกจากนี้ยังสามารถลบล้างการตั้งค่าทั่วทั้งโปรเจ็กต์สำหรับข้อบังคับที่เฉพาะเจาะจงได้อีกด้วย
ไวยากรณ์ของ Android.mk ช่วยให้คุณจัดกลุ่มแหล่งที่มาเป็นโมดูลได้
โมดูลคือไลบรารีแบบคงที่ ไลบรารีที่ใช้ร่วมกัน หรือไฟล์ปฏิบัติการแบบสแตนด์อโลน คุณสามารถกําหนดโมดูลอย่างน้อย 1 รายการในไฟล์ Android.mk แต่ละไฟล์ และสามารถใช้ไฟล์ต้นฉบับเดียวกันในหลายโมดูลได้ ระบบบิลด์จะวางเฉพาะไลบรารีที่ใช้ร่วมกันไว้ในแพ็กเกจแอปพลิเคชันเท่านั้น นอกจากนี้ ไลบรารีแบบคงที่ยังสร้างไลบรารีที่ใช้ร่วมกันได้
นอกเหนือจากไลบรารีแพ็กเกจแล้ว ระบบบิลด์จะจัดการรายละเอียดอื่นๆ มากมายให้คุณ เช่น คุณไม่จําเป็นต้องระบุไฟล์ส่วนหัวหรือความสัมพันธ์ที่ชัดเจนระหว่างไฟล์ที่สร้างขึ้นไว้ในไฟล์ Android.mk ระบบการบิลด์ NDK จะคํานวณความสัมพันธ์เหล่านี้ให้คุณโดยอัตโนมัติ คุณจึงควรได้รับประโยชน์จากการสนับสนุนเครื่องมือ/แพลตฟอร์มใหม่ใน NDK เวอร์ชันในอนาคตโดยไม่ต้องแก้ไขไฟล์ Android.mk
ไวยากรณ์ของไฟล์นี้คล้ายกับที่ใช้ในไฟล์ Android.mk ที่มาพร้อมกับ Android Open Source Project เวอร์ชันเต็ม แม้ว่าระบบของบิลด์ที่ใช้บิลด์จะแตกต่างออกไป แต่ความคล้ายคลึงกันของทั้งคู่คือการตัดสินใจด้านการออกแบบโดยเจตนาซึ่งมีเป้าหมายเพื่อให้นักพัฒนาแอปพลิเคชันนำซอร์สโค้ดสำหรับไลบรารีภายนอกมาใช้ซ้ำได้ง่ายขึ้น
ข้อมูลเบื้องต้น
ก่อนที่จะสำรวจรายละเอียดเกี่ยวกับไวยากรณ์ ควรเริ่มต้นด้วยการทำความเข้าใจพื้นฐานของสิ่งที่อยู่ในไฟล์ 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 จะจัดเก็บชื่อของโมดูลที่คุณต้องการสร้าง ใช้ตัวแปรนี้ 1 ครั้งต่อโมดูลในแอปพลิเคชัน
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 ของตัวอย่างดังกล่าวด้วย สุดท้าย ตัวแปรและมาโครจะให้ข้อมูลเพิ่มเติมเกี่ยวกับตัวแปรจากส่วนนี้
ตัวแปรและมาโคร
ระบบบิลด์มีตัวแปรที่เป็นไปได้หลายแบบสำหรับใช้ในไฟล์ Android.mk
ตัวแปรเหล่านี้จำนวนมากมาพร้อมกับค่าที่กำหนดไว้ล่วงหน้า ส่วนที่เหลือ คุณเป็นผู้กำหนด
นอกจากตัวแปรเหล่านี้แล้ว คุณยังกําหนดตัวแปรของคุณเองแบบไม่จํากัดได้ด้วย หากใช้วิธีนี้ โปรดทราบว่าระบบบิลด์ NDK สงวนชื่อตัวแปรต่อไปนี้ไว้
- ชื่อที่ขึ้นต้นด้วย
LOCAL_เช่นLOCAL_MODULE - ชื่อที่ขึ้นต้นด้วย
PRIVATE_,NDK_หรือAPPซึ่งระบบบิลด์จะใช้ สิ่งเหล่านี้ภายใน - ชื่อที่เป็นตัวพิมพ์เล็ก เช่น
my-dirระบบบิลด์จะใช้ข้อมูลเหล่านี้ภายในด้วย
หากต้องการกำหนดตัวแปรตามสะดวกของคุณเองในไฟล์ Android.mk เราขอแนะนำให้เพิ่ม MY_ ไว้หน้าชื่อของตัวแปรนั้น
ตัวแปรรวมที่กำหนดโดย NDK
ส่วนนี้จะกล่าวถึงตัวแปร GNU Make ที่ระบบบิลด์กำหนดไว้ก่อนแยกวิเคราะห์ไฟล์ Android.mk ในบางกรณี NDK อาจแยกวิเคราะห์ไฟล์ Android.mk หลายครั้งโดยใช้คําจํากัดความที่แตกต่างกันสําหรับตัวแปรเหล่านี้บางรายการในแต่ละครั้ง
CLEAR_VARS
ตัวแปรนี้ชี้ไปยังสคริปต์บิลด์ที่ยังไม่ได้กำหนดตัวแปร LOCAL_XXX เกือบทั้งหมดที่แสดงในส่วน "ตัวแปรที่นักพัฒนาแอปกำหนด" ด้านล่าง ใช้ตัวแปรนี้เพื่อรวมสคริปต์นี้ก่อนที่จะอธิบายโมดูลใหม่ ไวยากรณ์สำหรับใช้คำสั่งมีดังนี้
include $(CLEAR_VARS)
BUILD_EXECUTABLE
ตัวแปรนี้จะชี้ไปยังสคริปต์บิลด์ที่รวบรวมข้อมูลทั้งหมดเกี่ยวกับโมดูลที่คุณระบุไว้ในตัวแปร LOCAL_XXX และกำหนดวิธีสร้างไฟล์ปฏิบัติการเป้าหมายจากแหล่งที่มาที่คุณระบุ โปรดทราบว่าอย่างน้อยที่สุดในการใช้สคริปต์นี้ คุณต้องกำหนดค่าให้กับ LOCAL_MODULE และ LOCAL_SRC_FILES ไว้แล้ว (ดูข้อมูลเพิ่มเติมเกี่ยวกับตัวแปรเหล่านี้ได้ที่หัวข้อตัวแปรคำอธิบายโมดูล)
ไวยากรณ์สําหรับการใช้ตัวแปรนี้มีดังนี้
include $(BUILD_EXECUTABLE)
BUILD_SHARED_LIBRARY
ตัวแปรนี้จะชี้ไปยังสคริปต์บิลด์ที่รวบรวมข้อมูลทั้งหมดเกี่ยวกับโมดูลที่คุณระบุไว้ในตัวแปร 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_SHARED_LIBRARY แต่สำหรับไลบรารีแบบคงที่ที่สร้างไว้ล่วงหน้า ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้รายการที่สร้างไว้ล่วงหน้าได้ที่ใช้ไลบรารีที่สร้างไว้ล่วงหน้า
ตัวแปรข้อมูลเป้าหมาย
ระบบบิลด์จะแยกวิเคราะห์ Android.mk 1 ครั้งต่อ ABI ที่ระบุโดยตัวแปร APP_ABI ซึ่งปกติกำหนดไว้ในไฟล์ Application.mk หาก APP_ABI คือ all ระบบบิลด์จะแยกวิเคราะห์ Android.mk 1 ครั้งต่อ ABI ที่ NDK รองรับ ส่วนนี้จะอธิบายตัวแปรที่ระบบบิลด์กำหนดทุกครั้งที่แยกวิเคราะห์ Android.mk
TARGET_ARCH
ตระกูล CPU ที่ระบบบิลด์กำหนดเป้าหมายขณะแยกวิเคราะห์ไฟล์ Android.mk นี้ ตัวแปรนี้จะเป็นหนึ่งใน arm, arm64, x86 หรือ x86_64
TARGET_PLATFORM
หมายเลขระดับ API ของ Android ที่ระบบบิลด์กําหนดเป้าหมายขณะแยกวิเคราะห์ไฟล์นี้
Android.mk เช่น อิมเมจระบบ Android 5.1 สอดคล้องกับ Android API ระดับ 22: android-22 ดูรายการชื่อแพลตฟอร์มทั้งหมดและอิมเมจระบบ Android ที่เกี่ยวข้องได้ที่ Native API ตัวอย่างต่อไปนี้แสดงไวยากรณ์สําหรับการใช้ตัวแปรนี้
ifeq ($(TARGET_PLATFORM),android-22)
# ... do something ...
endif
TARGET_ARCH_ABI
ABI ที่ระบบบิลด์กําลังกําหนดเป้าหมายขณะแยกวิเคราะห์ไฟล์ Android.mk นี้
ตารางที่ 1 แสดงการตั้งค่า ABI ที่ใช้สำหรับ CPU และสถาปัตยกรรมที่รองรับแต่ละรายการ
ตารางที่ 1 การตั้งค่า ABI สำหรับ CPU และสถาปัตยกรรมต่างๆ
| CPU และสถาปัตยกรรม | การเกริ่นนำ |
|---|---|
| ARMv7 | armeabi-v7a |
| ARMv8 AArch64 | arm64-v8a |
| I686 | x86 |
| X86-64 | x86_64 |
ตัวอย่างต่อไปนี้แสดงวิธีตรวจสอบ ARMv8 AArch64 เป็นชุดค่าผสมระหว่าง CPU กับ ABI เป้าหมาย
ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
# ... do something ...
endif
ดูรายละเอียดเพิ่มเติมเกี่ยวกับ ABI ของสถาปัตยกรรมและปัญหาความเข้ากันได้ที่เกี่ยวข้องได้ที่ ABI ของ Android
ABI เป้าหมายใหม่ในอนาคตจะมีค่าที่แตกต่างกัน
TARGET_ABI
การเชื่อมโยงระดับ API ของ Android เป้าหมายกับ ABI เข้าด้วยกัน ซึ่งมีประโยชน์อย่างยิ่งเมื่อคุณต้องการทดสอบกับอิมเมจระบบเป้าหมายที่เจาะจงสำหรับอุปกรณ์จริง เช่น หากต้องการตรวจสอบอุปกรณ์ ARM 64 บิตที่ใช้ Android API ระดับ 22 ให้ทำดังนี้
ifeq ($(TARGET_ABI),android-22-arm64-v8a)
# ... do something ...
endif
ตัวแปรคำอธิบายโมดูล
ตัวแปรในส่วนนี้จะอธิบายโมดูลของคุณต่อระบบบิลด์ คำอธิบายแต่ละข้อของข้อบังคับควรเป็นไปตามขั้นตอนพื้นฐานต่อไปนี้
- เริ่มต้นหรือยกเลิกการกำหนดตัวแปรที่เชื่อมโยงกับโมดูล โดยใช้ตัวแปร
CLEAR_VARS - กําหนดค่าให้กับตัวแปรที่ใช้อธิบายข้อบังคับ
- ตั้งค่าระบบการสร้าง NDK ให้ใช้สคริปต์การสร้างที่เหมาะสมสําหรับโมดูลโดยใช้ตัวแปร
BUILD_XXX
LOCAL_PATH
ตัวแปรนี้ใช้เพื่อกำหนดเส้นทางของไฟล์ปัจจุบัน คุณต้องกำหนดค่าที่จุดเริ่มต้นของไฟล์ Android.mk ตัวอย่างต่อไปนี้แสดงวิธีดำเนินการ
LOCAL_PATH := $(call my-dir)
สคริปต์ที่ CLEAR_VARS ชี้ถึงไม่ได้ล้างตัวแปรนี้ คุณจึงต้องกําหนดเพียงครั้งเดียว แม้ว่าไฟล์ Android.mk จะอธิบายหลายโมดูลก็ตาม
โมดูลในพื้นที่
ตัวแปรนี้จัดเก็บชื่อโมดูลของคุณ โดยชื่อโมดูลต้องไม่ซ้ำกัน และต้องไม่มีการเว้นวรรค คุณต้องกำหนดก่อนรวมสคริปต์ใดๆ (นอกเหนือจากสคริปต์สำหรับ 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 พกพาสะดวกมากขึ้น
LOCAL_CPP_EXTENSION
คุณสามารถใช้ตัวแปรที่ไม่บังคับนี้เพื่อระบุนามสกุลไฟล์อื่นที่ไม่ใช่ .cpp สำหรับไฟล์ซอร์ส C++ ตัวอย่างเช่น บรรทัดต่อไปนี้จะเปลี่ยนนามสกุลเป็น .cxx (การตั้งค่าต้องมีจุด)
LOCAL_CPP_EXTENSION := .cxx
คุณสามารถใช้ตัวแปรนี้เพื่อระบุส่วนขยายหลายรายการได้ เช่น
LOCAL_CPP_EXTENSION := .cxx .cpp .cc
ฟีเจอร์ LOCAL_CPP
คุณสามารถใช้ตัวแปรที่ไม่บังคับนี้เพื่อระบุว่าโค้ดของคุณใช้ฟีเจอร์ C++ ที่เฉพาะเจาะจง ซึ่งจะเปิดใช้คอมไพเลอร์และ Flag ของ linker ที่ถูกต้องในระหว่างกระบวนการสร้าง สำหรับไบนารีที่สร้างไว้ล่วงหน้า ตัวแปรนี้จะประกาศฟีเจอร์ที่ไบนารีนั้นอ้างอิงด้วย จึงช่วยให้การลิงก์สุดท้ายทำงานได้อย่างถูกต้อง เราขอแนะนำให้คุณใช้ตัวแปรนี้แทนการเปิดใช้ -frtti และ -fexceptions ในคำจำกัดความ LOCAL_CPPFLAGS โดยตรง
การใช้ตัวแปรนี้ช่วยให้ระบบบิลด์ใช้ Flag ที่เหมาะสมสำหรับแต่ละโมดูลได้ การใช้ LOCAL_CPPFLAGS จะทำให้คอมไพเลอร์ใช้แฟล็กที่ระบุทั้งหมดสำหรับโมดูลทั้งหมด โดยไม่คำนึงถึงความต้องการจริง
เช่น หากต้องการระบุว่าโค้ดใช้ RTTI (ข้อมูลประเภทรันไทม์) ให้เขียนดังนี้
LOCAL_CPP_FEATURES := rtti
หากต้องการระบุว่าโค้ดของคุณใช้ข้อยกเว้น C++ ให้เขียนดังนี้
LOCAL_CPP_FEATURES := exceptions
คุณสามารถระบุหลายค่าสำหรับตัวแปรนี้ได้เช่นกัน เช่น
LOCAL_CPP_FEATURES := rtti features
ลำดับที่คุณอธิบายค่านั้นไม่สำคัญ
LOCAL_C_INCLUDES
คุณสามารถใช้ตัวแปรที่ไม่บังคับนี้เพื่อระบุรายการเส้นทางซึ่งสัมพันธ์กับไดเรกทอรี NDK root เพื่อเพิ่มลงในเส้นทางการค้นหาที่รวมเมื่อคอมไพล์ซอร์สโค้ดทั้งหมด (C, C++ และ Assembly) เช่น
LOCAL_C_INCLUDES := sources/foo
หรือแม้แต่
LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo
กำหนดตัวแปรนี้ก่อนตั้งค่าแฟล็กการรวมที่เกี่ยวข้องผ่าน LOCAL_CFLAGS หรือ LOCAL_CPPFLAGS
ระบบบิลด์ยังใช้เส้นทาง LOCAL_C_INCLUDES โดยอัตโนมัติเมื่อเปิดการแก้ไขข้อบกพร่องของระบบด้วย ndk-gdb
LOCAL_ASFLAGS
Flag ที่ส่งไปยัง Clang เมื่อสร้างไฟล์ .s หรือ .S
LOCAL_ASMFLAGS
แฟล็กซึ่งจะส่งไปยัง yasm เมื่อสร้างไฟล์ .asm
LOCAL_CFLAGS
Flag ที่ส่งไปยัง Clang เมื่อสร้างไฟล์ซอร์ส C, C++ และ Assembly บางไฟล์ (.s และ .S แต่ไม่ใช่ .asm) ความสามารถในการทำเช่นนี้อาจมีประโยชน์สำหรับการระบุคำจำกัดความของมาโครหรือตัวเลือกการคอมไพล์เพิ่มเติม ใช้ LOCAL_CPPFLAGS เพื่อระบุแฟล็กสำหรับ C++ เท่านั้น ใช้ LOCAL_CONLYFLAGS เพื่อระบุ Flag สำหรับ C เท่านั้น
พยายามอย่าเปลี่ยนระดับการเพิ่มประสิทธิภาพ/การแก้ไขข้อบกพร่องในไฟล์ Android.mk
ระบบบิลด์จะจัดการการตั้งค่านี้ให้คุณโดยอัตโนมัติได้ โดยใช้ข้อมูลที่เกี่ยวข้องในไฟล์ Application.mk การทำเช่นนี้จะช่วยให้ระบบบิลด์สร้างไฟล์ข้อมูลที่มีประโยชน์ซึ่งใช้ในการแก้ไขข้อบกพร่องได้
คุณสามารถระบุเส้นทางรวมเพิ่มเติมได้โดยเขียนดังนี้
LOCAL_CFLAGS += -I<path>,
อย่างไรก็ตาม การใช้ LOCAL_C_INCLUDES เพื่อวัตถุประสงค์นี้จะดีกว่า เนื่องจากการใช้เส้นทางนี้จะทำให้สามารถใช้เส้นทางที่มีอยู่สำหรับการแก้ไขข้อบกพร่องของระบบด้วย ndk-gdb ได้
LOCAL_CONLYFLAGS
แฟล็กซึ่งจะส่งไปยัง Clang เมื่อคอมไพล์ซอร์ส C ระบบจะไม่ส่ง LOCAL_CONLYFLAGS ไปยัง Clang เมื่อคอมไพล์แหล่งที่มาของ C++ หรือแหล่งที่มาของการประกอบ ซึ่งต่างจาก LOCAL_CFLAGS
LOCAL_CPPFLAGS
ชุด Flag คอมไพเลอร์ที่ไม่บังคับซึ่งจะส่งเมื่อสร้างไฟล์ซอร์ส C++ เท่านั้น โดยจะปรากฏหลัง LOCAL_CFLAGS บนบรรทัดคำสั่งของคอมไพเลอร์ ใช้ LOCAL_CFLAGS เพื่อระบุแฟล็กสำหรับทั้ง C และ C++
LOCAL_STATIC_LIBRARIES
ตัวแปรนี้จัดเก็บรายการโมดูลไลบรารีแบบคงที่ซึ่งโมดูลปัจจุบันใช้อยู่
หากโมดูลปัจจุบันเป็นไลบรารีที่ใช้ร่วมกันหรือไฟล์ปฏิบัติการ ตัวแปรนี้จะบังคับให้ลิงก์ไลบรารีเหล่านี้เข้ากับไบนารีที่ได้
หากโมดูลปัจจุบันเป็นไลบรารีแบบคงที่ ตัวแปรนี้จะเพียงแค่ระบุว่าโมดูลอื่นๆ ที่ขึ้นอยู่กับโมดูลปัจจุบันจะขึ้นอยู่กับไลบรารีที่ระบุไว้ด้วย
LOCAL_SHARED_LIBRARIES
ตัวแปรนี้เป็นรายการโมดูลของไลบรารีที่ใช้ร่วมกัน ซึ่งโมดูลนี้ขึ้นอยู่กับรันไทม์ ข้อมูลนี้จําเป็นเมื่อลิงก์ และเพื่อฝังข้อมูลที่เกี่ยวข้องในไฟล์ที่สร้างขึ้น
LOCAL_WHOLE_STATIC_LIBRARIES
ตัวแปรนี้เป็นตัวแปรของ LOCAL_STATIC_LIBRARIES และแสดงว่า Linker ควรถือว่าโมดูลไลบรารีที่เกี่ยวข้องเป็นไฟล์เก็บถาวรทั้งไฟล์ ดูข้อมูลเพิ่มเติมเกี่ยวกับไฟล์เก็บถาวรทั้งหมดได้ที่เอกสารประกอบ GNU ld สำหรับ Flag --whole-archive
ตัวแปรนี้มีประโยชน์เมื่อมีทรัพยากร Dependency แบบวงกลมในไลบรารีแบบคงที่หลายรายการ เมื่อคุณใช้ตัวแปรนี้เพื่อสร้างไลบรารีที่ใช้ร่วมกัน ระบบจะบังคับให้ระบบบิลด์เพิ่มไฟล์ออบเจ็กต์ทั้งหมดจากไลบรารีแบบคงที่ลงในไบนารีสุดท้าย อย่างไรก็ตาม จะไม่เป็นความจริงเมื่อสร้างไฟล์ปฏิบัติการ
LOCAL_LDLIBS
ตัวแปรนี้มีรายการ Flag ตัวลิงก์เพิ่มเติมสำหรับใช้ในการสร้างไลบรารีที่ใช้ร่วมกันหรือไฟล์ปฏิบัติการ ซึ่งจะช่วยให้คุณใช้คำนำหน้า -l เพื่อส่งชื่อไลบรารีของระบบที่เฉพาะเจาะจงได้ ตัวอย่างต่อไปนี้จะบอกให้ Linker สร้างโมดูลที่ลิงก์ไปยัง /system/lib/libz.so ขณะโหลด
LOCAL_LDLIBS := -lz
ดูรายการไลบรารีระบบที่เปิดเผยซึ่งคุณลิงก์ได้ในรุ่น NDK นี้ได้จากAPI เดิม
LOCAL_LDFLAGS
รายการ Flag อื่นๆ ของ linker สำหรับระบบการบิลด์ที่จะใช้เมื่อสร้างห้องสมุดที่ใช้ร่วมกันหรือไฟล์ปฏิบัติการ เช่น หากต้องการใช้ตัวลิงก์ ld.bfd บน ARM/X86 ให้ทำดังนี้
LOCAL_LDFLAGS += -fuse-ld=bfd
LOCAL_ALLOW_UNDEFINED_SYMBOLS
โดยค่าเริ่มต้น เมื่อระบบบิลด์พบการอ้างอิงที่ไม่ได้กำหนดขณะที่พยายามสร้างการแชร์ ระบบจะแสดงข้อผิดพลาดสัญลักษณ์ที่ไม่ระบุ ข้อผิดพลาดนี้จะช่วยคุณจับข้อบกพร่องในซอร์สโค้ดได้
หากต้องการปิดใช้การตรวจสอบนี้ ให้ตั้งค่าตัวแปรนี้เป็น true โปรดทราบว่าการตั้งค่านี้อาจทำให้ไลบรารีที่ใช้ร่วมกันโหลดเมื่อรันไทม์
โหมด LOCAL_ARM
โดยค่าเริ่มต้น ระบบบิลด์จะสร้างไบนารีเป้าหมาย ARM ในโหมด thumb ซึ่งแต่ละคำสั่งมีความกว้าง 16 บิตและลิงก์กับไลบรารี STL ในไดเรกทอรี thumb/ การกำหนดตัวแปรนี้เป็น arm จะบังคับให้ระบบบิลด์สร้างไฟล์ออบเจ็กต์ของโมดูลในโหมด arm แบบ 32 บิต ตัวอย่างต่อไปนี้จะแสดงวิธีการ
LOCAL_ARM_MODE := arm
นอกจากนี้ คุณยังสั่งให้ระบบบิลด์สร้างเฉพาะแหล่งที่มาที่ต้องการในarmโหมดโดยใส่ส่วนต่อท้าย .arm ต่อท้ายชื่อไฟล์ต้นทาง ตัวอย่างตัวอย่างต่อไปนี้จะบอกระบบบิลด์ให้คอมไพล์ bar.c ในโหมด ARM เสมอ แต่ต้องสร้าง foo.c ตามค่าของ LOCAL_ARM_MODE
LOCAL_SRC_FILES := foo.c bar.c.arm
LOCAL_ARM_NEON
ตัวแปรนี้จะมีผลก็ต่อเมื่อคุณกําหนดเป้าหมายเป็น armeabi-v7a ABI เท่านั้น ซึ่งอนุญาตให้ใช้อินทรินสิกคอมไพเลอร์ SIMD (NEON) ขั้นสูงของ ARM ในซอร์สโค้ด C และ C++ รวมถึงคำสั่ง NEON ในไฟล์แอสเซมบลี
โปรดทราบว่า CPU ที่ใช้ ARMv7 บางรุ่นไม่รองรับส่วนขยายชุดคำสั่ง NEON ด้วยเหตุนี้ คุณจึงต้องดำเนินการตรวจหารันไทม์เพื่อให้ใช้โค้ดนี้ได้อย่างปลอดภัยในรันไทม์ ดูข้อมูลเพิ่มเติมได้ที่การรองรับ Neon และฟีเจอร์ของ CPU
หรือจะใช้ส่วนต่อท้าย .neon เพื่อระบุว่าระบบบิลด์จะรวบรวมเฉพาะไฟล์ต้นทางที่มีการรองรับ NEON เท่านั้นก็ได้ ในตัวอย่างต่อไปนี้ ระบบบิลด์จะคอมไพล์ foo.c พร้อมการรองรับนิ้วโป้งและนีออน bar.c พร้อมการรองรับนิ้วโป้ง และ zoo.c พร้อมการรองรับ ARM และ NEON
LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon
หากคุณใช้คำต่อท้ายทั้ง 2 แบบ .arm ต้องมาก่อน .neon
LOCAL_DISABLE_FORMAT_STRING_CHECKS
โดยค่าเริ่มต้น ระบบบิลด์จะคอมไพล์โค้ดด้วยการปกป้องสตริงรูปแบบ การทำเช่นนี้จะทำให้เกิดข้อผิดพลาดของคอมไพเลอร์หากใช้สตริงรูปแบบที่ไม่คงที่ในฟังก์ชันรูปแบบ printf การป้องกันนี้จะเปิดอยู่โดยค่าเริ่มต้น แต่คุณปิดใช้ได้โดยการตั้งค่าตัวแปรนี้เป็น true เราไม่แนะนำให้ทำเช่นนั้น
โดยไม่มีเหตุผลสมควร
LOCAL_EXPORT_CFLAGS
ตัวแปรนี้จะบันทึกชุด Flag คอมไพเลอร์ C/C++ เพื่อเพิ่มลงในLOCAL_CFLAGSการกําหนดค่าของโมดูลอื่นๆ ที่ใช้โมดูลนี้ผ่านตัวแปร 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)
ในที่นี้ ระบบบิลด์จะส่งผ่าน Flag -DFOO=1 และ -DBAR=2 ไปยังคอมไพเลอร์เมื่อสร้าง bar.c นอกจากนี้ ยังใส่ Flag ที่ส่งออกไว้ข้างหน้า LOCAL_CFLAGS ของโมดูลเพื่อให้คุณลบล้าง Flag เหล่านั้นได้ง่ายๆ
นอกจากนี้ ความสัมพันธ์ระหว่างโมดูลต่างๆ เป็นแบบทรานซิชัน หาก zoo ขึ้นอยู่กับ bar ซึ่งก็ขึ้นอยู่กับ foo ด้วย zoo จะรับค่า Flag ทั้งหมดที่ส่งออกจาก foo ด้วย
สุดท้าย ระบบบิลด์จะไม่ใช้ Flag ที่ส่งออกเมื่อสร้างในเครื่อง (เช่น สร้างโมดูลที่ส่งออก Flag) ดังนั้น ในตัวอย่างข้างต้น ระบบจะไม่ส่ง -DFOO=1 ไปยังคอมไพเลอร์เมื่อสร้าง foo/foo.c หากต้องการสร้างภายในเครื่อง ให้ใช้ LOCAL_CFLAGS แทน
LOCAL_EXPORT_CPPFLAGS
ตัวแปรนี้เหมือนกับ LOCAL_EXPORT_CFLAGS แต่เป็นสำหรับ Flag ของ C++ เท่านั้น
LOCAL_EXPORT_C_INCLUDES
ตัวแปรนี้เหมือนกับ LOCAL_EXPORT_CFLAGS แต่สําหรับ C จะรวมเส้นทาง ซึ่งจะเป็นประโยชน์ในกรณีที่ bar.c จำเป็นต้องใส่ส่วนหัวจากโมดูล foo เป็นต้น
LOCAL_EXPORT_LDFLAGS
ตัวแปรนี้เหมือนกับ LOCAL_EXPORT_CFLAGS แต่ใช้สำหรับ Flag ของ linker
LOCAL_EXPORT_LDLIBS
ตัวแปรนี้เหมือนกับ LOCAL_EXPORT_CFLAGS ซึ่งบอกให้ระบบบิลด์ส่งชื่อไลบรารีระบบที่เฉพาะเจาะจงไปยังคอมไพเลอร์ แทรก -l ไว้หน้าชื่อคลังแต่ละรายการที่คุณระบุ
โปรดทราบว่าระบบบิลด์จะเพิ่ม Flag ของ linker ที่นําเข้าไว้ต่อท้ายค่าของตัวแปร 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)
ในตัวอย่างนี้ ระบบบิลด์จะใส่ -llog ต่อท้ายคำสั่ง linker เมื่อสร้าง libbar.so การทำเช่นนี้จะบอกให้ Linker ทราบว่า libbar.so ขึ้นอยู่กับ foo จึงขึ้นอยู่กับไลบรารีการบันทึกของระบบด้วย
LOCAL_SHORT_COMMAND
ตั้งค่าตัวแปรนี้เป็น true เมื่อโมดูลมีแหล่งที่มาจํานวนมาก และ/หรือไลบรารีแบบคงที่หรือแบบแชร์ที่ขึ้นต่อกัน ซึ่งจะบังคับให้ระบบบิลด์ใช้ไวยากรณ์ @ สำหรับไฟล์เก็บถาวรที่มีไฟล์ออบเจ็กต์ระดับกลางหรือไลบรารีการลิงก์
ฟีเจอร์นี้มีประโยชน์ใน Windows เนื่องจากบรรทัดคำสั่งยอมรับอักขระได้สูงสุดเพียง 8,191 ตัว ซึ่งอาจเล็กเกินไปสำหรับโปรเจ็กต์ที่ซับซ้อน นอกจากนี้ ยังส่งผลต่อการคอมไพล์ไฟล์ต้นฉบับแต่ละไฟล์ด้วย โดยวาง Flag คอมไพเลอร์เกือบทั้งหมดไว้ในไฟล์ลิสต์ด้วย
โปรดทราบว่าค่าอื่นที่ไม่ใช่ true จะเปลี่ยนกลับเป็นลักษณะการทำงานเริ่มต้น นอกจากนี้ คุณยังกำหนด APP_SHORT_COMMANDS ในไฟล์ Application.mk เพื่อบังคับใช้ลักษณะการทำงานนี้สำหรับทุกโมดูลในโปรเจ็กต์ได้ด้วย
เราไม่แนะนำให้เปิดใช้ฟีเจอร์นี้โดยค่าเริ่มต้นเนื่องจากจะทำให้การสร้างช้าลง
LOCAL_THIN_ARCHIVE
ตั้งค่าตัวแปรนี้เป็น true เมื่อสร้างไลบรารีแบบคงที่ การทำเช่นนี้จะสร้าง Tin Archive ซึ่งเป็นไฟล์ไลบรารีที่ไม่มีไฟล์ออบเจ็กต์ แต่มีเพียงแค่เส้นทางไฟล์ไปยังออบเจ็กต์จริงที่โดยปกติจะมีอยู่
ซึ่งมีประโยชน์ในการลดขนาดเอาต์พุตของบิลด์ ข้อเสียคือไลบรารีดังกล่าวไม่สามารถย้ายไปยังตำแหน่งอื่น (เส้นทางทั้งหมดภายในเป็นแบบสัมพัทธ์)
ค่าที่ถูกต้องคือ true, false หรือว่างเปล่า คุณสามารถกําหนดค่าเริ่มต้นในไฟล์ Application.mk ผ่านตัวแปร APP_THIN_ARCHIVE
LOCAL_FILTER_ASM
กําหนดตัวแปรนี้เป็นคําสั่งเชลล์ที่ระบบบิลด์จะใช้เพื่อกรองไฟล์แอสเซมบลีที่ดึงข้อมูลหรือสร้างจากไฟล์ที่คุณระบุสําหรับ LOCAL_SRC_FILES การกําหนดตัวแปรนี้ทําให้สิ่งต่อไปนี้เกิดขึ้น
- ระบบบิลด์จะสร้างไฟล์แอสเซมบลีชั่วคราวจากไฟล์ซอร์ส C หรือ C++ แทนการคอมไพล์เป็นไฟล์ออบเจ็กต์
- ระบบบิลด์จะเรียกใช้คำสั่ง Shell ใน
LOCAL_FILTER_ASMบนไฟล์การประกอบชั่วคราวทุกไฟล์และในไฟล์แอสเซมบลีใดก็ได้ที่ระบุไว้ในLOCAL_SRC_FILESจึงสร้างไฟล์การประกอบชั่วคราวขึ้นอีกไฟล์หนึ่ง - ระบบบิลด์จะรวมไฟล์แอสเซมบ์ที่กรองแล้วเหล่านี้ลงในไฟล์ออบเจ็กต์
เช่น
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" สอดคล้องกับแอสเซมเบลอร์ ตัวกรองต้องเป็นคำสั่งเชลล์แบบสแตนด์อโลนที่รับชื่อไฟล์อินพุตเป็นอาร์กิวเมนต์แรก และชื่อไฟล์เอาต์พุตเป็นอาร์กิวเมนต์ที่ 2 เช่น
myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S
มาโครฟังก์ชันจาก NDK
ส่วนนี้อธิบายถึงมาโครฟังก์ชันของ GNU ที่ NDK มีให้ ใช้ $(call <function>) เพื่อประเมินข้อมูล ซึ่งจะแสดงผลเป็นข้อความ
my-dir
มาโครนี้แสดงผลเส้นทางของ getfile ที่รวมไว้ล่าสุด ซึ่งปกติแล้วจะเป็นไดเรกทอรีของ Android.mk ปัจจุบัน my-dir มีประโยชน์ในการกําหนด LOCAL_PATH ที่จุดเริ่มต้นของไฟล์ Android.mk เช่น
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
ปัญหาก็คือการเรียกครั้งที่ 2 ไปยัง 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
ไฟล์ย่อยทั้งหมด
แสดงรายการไฟล์ Android.mk ที่อยู่ในไดเรกทอรีย่อยทั้งหมดของเส้นทาง my-dir ปัจจุบัน
คุณสามารถใช้ฟังก์ชันนี้เพื่อระบุลําดับชั้นไดเรกทอรีแหล่งที่มาที่ฝังลึกให้กับระบบบิลด์ได้ โดยค่าเริ่มต้น NDK จะค้นหาเฉพาะไฟล์ในไดเรกทอรีที่มีไฟล์ Android.mk
ไฟล์รูปแบบนี้
แสดงเส้นทางของไฟล์ Makefile ปัจจุบัน (ซึ่งระบบบิลด์ใช้เรียกว่าฟังก์ชัน)
ไฟล์หลัก
แสดงผลเส้นทางของไฟล์ Make หลักในต้นไม้การรวม (เส้นทางของไฟล์ Make ที่รวมไฟล์ Make ปัจจุบัน)
grand-parent-makefile
แสดงผลเส้นทางของ setfile ระดับบนสุดในโครงสร้างการรวม (เส้นทางของไฟล์แต่งที่มีไฟล์ปัจจุบัน)
โมดูลนำเข้า
ฟังก์ชันที่ช่วยให้คุณค้นหาและรวมไฟล์ Android.mk ของโมดูลตามชื่อของโมดูลได้ ตัวอย่างทั่วไปมีดังนี้
$(call import-module,<name>)
ในตัวอย่างนี้ ระบบบิลด์จะมองหาโมดูลที่ติดแท็ก <name> ในรายการไดเรกทอรีที่อ้างอิงตัวแปรสภาพแวดล้อม NDK_MODULE_PATH ของคุณ และรวมไฟล์ Android.mk ไว้ให้คุณโดยอัตโนมัติ