Android mk

หน้านี้อธิบายไวยากรณ์ของไฟล์บิลด์ Android.mk ที่ใช้โดย ndk-build

ภาพรวม

ไฟล์ Android.mk อยู่ในไดเรกทอรีย่อยของไดเรกทอรี jni/ ของโปรเจ็กต์ และอธิบายแหล่งที่มาและไลบรารีที่ใช้ร่วมกันให้กับระบบบิลด์ นี่เป็นส่วนย่อยของไฟล์ GNU ขนาดเล็กที่ระบบบิลด์จะแยกวิเคราะห์เพียงครั้งเดียวหรือ และอีกมากมาย ไฟล์ Android.mk มีประโยชน์ในการกำหนดการตั้งค่าทั่วทั้งโปรเจ็กต์ที่ Application.mk, ระบบบิลด์ และตัวแปรสภาพแวดล้อมไม่ได้กำหนดไว้ นอกจากนี้ยังลบล้างการตั้งค่าของทั้งโปรเจ็กต์สำหรับโมดูลที่เจาะจงได้ด้วย

ไวยากรณ์ของ Android.mk ช่วยให้คุณจัดกลุ่มแหล่งที่มาเป็นโมดูลได้ โมดูลอาจเป็นไลบรารีแบบคงที่ ไลบรารีที่ใช้ร่วมกัน หรือสแตนด์อโลน ไฟล์ปฏิบัติการ คุณสามารถกำหนดอย่างน้อย 1 โมดูลในไฟล์ Android.mk แต่ละไฟล์ และ คุณสามารถใช้ไฟล์ต้นฉบับเดียวกันในหลายโมดูลได้ ระบบบิลด์จะวางไลบรารีที่ใช้ร่วมกันไว้ในแพ็กเกจแอปพลิเคชันเท่านั้น นอกจากนี้ ไลบรารีแบบคงที่ยังสร้างไลบรารีที่ใช้ร่วมกันได้

นอกจากการแพ็กเกจไลบรารีแล้ว ระบบบิลด์ยังจัดการรายละเอียดอื่นๆ ให้คุณด้วย เช่น คุณไม่จำเป็นต้องแสดงไฟล์ส่วนหัวหรือเนื้อหาที่อาจไม่เหมาะสม ทรัพยากร Dependency ระหว่างไฟล์ที่สร้างขึ้นในไฟล์ Android.mk บิลด์ NDK ระบบจะคำนวณความสัมพันธ์เหล่านี้ให้คุณโดยอัตโนมัติ ด้วยเหตุนี้คุณ จะได้รับประโยชน์จากการรองรับแพลตฟอร์ม/เชนเครื่องมือใหม่ในอนาคต NDK ออกใหม่โดยไม่ต้องแตะไฟล์ Android.mk

ไวยากรณ์ของไฟล์นี้ใกล้เคียงกับที่ใช้ในไฟล์ Android.mk มาก แจกจ่ายด้วยโครงการโอเพนซอร์ส Android เต็มรูปแบบ ขณะที่ระบบบิลด์ ในการใช้งานจริงนั้นแตกต่างกัน ความคล้ายคลึงกันของทั้ง 2 แบบคือความตั้งใจ การตัดสินใจออกแบบที่มุ่งให้นักพัฒนาแอปพลิเคชันสามารถนำ ซอร์สโค้ดสำหรับไลบรารีภายนอก

ข้อมูลเบื้องต้น

ก่อนดูรายละเอียดของไวยากรณ์ คุณควรเริ่มต้นด้วยการทำความเข้าใจข้อมูลพื้นฐานเกี่ยวกับสิ่งที่ไฟล์ 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 สร้างบริบทการดำเนินการที่ตัวแปรทั้งหมดอยู่ส่วนกลาง คุณต้องประกาศตัวแปรนี้ (อีกครั้ง) ก่อนอธิบายแต่ละข้อบังคับ

จากนั้นตัวแปร 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 ที่มีความคิดเห็นให้ดู นอกจากนี้ ตัวอย่าง: Native-activity จะให้คำอธิบายโดยละเอียดเกี่ยวกับไฟล์ 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)

คลังที่ใช้ร่วมกัน

ตัวแปรนี้ชี้ไปยังสคริปต์บิลด์ที่รวบรวมข้อมูลทั้งหมดเกี่ยวกับ โมดูลที่คุณระบุไว้ในตัวแปร LOCAL_XXX รวมทั้งกำหนดวิธีการ สร้างไลบรารีที่ใช้ร่วมกันเป้าหมายจากแหล่งที่มาที่คุณแสดงรายการไว้ โปรดทราบว่าการใช้สิ่งนี้ คุณต้องกำหนดค่าให้กับ LOCAL_MODULE และ LOCAL_SRC_FILES เป็นอย่างน้อย (ดูข้อมูลเพิ่มเติมเกี่ยวกับตัวแปรเหล่านี้ได้ที่ ตัวแปรคำอธิบายโมดูล)

ไวยากรณ์สําหรับการใช้ตัวแปรนี้มีดังนี้

include $(BUILD_SHARED_LIBRARY)

ตัวแปรไลบรารีที่ใช้ร่วมกันทําให้ระบบบิลด์สร้างไฟล์ไลบรารีที่มีนามสกุล .so

คลังสถิติสถิติ

ตัวแปรของ BUILD_SHARED_LIBRARY ที่ใช้สร้างไลบรารีแบบคงที่ ระบบบิลด์จะไม่คัดลอกไลบรารีแบบคงที่ลงในโปรเจ็กต์/แพ็กเกจ แต่จะใช้ไลบรารีดังกล่าวเพื่อสร้างไลบรารีที่ใช้ร่วมกันได้ (ดู LOCAL_STATIC_LIBRARIES และ LOCAL_WHOLE_STATIC_LIBRARIES ด้านล่าง) ไวยากรณ์สำหรับการใช้ตัวแปรนี้คือ

include $(BUILD_STATIC_LIBRARY)

ตัวแปรไลบรารีแบบคงที่จะทำให้ระบบสร้างไลบรารีที่มี ส่วนขยาย .a

คลังที่สร้างไว้ล่วงหน้า

ชี้ไปที่สคริปต์บิลด์ที่ใช้ระบุไลบรารีที่ใช้ร่วมกันที่สร้างไว้ล่วงหน้า เลิกชอบ ในกรณีของ 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 สอดคล้องกับ API ของ Android ระดับ 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 และสถาปัตยกรรมที่ต่างกัน

ตัวอย่างต่อไปนี้แสดงวิธีตรวจสอบว่า 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

ตัวแปรคำอธิบายโมดูล

ตัวแปรในส่วนนี้จะอธิบายโมดูลของคุณให้กับระบบบิลด์ คำอธิบายแต่ละข้อของข้อบังคับควรเป็นไปตามขั้นตอนพื้นฐานต่อไปนี้

1. เริ่มต้นหรือยกเลิกการกำหนดตัวแปรที่เชื่อมโยงกับโมดูล โดยใช้ ตัวแปร CLEAR_VARS
2. กําหนดค่าให้กับตัวแปรที่ใช้อธิบายข้อบังคับ
3. ตั้งค่าระบบการสร้าง 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 ให้อ้างอิงโมดูลด้วยชื่อเดิม ตัวอย่างเช่น URL ต่อไปนี้ ผลลัพธ์บรรทัดในการสร้างโมดูลไลบรารีที่ใช้ร่วมกันชื่อ 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_FEATURES

คุณสามารถใช้ตัวแปรที่ไม่บังคับนี้เพื่อระบุว่าโค้ดของคุณใช้ฟีเจอร์ C++ ที่เฉพาะเจาะจง ช่วยให้มีการแฟล็กคอมไพเลอร์และ Linker ที่เหมาะสมระหว่างการสร้าง ขั้นตอนได้ สําหรับไบนารีที่สร้างไว้ล่วงหน้า ตัวแปรนี้จะประกาศฟีเจอร์ที่ไบนารีนั้นใช้ด้วย ซึ่งช่วยให้การลิงก์ขั้นสุดท้ายทํางานได้อย่างถูกต้อง เราขอแนะนําให้คุณใช้ตัวแปรนี้แทนการเปิดใช้ -frtti และ -fexceptions ในคําจํากัดความ LOCAL_CPPFLAGS โดยตรง

การใช้ตัวแปรนี้ช่วยให้ระบบบิลด์ใช้แฟล็กที่เหมาะสมสำหรับ แต่ละโมดูล การใช้ LOCAL_CPPFLAGS จะทำให้คอมไพเลอร์ใช้ Flag ที่ระบุทั้งหมดสำหรับโมดูลทั้งหมด โดยไม่คำนึงถึงความต้องการจริง

เช่น เพื่อระบุว่าโค้ดของคุณใช้ RTTI (ข้อมูลประเภทรันไทม์) เขียน:

LOCAL_CPP_FEATURES := rtti

หากต้องการระบุว่าโค้ดของคุณใช้ข้อยกเว้น C++ ให้เขียนดังนี้

LOCAL_CPP_FEATURES := exceptions

นอกจากนี้ คุณยังระบุค่าหลายค่าสําหรับตัวแปรนี้ได้อีกด้วย เช่น

LOCAL_CPP_FEATURES := rtti features

ลำดับที่คุณอธิบายค่านั้นไม่สำคัญ

Local_C_INCLUDES

คุณสามารถใช้ตัวแปรที่ไม่บังคับนี้เพื่อระบุรายการเส้นทางที่สัมพันธ์กับ ไดเรกทอรี root ของ NDK เพื่อเพิ่มไปยังเส้นทางการค้นหาเมื่อรวบรวมข้อมูลทั้งหมด แหล่งที่มา (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

แฟล็กที่จะส่งไปยัง Clang เมื่อสร้างไฟล์ .s หรือ .S

LOCAL_ASMFLAGS

Flag ที่ส่งไปยัง yasm เมื่อสร้างไฟล์ .asm

LOCAL_CFLAGS

แฟล็กที่จะส่งไปยัง Clang เมื่อสร้าง C, C++ และบางแฟล็ก ไฟล์ต้นฉบับ Assembly (.s และ .S แต่ไม่ใช่ .asm) ความสามารถในการทำเช่นนี้อาจมีประโยชน์สำหรับการระบุคำจำกัดความของมาโครหรือตัวเลือกการคอมไพล์เพิ่มเติม ใช้ LOCAL_CPPFLAGS เพื่อระบุ Flag สำหรับ C++ เท่านั้น ใช้ LOCAL_CONLYFLAGS เพื่อระบุ Flag สำหรับ C เท่านั้น

พยายามอย่าเปลี่ยนระดับการเพิ่มประสิทธิภาพ/การแก้ไขข้อบกพร่องในไฟล์ Android.mk ระบบบิลด์สามารถจัดการการตั้งค่านี้ให้คุณโดยอัตโนมัติ โดยใช้ ข้อมูลที่เกี่ยวข้องในไฟล์ Application.mk การทำเช่นนี้จะช่วยให้ระบบบิลด์สร้างไฟล์ข้อมูลที่มีประโยชน์ซึ่งใช้ในการแก้ไขข้อบกพร่องได้

คุณสามารถระบุเส้นทางรวมเพิ่มเติมได้ด้วยการเขียนดังนี้

LOCAL_CFLAGS += -I<path>,

อย่างไรก็ตาม การใช้ LOCAL_C_INCLUDES เพื่อวัตถุประสงค์นี้จะดีกว่า เนื่องจาก จึงทำให้สามารถใช้เส้นทางที่มีอยู่สำหรับการแก้ไขข้อบกพร่องของระบบด้วย ndk-gdb

LOCAL_CONLYFLAGS

แฟล็กซึ่งจะส่งไปยัง Clang เมื่อคอมไพล์ซอร์ส C เลิกชอบ LOCAL_CFLAGS, LOCAL_CONLYFLAGS จะไม่ถูกส่งผ่านไปยัง Clang เมื่อคอมไพล์ C++ หรือแหล่งที่มาของการประกอบ

LOCAL_CPPFLAGS

ชุด Flag คอมไพเลอร์ที่ไม่บังคับซึ่งจะส่งเมื่อสร้างไฟล์ซอร์ส C++ เท่านั้น โดยจะปรากฏหลัง LOCAL_CFLAGS ใน บรรทัดคำสั่ง ใช้ LOCAL_CFLAGS เพื่อระบุ Flag สำหรับทั้ง C และ C++

ไลบรารี LOCAL_STATIC_LIBRARIES

ตัวแปรนี้จัดเก็บรายการโมดูลไลบรารีแบบคงที่ซึ่งฟังก์ชัน ขึ้นอยู่กับ

หากโมดูลปัจจุบันเป็นไลบรารีที่ใช้ร่วมกันหรือไฟล์ปฏิบัติการ ตัวแปรนี้จะบังคับให้ลิงก์ไลบรารีเหล่านี้เข้ากับไบนารีที่ได้

หากโมดูลปัจจุบันเป็นไลบรารีแบบคงที่ ตัวแปรนี้เพียงแค่ระบุว่า โมดูลอื่นๆ ที่ขึ้นอยู่กับโมดูลปัจจุบัน จะขึ้นอยู่กับโมดูล ห้องสมุด

LOCAL_SHARED_LIBRARIES

ตัวแปรนี้คือรายการโมดูลไลบรารีที่ใช้ร่วมกันซึ่งโมดูลนี้ใช้อยู่ ขึ้นอยู่กับรันไทม์ ข้อมูลนี้เป็นสิ่งจำเป็นในเวลาที่ลิงก์ และเพื่อฝัง ข้อมูลที่เกี่ยวข้องในไฟล์ที่สร้างขึ้น

LOCAL_WHOLE_STATIC_LIBRARIES

ตัวแปรนี้เป็นตัวแปรของ LOCAL_STATIC_LIBRARIES และแสดงว่า Linker ควรถือว่าโมดูลไลบรารีที่เกี่ยวข้องเป็นไฟล์เก็บถาวรทั้งไฟล์ ดูข้อมูลเพิ่มเติมเกี่ยวกับไฟล์เก็บถาวรทั้งหมดได้ที่เอกสารประกอบ GNU ld สำหรับ Flag --whole-archive

ตัวแปรนี้มีประโยชน์เมื่อมีทรัพยากร Dependency แบบวงกลมจากหลายๆ กลุ่ม และไลบรารีแบบคงที่ เมื่อคุณใช้ตัวแปรนี้เพื่อสร้างไลบรารีที่ใช้ร่วมกัน ระบบจะบังคับให้ระบบบิลด์เพิ่มไฟล์ออบเจ็กต์ทั้งหมดจากไลบรารีแบบคงที่ลงในไบนารีสุดท้าย อย่างไรก็ตาม จะไม่เป็นความจริงเมื่อสร้างไฟล์ปฏิบัติการ

LOCAL_LDLIBS

ตัวแปรนี้มีรายการแฟล็ก Linker เพิ่มเติมสำหรับใช้ในอาคาร ไลบรารีที่ใช้ร่วมกันหรือไฟล์ปฏิบัติการของคุณ ซึ่งจะช่วยให้คุณใช้คำนำหน้า -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

ตัวแปรนี้สําคัญเฉพาะเมื่อคุณกําหนดเป้าหมาย ABI armeabi-v7a เท่านั้น ทั้งนี้ อนุญาตให้ใช้คอมไพเลอร์ของ ARM Advanced SIMD (NEON) ใน C และ C++ ได้ รวมถึงคำแนะนำ NEON ในไฟล์ Assembly

โปรดทราบว่า 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

ตัวแปรนี้บันทึกชุดแฟล็กคอมไพเลอร์ 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)

ในส่วนนี้ ระบบบิลด์จะส่งแฟล็ก -DFOO=1 และ -DBAR=2 ไปยังคอมไพเลอร์ เมื่อสร้างbar.c นอกจากนี้ยังเพิ่ม Flag ที่ส่งออกไว้หน้า Flag ของโมดูลของคุณ LOCAL_CFLAGSเพื่อให้คุณลบล้างค่าได้อย่างง่ายดาย

นอกจากนี้ ความสัมพันธ์ระหว่างโมดูลต่างๆ เป็นแบบทรานซิทีฟ: หาก 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 แต่มีไว้สำหรับแฟล็ก 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 เมื่อสร้างไลบรารีแบบคงที่ การดำเนินการนี้จะ สร้างที่เก็บถาวรแบบ Thin ซึ่งเป็นไฟล์ไลบรารีที่ไม่มีไฟล์ออบเจ็กต์ แต่ให้ส่งเส้นทางไปยังออบเจ็กต์จริงที่ตามปกติ มี

ซึ่งมีประโยชน์ในการลดขนาดเอาต์พุตของบิลด์ ข้อเสียก็คือ ไลบรารีดังกล่าวไม่สามารถย้ายไปยังตำแหน่งอื่น (ทุกเส้นทางภายใน เป็นแบบสัมพัทธ์)

ค่าที่ถูกต้องคือ true, false หรือว่างเปล่า คุณสามารถกำหนดค่าเริ่มต้นได้ใน Application.mk ผ่านตัวแปร APP_THIN_ARCHIVE

LOCAL_FILTER_ASM

กําหนดตัวแปรนี้เป็นคําสั่งเชลล์ที่ระบบบิลด์จะใช้เพื่อกรองไฟล์แอสเซมบลีที่ดึงข้อมูลหรือสร้างจากไฟล์ที่คุณระบุสําหรับ LOCAL_SRC_FILES การกําหนดตัวแปรนี้ทําให้เกิดเหตุการณ์ต่อไปนี้

1. ระบบบิลด์จะสร้างไฟล์การประกอบชั่วคราวจากซอร์ส C หรือ C++ ใดก็ได้ แทนการรวบรวมเป็นไฟล์ออบเจ็กต์
2. ระบบบิลด์จะเรียกใช้คำสั่ง Shell ใน 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" สอดคล้องกับแอสเซมเบลอร์ ตัวกรองต้องเป็นคำสั่ง Shell แบบสแตนด์อโลนที่ใช้ชื่อของอินพุต เป็นอาร์กิวเมนต์แรก และชื่อไฟล์เอาต์พุตเป็นอาร์กิวเมนต์ที่สอง เช่น

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

มาโครฟังก์ชันที่ NDK มีให้

ส่วนนี้จะอธิบายมาโครฟังก์ชัน GNU Make ที่ NDK มีให้ ใช้ $(call <function>) เพื่อประเมินผล กลับมีข้อมูลที่เป็นข้อความ

ไดเรกทอรีของฉัน

มาโครนี้จะส่งคืนเส้นทางของ Makefile ที่รวมไว้ล่าสุด ซึ่งโดยทั่วไปจะเป็น ไดเรกทอรีปัจจุบันของ 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

ปัญหาคือ การเรียกใช้ 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

this-makefile

แสดงเส้นทางของไฟล์บิลด์ปัจจุบัน (ซึ่งระบบบิลด์ใช้ชื่อว่า )

ไฟล์หลัก

แสดงผลเส้นทางของไฟล์ Make หลักในต้นไม้การรวม (เส้นทางของไฟล์ Make ที่รวมไฟล์ Make ปัจจุบัน)

grand-parent-makefile

แสดงผลเส้นทางของไฟล์ Make ระดับปู่ย่าตายายในต้นไม้การรวม (เส้นทางของไฟล์ Make ที่รวมไฟล์ Make ในปัจจุบัน)

โมดูลนำเข้า

ฟังก์ชันที่ช่วยให้คุณค้นหาและรวมไฟล์ Android.mk ของโมดูลได้โดย ชื่อของโมดูล ตัวอย่างทั่วไปมีดังนี้

$(call import-module,<name>)

ในตัวอย่างนี้ ระบบบิลด์จะมองหาโมดูลที่ติดแท็ก <name> ใน รายการไดเรกทอรีที่อ้างอิงว่าสภาพแวดล้อม NDK_MODULE_PATH ของคุณ และรวมไฟล์ Android.mk ไว้ให้คุณโดยอัตโนมัติ