Application.mk

במסמך הזה מוסבר על קובץ ה-build Application.mk שמשמש את ndk-build.

מומלץ לקרוא את הדף Concepts לפני אחת.

סקירה כללית

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

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

משתנים

APP_ABI

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

טבלה 1. הגדרות של APP_ABI לערכות שונות של הוראות.

הוראות מוגדרות	ערך
ARMv7 32 ביט	APP_ABI := armeabi-v7a
64-bit ARMv8 (AArch64)	APP_ABI := arm64-v8a
x86	APP_ABI := x86
x86-64	APP_ABI := x86_64
כל ממשקי ה-ABI הנתמכים (ברירת מחדל)	APP_ABI := all

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

APP_ABI := armeabi-v7a arm64-v8a x86

הערה: הסרטון externalNativeBuild של Gradle מתעלם מ-APP_ABI. במקום זאת, השתמשו abiFilters חסימה או (אם משתמשים ב'מספר חבילות APK') או חסימה של abi בתוך חסימה של splits.

לרשימה של כל ממשקי ה-ABI הנתמכים ופרטים על השימוש בהם המגבלות האלה מפורטות במאמר ממשקי ABI של Android.

APP_ASFLAGS

סימונים שיועברו למקבץ עבור כל קובץ מקור של הרכבה (.s וגם .S קבצים) בפרויקט.

הערה: יש הבדל בין ASFLAGS לבין ASMFLAGS. הדרך השנייה חלה באופן ספציפי על קובצי מקור של YASM (מידע נוסף זמין בקטע APP_ASMFLAGS).

APP_ASMFLAGS

סימונים שיועברו ל-YASM כאשר עבור כל קובצי המקור של YASM (.asm, x86/x86_64 בלבד).

APP_BUILD_SCRIPT

כברירת מחדל, ndk-build מניח שהקובץ Android.mk נמצא ב- jni/Android.mk ביחס לשורש הפרויקט.

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

הערה: ההגדרה externalNativeBuild של Gradle תגדיר את הפעולה הזו באופן אוטומטי על סמך את המשתנה externalNativeBuild.ndkBuild.path.

APP_CFLAGS

דגלים שיועברו לכל מהדרות של C/C++ בפרויקט.

הערה: כשכוללים נתיבים, צריך להשתמש ב-LOCAL_C_INCLUDES ולא באופן מפורש ב--I דגלים.

למידע נוסף: APP_CONLYFLAGS, APP_CPPFLAGS.

APP_CLANG_TIDY

צריך להגדיר את הערך כ-True כדי להפעיל Clang-סדר בכל המודולים בפרויקט. הושבת על ידי כברירת מחדל.

APP_CLANG_TIDY_FLAGS

דגלים להעביר את כל פעולות הניקוז של הקהל בפרויקט.

APP_CONLYFLAGS

דגלים שיועברו לכל ההדרות של C בפרויקט. הסימונים האלה לא משמש לקוד C++.

למידע נוסף: APP_CFLAGS, APP_CPPFLAGS.

APP_CPPFLAGS

דגלים שיועברו לכל מהדרות של C++ בפרויקט. הסימונים האלה לא שמשמש לקוד C.

למידע נוסף: APP_CFLAGS, APP_CONLYFLAGS.

APP_CXXFLAGS

הערה: צריך לתת עדיפות ל-APP_CPPFLAGS על פני APP_CXXFLAGS.

זהה ל-APP_CPPFLAGS, אבל יופיע אחרי APP_CPPFLAGS בהדרה הפקודה. לדוגמה:

APP_CPPFLAGS := -DFOO
APP_CXXFLAGS := -DBAR

התצורה שלמעלה תוביל לפקודת הידור שדומה ל-clang++ -DFOO -DBAR ולא ל-clang++ -DBAR -DFOO.

APP_DEBUG

צריך להגדיר את הערך True כדי ליצור אפליקציה שניתנת לניפוי באגים.

APP_LDFLAGS

הסימונים שיועברו כשמקשרים בין קובצי הפעלה לספריות משותפות.

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

APP_MANIFEST

נתיב מוחלט לקובץ AndroidManifest.xml.

כברירת מחדל, ייעשה שימוש ב-$(APP_PROJECT_PATH)/AndroidManifest.xml) אם הוא קיים.

הערה: כשמשתמשים ב-externalNativeBuild הערך הזה לא יוגדר על ידי Gradle.

APP_MODULES

רשימה מפורשת של מודולים לבנייה. הרכיבים ברשימה הזו הם השמות של את המודולים כפי שהם מופיעים ב-LOCAL_MODULE בקובץ Android.mk.

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

הערה: מודולים מיובאים (אלה שמוגדרים בסקריפטים של build שיובאו עם $(call import-module) לא ייבנו אלא אם הם תלויים במודול לבנייה או רשומה ב-APP_MODULES.

APP_OPTIM

צריך להגדיר את המשתנה האופציונלי הזה כ-release או כ-debug. פרסום קבצים בינאריים תיבנה כברירת מחדל.

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

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

יש הצהרה על android:debuggable במניפסט של האפליקציה <application> יגרום למשתנה הזה להיות debug במקום release כברירת מחדל. כדי לשנות את ערך ברירת המחדל צריך להגדיר את APP_OPTIM ל-release.

הערה: כשיוצרים עם externalNativeBuild, מערכת Android Studio מגדירה את זה בהתאם לטעם של ה-build שלכם.

APP_PLATFORM

האתר APP_PLATFORM מצהיר על רמת ה-API ל-Android שעל פיה האפליקציה מתווספת שתואמים ל-minSdkVersion של האפליקציה.

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

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

לדוגמה, הערך android-16 מציין שהספרייה שלך משתמשת בממשקי API הן לא זמינות מתחת ל-Android 4.1 (רמת API 16) ואי אפשר להשתמש בהן במכשירים שפועלת בהם גרסת פלטפורמה נמוכה יותר. לרשימה מלאה של שמות הפלטפורמות לתמונות המתאימות של מערכת Android, ראו מודעות מותאמות של Android NDK ממשקי API.

כשמשתמשים ב-Gradle וב-externalNativeBuild, אין להגדיר את הפרמטר הזה ישירות. במקום זאת, צריך להגדיר את המאפיין minSdkVersion בשדה defaultConfig או productFlavors בלוקים מתוך קובץ build.gradle ברמת המודול. הזה מוודא שהספרייה נמצאת בשימוש רק על ידי אפליקציות שמותקנות במכשירים עם מספקת גרסה הולמת של Android.

הערה: ה-NDK לא מכיל ספריות לכל רמת API ב-Android. גרסאות שלא כללו ממשקי API מקוריים חדשים מושמטות כדי לחסוך מקום NDK. ndk-build שימושים, בסדר יורד לפי עדיפות:

1. גרסת הפלטפורמה שתואמת ל-APP_PLATFORM.
2. רמת ה-API הבאה שזמינה מתחת ל-APP_PLATFORM. לדוגמה, android-19. ייעשה שימוש כאשר APP_PLATFORM הוא android-20, מכיוון שלא היו ממשקי API מקוריים ב-android-20.
3. רמת ה-API המינימלית שנתמכת על ידי ה-NDK.

APP_PROJECT_PATH

הנתיב המוחלט של תיקיית השורש של הפרויקט.

APP_SHORT_CommandS

שווה ערך ל-LOCAL_SHORT_COMMANDS ברמת הפרויקט. מידע נוסף זמין במאמר הבא: התיעוד עבור LOCAL_SHORT_COMMANDS ב-Android.mk.

APP_STL

הספרייה הרגילה של C++ לשימוש עבור האפליקציה הזו.

כברירת מחדל נעשה שימוש ב-STL system. אפשרויות נוספות הן c++_shared, c++_static ו-none. למידע נוסף, אפשר לעיין ב-NDK C++ זמני ריצה ו תכונות.

APP_STRIP_מצב

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

APP_THIN_ARCHIVE

יש להגדיר את הערך כ-True כדי להשתמש בארכיונים דקים בכל הספריות הסטטיות בפרויקט. עבור מידע נוסף זמין במסמכי התיעוד של LOCAL_THIN_ARCHIVE ב Android.mk

APP_WRAP_SH

נתיב לקובץ wrap.sh שייכלל באפליקציה הזו.

לכל ABI קיים וריאנט של המשתנה, כך גם וריאנט גנרי של ABI:

• APP_WRAP_SH
• APP_WRAP_SH_armeabi-v7a
• APP_WRAP_SH_arm64-v8a
• APP_WRAP_SH_x86
• APP_WRAP_SH_x86_64

הערה: לא ניתן לשלב את APP_WRAP_SH_<abi> עם APP_WRAP_SH. אם קיים ממשק ABI כלשהו משתמש ב-wrap.sh ספציפי ל-ABI, כל ממשקי ה-ABI חייבים.