下面是我個(gè)人對android-ndk-r4版本中Android.mk文件做的翻譯，由于自己英語(yǔ)水平和專(zhuān)業(yè)知識的限制，有些地方可能翻譯的不是很準確，敬請指正，本文僅希望對做android NDK開(kāi)發(fā)的同仁們能提供一點(diǎn)點(diǎn)的幫助而已。
Android.mk文件是用來(lái)描述你想要編譯進(jìn)系統的資源的。
這個(gè)文件的語(yǔ)法允許你把你的資源打包進(jìn)“modules”。Module應該是下面module中的一種：
- a static library
- a shared library
只有shared library會(huì )被打包到你的應用程序中，盡管static library也能用來(lái)生產(chǎn)shared library。
你可以在一個(gè)Android.mk中定義多個(gè)module，你也可以在幾個(gè)module中使用相同的資源文件。
編譯系統會(huì )為你處理一些細節。例如，你不需要在你的Android.mk文件中列出你的頭文件或是你的文件之間明確的依賴(lài)關(guān)系。NDK編譯系統會(huì )自動(dòng)幫你處理。
這同時(shí)意味著(zhù)，當升級到新版本的NDK時(shí)，你不需要動(dòng)你的Android.mk文件就可以使用心得toolchain/platform支持。
注意，用在A(yíng)ndroid.mk文件中的語(yǔ)法和整個(gè)的android平臺的開(kāi)源資源語(yǔ)法是不同的。編譯系統實(shí)現了對他們不同的使用，這是故意這樣設計的，用來(lái)允許應用開(kāi)發(fā)人員更容易地重用外部庫資源代碼。
一個(gè)簡(jiǎn)單的例子：
在語(yǔ)法詳細說(shuō)明之前，讓我們先來(lái)看一個(gè)簡(jiǎn)單的“hello-jni”例子，文件在$NDK/samples/hello-jni下：
在這我們可以看到：
-src目錄下包含這個(gè)簡(jiǎn)單的android工程的一個(gè)java源文件
-jni目錄下包含了這個(gè)例子的本地源文件
這個(gè)源文件實(shí)現了一個(gè)簡(jiǎn)單的共享庫，這個(gè)共享庫實(shí)現了一個(gè)想vm應用程序返回一個(gè)字符串的本地方法。
-Android.mk文件向NDK編譯系統描述了一個(gè)共享庫。它的內容如下：
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_SHARED_LIBRARY
現在讓我們來(lái)解釋這些語(yǔ)法：
LOCAL_PATH := $(call my-dir)
一個(gè)Android.mk文件必須以定義一個(gè)LOCAL_PATH 變量開(kāi)始。它用來(lái)在你的工程樹(shù)形目錄下定位你的資源文件的位置。在這個(gè)例子中，那個(gè)編譯系統提供的“my-dir”宏函數用來(lái)返回當前目錄的路徑（Android.mk文件所在的目錄）。
include $(CLEAR_VARS)
編譯系統提供的一個(gè)指向特殊的GNU Makefile文件的CLEAR_VARS變量將為你清理很多LOCAL_PATH中的LOCAL_XXX變量（例如： LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES等等）。這是有必要的，因為所有的編譯控制文件都會(huì )在一個(gè)單獨的GNU Make可執行上下文中被解析，在這里所有的變量都是全局的。
LOCAL_MODULE := hello-jni
用來(lái)標識分布在A(yíng)ndroid.mk文件中的每一個(gè)module的LOCAL_MODULE變量必須定義。名字必須是唯一的而且不能有空格。
注意，編譯系統會(huì )給相應的生成文件自動(dòng)地添加適當的前綴和后綴。換句話(huà)說(shuō)，一個(gè)命名為“foo”的共享庫module將生成名為“l(fā)ibfoo.so”的文件。
重點(diǎn)注意：
如果你的module命名為“l(fā)ibfoo”，編譯系統不會(huì )為你添加另外一個(gè)“l(fā)ib”前綴，還是會(huì )生成一個(gè)“l(fā)ibfoo.so”的文件而已。這個(gè)為了支持你需要使用的android平臺資源的Android.mk文件。
LOCAL_SRC_FILES := hello-jni.c
LOCAL_SRC_FILES變量必須包含一個(gè)將要被編譯和匯編進(jìn)module的一個(gè)C/C++資源文件列表。注意你不需要列出頭文件和包含文件，因為編譯系統會(huì )自動(dòng)幫你計算依賴(lài)關(guān)系；僅僅需要列出直接傳遞給編譯器的資源文件就可以了。
注意：默認的C++資源文件的擴展名是“.cpp”。然而可以通過(guò)定義LOCAL_DEFAULT_CPP_EXTENSION變量來(lái)指定一個(gè)不同的擴展名。不要忘記最開(kāi)始的dot(例如：.cxx是可以的，但是cxx是不行的)。
include $(BUILD_SHARED_LIBRARY)
BUILD_SHARED_LIBRARY是編譯系統提供的一個(gè)指向GNU Makefile腳本的變量，它負責收集從最近的include $(CLEAR_VARS)' 變量開(kāi)始的所有內定義的 LOCAL_XXX變量的信息，然后決定哪些需要編譯以及怎樣編譯。BUILD_STATIC_LIBRARY變量可以生成一個(gè)static library。
在samples目錄下有幾個(gè)復雜的例子，在他們的Android.mk文件中你可以看到一些注釋。
Reference：
下面是你可以在A(yíng)ndroid.mk文件里可以直接使用或是定義的變量的列表。你能夠定義其它的變量供自己使用，但是下面的變量名是NDK編譯系統的保留字：
- 以L(fǎng)OCAL_ 開(kāi)頭命名的 (例如LOCAL_MODULE)
- 以PRIVATE_，NDK_ 或是 APP_ 命名的(僅供內部使用)
- 以小寫(xiě)字母命名的(僅供內部使用, 例如 'my-dir')
如果你需要在A(yíng)ndroid.mk文件里定義一個(gè)你自己使用比較方便的變量，我們建議使用MY_前綴，這是一個(gè)普通的例子：
MY_SOURCES := foo.c
ifneq ($(MY_CONFIG_BAR),)
MY_SOURCES += bar.c
endif
LOCAL_SRC_FILES += $(MY_SOURCES)
好，我們接著(zhù)看：
NDK提供的變量：
在你的Android.mk文件解析之前，編譯系統定義了這些GNU Make變量。注意，在某種情況下NDK可能會(huì )多次解析你的Android.mk文件，每一次解析某些變量的定義可能不同。
CLEAR_VARS
指向一個(gè)幾乎所有在"Module-description"部分列出的LOCAL_XXX變量都沒(méi)有定義的編譯腳本（我的理解就是在編譯前清空所有變量，然后在這個(gè)變量的下面再重新定義）。在開(kāi)始一個(gè)新的module之前你必須包含這個(gè)腳本，例如：
include $(CLEAR_VARS)
BUILD_SHARED_LIBRARY
指向一個(gè)收集所有你提供的關(guān)于module的LOCAL_XXX變量的信息的編譯腳本，然后決定如何根據你列出的資源編譯一個(gè)目標shared library。注意，你在包含這個(gè)變量之前必須至少OCAL_MODULE 和LOCAL_SRC_FILES 變量?？梢赃@樣使用：
include $(BUILD_SHARED_LIBRARY)
注意它將生成一個(gè)以lib$(LOCAL_MODULE).so命名的文件。
BUILD_STATIC_LIBRARY
BUILD_STATIC_LIBRARY變量的不同之處在于它是用來(lái)生成一個(gè)目標static ibrary 。static ibrary 不會(huì )被打包進(jìn)你的工程包，但是可以用來(lái)生成shared library（看下面的LOCAL_STATIC_LIBRARIES 和LOCAL_STATIC_WHOLE_LIBRARIES說(shuō)明）?？梢赃@樣使用：
include $(BUILD_STATIC_LIBRARY)
注意，它將生成一個(gè)以lib$(LOCAL_MODULE).a命名的文件。
TARGET_ARCH
指明一個(gè)full Android open-source build明確說(shuō)明的目標CPU架構。如果是“arm”用來(lái)所有的兼容ARM的編譯，不依賴(lài)與CPU架構版本。
TARGET_PLATFORM
當Android.mk文件解析時(shí)，指明一個(gè)android目標平臺。例如"android-3”對應"android1.5"系統鏡像。完整的平臺名字和android系統鏡像的對應列表可以閱讀docs/目錄下STABLE-APIS.TXT文檔。
TARGET_ARCH_ABI
當Android.mk文件解析時(shí)，指明一個(gè)目標CPU+ABI。有兩個(gè)值可供使用：
armeabi
對應Armv5TE
armeabi-v7a
注意：Android NDK 1.6_r1之上的版本，這個(gè)變量被定義為'arm'。然而，這個(gè)變量的重定義能夠被Android platform內部更好的使用。
對于更多的ABI架構和對應的兼容性問(wèn)題的細節，可以閱讀docs目錄下的CPU-ARCH-ABIS.TXT文檔。
其他的ABI架構將會(huì )在以后的NDK版本中引入，并且有不同的名字。注意，所有基于A(yíng)RM的ABIs都會(huì )被'TARGET_ARCH' 定義為 'arm'，但是可能有不同的'TARGET_ARCH_ABI'。
TARGET_ABI
目標平臺和abi的連結，它被定義為$(TARGET_PLATFORM)-$(TARGET_ARCH_ABI)，當你用真機測試一個(gè)指定的目標平臺鏡像的時(shí)候會(huì )有用處。
默認情況下，它將是'android-3-armeabi'
（Android NDK 1.6_r1以上的版本，'android-3-arm'是默認的）
NDK提供的宏函數
下面是GNU Make宏函數，通過(guò)使用'$(call <function>)'來(lái)獲得他的值。它們返回文本信息。
my-dir
返回相對于上層的NDK編譯系統的當前Android.mk文件目錄的路徑。這對于以下面這種方式在你的Android.mk文件的開(kāi)始定義LOCAL_PATH變量很有用：
LOCAL_PATH := $(call my-dir)
all-subdir-makefiles
返回當前所有在'my-dir'路徑下以及他的子路徑下的Android.mk 文件列表。例如，考慮下面的這種層次結構：
sources/foo/Android.mk
sources/foo/lib1/Android.mk
sources/foo/lib2/Android.mk
如果sources/foo/Android.mk文件包含下面這條指令：
include $(call all-subdir-makefiles)
這時(shí)它將自動(dòng)包含 sources/foo/lib1/Android.mk和sources/foo/lib2/Android.mk文件。
這個(gè)函數能用來(lái)為編譯系統提供深層嵌套的資源目錄層次結構。注意，默認情況下 ，NDK只會(huì )在sources/*/Android.mk目錄下尋找文件。
this-makefile
返回當前Makefile文件的路徑（例如，函數在哪里被調用）。
parent-makefile
放回父Makefile文件在包含樹(shù)中的路徑。例如包含當前Makefile文件的Makefile文件的路徑。
Module描述變量
下面的變量是用來(lái)向系統描述你的module的。你應該在一個(gè)'include $(CLEAR_VARS)'和'一個(gè)include $(BUILD_XXXXX)'變量之間定義它們中的某些變量。前面的部分已經(jīng)介紹過(guò)了，$(CLEAR_VARS)變量是取消/清除所有這些變量的定義，除非在他們的描述說(shuō)明確地注明。
LOCAL_PATH
這個(gè)變量用來(lái)給出當前文件的路徑。你必須在你的Android.mk文件的開(kāi)始定義它，比如下面這樣定義是可以的：
LOCAL_PATH := $(call my-dir)
這個(gè)變量不會(huì )被$(CLEAR_VARS)清除掉，所以在每一個(gè)Android.mk文件中僅需要定義一次（在你的一個(gè)文件中定義了幾個(gè)module的情況下）。
LOCAL_MODULE
你的module的名字。它必須在所有的module名字中是唯一的，而且不能有空格。你必須在任何一個(gè)$(BUILD_XXXX)腳本之前定義它。
module名字決定了生成文件的名字，例如：一個(gè)名字為lib<foo>.so的shared library的module名字為<foo>?？墒?，你應該在你的NDK編譯文件中（無(wú)論是Android.mk還是 Application.mk）進(jìn)引用其它module的通用的名字（例如<foo>）。
LOCAL_SRC_FILES
這是一個(gè)將用于你的module編譯的資源文件列表。只用在列表中的文件才會(huì )傳遞給編譯器，因為編譯系統自動(dòng)幫你計算依賴(lài)關(guān)系。
注意，所有的資源文件名字都是相對于LOCAL_PATH的，你能夠使用路徑分隔符，例如：
LOCAL_SRC_FILES := foo.c \
toto/bar.c
注意：只有使用Unix風(fēng)格的正斜線(xiàn)（/）在編譯文件中才可以，windows風(fēng)格的反斜線(xiàn)（\）不能被正確處理。
LOCAL_CPP_EXTENSION
這是一個(gè)可選擇的變量，它能用來(lái)定義c++源文件的文件后綴名。默認的是'.cpp'，但是你可以改變它。例如：
LOCAL_CPP_EXTENSION := .cxx
LOCAL_C_INCLUDES
一個(gè)可選的編譯所有源文件（C,C++,匯編）時(shí)會(huì )添加到include搜索路徑相對于NDK *root*文件夾的路徑的列表。例如：
LOCAL_C_INCLUDES := sources/foo
或者
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
他們會(huì )在LOCAL_CFLAGS / LOCAL_CPPFLAGS中的任何inclusion flag之前被替換。
LOCAL_CFLAGS
當編譯 C 和 C++源文件時(shí)傳遞的一組可選的編譯器標識。
它可以用來(lái)指定額外的宏定義或編譯選項。
重要信息：不要在你的Android.mk文件中嘗試去改變優(yōu)化/調試等級，這個(gè)可以通過(guò)在你的Android.mk文件中指明適當的信息來(lái)讓系統自動(dòng)處理，將會(huì )使NDK生成在調試中可以使用的有用的數據文件。
注意：在android-ndk-1.5_r1中，對應標記僅能用在c源文件上，不能用在c++源文件上。這能夠正確匹配所有的android編譯系統行為。（你現在可以使用LOCAL_CPPFLAGS來(lái)僅為c++源文件設置標識）。
LOCAL_CXXFLAGS
LOCAL_CPPFLAGS的一個(gè)別名。注意，這種標識的使用是過(guò)時(shí)的，因為在以后的NDK版本中它可能被取消。
LOCAL_CPPFLAGS
當僅編譯 C++源文件時(shí)傳遞的一組可選的編譯器標識。他們將在LOCAL_CFLAGS之后顯示在命令行上。
注意：在android-ndk-1.5_r1中，對應標記在c源文件上和在c++源文件上都能使用。這能夠正確匹配所有的android編譯系統行為。（你現在可以使用LOCAL_CFLAGS來(lái)為c++源文件和c源文件設置標識）。
LOCAL_STATIC_LIBRARIES
將要被鏈接進(jìn)這個(gè)module的static libraries modules的列表（用BUILD_STATIC_LIBRARY編譯過(guò)的）。這個(gè)僅在shared library modules中能被檢測到。
LOCAL_SHARED_LIBRARIES
依賴(lài)于運行時(shí)的shared libraries *modules*的列表。這在鏈接時(shí)是必要的，為了把對應的信息嵌入到生成的文件中。
注意：他不會(huì )把列出的module添加到編譯表中，例如：你仍然需要在你的Application.mk文件中把他們添加到你的應用程序需要的module中。
LOCAL_LDLIBS
編譯你的module時(shí)使用到的額外的鏈接器標識列表。它能夠用一個(gè)帶 "-l" 前綴的表達式傳遞一個(gè)指明的系統庫的名字。例如：下面的定義將會(huì )通知編譯器在加載的時(shí)候生成一個(gè)鏈接到/system/lib/libz.so的module：
LOCAL_LDLIBS := -lz
閱讀docs目錄下的STABLE-APIS.TXT文檔，你將能了解到在這個(gè)NDK版本中你可以鏈接的系統庫的列表。
LOCAL_ALLOW_UNDEFINED_SYMBOLS
默認情況下，當嘗試編譯一個(gè)shared library時(shí)任何一個(gè)沒(méi)有定義的引用都將產(chǎn)生一個(gè)"undefined symbol"錯誤。這對在你的源代碼中捕獲bug很有幫助。
可是，如果由于某種原因你需要讓這些檢查失效，把這個(gè)變量設置為'true'。注意，對應的shared library在運行時(shí)加載可能出錯。
LOCAL_ARM_MODE
默認情況下，ARM的二進(jìn)制文件將生成每一條指令都是16位的'thumb'模式。你可以定義這個(gè)變量為'arm'，如果你想強制生成的module目標文件為 'arm'（每條指令32位）模式的。例如：
LOCAL_ARM_MODE := arm
注意，你也可以通過(guò)在源文件名后面添加一個(gè)'.arm'來(lái)指示編譯系統只把指定的文件編譯'bar.c'。例如：
LOCAL_SRC_FILES := foo.c bar.c.arm
通知編譯系統總是把'bar.c'編譯成'.arm'模式，而依據LOCAL_ARM_MODE變量的值來(lái)編譯 foo.c 文件。
注意：在你的Application.mk文件中設置APP_OPTIM為 'debug'也能強制生成ARM二進(jìn)制文件。這是因為在thumb模式下toolchain debugger 中的bug不能得到較好的處理。
LOCAL_ARM_NEON
把這個(gè)變量設置為'true'能夠允許你在你的C和C++源碼中使用ARM Advanced SIMD(a.k.a. NEON)GCC，也能在匯編文件中使用NEON指令。
你僅僅應該在想要對應ARMv7指令序列的'armeabi-v7a' ABI時(shí)定義它。注意，不是所有基于A(yíng)RMv7的CPU都支持NEON指令序列擴展，你應該開(kāi)啟運行時(shí)檢查來(lái)確保你能安全地使用這些代碼在運行期間。更多的關(guān)于這些的內容，可以閱讀docs目錄下的CPU-ARM-NEON.TXT 和CPU-FEATURES.TXT.文檔。
二選一，你也可以在指定的文件后面加上'.neon'來(lái)指示表儀器把指定的文件編譯成NEON支持的文件，例如：
LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon
在這個(gè)例子中'foo.c'將被編譯成thumb+neon模式，'bar.c'將被編譯成'thumb'模式，'zoo.c' 將被編譯成'arm+neon'模式。
注意，如果 '.neon' 后綴和'.arm' 后綴都是用，那么 '.neon' 后綴和一定要添加到'.arm' 后綴之后。(例如： foo.c.arm.neon 可以，但是 foo.c.neon.arm 不可以)。
LOCAL_DISABLE_NO_EXECUTE
Android NDK r4添加的用來(lái)支持"NX bit"安全特性的。默認情況下是啟用的，但是你也可以設置這個(gè)變量為 'true'來(lái)啟用它，如果你真的需要這么做的話(huà)。
注意：這個(gè)特性不會(huì )修改ABI，它僅僅是使內核能夠指向ARMv6+ CPU設備。在這種特性下生成的機器碼將不需要做修改就能運行在更早的CPU架構上
聯(lián)系客服
