配合 android.mk 使用的 make 文件還有一個 application.mk ，大部分情況無需修改該文件，下面也來自網(wǎng)絡(luò)翻譯
Application.mk 文件
簡介：
要將 C\C++ 代碼編譯為 SO 文件，光有 Android.mk 文件還不行，還需要一個 Application.mk 文件。
本文檔是描述你的 Android 應(yīng)用程序中需要的本地模塊的 Application.mk 的語法使用，要明白如下。
Application.mk 目的是描述在你的應(yīng)用程序中所需要的模塊(即靜態(tài)庫或動態(tài)庫)。
Application.mk 文件通常被放置在 $PROJECT/jni/Application.mk 下，$PROJECT 指的是您的項目。
另一種方法是將其放在頂層的子目錄下：
$NDK/apps 目錄下，例如：
$NDK/apps//Application.mk
是一個簡稱，用于描述你的 NDK 編譯系統(tǒng)的應(yīng)用程序（這個名字不會生成共享庫或者最終的包）
下面是 Application.mk 中定義的幾個變量。
APP_PROJECT_PATH
這個變量是強(qiáng)制性的，并且會給出應(yīng)用程序工程的根目錄的一個絕對路徑。這是用來復(fù)制或者安裝一個沒有任何版本限制的 JNI 庫，從而給 APK 生成工具一個詳細(xì)的路徑。
APP_MODULES
這個變量是可選的，如果沒有定義，NDK 將由在 Android.mk 中聲明的默認(rèn)的模塊編譯，并且包含所有的子文件（makefile 文件）
如果 APP_MODULES 定義了，它不許是一個空格分隔的模塊列表，這個模塊名字被定義在 Android.mk 文件中的 LOCAL_MODULE 中。注意 NDK 會自動計算模塊的依賴
注意：NDK 在 R4 開始改變了這個變量的行為，再次之前：
- 在您的Application.mk中，該變量是強(qiáng)制的
- 必須明確列出所有需要的模塊
APP_OPTIM
這個變量是可選的，用來定義“release”或”debug”。在編譯您的應(yīng)用程序模塊的時候，可以用來改變優(yōu)先級。
“release”模式是默認(rèn)的，并且會生成高度優(yōu)化的二進(jìn)制代碼?！眃ebug”模式生成的是未優(yōu)化的二進(jìn)制代碼，但可以檢測出很多的 BUG，可以用于調(diào)試。
注意：如果你的應(yīng)用程序是可調(diào)試的（即，如果你的清單文件中設(shè)置了 android:debuggable 的屬性是”true”）。默認(rèn)的是”debug”而不是”release”。這可以通過設(shè)置 APP_OPTIM 為”release”來將其覆蓋。
注意：可以在”release”和”debug”模式下一起調(diào)試，但是”release”模式編譯后將會提供更少的 BUG 信息。在我們清楚 BUG 的過程中，有一些變量被優(yōu)化了，或者根本就無法被檢測出來，代碼的重新排序會讓這些帶阿彌變得更加難以閱讀，并且讓這些軌跡更加不可靠。
APP_CFLAGS
當(dāng)編譯模塊中有任何 C 文件或者 C++文件的時候，C 編譯器的信號就會被發(fā)出。這里可以在你的應(yīng)用中需要這些模塊時，進(jìn)行編譯的調(diào)整，這樣就不許要直接更改 Android.mk 為文件本身了
重要警告：+++++++++++++++++++++++++++++++++++++++++++++++ + +
+
+ 在這些編制中，所有的路徑都需要于最頂層的 NDK 目錄相對應(yīng)。
+ 例如，如果您有以下設(shè)置：
+
+sources/foo/Android.mk
+sources/bar/ Android.mk
+ 編譯過程中，若要在 foo/Android.mk 中指定你要添加的路徑到 bar 源代碼中，
+ 你應(yīng)該使用
+ APP_CFLAGS += -Isources/bar
+ 或者交替：
+ APP_CFLAGS += -I $（LOCAL_PATH )/../bar
+
+ 使用’-l../bar/’將不會工作，以為它將等同于”-l$NDK_ROOT/../bar”
++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++
注意：在 Android 的 NDK 1.5_r1，只適用于 C 源文件，而不適合 C++。
這已得到糾正，以建立完整相匹配的 Andr??oid 系統(tǒng)。
APP_CXXFLAGS
APP_CPPFLAGS 的別名，已經(jīng)考慮在將在未來的版本中廢除了
APP_CPPFLAGS
當(dāng)編譯的只有 C++源文件的時候，可以通過這個 C++編譯器來設(shè)置
注意：在 Android NDK-1.5_r1 中，這個標(biāo)志可以應(yīng)用于 C 和 C++源文件中。并且得到了糾正，以建立完整的與系統(tǒng)相匹配的 Android 編譯系統(tǒng)。你先可也可以使用 APP_CFLAGS 來應(yīng)用于 C 或者 C++源文件中。
建議使用 APP_CFLAGS
APP_BUILD_SCRIPT
默認(rèn)情況下，NDK 編譯系統(tǒng)會在 $(APP_PROJECT_PATH)/jni 目錄下尋找名為 Android.mk 文件：
$(APP_PROJECT_PATH)/jni/Android.mk
如果你想覆蓋此行為，你可以定義 APP_BUILD_SCRIPT 來指定一個備用的編譯腳本。一個非絕對路徑總是被解釋為相對于 NDK 的頂層的目錄。
APP_ABI
默認(rèn)情況下，NDK 的編譯系統(tǒng)回味”armeabi”ABI生成機(jī)器代碼。喜愛哪個相當(dāng)于一個基于 CPU 可以進(jìn)行浮點運算的 ARMv5TE。你可以使用 APP_ABI 來選擇一個不同的 ABI。
比如：為了在 ARMv7 的設(shè)備上支持硬件 FPU 指令?？梢允褂?
APP_ABI := armeabi-v7a
或者為了支持 IA-32 指令集，可以使用
APP_ABI := x86
或者為了同時支持這三種，可以使用
APP_ABI := armeabi armeabi-v7a x86
APP_STL
默認(rèn)情況下，NDK 的編譯系統(tǒng)為最小的 C++運行時庫（/system/lib/libstdc++.so）提供 C++頭文件。
然而，NDK 的 C++的實現(xiàn)，可以讓你使用或著鏈接在自己的應(yīng)用程序中。
例如：
APP_STL := stlport_static –> static STLport library
APP_STL := stlport_shared –> shared STLport library
APP_STL := system –> default C++ runtime library
下面是一個 Application.mk 文件的示例：
```
APP_PROJECT_PATH :=
```
