Android.mk

בדף הזה מתואר התחביר של קובץ ה-build של Android.mk שמשמש את ndk-build.

סקירה כללית

הקובץ Android.mk נמצא בספריית משנה של jni/ של הפרויקט ומתאר את המקורות והספריות המשותפות למערכת ה-build. זה בעצם מקטע קטן של קובץ GNU שמערכת ה-build מנתחת פעם אחת, עוד. הקובץ Android.mk שימושי לקביעת הגדרות ברמת הפרויקט Application.mk, מערכת ה-build ומשתני הסביבה יוצאים ולא מוגדר. היא גם יכולה לשנות הגדרות ברמת הפרויקט למודולים ספציפיים.

התחביר של Android.mk מאפשר לקבץ את המקורות במודולים. מודול הוא ספרייה סטטית, ספרייה משותפת או דף נפרד קובץ הפעלה. אפשר להגדיר מודול אחד או יותר בכל קובץ Android.mk, וגם אתם יכולים להשתמש באותו קובץ מקור בכמה מודולים. רק מערכת ה-build מציבה ספריות משותפות בחבילת האפליקציה שלך. בנוסף, סטטי ספריות יכולות ליצור ספריות משותפות.

נוסף לספריות אריזה, מערכת ה-build מטפלת במגוון רחב של עבורך. לדוגמה, לא צריך להציג קובצי כותרות או תוכן בוטה של יחסי התלות בין הקבצים שנוצרו בקובץ Android.mk. גרסת ה-build של NDK המערכת מחשבת את הקשרים האלה בשבילכם באופן אוטומטי. כתוצאה מכך, יוכלו להפיק תועלת מתמיכה חדשה בפלטפורמה או בצרור הכלים ב-NDK בעתיד גרסאות בלי לגעת בקובץ Android.mk.

התחביר של הקובץ הזה קרוב מאוד לזה שבו נעשה שימוש בקובצי Android.mk שמופצת באמצעות פרויקט הקוד הפתוח המלא של Android. אומנם מערכת ה-build שמשתמשת בהם שונה, הדמיון ביניהם החלטה שנועדה להקל על מפתחי אפליקציות לעשות שימוש חוזר את קוד המקור לספריות חיצוניות.

יסודות

לפני לחקור לעומק את התחביר, כדאי להתחיל בהבנה את העקרונות הבסיסיים של קובץ Android.mk. הקטע הזה משתמש קובץ Android.mk בדוגמת Hello-JNI למטרה הזו, עם הסבר על התפקיד שמופעלת כל שורה בקובץ.

קובץ Android.mk חייב להתחיל בהגדרת המשתנה LOCAL_PATH:

LOCAL_PATH := $(call my-dir)

המשתנה הזה מציין את המיקום של קובצי המקור בפיתוח עץ. כאן, פונקציית המאקרו my-dir, שסופקה על ידי מערכת ה-build, מחזירה הנתיב של הספרייה הנוכחית (הספרייה שמכילה את הפקודה Android.mk בקובץ עצמו).

השורה הבאה מצהירה על המשתנה CLEAR_VARS, שהערך שלו הוא מערכת ה-build מספקת.

include $(CLEAR_VARS)

המשתנה CLEAR_VARS מפנה לקובץ Makefile מיוחד של GNU שמנקה הרבה LOCAL_XXX משתנים עבורך, כמו LOCAL_MODULE, LOCAL_SRC_FILES ו LOCAL_STATIC_LIBRARIES לתשומת ליבכם: לא מתבצע ניקוי של LOCAL_PATH. הזה חייב לשמור על הערך שלו מפני שהמערכת מנתחת את כל הקבצים של בקרת ה-build בהקשר ביצוע יחיד של GNU Make שבו כל המשתנים הם גלובליים. צריך (להצהיר מחדש) על המשתנה הזה לפני התיאור של כל מודול.

לאחר מכן, המשתנה LOCAL_MODULE שומר את שם המודול שרוצים לשמור build. צריך להשתמש במשתנה הזה פעם אחת בכל מודול באפליקציה.

LOCAL_MODULE := hello-jni

כל שם מודול חייב להיות ייחודי ולא מכיל רווחים. מערכת ה-build, כשהיא יוצרת את קובץ הספרייה המשותפת הסופי, מוסיפה באופן אוטומטי את קידומת וסיומת לשם שהקצית ל-LOCAL_MODULE. לדוגמה, בדוגמה שמופיעה למעלה נוצרת ספרייה שנקראת libhello-jni.so

הערה: אם שם המודול כבר מתחיל ב-lib, מערכת ה-build לא להוסיף תחילית 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 מפנה לסקריפט Makefile של GNU שאוספת את כל המידע שהגדרתם ב-LOCAL_XXX משתנים, כי include מהזמן האחרון. הסקריפט קובע מה ליצור ואיך לעשות אותו.

קיימות דוגמאות מורכבות יותר בספריות הדוגמאות עם הערות Android.mk קבצים שאפשר לצפות בהם. בנוסף, דוגמה: פעילות מותאמת מספק הסבר מפורט לגבי הקובץ Android.mk של הדוגמה. לבסוף, הקטע משתנים ופקודות מאקרו מספק מידע נוסף על המשתנים .

משתנים ופקודות מאקרו

מערכת ה-build מספקת משתנים אפשריים רבים לשימוש בקובץ Android.mk. רבים מהמשתנים האלה מגיעים עם ערכים שהוקצו מראש. את האחרים מקצים.

בנוסף למשתנים האלה תוכלו גם להגדיר שרירותיות משלכם. אם תעשה זאת, אל תמחק חשוב לזכור שמערכת ה-build של NDK שומרת את שמות המשתנים הבאים:

• שמות שמתחילים ב-LOCAL_, למשל LOCAL_MODULE.
• שמות שמתחילים ב-PRIVATE_, ב-NDK_ או ב-APP. מערכת ה-build משתמשת אותם באופן פנימי.
• שמות באותיות קטנות, כמו my-dir. מערכת ה-build משתמשת בהם באופן פנימי, נו.

אם אתם צריכים להגדיר משתני נוחות משלכם בקובץ Android.mk, מומלץ להוסיף את MY_ לשמות שלהם.

משתני הכללה שמוגדרים על ידי NDK

הקטע הזה מתאר את משתני ה-GNU ש-מערכת ה-build מגדירה לפני ניתוח הקובץ Android.mk. בנסיבות מסוימות, ה-NDK יכול לנתח את קובץ Android.mk כמה פעמים, תוך שימוש בהגדרה שונה עבור חלק מהמשתנים האלה בכל פעם.

CLEAR_VARS

המשתנה הזה מפנה לסקריפט build שמגדיר כמעט את כל LOCAL_XXX המשתנים שמפורטים בקטע "משתנים מוגדרים על ידי מפתחים" שבהמשך. שימוש בטיוטה הזו כדי לכלול את הסקריפט לפני תיאור של מודול חדש. התחביר של היא:

include $(CLEAR_VARS)

BUILD_EXECUTABLE

המשתנה הזה מפנה לסקריפט של build שאוסף את כל המידע על המודול שסיפקתם במשתנים של LOCAL_XXX, וקובע איך ליצור קובץ יעד להפעלה מהמקורות שציינת. שימו לב שהשימוש הסקריפט מחייב שכבר הקצית ערכים ל-LOCAL_MODULE LOCAL_SRC_FILES, לכל הפחות (למידע נוסף על המשתנים האלה, אפשר לעיין במאמר משתנים של תיאור מודול).

התחביר לשימוש במשתנה הזה הוא:

include $(BUILD_EXECUTABLE)

הערה: רוב האפליקציות ל-Android לא כוללות קובצי הפעלה, אבל הן שימושיות יצירת בדיקות יחידה וכלים אחרים לניפוי באגים.

BUILD_SHARED_LIBRARY

המשתנה הזה מפנה לסקריפט של build שאוסף את כל המידע על המודול שסיפקתם במשתנים של LOCAL_XXX, וקובע איך ליצור ספריית יעד משותפת מהמקורות שציינת. שימו לב שהשימוש הסקריפט מחייב שכבר הקצית ערכים ל-LOCAL_MODULE LOCAL_SRC_FILES, לכל הפחות (למידע נוסף על המשתנים האלה, אפשר לעיין במאמר משתנים של תיאור מודול).

התחביר לשימוש במשתנה הזה הוא:

include $(BUILD_SHARED_LIBRARY)

משתנה של ספרייה משותפת גורם למערכת ה-build ליצור קובץ ספרייה באמצעות סיומת .so.

BUILD_staticIC_LIBRARY

וריאנט של BUILD_SHARED_LIBRARY המשמש ליצירת ספרייה סטטית. מערכת ה-build לא מעתיקה ספריות סטטיות לפרויקט/לחבילות שלכם, אלא יכולים להשתמש בהם כדי ליצור ספריות משותפות (ראו LOCAL_STATIC_LIBRARIES LOCAL_WHOLE_STATIC_LIBRARIES, למטה). התחביר לשימוש במשתנה הזה הוא:

include $(BUILD_STATIC_LIBRARY)

משתנה ספרייה סטטית גורם למערכת ה-build ליצור ספרייה עם התוסף .a.

PREBUILT_SHARED_LIBRARY

מצביע על סקריפט build שמשמש לציון ספרייה משותפת שהוגדרה מראש. ביטול לייק ב: במקרה של BUILD_SHARED_LIBRARY ו-BUILD_STATIC_LIBRARY, כאן הערך של LOCAL_SRC_FILES לא יכול להיות קובץ מקור. במקום זאת, הוא חייב להיות נתיב יחיד ספרייה משותפת שהוגדרה מראש, כמו foo/libfoo.so. התחביר לשימוש הוא:

include $(PREBUILT_SHARED_LIBRARY)

תוכלו גם להפנות לספרייה שהוגדרה מראש במודול אחר באמצעות משתנה LOCAL_PREBUILTS. למידע נוסף על השימוש בנכסים מוכנים מראש, שימוש בספריות מוכנות מראש.

PREBUILT_staticIC_LIBRARY

זהה ל-PREBUILT_SHARED_LIBRARY, אבל לספרייה סטטית שהוגדרה מראש. עבור למידע נוסף על השימוש בתבניות מוכנות מראש, אפשר לעיין במאמר שימוש בספריות מוכנות מראש.

משתני מידע יעד

מערכת ה-build מנתחת את Android.mk פעם אחת לכל ממשק ABI שצוין ב-APP_ABI שמוגדר בדרך כלל בקובץ Application.mk. אם APP_ABI הוא all, אז מערכת ה-build מנתחת Android.mk פעם אחת לכל ABI וה-NDK נתמך. בקטע הזה מתוארים משתנים שמערכת ה-build מגדירה בכל פעם מנתח את Android.mk.

TARGET_ARCH

משפחת המעבדים (CPU) שמערכת ה-build מטרגטת בזמן שהיא מנתחת את Android.mk חדש. המשתנה יהיה אחד מהערכים הבאים: arm, arm64, x86 או x86_64.

TARGET_PLATFORM

המספר ברמת ה-API ב-Android שמערכת ה-build מטרגטת בזמן שהיא מנתחת את הנתונים האלה קובץ Android.mk. לדוגמה, תמונות המערכת של Android 5.1 מתאימות אל רמת API ב-Android 22: android-22. לרשימה מלאה של שמות הפלטפורמות לתמונות המתאימות של המערכת של Android, ראו ממשקי API נייטיב. הדוגמה הבאה מראה את התחביר לשימוש במשתנה הזה:

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

TARGET_ARCH_ABI

ה-ABI שמערכת ה-build מטרגטת בזמן שהיא מנתחת את קובץ ה-Android.mk הזה. בטבלה 1 מוצגת הגדרת ה-ABI שמשמשת לכל ארכיטקטורה ומעבדים (CPU) נתמכים.

טבלה 1. הגדרות של ממשק ABI לארכיטקטורות ולמעבדים שונים.

מעבד (CPU) וארכיטקטורה	הגדרה
ARMv7	armeabi-v7a
ARMv8 AArch64	arm64-v8a
i686	x86
x86-64	x86_64

בדוגמה הבאה אפשר לראות איך בודקים אם היעד ARMv8 AArch64 הוא 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

משתנים של תיאור מודול

המשתנים בקטע הזה מתארים את המודול שלכם למערכת ה-build. כל אחד תיאור המודול צריך להתאים לתהליך הבסיסי הבא:

1. לאתחל או לבטל את ההגדרה של המשתנים המשויכים למודול, באמצעות משתנה CLEAR_VARS.
2. מקצים ערכים למשתנים שמשמשים לתיאור המודול.
3. מגדירים את מערכת ה-build של NDK לשימוש בסקריפט ה-build המתאים למודול באמצעות המשתנה BUILD_XXX.

LOCAL_PATH

המשתנה הזה משמש לקביעת הנתיב של הקובץ הנוכחי. צריך להגדיר אותה בתחילת הקובץ Android.mk. בדוגמה הבאה אפשר לראות איך לבצע כך:

LOCAL_PATH := $(call my-dir)

הסקריפט שאליו נקודות CLEAR_VARS לא מנקה את המשתנה הזה. לכן, צריך להגדיר אותו פעם אחת בלבד, גם אם הקובץ Android.mk מתאר מודולים מרובים.

LOCAL_MODULE

המשתנה הזה שומר את שם המודול שלכם. הוא חייב להיות ייחודי בכל המודולים שמות, ולא יכולים להכיל רווחים. צריך להגדיר אותה לפני שכוללים טקסט סקריפטים (חוץ מזה של CLEAR_VARS). אין צורך להוסיף את lib קידומת או סיומת הקובץ .so או .a; מערכת ה-build הופכת את באופן אוטומטי. בכל Android.mk ו-Application.mk מתייחסים למודול לפי השם שבו לא בוצעו שינויים. לדוגמה, התוצאה של יצירת מודול ספרייה משותפת בשם libfoo.so:

LOCAL_MODULE := "foo"

אם רוצים שלמודול שנוצר יהיה שם שונה מ-lib + הערך של LOCAL_MODULE, אפשר להשתמש במשתנה LOCAL_MODULE_FILENAME כדי לתת שיצרנו עבורך שם לבחירתך.

LOCAL_MODULE_FILENAME

המשתנה האופציונלי הזה מאפשר לשנות את השמות ממערכת ה-build משתמש כברירת מחדל בקבצים שהוא יוצר. לדוגמה, אם השם של LOCAL_MODULE הוא foo. אפשר לאלץ את המערכת לקרוא לקובץ שהיא יוצרת libnewfoo. הדוגמה הבאה ממחישה איך לעשות זאת:

LOCAL_MODULE := foo
LOCAL_MODULE_FILENAME := libnewfoo

עבור מודול ספרייה משותפת, הדוגמה הזו תיצור קובץ בשם libnewfoo.so

הערה: אי אפשר לשנות את נתיב הקובץ או סיומת הקובץ.

LOCAL_SRC_FILES

המשתנה הזה מכיל את רשימת קובצי המקור שמערכת ה-build משתמשת בהם כדי היא ליצור את המודול. הצגת רשימה רק של הקבצים שמערכת ה-build מעבירה בפועל מהדר, מכיוון שמערכת ה-build תחשב באופן אוטומטי את כל של יחסי התלות. שימו לב שאפשר להשתמש גם ביחס ל-LOCAL_PATH וגם במספר מוחלט נתיבי קבצים.

מומלץ להימנע מנתיבי קבצים מוחלטים; הנתיבים היחסיים הופכים את Android.mk יותר ניידות.

הערה: בקובצי build תמיד צריך להשתמש בקו נטוי (/) בסגנון יוניקס. גרסת ה-build המערכת לא מטפלת כראוי בלוכסנים הפוכים בסגנון Windows (\).

LOCAL_CPP_תוספים

ניתן להשתמש במשתנה האופציונלי הזה כדי לציין סיומת קובץ שאינה .cpp לקובצי המקור מסוג C++. לדוגמה, השורה הבאה משנה את לתוסף ל-.cxx. (ההגדרה חייבת לכלול את הנקודה).

LOCAL_CPP_EXTENSION := .cxx

ניתן להשתמש במשתנה הזה כדי לציין כמה תוספים. לדוגמה:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

ניתן להשתמש במשתנה האופציונלי הזה כדי לציין שהקוד מסתמך על תכונות C++. היא מפעילה את דגלי המהדר והקישור הנכונים במהלך ה-build. תהליך האימות. לקבצים בינאריים מוכנים מראש, המשתנה הזה מצהיר גם אילו מהם כוללים הבינארית תלויה, וכך היא עוזרת להבטיח שהקישור הסופי פועל כמו שצריך. רביעי מומלץ להשתמש במשתנה הזה במקום להפעיל את -frtti ואת -fexceptions ישירות בהגדרה של LOCAL_CPPFLAGS.

שימוש במשתנה הזה מאפשר למערכת ה-build להשתמש בדגלים המתאימים בכל מודול. שימוש ב-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++ ו-Assembly). לדוגמה:

LOCAL_C_INCLUDES := sources/foo

או אפילו:

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

צריך להגדיר את המשתנה הזה לפני שמגדירים סימוני הכללה תואמים באמצעות LOCAL_CFLAGS או LOCAL_CPPFLAGS.

מערכת ה-build גם משתמשת בנתיבי LOCAL_C_INCLUDES באופן אוטומטי בהפעלה ניפוי באגים מקורי באמצעות ndk-gdb.

LOCAL_CFLAGS

המשתנה האופציונלי הזה מגדיר דגלי מהדר למערכת ה-build להעביר פיתוח קובצי מקור וגם C++. היכולת לעשות זאת יכולה להועיל מאוד לציון הגדרות מאקרו נוספות או אפשרויות הידור. שימוש בפורמט LOCAL_CPPFLAGS כדי לציין דגלים עבור C++ בלבד.

מומלץ לא לשנות את רמת האופטימיזציה או ניפוי הבאגים בקובץ Android.mk. מערכת ה-build יכולה לטפל בהגדרה הזו בשבילך באופן אוטומטי באמצעות מידע רלוונטי בקובץ Application.mk. ככה עושים את זה, build כדי ליצור קובצי נתונים שימושיים שמשמשים במהלך ניפוי באגים.

אפשר לציין נתיבי הכללה נוספים על ידי כתיבה:

LOCAL_CFLAGS += -I<path>,

עם זאת, עדיף להשתמש ב-LOCAL_C_INCLUDES למטרה הזו, כי הוא מאפשר גם להשתמש בנתיבים הזמינים לניפוי באגים מקורי עם ndk-gdb.

LOCAL_CPPFLAGS

קבוצה אופציונלית של דגלי מהדר שיועברו במהלך פיתוח מקור C++ קבצים בלבד. הם יופיעו אחרי ה-LOCAL_CFLAGS בחשבון המהדר בשורת הפקודה. השתמשו ב-LOCAL_CFLAGS כדי לציין דגלים גם ל-C וגם ל-C++.

LOCAL_staticIC_LIBRARIES

המשתנה הזה מאחסן את רשימת המודולים של הספריות הסטטיות שבהן תלוי.

אם המודול הנוכחי הוא ספרייה משותפת או קובץ הפעלה, המשתנה הזה לקשר את הספריות האלה לקובץ הבינארי שנוצר.

אם המודול הנוכחי הוא ספרייה סטטית, המשתנה פשוט מציין בהתאם למודול הנוכחי, תלויים גם הם של הספריות.

LOCAL_SHARED_LIBRARIES

המשתנה הזה הוא רשימת המודולים של הספריות המשותפות שבהן המודול הזה תלוי בזמן הריצה. המידע הזה נדרש בזמן הקישור, וכדי להטמיע את את המידע התואם בקובץ שנוצר.

LOCAL_WHOLE_staticIC_LIBRARIES

המשתנה הזה הוא וריאנט של LOCAL_STATIC_LIBRARIES, והוא מציין המקשר צריך להתייחס למודולים של הספריות המשויכים כארכיונים שלמים. עבור ניתן למצוא מידע נוסף על ארכיונים שלמים במסמכי התיעוד של GNU ld דגל --whole-archive.

המשתנה הזה שימושי כאשר יש יחסי תלות מעגליים בין מספר של ספריות סטטיות. כשמשתמשים במשתנה הזה כדי לבנות ספרייה משותפת, הוא לאלץ את מערכת ה-build להוסיף את כל קובצי האובייקטים מהספריות הסטטיות הבינארית הסופית. עם זאת, הכלל הזה לא נכון גם כשיוצרים קובצי הפעלה.

LOCAL_LDLIBS

המשתנה הזה מכיל את רשימת דגלי הקישור הנוספים לשימוש בבניין את הספרייה המשותפת או את קובץ ההפעלה. היא מאפשרת להשתמש בקידומת -l כדי להעביר השם של ספריות מערכת ספציפיות. לדוגמה, הדוגמה הבאה מראה את המקשר כדי ליצור מודול שמקשר אל /system/lib/libz.so בטעינה שעה:

LOCAL_LDLIBS := -lz

לרשימה של ספריות המערכת החשופות שאפשר לקשר אליהן ב-NDK הזה שלו, ראו ממשקי API נייטיב.

הערה: אם מגדירים את המשתנה הזה לספרייה סטטית, מערכת ה-build מתעלמת ואז ndk-build מדפיסה אזהרה.

LOCAL_LDFLAGS

רשימה של דגלים אחרים לקישור שבהם מערכת ה-build יכולה להשתמש במהלך הבנייה של ספרייה משותפת או קובץ הפעלה. לדוגמה, כדי להשתמש במנגנון לקישור בין ld.bfd ARM/X86:

LOCAL_LDFLAGS += -fuse-ld=bfd

הערה: אם מגדירים את המשתנה הזה לספרייה סטטית, מערכת ה-build מתעלמת ו-ndk-build מדפיסה אזהרה.

LOCAL_ALLOW_UNDEFINED_SYMBOLS

כברירת מחדל, כשמערכת ה-build נתקלת בהפניה לא מוגדרת כשמנסים ליצור קובץ משותף, תקבלו שגיאת סמל לא מוגדר. הזה יכולה לעזור לכם לאתר באגים בקוד המקור.

כדי להשבית את הבדיקה הזו, צריך להגדיר את המשתנה הזה ל-true. חשוב לשים לב שההגדרה הזו עשויה תגרום לטעינת הספרייה המשותפת בזמן הריצה.

הערה: אם מגדירים את המשתנה הזה לספרייה סטטית, מערכת ה-build מתעלמת ו-ndk-build מדפיסה אזהרה.

LOCAL_ARM_מצב

כברירת מחדל, מערכת ה-build יוצרת קבצים בינאריים של יעד ARM במצב תמונה ממוזערת, כל הוראה היא ברוחב 16 סיביות ומקושרת לספריות ה-STL ספריית thumb/. הגדרת המשתנה הזה כ-arm מאלצת את מערכת ה-build ליצור את קובצי האובייקט של המודול במצב arm 32-ביט. הדוגמה הבאה מראה כיצד לעשות זאת:

LOCAL_ARM_MODE := arm

אפשר גם להורות למערכת ה-build לבנות מקורות ספציפיים רק ב-arm על ידי הוספת הסיומת .arm לשמות הקבצים שבמקור. לדוגמה, מהדוגמה הבאה אומרת למערכת ה-build תמיד לבצע הידור של bar.c במצב ARM, אלא לבנות את foo.c בהתאם לערך של LOCAL_ARM_MODE.

LOCAL_SRC_FILES := foo.c bar.c.arm

הערה: אפשר גם לאלץ את מערכת ה-build ליצור קבצים בינאריים של ARM באמצעות הגדרה APP_OPTIM בקובץ Application.mk אל debug. ציון: debug מאלץ גרסת build של ARM כי הכלי לניפוי באגים ב-toolchain לא מטפל בקוד אהבתי כראוי.

LOCAL_ARM_NEON

המשתנה הזה חשוב רק כשמטרגטים את ה-ABI של armeabi-v7a. הוא מאפשר להשתמש באלמנטים של מהדר (compiler) ARM Advanced SIMD (NEON) ב-C וב-C++ מקורות, וגם הוראות NEON בקובצי Assembly.

שימו לב שלא כל המעבדים (CPU) מבוססי ARMv7 תומכים בתוספים של קבוצת ההוראות של NEON. לכן, צריך לבצע זיהוי של סביבת זמן הריצה כדי להשתמש בצורה בטוחה את הקוד הזה בזמן הריצה. למידע נוסף, ראו תמיכה ב-Neon תכונות מעבד (CPU).

לחלופין, אפשר להשתמש בסיומת .neon כדי לציין שמערכת ה-build. הכינו רק קובצי מקור ספציפיים בתמיכה של NEON. בדוגמה הבאה, מערכת ה-build יוצרת את foo.c בעזרת תמיכה באצבע וניאון, bar.c עם תמיכה ב'אגודל', ו-zoo.c עם תמיכה ב-ARM וב-NEON:

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

אם משתמשים בשתי הסיומות, .arm חייב להקדים את .neon.

LOCAL_DISABLE_FORMAT_STRING_CHECKS

כברירת מחדל, מערכת ה-build מהדרת קוד עם הגנה על מחרוזת פורמט. ביצוע אז יאלץ שגיאת מהדר אם משתמשים במחרוזת בפורמט לא קבוע פונקציה בסגנון 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)

כאן, מערכת ה-build מעבירה את הדגלים -DFOO=1 ו--DBAR=2 אל המהדר כשבונים את bar.c. הוא גם מצרף דגלים מיוצאים למודול של המודול LOCAL_CFLAGS כדי שתוכלו לשנות אותם בקלות.

בנוסף, הקשר בין המודולים הוא טרנזיטיבי: אם zoo תלוי bar, שבתורו תלוי ב-foo, zoo גם יורש את כל הדגלים יוצא מ-foo.

לבסוף, מערכת ה-build לא משתמשת בדגלים מיוצאים בזמן הבנייה של גרסת ה-build באופן מקומי (כלומר, בניית המודול שאת הדגלים שלו ניתן לייצא). כך שבדוגמה שלמעלה, הוא לא מעביר את -DFOO=1 למהדר במהלך הבנייה של foo/foo.c. שפת תרגום לפתח באופן מקומי, להשתמש ב-LOCAL_CFLAGS במקום זאת.

LOCAL_EXPORT_CPPFLAGS

המשתנה הזה זהה ל-LOCAL_EXPORT_CFLAGS, אבל רק לדגלי 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, והוא מנחה את מערכת ה-build להעביר שמות של ספריות מערכת ספציפיות למהדר. מוסיפים את -l בהתחלה של כל ספרייה שציינתם.

שימו לב שמערכת ה-build מצרפת סימונים של מנגנון קישור מיובאים לערך של במשתנה 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)

בדוגמה הזו, מערכת ה-build מוסיפה את -llog בסוף פקודת ה-linker כשהוא יוצר את libbar.so. הפעולה הזו אומרת למקשרים ש-libbar.so תלוי ב-foo, הוא תלוי גם בספריית הרישום ביומן של המערכת.

LOCAL_SHORT_CommandS

מגדירים את המשתנה הזה ל-true כשבמודול יש מספר גבוה מאוד של מקורות ו/או ספריות סטטיות או משותפות תלויות. הפעולה הזאת מאלצת את מערכת ה-build להשתמש בתחביר @ לארכיונים שמכילים קובצי אובייקטים מתווכים או קישורים של הספריות.

תכונה זו יכולה להיות שימושית ב-Windows, שבה שורת הפקודה מקבלת ערך מקסימלי של כולל רק 8,191 תווים, מה שעלול להיות קטן מדי לפרויקטים מורכבים. כמו כן משפיעה על האיסוף של קובצי מקור נפרדים, ולכן כמעט כל המהדר דגלים בתוך קובצי רשימה.

חשוב לזכור שכל ערך מלבד true יחזור להתנהגות ברירת המחדל. שלך יכול גם להגדיר APP_SHORT_COMMANDS בקובץ Application.mk כדי לאלץ התנהגות זו בכל המודולים בפרויקט.

לא מומלץ להפעיל את התכונה הזו כברירת מחדל, כי היא הופכת את ה-build לאט יותר.

LOCAL_THIN_ARCHIVE

צריך להגדיר את המשתנה הזה כ-true כשיוצרים ספריות סטטיות. הפעולה הזו תגרום ליצור ארכיון דל, קובץ ספרייה שלא מכיל קובצי אובייקטים, אלא רק נתיבים של קבצים לאובייקטים שבדרך כלל מכילים.

האפשרות הזו שימושית כדי להקטין את הגודל של פלט ה-build. החיסרון הוא לא ניתן להעביר ספריות כאלו למיקום אחר (כל הנתיבים שבתוכן הם יחסיים).

הערכים החוקיים הם true, false או ריקים. ניתן להגדיר ערך ברירת מחדל בשדה Application.mk באמצעות המשתנה APP_THIN_ARCHIVE.

הערה: המערכת מתעלמת מהקישור הזה למודולים של ספרייה לא סטטית או לספרייה סטטית מוכנה מראש האלה.

LOCAL_FILTER_ASM

צריך להגדיר את המשתנה הזה כפקודת מעטפת שמערכת ה-build תשתמש בה כדי לסנן קובצי ההרכבה שחולצו או נוצרו מהקבצים שציינת LOCAL_SRC_FILES הגדרת המשתנה הזה גורמת לשינויים הבאים:

1. מערכת ה-build יוצרת קובץ הרכבה זמני מכל מקור מסוג C או C++ במקום להרכיב אותם לקובץ אובייקט.
2. מערכת ה-build מריצים את פקודת המעטפת ב-LOCAL_FILTER_ASM בכל בקובץ הרכבה זמני ובכל קובץ הרכבה שרשום בכתובת LOCAL_SRC_FILES, וכך ייווצר קובץ הרכבה זמני נוסף.
3. מערכת ה-build משלבת את קובצי ההרכבה המסוננים האלה לקובץ אובייקט.

לדוגמה:

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

קטע זה מסביר את פקודות המאקרו של פונקציית GNU Make שה-NDK מספק. כדאי להשתמש $(call <function>) כדי להעריך אותם. הם מחזירים מידע טקסטואלי.

my-dir

המאקרו מחזיר את הנתיב של קובץ ה-makefile האחרון שנכלל, שלרוב הספרייה של Android.mk הנוכחית. my-dir שימושי להגדרה LOCAL_PATH בתחילת הקובץ Android.mk. לדוגמה:

LOCAL_PATH := $(call my-dir)

בשל אופן הפעולה של GNU Maker, המאקרו הזה באמת מחזיר את הנתיב ה-Makefile האחרון שמערכת ה-build כללה במהלך ניתוח הסקריפטים של ה-build. עבור לכן, אין לקרוא לפונקציה 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

קבצי מאכל-כל-subdir

הפונקציה מחזירה את הרשימה של Android.mk קבצים שנמצאים בכל ספריות המשנה של בנתיב my-dir הנוכחי.

אפשר להשתמש בפונקציה הזו כדי לספק היררכיות של ספריות מקורות מוטמעות עמוקות, במערכת ה-build. כברירת מחדל, ה-NDK מחפש רק קבצים בספרייה שמכיל את הקובץ Android.mk.

קובץ ה-makefile הזה

מחזירה את הנתיב של קובץ ה-getfile הנוכחי (שממנו מערכת ה-build קראה ).

קובץ הורה

מחזירה את הנתיב של קובץ ה-getfile של ההורה בעץ ההכללה (הנתיב של רכיב makefile שכלל את הקובץ הנוכחי).

קובץ סבא-סבתא

הפונקציה מחזירה את הנתיב של קובץ ה-Makefile הסב בעץ ההכללה (הנתיב של קובץ ה-Makefile שכלל את הקובץ הנוכחי).

מודול ייבוא

פונקציה שמאפשרת למצוא ולכלול את קובץ Android.mk של המודול באמצעות הוא שם המודול. דוגמה אופיינית היא:

$(call import-module,<name>)

בדוגמה זו, מערכת ה-build מחפשת את המודול שתויג ב-<name> רשימת הספריות שסביבת NDK_MODULE_PATH שלך מפנה אליהן בהפניות למשתנים, וכוללת את קובץ ה-Android.mk שלו באופן אוטומטי עבורכם.