【翻译】(5)Android.mk File
-----------------
英文文檔見android-ndk-r5b的documentation.html
屬于Android Native Development Kit (NDK)的一部分
見http://developer.android.com/sdk/ndk/（需要代理）
翻譯僅個人見解
-----------------
?
Android.mk file syntax specification
?
Android.mk文件語法規范
?
Introduction:
?
介紹：
-------------
?
This document describes the syntax of Android.mk build file written to describe your C and C++ source files to the Android NDK. To understand what follows, it is assumed that you have read the docs/OVERVIEW.html file that explains their role and usage.
?
這篇文檔描述Android.mk構建文件的語法，書寫這個文件是為了向Android NDK描述你的C和C++源文件。為了明白下面介紹的東西，假設你已經閱讀過docs/OVERVIEW.html文件，它解釋了那些文件的角色和用法。
?
Overview:
?
概述
---------
?
An Android.mk file is written to describe your sources to the build system. More specifically:
?
書寫Android.mk是為了描述向構建系統描述你的源代碼。更特別地：
?
- The file is really a tiny GNU Makefile fragment that will be parsed one or more times by the build system. As such, you should try to minimize the variables you declare there and do not assume that anything is not defined during parsing.
?
- 文件是一段很小的GNU Makefile片段，它將被構建系統解析一或多次。因此，在那里你應該盡量減少聲明的變量，并且不要假設任何東西在解析期間沒有定義。
?
- The file syntax is designed to allow you to group your sources into 'modules'. A module is one of the following:
?
- 文件語法是設計為允許你把源代碼組織成模塊。一個模塊是以下其中一種：
?
?? ?- a static library
?
?? ?- 靜態庫
?
?? ?- a shared library
?
?? ?- 動態庫
?
??Only shared libraries will be installed/copied to your application package. Static libraries can be used to generate shared libraries though.
?
??只有動態庫將被安裝或復制到你的應用程序包。然而靜態庫可以用于生成動態庫。
?
??You can define one or more modules in each Android.mk file, and you can use the same source file in several modules.
?
??你可以在每個Android.mk文件中定義一個或多個模塊，而且你可以在幾個模塊中使用相同的源代碼。
?
- The build system handles many details for you. For example, you don't need to list header files or explicit dependencies between generated files in your Android.mk. The NDK build system will compute these automatically for you.
?
- 構建系統為你處理許多細節。例如，你不需要在你的Android.mk中列出頭文件或所生成文件之間的顯式依賴。NDK構建系統將自動為你計算這些東西。
?
??This also means that, when updating to newer releases of the NDK, you should be able to benefit from new toolchain/platform support without having to touch your Android.mk files.
?
??這也意味著，當更新到更新的NDK發布版，你應該可以從新的工具鏈或平臺支持中獲益而不必修改你的Android.mk文件。
?
Note that the syntax is *very* close to the one used in Android.mk files distributed with the full open-source Android platform sources. While the build system implementation that uses them is different, this is an intentional design decision made to allow reuse of 'external' libraries' source code easier for application developers.
?
注意，它非常接近于跟隨完全開源的Android平臺源代碼發布的Android.mk文件中所使用的語法。但用于它們的構建系統實現是不相同的，這是內部設計所作出的決定以允許外部庫源代碼的重用對于應用程序開發者來說更加容易。（注：意思是，Android開源代碼的構建系統與NDK的構建系統相似，但實現不同，所以不能混用）
?
Simple example:
?
簡單的示例：
---------------
?
Before describing the syntax in details, let's consider the simple "hello JNI" example, i.e. the files under:
?
在詳細描述語法之前，讓我們考慮簡單的hello JNI示例，即以下目錄下的文件：
?
?? ?apps/hello-jni/project
?
（注：新版NDK放在samples/hello-jni下）
?
Here, we can see:
?
這里，我們可以看到：
?
??- The 'src' directory containing the Java sources for the sample Android project.
?
??- src目錄包含用于示例Android工程的Java源代碼
?
??- The 'jni' directory containing the native source for the sample, i.e. 'jni/hello-jni.c'
?
??- jni目錄包含用于示例的原生代碼，即jni/hello-jni.c（注：原生的意思是與機器代碼有關，這里只是相對Java而言，即實現JNI接口的C代碼。或許匯編也可以稱為原生代碼）
?
?? ?This source file implements a simple shared library that implements a native method that returns a string to the VM application.
?
?? ?這個源文件實現一個簡單動態庫，它實現了一個native方法，返回一個字符串到VM應用程序。
?
??- The 'jni/Android.mk' file that describes the shared library to the NDK build system. Its content is:
?
??- jni/Android.mk文件向NDK構建系統描述動態庫。它的內容是：
?
?? ---------- cut here ------------------
?? LOCAL_PATH := $(call my-dir)
?
?? include $(CLEAR_VARS)
?
?? LOCAL_MODULE ? ?:= hello-jni
?? LOCAL_SRC_FILES := hello-jni.c
?
?? include $(BUILD_SHARED_LIBRARY)
?? ---------- cut here ------------------
?
Now, let's explain these lines:
?
現在，讓我們解釋這些代碼行：
?
??LOCAL_PATH := $(call my-dir)
?
An Android.mk file must begin with the definition of the LOCAL_PATH variable. It is used to locate source files in the development tree. In this example, the macro function 'my-dir', provided by the build system, is used to return the path of the current directory (i.e. the directory containing the Android.mk file itself).
?
一個Android.mk文件必須以LOCAL_PATH變量定義開頭。它用于在開發樹中定位源文件。在這個例子中，宏函數my-dir，由構建系統提供，用于返回當前目錄的路徑（即，包含Android.mk文件自身的目錄）。
?
??include $(CLEAR_VARS)
?
The CLEAR_VARS variable is provided by the build system and points to a special GNU Makefile that will clear many LOCAL_XXX variables for you (e.g. LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, etc...), with the exception of LOCAL_PATH. This is needed because all build control files are parsed in a single GNU Make execution context where all variables are global.
?
CLEAR_VARS由構建系統提供，并且指向一個特殊GNU Makefile，這個Makefile將為你清除許多LOCAL_XXX變量（例如LOCAL_MODULE，LOCAL_SRC_FILES，LOCAL_STATIC_LIBRARIES，等等），但LOCAL_PATH例外。這是必須的，因為所有構建控制文件在單一GNU Make的執行上下文中執行，所有變量都是全局的。
?
??LOCAL_MODULE := hello-jni
?
The LOCAL_MODULE variable must be defined to identify each module you describe in your Android.mk. The name must be *unique* and not contain any spaces. Note that the build system will automatically add proper prefix and suffix to the corresponding generated file. In other words, a shared library module named 'foo' will generate 'libfoo.so'.
?
必須定義LOCAL_MODULE變量以標識你在你的Android.mk中描述的每個模塊。名稱必須是唯一的并且不要包含任何空白符。注意構建系統將自動添加合適的前綴和后綴到相應的生成文件。換言之，一個名為foo的動態庫模塊將生成libfoo.so。
?
IMPORTANT NOTE:
If you name your module 'libfoo', the build system will not add another 'lib' prefix and will generate libfoo.so as well. This is to support Android.mk files that originate from the Android platform sources, would you need to use these.
?
重要注意事項：
如果你把你的模塊命名為libfoo，構建系統將不會添加另一個lib前綴而且仍將生成libfoo.so。這是為了支持最初在Android平臺的源代碼中的Android.mk文件，而你可能需要使用它們。
?
??LOCAL_SRC_FILES := hello-jni.c
?
The LOCAL_SRC_FILES variables must contain a list of C and/or C++ source files that will be built and assembled into a module. Note that you should not list header and included files here, because the build system will compute dependencies automatically for you; just list the source files that will be passed directly to a compiler, and you should be good.
?
LOCAL_SRC_FILES變量必須包含一個C和/或C++源代碼文件列表，它們將被構建并且匯編成一個模塊。注意你不應該在這里列出頭文件和被包含的文件，因為構建系統將為你自動計算依賴；只要列舉將被直接傳遞給編譯器的源文件，然后你就做好了。（注：頭文件只是預編譯期被處理的文件，真正編譯成.o文件的是被預處理后被展開的.c源代碼）
?
Note that the default extension for C++ source files is '.cpp'. It is however possible to specify a different one by defining the variable LOCAL_CPP_EXTENSION. Don't forget the initial dot (i.e. '.cxx' will work, but not 'cxx').
?
注意C++源文件的默認擴展名是.cpp。然而可以通過定義LOCAL_CPP_EXTENSION變量定義不同的擴展名。不要忘記開頭的點（即.cxx可以，但cxx不可以）
?
??include $(BUILD_SHARED_LIBRARY)
?
The BUILD_SHARED_LIBRARY is a variable provided by the build system that points to a GNU Makefile script that is in charge of collecting all the information you defined in LOCAL_XXX variables since the latest 'include $(CLEAR_VARS)' and determine what to build, and how to do it exactly. There is also BUILD_STATIC_LIBRARY to generate a static library.
?
BUILD_SHARED_LIBRARY是構建系統提供的變量，指向一個GNU Makefile腳本，它負責收集最后的include $(CLEAR_VARS)之后你所定義的所有信息，然后決定要構建什么，并且如何準確地做到。還有一個BUILD_STATIC_LIBRARY變量用于生成靜態庫。
?
There are more complex examples in the samples directories, with commented Android.mk files that you can look at.
?
在例子目錄中有更多復雜的示例，你可以看里面帶注釋的Android.mk文件。
?
Reference:
?
參考：
----------
?
This is the list of variables you should either rely on or define in an Android.mk. You can define other variables for your own usage, but the NDK build system reserves the following variable names:
?
這是在Android.mk中你應該依賴或定義的變量列表。你可以定義其它變量供你自己使用，但NDK構建系統保留以下變量名稱：
?
- names that begin with LOCAL_ ?(e.g. LOCAL_MODULE)
?
- 以LOCAL_開頭的名稱（例如LOCAL_MODULE）
?
- names that begin with PRIVATE_, NDK_ or APP_ ?(used internally)
?
- 以PRIVATE_，NDK_或APP_開頭的名稱（內部使用）
?
- lower-case names (used internally, e.g. 'my-dir')
?
- 小寫名稱（用于內部，例如my-dir）
?
If you need to define your own convenience variables in an Android.mk file, we recommend using the MY_ prefix, for a trivial example:
?
如果你需要在Android.mk文件中定義你自己的便利變量，對于一個小示例，我們建議使用MY_前綴：
?
?? ---------- cut here ------------------
?? ?MY_SOURCES := foo.c
?? ?ifneq ($(MY_CONFIG_BAR),)
?? ? ?MY_SOURCES += bar.c
?? ?endif
?
?? ?LOCAL_SRC_FILES += $(MY_SOURCES)
?? ---------- cut here ------------------
?
So, here we go:
?
接下來，我們繼續：
?
NDK-provided variables:
?
NDK提供的變量
- - - - - - - - - - - -
?
These GNU Make variables are defined by the build system before your Android.mk file is parsed. Note that under certain circumstances the NDK might parse your Android.mk several times, each with different definition for some of these variables.
?
在你的Android.mk文件被解析前這些GNU Make變量被構建系統定義。注意在某些情況下NDK可能多次解析你的Android.mk，每次用不同的值定義這些變量。
?
CLEAR_VARS
?? ?Points to a build script that undefines nearly all LOCAL_XXX variables listed in the "Module-description" section below. You must include the script before starting a new module, e.g.:
?
CLEAR_VARS
?? ?指向一個構建腳本，它取消定義在下面的“模塊描述”部分列舉的幾乎所有LOCAL_XXX變量。你必須在一個新模塊開始之前包含這個腳本，例如：
?
?? ? ?include $(CLEAR_VARS)
?
BUILD_SHARED_LIBRARY
?? ?Points to a build script that collects all the information about the module you provided in LOCAL_XXX variables and determines how to build a target shared library from the sources you listed. Note that you must have LOCAL_MODULE and LOCAL_SRC_FILES defined, at a minimum before including this file. Example usage:
?
BUILD_SHARED_LIBRARY
?? ?指向一個構建腳本，它收集你用LOCAL_XXX變量提供的所有模塊相關信息，并且決定如何從你列舉的源代碼中構建目標動態庫。注意你必須已經定義了LOCAL_MODULE和LOCAL_SRC_FILES，至少在包含這個文件之前。示例用法：
?
?? ? ?include $(BUILD_SHARED_LIBRARY)
?
?? ?note that this will generate a file named lib$(LOCAL_MODULE).so
?
?? ?注意它將生成一個名為lib$(LOCAL_MODULE).so的文件。
?
BUILD_STATIC_LIBRARY
?? ?A variant of BUILD_SHARED_LIBRARY that is used to build a target static library instead. Static libraries are not copied into your project/packages but can be used to build shared libraries (see LOCAL_STATIC_LIBRARIES and LOCAL_STATIC_WHOLE_LIBRARIES described below).
?? ?Example usage:
?
BUILD_STATIC_LIBRARY
?? ?一個BUILD_SHARED_LIBRARY的變種，不同的是用于構建一個目標靜態庫。靜態庫不會被復制進你的project/packages，但可以它用于構建動態庫（見后面描述的LOCAL_STATIC_LIBRARIES和LOCAL_STATIC_WHOLE_LIBRARIES）。
?? ?示例用法：
?
?? ? ?include $(BUILD_STATIC_LIBRARY)
?
?? ?Note that this will generate a file named lib$(LOCAL_MODULE).a
?
?? ?注意這將生成一個名為lib$(LOCAL_MODULE).a的文件。
?
PREBUILT_SHARED_LIBRARY
?? ?Points to a build script used to specify a prebuilt shared library. Unlike BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY, the value of LOCAL_SRC_FILES must be a single path to a prebuilt shared library (e.g. foo/libfoo.so), instead of a source file.
?
PREBUILT_SHARED_LIBRARY
?? ?指向一個構建腳本，用于指定一個預構建的動態庫。不同于BUILD_SHARED_LIBRARY和BUILD_STATIC_LIBRARY，LOCAL_SRC_FILES的值（注：原文可能有誤，應該是PREBUILT_SHARED_LIBRARY的值）必須是一個指向預構建動態庫的單一路徑（例如foo/libfoo.so），而非一個源文件。
?
?? ?You can reference the prebuilt library in another module using the LOCAL_PREBUILTS variable (see docs/PREBUILTS.html for more information).
?
?? ?你可以在另一個模塊中引用預構建庫，使用LOCAL_PREBUILTS變量（見docs/PREBUILTS.html獲得更多信息）。
?
PREBUILT_STATIC_LIBRARY
?? ?This is the same as PREBUILT_SHARED_LIBRARY, but for a static library file instead. See docs/PREBUILTS.html for more.
?
PREBUILT_STATIC_LIBRARY
?? ?和PREBUILT_SHARED_LIBRARY相同，不同的是使用靜態庫文件。見docs/PREBUILTS.html獲得更多信息。
?
TARGET_ARCH
?? ?Name of the target CPU architecture as it is specified by the full Android open-source build. This is 'arm' for any ARM-compatible build, independent of the CPU architecture revision.
?
TARGET_ARCH
?? ?目標CPU架構的名稱，它由完全Android開源構建指定。對于任意與ARM兼容的構建來說它的值是arm，與CPU架構的修訂號無關。
?
TARGET_PLATFORM
?? ?Name of the target Android platform when this Android.mk is parsed. For example, 'android-3' correspond to Android 1.5 system images. For a complete list of platform names and corresponding Android system images, read docs/STABLE-APIS.html.
?
TARGET_PLATFORM
?? ?在這個Android.mk解析時目標Android平臺的名稱。例如android-3對應Android 1.5系統鏡像。要想獲得平臺名稱和對應Android系統鏡像的完整列表，請閱讀docs/STABLE-APIS.html。
?
TARGET_ARCH_ABI
?? ?Name of the target CPU+ABI when this Android.mk is parsed. Two values are supported at the moment:
?
TARGET_ARCH_ABI
?? ?當這個Android.mk被解析時目標CPU+ABI的名稱。現在支持兩種值：
?
?? ? ? armeabi
?? ? ? ? ? ?For Armv5TE
?
?? ? ? armeabi-v7a
?
?? ?NOTE: Up to Android NDK 1.6_r1, this variable was simply defined as 'arm'. However, the value has been redefined to better match what is used internally by the Android platform.
?
?? ?注意：Android NDK 1.6_r1以上，這個變量被簡單地定義為arm。然而，這個值已經被重新定義以更好地匹配Android平臺內部所使用的值。
?
?? ?For more details about architecture ABIs and corresponding compatibility issues, please read docs/CPU-ARCH-ABIS.html
?
?? ?想獲得更多關于架構ABI和相應兼容性問題的細節，請閱讀docs/CPU-ARCH-ABIS.html。
?
?? ?Other target ABIs will be introduced in future releases of the NDK and will have a different name. Note that all ARM-based ABIs will have 'TARGET_ARCH' defined to 'arm', but may have different 'TARGET_ARCH_ABI'
?
?? ?其它目標ABI將在未來的NDK發布版中引入，并且將擁有不同的名稱。注意對于所有基于ARM的ABI，TARGET_ARCH都會被定義為arm，但TARGET_ARCH_ABI的值可能不同。
?
TARGET_ABI
?? ?The concatenation of target platform and abi, it really is defined as $(TARGET_PLATFORM)-$(TARGET_ARCH_ABI) and is useful when you want to test against a specific target system image for a real device.
?
TARGET_ABI
?? ?目標平臺和abi（注：ABI是Application binary interface的縮寫，意思是應用程序和操作系統之間的底層接口）的并稱，它實際上被定義為$(TARGET_PLATFORM)-$(TARGET_ARCH_ABI)，當你想測試一個特定供真實設備使用的特定目標系統鏡像時它會很有用。
?
?? ?By default, this will be 'android-3-armeabi'
?
默認，它的值將是android-3-armeabi。
?
?? ?(Up to Android NDK 1.6_r1, this used to be 'android-3-arm' by default)
?
?? ?（在NDK 1.6_r1之前，它的值曾經默認為android-3-arm）
?
NDK-provided function macros:
?
NDK提供的函數宏：
- - - - - - - - - - - - - - -
?
The following are GNU Make 'function' macros, and must be evaluated by using '$(call <function>)'. They return textual information.
?
以下是GNU Make的function宏，必須通過使用$(call <function>)來計算。它們返回文本信息。
?
my-dir
?? ?Returns the path of the last included Makefile, which typically is the current Android.mk's directory. This is useful to define LOCAL_PATH at the start of your Android.mk as with:
?
my-dir
?? ?返回最近包含的Makefile的路徑，它通常是當前Android.mk的目錄。對在你的Android.mk開頭定義LOCAL_PATH的值有用，正如這樣：
?
?? ? ? ?LOCAL_PATH := $(call my-dir)
?
?? ?IMPORTANT NOTE: Due to the way GNU Make works, this really returns the path of the *last* *included* *Makefile* during the parsing of build scripts. Do not call my-dir after including another file.
?
?? ?重點注意：由于GNU Make的工作方式，實際上返回的路徑是在解析構建腳本時最近包含的Makefile的路徑。請不要再包含另一個文件之后調用my-dir。
?
?? ?For example, consider the following example:
?
例如，考慮以下示例
?
?? ? ? ?LOCAL_PATH := $(call my-dir)
?
?? ? ? ?... declare one module
?
?? ? ? ?... 聲明一個模塊
?
?? ? ? ?include $(LOCAL_PATH)/foo/Android.mk
?
?? ? ? ?LOCAL_PATH := $(call my-dir)
?
?? ? ? ?... declare another module
?
?? ? ? ?... 聲明另一個模塊
?
?? ?The problem here is that the second call to 'my-dir' will define LOCAL_PATH to $PATH/foo instead of $PATH, due to the include that was performed before that.
?
這里的問題是第二次調用my-dir將定義LOCAL_PATH為$PATH/foo而非$PATH，因為在此之前執行了include。
?
?? ?For this reason, it's better to put additional includes after everything else in an Android.mk, as in:
?
?? ?因為這個原因，最好把額外的include放在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
?? ? ? ?# Android.mk結束處的額外include
?? ? ? ?include $(LOCAL_PATH)/foo/Android.mk
?
?? ?If this is not convenient, save the value of the first my-dir call into another variable, for example:
?
?? ?如果這不夠方便，保存第一個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
?
?? ? ? ?... 聲明另一個模塊
?
?
all-subdir-makefiles
?? ?Returns a list of Android.mk located in all sub-directories of the current 'my-dir' path. For example, consider the following hierarchy:
?
all-subdir-makefiles
?? ?返回當前my-dir路徑的所有子目錄下的Android.mk列表。例如，考慮以下目錄層次
?
?? ? ? ?sources/foo/Android.mk
?? ? ? ?sources/foo/lib1/Android.mk
?? ? ? ?sources/foo/lib2/Android.mk
?
?? ?If sources/foo/Android.mk contains the single line:
?
?? ?如果sources/foo/Android.mk包含以下單一行：
?
?? ? ? ?include $(call all-subdir-makefiles)
?
?? ?Then it will include automatically sources/foo/lib1/Android.mk and sources/foo/lib2/Android.mk
?
?? ?那么它將自動地包含sources/foo/lib1/Android.mk和sources/foo/lib2/Android.mk
?
?? ?This function can be used to provide deep-nested source directory hierarchies to the build system. Note that by default, the NDK will only look for files in sources/*/Android.mk
?
?? ?這個函數可以用于把深嵌套源代碼目錄層次提供給構建系統。注意默認，NDK將只查找sources/*/Android.mk的文件。
?
this-makefile
?? ?Returns the path of the current Makefile (i.e. where the function is called).
?
this-makefile
?? ?返回當前Makefile的路徑（即函數被調用的地方）
?
parent-makefile
?? ?Returns the path of the parent Makefile in the inclusion tree, i.e. the path of the Makefile that included the current one.
?
parent-makefile
?? ?返回包含樹中父級Makefile的路徑，即包含當前Makefile的Makefile路徑。
?
grand-parent-makefile
?? ?Guess what...
?
grand-parent-makefile
?? ?猜猜這是什么...（注：應該是祖父母級Makefile的路徑）
?
import-module
?? ?A function that allows you to find and include the Android.mk of another module by name. A typical example is:
?
import-module
?? ?這個函數允許你通過名稱尋找和包含另一個模塊的Android.mk。典型例子是：
?
?? ? ?$(call import-module,<name>)
?
?? ?And this will look for the module tagged <name> in the list of directories referenced by your NDK_MODULE_PATH environment variable, and include its Android.mk automatically for you.
?
?? ?這將在通過你的NDK_MODULE_PATH環境變量引用的目錄中尋找標記為<name>的模塊，并且自動為你包含它的Android.mk。
?
?? ?Read docs/IMPORT-MODULE.html for more details.
?
?? ?閱讀docs/IMPORT-MODULE.html以獲得更詳細的信息。
?
Module-description variables:
?
模塊描述變量：
- - - - - - - - - - - - - - -
?
The following variables are used to describe your module to the build system. You should define some of them between an 'include $(CLEAR_VARS)' and an 'include $(BUILD_XXXXX)'. As written previously, $(CLEAR_VARS) is a script that will undefine/clear all of these variables, unless explicitly noted in their description.
?
以下變量用于向構建系統描述你的模塊。你應該在include $(CLEAR_VARS)和include $(BUILD_XXXXX)之間定義它們中的一些。正如前面所寫的，$(CLEAR_VARS)是一個腳本，它將取消定義或清除所有這些變量，除非在它們的描述中顯式地標明。
?
LOCAL_PATH
?? ?This variable is used to give the path of the current file. You MUST define it at the start of your Android.mk, which can be done with:
?
LOCAL_PATH
?? ?這個變量用于給定當前文件的路徑。你必須在你的Android.mk開頭定義它，它可以這樣寫：
?
?? ? ?LOCAL_PATH := $(call my-dir)
?
?? ?This variable is *not* cleared by $(CLEAR_VARS) so only one definition per Android.mk is needed (in case you define several modules in a single file).
?
?? ?這個變量不會被$(CLEAR_VARS)清除，所以每個Android.mk只需要定義一次（如果你在一個文件中定義幾個模塊）。
?
LOCAL_MODULE
?? ?This is the name of your module. It must be unique among all module names, and shall not contain any space. You MUST define it before including any $(BUILD_XXXX) script.
?
LOCAL_MODULE
?? ?這是你的模塊的名稱。在所有模塊名稱中它必須是唯一的，并且不應該包含任何空格。你必須在包含任意$(BUILD_XXXX)腳本之前定義它。
?
?? ?By default, the module name determines the name of generated files, e.g. lib<foo>.so for a shared library module named <foo>. However you should only refer to other modules with their 'normal' name (e.g. <foo>) in your NDK build files (either Android.mk or Application.mk)
?
?? ?默認，模塊名稱決定生成文件的名稱，例如lib<foo>.so對應一個名為<foo>的動態庫模塊。然而你只應該在你的NDK構建文件中引用它們正常的名稱（例如<foo>）（Android.mk或者Application.mk）
?
?? ?You can override this default with LOCAL_MODULE_FILENAME (see below)
?
?? ?你可以用LOCAL_MODULE_FILENAME重載這個默認名稱（見下）。
?
LOCAL_MODULE_FILENAME
?? ?This variable is optional, and allows you to redefine the name of generated files. By default, module <foo> will always generate a static library named lib<foo>.a or a shared library named lib<foo>.so, which are standard Unix conventions.
?
LOCAL_MODULE_FILENAME
?? ?這個變量是可選的，允許你重新定義生成文件的名稱。默認，模塊<foo>將總是生成名為lib<foo>.a的靜態庫或者名為lib<foo>.so的動態庫，它是標準Unix約定。
?
?? ?You can override this by defining LOCAL_MODULE_FILENAME, For example:
?
?? ?你可以通過定義LOCAL_MODULE_FILENAME重載這個名稱，例如：
?
?? ? ? ?LOCAL_MODULE := foo-version-1
?? ? ? ?LOCAL_MODULE_FILENAME := libfoo
?
?? ?NOTE: You should not put a path or file extension in your LOCAL_MODULE_FILENAME, these will be handled automatically by the build system.
?
?? ?注意：你不應該在你的LOCAL_MODULE_FILENAME中放置路徑或文件擴展名，這些將由構建系統自動處理。
?
LOCAL_SRC_FILES
?? ?This is a list of source files that will be built for your module. Only list the files that will be passed to a compiler, since the build system automatically computes dependencies for you.
?
LOCAL_SRC_FILES
?? ?這是將被構建成你的模塊的源文件列表。只需要列出將被傳遞僅編譯器的文件，因為構建系統會自動為你計算依賴（注：C編譯器在編譯時是分布式的，所以它的輸入文件一般是.c文件。.h頭文件由預處理程序自動尋找，故不需要在命令行中給出。make在構建期間根據依賴信息忽略不需要重新編譯的步驟，提高編譯速度。.c文件和.o文件，.o文件和.a/.so文件，.h和.c文件之間存在依賴）
?
?? ?Note that source files names are all relative to LOCAL_PATH and you can use path components, e.g.:
?
注意源文件的名稱全部都相對于LOCAL_PATH，你可以使用路徑元素，例如：
?
?? ? ?LOCAL_SRC_FILES := foo.c /
?? ? ? ? ? ? ? ? ? ? ? ? toto/bar.c
?
?? ?NOTE: Always use Unix-style forward slashes (/) in build files. Windows-style back-slashes will not be handled properly.
?
?? ?注意：總是在構建文件中使用Unix風格的正斜杠（/）。Windows風格的反斜杠將不能正確地處理。（注：Cygwin風格的/cygdrive/<盤符>/<路徑>不知如何？）
?
LOCAL_CPP_EXTENSION
?? ?This is an optional variable that can be defined to indicate the file extension of C++ source files. The default is '.cpp' but you can change it. For example:
?
LOCAL_CPP_EXTENSION
?? ?可選變量，可以定義它來指定C++源文件的擴展名。默認是.cpp，但你可以改變它。例如：
?
?? ? ? ?LOCAL_CPP_EXTENSION := .cxx
?
LOCAL_C_INCLUDES
?? ?An optional list of paths, relative to the NDK *root* directory, which will be appended to the include search path when compiling all sources (C, C++ and Assembly). For example:
?
LOCAL_C_INCLUDES
?? ?路徑的可選的列表，相對于NDK根目錄，在編譯全部源文件（C、C++和匯編）時它將被接在include搜索路徑的后面。例如：
?
?? ? ? ?LOCAL_C_INCLUDES := sources/foo
?
?? ?Or even:
?
?? ?或者甚至是：
?
?? ? ? ?LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
?
?? ?These are placed before any corresponding inclusion flag in LOCAL_CFLAGS / LOCAL_CPPFLAGS
?
?? ?它們放置在LOCAL_CFLAGS或LOCAL_CPPFLAGS中任意對應的包含標記之前。
?
?? ?The LOCAL_C_INCLUDES path are also used automatically when launching native debugging with ndk-gdb.
?
LOCAL_C_INCLUDES路徑還在使用ndk-gdb啟動原生調試時自動被使用。
?
LOCAL_CFLAGS
?? ?An optional set of compiler flags that will be passed when building C *and* C++ source files.
?
LOCAL_CFLAGS
?? ?編譯器參數的可選集合，將在構建C和C++源代碼時傳遞給編譯器。
?
?? ?This can be useful to specify additional macro definitions or compile options.
?
?? ?這可能對指定額外宏定義或編譯器選項有用。
?
?? ?IMPORTANT: Try not to change the optimization/debugging level in your Android.mk, this can be handled automatically for you by specifying the appropriate information in your Application.mk, and will let the NDK generate useful data files used during debugging.
?
?? ?重要事項：不要嘗試在你的Android.mk中改變優化或調試級別，它會自動地為你指定你的Application.mk的合適信息，并且讓NDK生成用于調試階段的有用數據文件。
?
?? ?NOTE: In android-ndk-1.5_r1, the corresponding flags only applied to C source files, not C++ ones. This has been corrected to match the full Android build system behaviour. (You can use LOCAL_CPPFLAGS to specify flags for C++ sources only now).
?
注意：在android-ndk-1.5_r1中，對應的標記值應用于C源文件，而非C++源文件。它已經被更正為符合完全Android構建系統的行為。（現在你可以使用LOCAL_CPPFLAGS指定C++源文件的標記）
?
?? ?It is possible to specify additional include paths with LOCAL_CFLAGS += -I<path>, however, it is better to use LOCAL_C_INCLUDES for this, since the paths will then also be used during native debugging with ndk-gdb.
?
可以用LOCAL_CFLAGS += -I<路徑>指定額外的包含路徑，最好使用LOCAL_C_INCLUDES做這種事情，因為這些路徑也將會在使用ndk-gdb進行原生調試期間使用。
?
LOCAL_CXXFLAGS
?? ?An alias for LOCAL_CPPFLAGS. Note that use of this flag is obsolete as it may disappear in future releases of the NDK.
?
LOCAL_CXXFLAGS
?? ?LOCAL_CPPFLAGS的別名。注意使用這個標記是過時的，因為它可能在NDK的未來發布版中消失。
?
LOCAL_CPPFLAGS
?? ?An optional set of compiler flags that will be passed when building C++ source files *only*. They will appear after the LOCAL_CFLAGS on the compiler's command-line.
?
LOCAL_CPPFLAGS
?? ?編譯器參數的可選集合，它將只在構建C++源代碼時傳遞給編譯器。它們將在LOCAL_CFLAGS之后出現在編譯器的命令行中。
?
?? ?NOTE: In android-ndk-1.5_r1, the corresponding flags applied to both C and C++ sources. This has been corrected to match the full Android build system. (You can use LOCAL_CFLAGS to specify flags for both C and C++ sources now).
?
注意：在android-ndk-1.5_r1中，對應的參數應用于C和C++源文件。這已經被更正為符合完全Android構建系統。（現在你可以使用LOCAL_CFLAGS指定給C和C++源文件的參數）
?
LOCAL_STATIC_LIBRARIES
?? ?The list of static libraries modules (built with BUILD_STATIC_LIBRARY) that should be linked to this module. This only makes sense in shared library modules.
?
LOCAL_STATIC_LIBRARIES
?? ?靜態庫模塊的列表（用BUILD_STATIC_LIBRARY構建），這些模塊應該被鏈接進這個模塊。這只對動態庫模塊有意義。
?
LOCAL_SHARED_LIBRARIES
?? ?The list of shared libraries *modules* this module depends on at runtime. This is necessary at link time and to embed the corresponding information in the generated file.
?
LOCAL_SHARED_LIBRARIES
?? ?這個模塊在運行時依賴的動態庫模塊的列表。在鏈接期需要這個列表，在生成文件中嵌入相應的信息。
?
LOCAL_LDLIBS
?? ?The list of additional linker flags to be used when building your module. This is useful to pass the name of specific system libraries with the "-l" prefix. For example, the following will tell the linker to generate a module that links to /system/lib/libz.so at load time:
?
LOCAL_LDLIBS
?? ?額外鏈接器參數列表，在構建你的模塊時使用。在用-l前綴傳遞指定的系統庫名稱時有用。例如，以下內容將告訴鏈接器生成一個模塊，它在加載期鏈接到/system/lib/libz.so：
?
?? ? ?LOCAL_LDLIBS := -lz
?
?? ?See docs/STABLE-APIS.html for the list of exposed system libraries you can linked against with this NDK release.
?
參考docs/STABLE-APIS.html以獲得你可以用NDK發布版鏈接的公開系統庫的列表。
?
LOCAL_ALLOW_UNDEFINED_SYMBOLS
?? ?By default, any undefined reference encountered when trying to build a shared library will result in an "undefined symbol" error. This is a great help to catch bugs in your source code.
?
LOCAL_ALLOW_UNDEFINED_SYMBOLS
?? ?當你嘗試構建一個共享庫時將導致一個未定義符號錯誤，用這個變量列出默認下所有遇到的未定義引用。對捕捉你的源代碼缺陷有很大的幫助。（注：可能是交叉編譯導致？）
?
?? ?However, if for some reason you need to disable this check, set this variable to 'true'. Note that the corresponding shared library may fail to load at runtime.
?
?? ?然而，如果因為某些原因，你需要關閉這個檢查，把這個變量設為true。注意對應的動態庫可能在運行期失敗。
?
LOCAL_ARM_MODE
?? ?By default, ARM target binaries will be generated in 'thumb' mode, where each instruction are 16-bit wide. You can define this variable to 'arm' if you want to force the generation of the module's object files in 'arm' (32-bit instructions) mode. E.g.:
?
LOCAL_ARM_MODE
?? ?默認ARM目標的二進制文件將以thumb模式生成，每個指令是16位寬。如果你想強制以arm（32位指令）模式生成模塊目標文件，你可以定義這個變量為arm。例如：
?
?? ? ?LOCAL_ARM_MODE := arm
?
?? ?Note that you can also instruct the build system to only build specific sources in arm mode by appending an '.arm' suffix to its source file name. For example, with:
?
?? ?注意你還可以通過源文件名的.arm后綴，指示構建系統以arm模式僅構建指定的源文件。例如，用以下內容：
?
?? ? ? LOCAL_SRC_FILES := foo.c bar.c.arm
?
?? ?Tells the build system to always compile 'bar.c' in arm mode, and to build foo.c according to the value of LOCAL_ARM_MODE.
?
?? ?告訴構建系統總是以arm模式編譯bar.c，并且根據LOCAL_ARM_MODE的值構建foo.c。
?
?? ?NOTE: Setting APP_OPTIM to 'debug' in your Application.mk will also force the generation of ARM binaries as well. This is due to bugs in the toolchain debugger that don't deal too well with thumb code.
?
?? ?注意：在Application.mk中設置APP_OPTIM為debug也會強制生成ARM二進制文件。因為工具鏈調試器的缺陷，它處理thumb代碼不是太好。
?
LOCAL_ARM_NEON
?? ?Defining this variable to 'true' allows the use of ARM Advanced SIMD (a.k.a. NEON) GCC intrinsics in your C and C++ sources, as well as NEON instructions in Assembly files.
?
LOCAL_ARM_NEON
?? ?定義這個變量為true，可以允許在你的C和C++源代碼中使用ARM進階SIMD（即NEON）的GCC內建（注：NEON是用于多媒體運算的硬件加速技術），以及在匯編文件中使用NEON指令。
?
?? ?You should only define it when targetting the 'armeabi-v7a' ABI that corresponds to the ARMv7 instruction set. Note that not all ARMv7 based CPUs support the NEON instruction set extensions and that you should perform runtime detection to be able to use this code at runtime safely. To lean more about this, please read the documentation at docs/CPU-ARM-NEON.html and docs/CPU-FEATURES.html.
?
?? ?你應該只在目標為對應ARMv7指令集的armeabi-v7a的ABI時定義它。注意不是所有基于ARMv7的CPU支持NEON指令集擴展，所以你應該執行運行期檢測以在運行期安全地使用這個代碼。想知道更多關于這方面的信息，請閱讀docs/CPU-ARM-NEON.html和docs/CPU-FEATURES.html的文檔。
?
?? ?Alternatively, you can also specify that only specific source files may be compiled with NEON support by using the '.neon' suffix, as in:
?
?? ?另外，你還可以通過使用.neon后綴，指定特定的源文件使用NEON支持來編譯，正如這樣：
?
?? ? ? ?LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon
?
?? ?In this example, 'foo.c' will be compiled in thumb+neon mode, 'bar.c' will be compiled in 'thumb' mode, and 'zoo.c' will be compiled in 'arm+neon' mode.
?
?? ?在這個例子中，foo.c將用thumb+neon模式編譯，bar.c將用thumb模式編譯，而zoo.c將以arm+neon模式編譯。
?
?? ?Note that the '.neon' suffix must appear after the '.arm' suffix if you use both (i.e. foo.c.arm.neon works, but not foo.c.neon.arm !)
?
?? ?注意.neon后綴必須出現在.arm后綴后面，如果你都使用（即foo.c.arm.neon可行，但foo.c.neon.arm不可以！）
?
LOCAL_DISABLE_NO_EXECUTE
?? ?Android NDK r4 added support for the "NX bit" security feature. It is enabled by default, but you can disable it if you *really* need to by setting this variable to 'true'.
?
LOCAL_DISABLE_NO_EXECUTE
?? ?Android NDK r4添加對NX bit（注：NX是No eXecute的縮寫，一種CPU技術，用于防止緩沖溢出攻擊）安全特性的支持。默認是打開NX位，如果你真的需要關閉NX位，可以通過設置這個變量為true來做到。
?
?? ?NOTE: This feature does not modify the ABI and is only enabled on kernels targetting ARMv6+ CPU devices. Machine code generated with this feature enabled will run unmodified on devices running earlier CPU architectures.
?
注意：這個特性不會修改ABI，而且只對目標為ARMv6+ CPU設備的內核有效。這個特性生效所生成的機器代碼將不需要修改就能在運行早期CPU架構的設備上運行。
?
?? ?For more information, see:
?
更多信息請參考：
?
?? ? ? ?http://en.wikipedia.org/wiki/NX_bit
?? ? ? ?http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
?
LOCAL_EXPORT_CFLAGS
?? ?Define this variable to record a set of C/C++ compiler flags that will be added to the LOCAL_CFLAGS definition of any other module that uses this one with LOCAL_STATIC_LIBRARIES or LOCAL_SHARED_LIBRARIES.
?
LOCAL_EXPORT_CFLAGS
?? ?定義這個變量以記錄C/C++編譯器參數集合，它將添加到那些通過LOCAL_STATIC_LIBRARIES或LOCAL_SHARED_LIBRARIES使用它的其它任何一個模塊的LOCAL_CFLAGS定義，
?
?? ?For example, consider the module 'foo' with the following definition:
?
例如，考慮使用以下定義的foo模塊：
?
?? ? ? ?include $(CLEAR_VARS)
?? ? ? ?LOCAL_MODULE := foo
?? ? ? ?LOCAL_SRC_FILES := foo/foo.c
?? ? ? ?LOCAL_EXPORT_CFLAGS := -DFOO=1
?? ? ? ?include $(BUILD_STATIC_LIBRARY)
?
?? ?And another module, named 'bar' that depends on it as:
?
而另一個名為bar模塊，像這樣依賴于它：
?
?? ? ? ?include $(CLEAR_VARS)
?? ? ? ?LOCAL_MODULE := bar
?? ? ? ?LOCAL_SRC_FILES := bar.c
?? ? ? ?LOCAL_CFLAGS := -DBAR=2
?? ? ? ?LOCAL_STATIC_LIBRARIES := foo
?? ? ? ?include $(BUILD_SHARED_LIBRARY)
?
?? ?Then, the flags '-DFOO=1 -DBAR=2' will be passed to the compiler when building bar.c
?
那么，參數-DFOO=1 -DBAR=2將在構建bar.c時傳遞給編譯器。
?
?? ?Exported flags are prepended to your module's LOCAL_CFLAGS so you can easily override them. They are also transitive: if 'zoo' depends on 'bar' which depends on 'foo', then 'zoo' will also inherit all flags exported by 'foo'.
?
導出的參數被前置到你的模塊的LOCAL_CFLAGS，所以你可以簡單地重載它們。它們還是及物的：如果zoo依賴于bar，而bar依賴于foo，那么zoo將繼承foo導出的所有參數。
?
?? ?Finally, exported flags are *not* used when building the module that exports them. In the above example, -DFOO=1 would not be passed to the compiler when building foo/foo.c.
?
最后，導出參數在構建導出它們的模塊時不會被使用。上面的例子中，在構建foo/foo.c時-DFOO=1將不會被傳遞給編譯器。
?
LOCAL_EXPORT_CPPFLAGS
?? ?Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only.
?
LOCAL_EXPORT_CPPFLAGS
?? ?和LOCAL_EXPORT_CFLAGS相同，但只用于C++編譯器參數
?
LOCAL_EXPORT_C_INCLUDES
?? ?Same as LOCAL_EXPORT_CFLAGS, but for C include paths. This can be useful if 'bar.c' wants to include headers that are provided by module 'foo'.
?
LOCAL_EXPORT_C_INCLUDES
?? ?和LOCAL_EXPORT_CFLAGS相同，但只用于C包含路徑。如果bar.c想包含foo模塊提供的頭文件，這將有用。
?
LOCAL_EXPORT_LDLIBS
?? ?Same as LOCAL_EXPORT_CFLAGS, but for linker flags. Note that the imported linker flags will be appended to your module's LOCAL_LDLIBS though, due to the way Unix linkers work.
?
LOCAL_EXPORT_LDLIBS
?? ?和LOCAL_EXPORT_CFLAGS相同，但用于鏈接器參數。不過注意由于Unix鏈接器的工作方式，導入的鏈接器參數將接在你的模塊的LOCAL_LDLIBS后面。
?
?? ?This is typically useful when module 'foo' is a static library and has code that depends on a system library. LOCAL_EXPORT_LDLIBS can then be used to export the dependency. For example:
?
這通常在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)
?
?? ?There, libbar.so will be built with a -llog at the end of the linker command to indicate that it depends on the system logging library, because it depends on 'foo'.
?
?? ?那里，libbar.so構建時，在連接器命令中使用-llog以表示它依賴系統的日志庫，因為它依賴于foo。
?
LOCAL_FILTER_ASM
?? ?Define this variable to a shell command that will be used to filter the assembly files from, or generated from, your LOCAL_SRC_FILES.
?
LOCAL_FILTER_ASM
?? ?定義這個變量為一個shell命令，它將用于從LOCAL_SRC_FILES中過濾匯編文件或所生成的匯編文件。
?
?? ?When it is defined, the following happens:
?
當它被定義時，以下事情會發生：
?
?? ? ?- Any C or C++ source file is generated into a temporary assembly file (instead of being compiled into an object file).
?
?? ? ?- 任一C或C++源文件被轉成一個臨時的匯編文件（而非編譯成對象文件）。
?
?? ? ?- Any temporary assembly file, and any assembly file listed in LOCAL_SRC_FILES is sent through the LOCAL_FILTER_ASM command to generate _another_ temporary assembly file.
?
?? ? ?- LOCAL_SRC_FILES列出的任一臨時匯編文件，以及任一匯編文件，通過LOCAL_FILTER_ASM命令發送給LOCAL_FILTER_ASM命令以生成另一個臨時匯編文件。
?
?? ? ?- These filtered assembly files are compiled into object file.
?
?? ? ?- 這些過濾的匯編文件被編譯成對象文件。
?
?? ?In other words, If you have:
?
也就是說，如果你這樣：
?
?? ? ?LOCAL_SRC_FILES ?:= foo.c bar.S
?? ? ?LOCAL_FILTER_ASM := myasmfilter
?
?? ?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
?
?? ?Were "1" corresponds to the compiler, "2" to the filter, and "3" to the assembler. The filter must be a standalone shell command that takes the name of the input file as its first argument, and the name of the output file as the second one, as in:
?
?? ?1對應編譯器，2對應過濾器，3對應匯編器。過濾器必須是一個獨立的shell命令，以輸入文件名作為第一參數，以輸出文件名作為第二參數，正如這樣：
?
?? ? ? ?myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
?? ? ? ?myasmfilter bar.S $OBJS_DIR/bar.S
轉載于:https://www.cnblogs.com/qq78292959/archive/2011/11/02/2232946.html
總結
以上是生活随笔為你收集整理的【翻译】(5)Android.mk File的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Perl Learning (5) ——
- 下一篇： RFID系统集成公司