Android.mk和Application.mk文件语法规范说明及举例
浏览数：191 /
时间：2015年06月11日
以下英文内容摘自：http://www.kandroid.org/ndk/docs/OVERVIEW.html
The Android NDK is a set of tools that allows Android application developers to embed native machine code compiled from C and/or C++ source files into their application packages.
NDK development in practice:(1)、Configuring the NDK; (2)、Placing C and C++ sources; (3)、Writing an Android.mk build script; (4)、Writing an Application.mk build file (optional); (5)、Invoke the NDK build system; (6)、Specifying custom output directories.
An Android.mk file is written to describe your sources to the build system.
An Android.mk file is really a tiny GNU Makefile fragment that will be parsed one or more times by the build system.
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.
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.
NDK build system reserves the following variable names:
- names that begin with LOCAL_ (e.g. LOCAL_MODULE)
- names that begin with PRIVATE_, NDK_ or APP_ (used internally)
- lower-case names (used internally, e.g. ‘my-dir‘)
2、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. 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:
Note that this will generate a file named lib$(LOCAL_MODULE).so
3、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:
4、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.
5、PREBUILT_STATIC_LIBRARY : This is the same as PREBUILT_SHARED_LIBRARY, but for a static library file instead.
6、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.
7、TARGET_PLATFORM : Name of the target Android platform when this Android.mk is parsed.
8、TARGET_ARCH_ABI : Name of the target CPU+ABI when this Android.mk is parsed. Two values are supported at the moment: armeabi armeabi-v7a , e.g.:
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.
9、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. By default, this will be ‘android-3-armeabi‘ (Up to Android NDK 1.6_r1, this used to be ‘android-3-arm‘ by default).
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.
2、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:
sources/foo/Android.mk sources/foo/lib1/Android.mk sources/foo/lib2/Android.mk
If sources/foo/Android.mk contains the single line:
Then it will include automatically sources/foo/lib1/Android.mk and sources/foo/lib2/Android.mk
3、this-makefile : Returns the path of the current Makefile (i.e. where the function is called).
4、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.
5、grand-parent-makefile : Guess what...
6、import-module : A function that allows you to find and include the Android.mk of another module by name. A typical example is: $(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.
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).
2、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. 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). e.g.:
3、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. You can override this by defining LOCAL_MODULE_FILENAME, For example:
NOTE: You should not put a path or file extension in your LOCAL_MODULE_FILENAME, these will be handled automatically by the build system.
4、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. Note that source files names are all relative to LOCAL_PATH and you can use path components, e.g.:
5、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:
6、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:
Or even:
These are placed before any corresponding inclusion flag in LOCAL_CFLAGS / LOCAL_CPPFLAGS
The LOCAL_C_INCLUDES path are also used automatically when launching native debugging with ndk-gdb.
7、LOCAL_CFLAGS : An optional set of compiler flags that will be passed when building C *and* C++ source files. 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.
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).
8、 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.
9、 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.
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).
10、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.
11、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.
12、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:
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.
13、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.
14、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.:
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:
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.
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. 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.
15、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. 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.
Alternatively, you can also specify that only specific source files may be compiled with NEON support by using the ‘.neon‘ suffix, as in:
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.
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 !)
16、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‘.
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.
17、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. For example, consider the module ‘foo‘ with the following definition:
And another module, named ‘bar‘ that depends on it as:
Then, the flags ‘-DFOO=1 -DBAR=2‘ will be passed to the compiler when building 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‘. 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.
18、LOCAL_EXPORT_CPPFLAGS : Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only.
19、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‘.
20、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. 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:
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‘.
21、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. 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).
- 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.
- These filtered assembly files are compiled into object file.
In other words, If you have:
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:
myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S
If you want to override this behaviour, you can define APP_BUILD_SCRIPT to point to an alternate build script. A non-absolute path will always be interpreted as relative to the NDK‘s top-level directory.
8、APP_ABI : By default, the NDK build system will generate machine code for the ‘armeabi‘ ABI. This corresponds to an ARMv5TE based CPU with software floating point operations. You can use APP_ABI to select a different ABI.
For example, to support hardware FPU instructions on ARMv7 based devices, use:
Or to support the IA-32 instruction set, use:
Or to support the MIPS instruction set, use:
Or to support all at the same time, use:
Or even better, since NDK r7, you can also use the special value ‘all‘ which means "all ABIs supported by this NDK release":
9、APP_STL : By default, the NDK build system provides C++ headers for the minimal C++ runtime library (/system/lib/libstdc++.so) provided by the Android system.
However, the NDK comes with alternative C++ implementations that you can use or link to in your own applications. Define APP_STL to select one of them. Examples are:
10、APP_GNUSTL_FORCE_CPP_FEATURES : In prior NDK versions, the simple fact of using the GNU libstdc++ runtime (i.e. by setting APP_STL to either ‘gnustl_static‘ or ‘gnustl_shared‘) enforced the support for exceptions and RTTI in all generated machine code. This could be problematic in specific, but rare, cases, and also generated un-necessarily bigger code for projects that don‘t require these features.
This bug was fixed in NDK r7b, but this means that if your code requires exceptions or RTTI, it should now explicitely say so, either in your APP_CPPFLAGS, or your LOCAL_CPPFLAGS / LOCAL_CPP_FEATURES definitions. To make it easier to port projects to NDK r7b and later, one can optionally defined APP_GNUSTL_CPP_FEATURES to contain one or more of the following values:
exceptions -> to enforce exceptions support for all modules.
rtti -> to enforce rtti support for all modules.
For example, to get the exact same behaviour than NDK r7:
IMPORTANT: This variable is provided here as a convenience to make it easier to transition to a newer version of the NDK. It will be removed in a future revision. We thus encourage all developers to modify the module definitions properly instead of relying on it here.
11、APP_SHORT_COMMANDS : The equivalent of LOCAL_SHORT_COMMANDS for your whole project.
Application.mk使用举例：
The Android NDK is a set of tools that allows Android application developers to embed native machine code compiled from C and/or C++ source files into their application packages.
NDK development in practice:(1)、Configuring the NDK; (2)、Placing C and C++ sources; (3)、Writing an Android.mk build script; (4)、Writing an Application.mk build file (optional); (5)、Invoke the NDK build system; (6)、Specifying custom output directories.
An Android.mk file is written to describe your sources to the build system.
An Android.mk file is really a tiny GNU Makefile fragment that will be parsed one or more times by the build system.
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.
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.
NDK build system reserves the following variable names:
- names that begin with LOCAL_ (e.g. LOCAL_MODULE)
- names that begin with PRIVATE_, NDK_ or APP_ (used internally)
- lower-case names (used internally, e.g. ‘my-dir‘)
If you need to define your own convenience variables in an Android.mk file, we recommend using the MY_ prefix.
NDK-provided variables:
1、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. 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.:
include $(CLEAR_VARS)
2、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. 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:
include $(BUILD_SHARED_LIBRARY)
Note that this will generate a file named lib$(LOCAL_MODULE).so
3、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:
include $(BUILD_STATIC_LIBRARY)Note that this will generate a file named lib$(LOCAL_MODULE).a
4、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.
5、PREBUILT_STATIC_LIBRARY : This is the same as PREBUILT_SHARED_LIBRARY, but for a static library file instead.
6、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.
7、TARGET_PLATFORM : Name of the target Android platform when this Android.mk is parsed.
8、TARGET_ARCH_ABI : Name of the target CPU+ABI when this Android.mk is parsed. Two values are supported at the moment: armeabi armeabi-v7a , e.g.:
TARGET_ARCH_ABI := 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.
9、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. By default, this will be ‘android-3-armeabi‘ (Up to Android NDK 1.6_r1, this used to be ‘android-3-arm‘ by default).
NDK-provided function macros:
The following are GNU Make ‘function‘ macros, and must be evaluated by using ‘$(call <function>)‘. They return textual information.
1、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:
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.
2、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:
sources/foo/Android.mk sources/foo/lib1/Android.mk sources/foo/lib2/Android.mk
If sources/foo/Android.mk contains the single line:
include $(call all-subdir-makefiles)
Then it will include automatically sources/foo/lib1/Android.mk and sources/foo/lib2/Android.mk
3、this-makefile : Returns the path of the current Makefile (i.e. where the function is called).
4、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.
5、grand-parent-makefile : Guess what...
6、import-module : A function that allows you to find and include the Android.mk of another module by name. A typical example is: $(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.
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.
1、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 := $(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).
2、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. 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). e.g.:
LOCAL_MODULE := foo
3、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. You can override this by defining LOCAL_MODULE_FILENAME, For example:
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.
4、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. Note that source files names are all relative to LOCAL_PATH and you can use path components, e.g.:
LOCAL_SRC_FILES := foo.c \ toto/bar.cNOTE: Always use Unix-style forward slashes (/) in build files. Windows-style back-slashes will not be handled properly.
5、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 := .cxx
6、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 := sources/foo
Or even:
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
These are placed before any corresponding inclusion flag in LOCAL_CFLAGS / LOCAL_CPPFLAGS
The LOCAL_C_INCLUDES path are also used automatically when launching native debugging with ndk-gdb.
7、LOCAL_CFLAGS : An optional set of compiler flags that will be passed when building C *and* C++ source files. 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.
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).
8、 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.
9、 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.
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).
10、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.
11、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.
12、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 := -lz
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.
13、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.
14、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
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:
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.
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. 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.
15、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. 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.
Alternatively, you can also specify that only specific source files may be compiled with NEON support by using the ‘.neon‘ suffix, as in:
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.
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 !)
16、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‘.
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.
17、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. For example, consider the module ‘foo‘ with the following definition:
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:
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
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‘. 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.
18、LOCAL_EXPORT_CPPFLAGS : Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only.
19、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‘.
20、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. 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:
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‘.
21、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. 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).
- 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.
- 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:
myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S
The purpose of Application.mk is to describe which native ‘modules‘ (i.e. static/shared libraries) are needed by your application.
An Application.mk file is usually placed under $PROJECT/jni/Application.mk, where $PROJECT points to your application‘s project directory.
The Application.mk is really a tiny GNU Makefile fragment that must define a few variables:
1、APP_PROJECT_PATH : This variable should give the *absolute* path to your Application‘s project root directory. This is used to copy/install stripped versions of the generated JNI shared libraries to a specific location known to the APK-generating tools.
Note that it is optional for $PROJECT/jni/Application.mk, but *mandatory* for $NDK/apps/<myapp>/Application.mk
2、APP_MODULES : This variable is optional. If not defined, the NDK will build by default _all_ the modules declared by your Android.mk, and any sub-makefile it may include. If APP_MODULES is defined, it must be a space-separated list of module names as they appear in the LOCAL_MODULE definitions of Android.mk files. Note that the NDK will compute module dependencies automatically.
3、APP_OPTIM : This optional variable can be defined to either ‘release‘ or ‘debug‘. This is used to alter the optimization level when building your application‘s modules. A ‘release‘ mode is the default, and will generate highly optimized binaries. The ‘debug‘ mode will generate un-optimized binaries which are much easier to debug.
Note that if your application is debuggable (i.e. if your manifest sets the android:debuggable attribute to "true" in its <application> tag), the default will be ‘debug‘ instead of ‘release‘. This can be overridden by setting APP_OPTIM to ‘release‘.
Note that it is possible to debug both ‘release‘ and ‘debug‘ binaries, but the ‘release‘ builds tend to provide less information during debugging sessions: some variables are optimized out and can‘t be inspected, code re-ordering can make stepping through the code difficult, stack traces may not be reliable, etc...
4、APP_CFLAGS : A set of C compiler flags passed when compiling any C or C++ source code of any of the modules. This can be used to change the build of a given module depending on the application that needs it, instead of modifying the Android.mk file itself.
5、APP_CXXFLAGS : An alias for APP_CPPFLAGS, to be considered obsolete as it may disappear in a future release of the NDK.
6、APP_CPPFLAGS : A set of C++ compiler flags passed when building C++ sources *only*.
7、APP_BUILD_SCRIPT : By default, the NDK build system will look for a file named Android.mk under $(APP_PROJECT_PATH)/jni, i.e. for the file:
$(APP_PROJECT_PATH)/jni/Android.mk
If you want to override this behaviour, you can define APP_BUILD_SCRIPT to point to an alternate build script. A non-absolute path will always be interpreted as relative to the NDK‘s top-level directory.
8、APP_ABI : By default, the NDK build system will generate machine code for the ‘armeabi‘ ABI. This corresponds to an ARMv5TE based CPU with software floating point operations. You can use APP_ABI to select a different ABI.
For example, to support hardware FPU instructions on ARMv7 based devices, use:
APP_ABI := armeabi-v7a
Or to support the IA-32 instruction set, use:
APP_ABI := x86
Or to support the MIPS instruction set, use:
APP_ABI := mips
Or to support all at the same time, use:
APP_ABI := armeabi armeabi-v7a x86 mips
Or even better, since NDK r7, you can also use the special value ‘all‘ which means "all ABIs supported by this NDK release":
APP_ABI := all
9、APP_STL : By default, the NDK build system provides C++ headers for the minimal C++ runtime library (/system/lib/libstdc++.so) provided by the Android system.
However, the NDK comes with alternative C++ implementations that you can use or link to in your own applications. Define APP_STL to select one of them. Examples are:
APP_STL := stlport_static --> static STLport library APP_STL := stlport_shared --> shared STLport library APP_STL := system --> default C++ runtime library
10、APP_GNUSTL_FORCE_CPP_FEATURES : In prior NDK versions, the simple fact of using the GNU libstdc++ runtime (i.e. by setting APP_STL to either ‘gnustl_static‘ or ‘gnustl_shared‘) enforced the support for exceptions and RTTI in all generated machine code. This could be problematic in specific, but rare, cases, and also generated un-necessarily bigger code for projects that don‘t require these features.
This bug was fixed in NDK r7b, but this means that if your code requires exceptions or RTTI, it should now explicitely say so, either in your APP_CPPFLAGS, or your LOCAL_CPPFLAGS / LOCAL_CPP_FEATURES definitions. To make it easier to port projects to NDK r7b and later, one can optionally defined APP_GNUSTL_CPP_FEATURES to contain one or more of the following values:
exceptions -> to enforce exceptions support for all modules.
rtti -> to enforce rtti support for all modules.
For example, to get the exact same behaviour than NDK r7:
APP_GNUSTL_FORCE_CPP_FEATURES := exceptions rtti
IMPORTANT: This variable is provided here as a convenience to make it easier to transition to a newer version of the NDK. It will be removed in a future revision. We thus encourage all developers to modify the module definitions properly instead of relying on it here.
11、APP_SHORT_COMMANDS : The equivalent of LOCAL_SHORT_COMMANDS for your whole project.
Android Native CPU ABI Management:
1、‘armeabi‘:This is the name of an ABI for ARM-based CPUs that support *at* *least* the ARMv5TE instruction set.
2、‘armeabi-v7a‘:This is the name of another ARM-based CPU ABI that *extends* ‘armeabi‘ to include a few CPU instruction set extensions.
3、‘x86‘:This is the name of an ABI for CPUs supporting the instruction set commonly named ‘x86‘ or ‘IA-32‘.
4、‘mips‘:This is the name of an ABI for MIPS-based CPUs that support *at* *least* the MIPS32r1 instruction set.
Android.mk使用举例(http://stackoverflow.com/questions/12260149/libjpeg-turbo-for-android)：
# Makefile for libjpeg-turbo ifneq ($(TARGET_SIMULATOR),true) ################################################## ### simd ### ################################################## LOCAL_PATH := $(my-dir) include $(CLEAR_VARS) ifeq ($(ARCH_ARM_HAVE_NEON),true) LOCAL_CFLAGS += -D__ARM_HAVE_NEON endif # From autoconf-generated Makefile EXTRA_DIST = simd/nasm_lt.sh simd/jcclrmmx.asm simd/jcclrss2.asm simd/jdclrmmx.asm simd/jdclrss2.asm simd/jdmrgmmx.asm simd/jdmrgss2.asm simd/jcclrss2-64.asm simd/jdclrss2-64.asm simd/jdmrgss2-64.asm simd/CMakeLists.txt libsimd_SOURCES_DIST = simd/jsimd_arm_neon.S simd/jsimd_arm.c LOCAL_SRC_FILES := $(libsimd_SOURCES_DIST) LOCAL_C_INCLUDES := $(LOCAL_PATH)/simd $(LOCAL_PATH)/android AM_CFLAGS := -march=armv7-a -mfpu=neon AM_CCASFLAGS := -march=armv7-a -mfpu=neon LOCAL_MODULE_TAGS := debug LOCAL_MODULE := libsimd include $(BUILD_STATIC_LIBRARY) ###################################################### ### libjpeg.so ## ###################################################### include $(CLEAR_VARS) # From autoconf-generated Makefile libjpeg_SOURCES_DIST = jcapimin.c jcapistd.c jccoefct.c jccolor.c jcdctmgr.c jchuff.c jcinit.c jcmainct.c jcmarker.c jcmaster.c jcomapi.c jcparam.c jcphuff.c jcprepct.c jcsample.c jctrans.c jdapimin.c jdapistd.c jdatadst.c jdatasrc.c jdcoefct.c jdcolor.c jddctmgr.c jdhuff.c jdinput.c jdmainct.c jdmarker.c jdmaster.c jdmerge.c jdphuff.c jdpostct.c jdsample.c jdtrans.c jerror.c jfdctflt.c jfdctfst.c jfdctint.c jidctflt.c jidctfst.c jidctint.c jidctred.c jquant1.c jquant2.c jutils.c jmemmgr.c jmemnobs.c jaricom.c jcarith.c jdarith.c turbojpeg.c transupp.c jdatadst-tj.c jdatasrc-tj.c turbojpeg-mapfile LOCAL_SRC_FILES:= $(libjpeg_SOURCES_DIST) LOCAL_SHARED_LIBRARIES := libcutils LOCAL_STATIC_LIBRARIES := libsimd LOCAL_C_INCLUDES := $(LOCAL_PATH) LOCAL_CFLAGS := -DAVOID_TABLES -O3 -fstrict-aliasing -fprefetch-loop-arrays -DANDROID -DANDROID_TILE_BASED_DECODE -DENABLE_ANDROID_NULL_CONVERT LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_STATIC_LIBRARY) LOCAL_MODULE_TAGS := debug LOCAL_MODULE := libjpeg include $(BUILD_SHARED_LIBRARY) ###################################################### ### cjpeg ### ###################################################### include $(CLEAR_VARS) # From autoconf-generated Makefile cjpeg_SOURCES = cdjpeg.c cjpeg.c rdbmp.c rdgif.c rdppm.c rdswitch.c rdtarga.c LOCAL_SRC_FILES:= $(cjpeg_SOURCES) LOCAL_SHARED_LIBRARIES := libjpeg LOCAL_C_INCLUDES := $(LOCAL_PATH) $(LOCAL_PATH)/android LOCAL_CFLAGS := -DBMP_SUPPORTED -DGIF_SUPPORTED -DPPM_SUPPORTED -DTARGA_SUPPORTED -DANDROID -DANDROID_TILE_BASED_DECODE -DENABLE_ANDROID_NULL_CONVERT LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLE) LOCAL_MODULE_TAGS := debug LOCAL_MODULE := cjpeg include $(BUILD_EXECUTABLE) ###################################################### ### djpeg ### ###################################################### include $(CLEAR_VARS) # From autoconf-generated Makefile djpeg_SOURCES = cdjpeg.c djpeg.c rdcolmap.c rdswitch.c wrbmp.c wrgif.c wrppm.c wrtarga.c LOCAL_SRC_FILES:= $(djpeg_SOURCES) LOCAL_SHARED_LIBRARIES := libjpeg LOCAL_C_INCLUDES := $(LOCAL_PATH) $(LOCAL_PATH)/android LOCAL_CFLAGS := -DBMP_SUPPORTED -DGIF_SUPPORTED -DPPM_SUPPORTED -DTARGA_SUPPORTED -DANDROID -DANDROID_TILE_BASED_DECODE -DENABLE_ANDROID_NULL_CONVERT LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLE) LOCAL_MODULE_TAGS := debug LOCAL_MODULE := djpeg include $(BUILD_EXECUTABLE) ###################################################### ### jpegtran ### ###################################################### include $(CLEAR_VARS) # From autoconf-generated Makefile jpegtran_SOURCES = jpegtran.c rdswitch.c cdjpeg.c transupp.c LOCAL_SRC_FILES:= $(jpegtran_SOURCES) LOCAL_SHARED_LIBRARIES := libjpeg LOCAL_C_INCLUDES := $(LOCAL_PATH) $(LOCAL_PATH)/android LOCAL_CFLAGS := -DANDROID -DANDROID_TILE_BASED_DECODE -DENABLE_ANDROID_NULL_CONVERT LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLE) LOCAL_MODULE_TAGS := debug LOCAL_MODULE := jpegtran include $(BUILD_EXECUTABLE) ###################################################### ### tjunittest ### ###################################################### include $(CLEAR_VARS) # From autoconf-generated Makefile tjunittest_SOURCES = tjunittest.c tjutil.c LOCAL_SRC_FILES:= $(tjunittest_SOURCES) LOCAL_SHARED_LIBRARIES := libjpeg LOCAL_C_INCLUDES := $(LOCAL_PATH) LOCAL_CFLAGS := -DANDROID -DANDROID_TILE_BASED_DECODE -DENABLE_ANDROID_NULL_CONVERT LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLE) LOCAL_MODULE_TAGS := debug LOCAL_MODULE := tjunittest include $(BUILD_EXECUTABLE) ###################################################### ### tjbench ### ###################################################### include $(CLEAR_VARS) # From autoconf-generated Makefile tjbench_SOURCES = tjbench.c bmp.c tjutil.c rdbmp.c rdppm.c wrbmp.c wrppm.c LOCAL_SRC_FILES:= $(tjbench_SOURCES) LOCAL_SHARED_LIBRARIES := libjpeg LOCAL_C_INCLUDES := $(LOCAL_PATH) LOCAL_CFLAGS := -DBMP_SUPPORTED -DPPM_SUPPORTED -DANDROID -DANDROID_TILE_BASED_DECODE -DENABLE_ANDROID_NULL_CONVERT LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLE) LOCAL_MODULE_TAGS := debug LOCAL_MODULE := tjbench include $(BUILD_EXECUTABLE) ###################################################### ### rdjpgcom ### ###################################################### include $(CLEAR_VARS) # From autoconf-generated Makefile rdjpgcom_SOURCES = rdjpgcom.c LOCAL_SRC_FILES:= $(rdjpgcom_SOURCES) LOCAL_SHARED_LIBRARIES := libjpeg LOCAL_C_INCLUDES := $(LOCAL_PATH) LOCAL_CFLAGS := -DANDROID -DANDROID_TILE_BASED_DECODE -DENABLE_ANDROID_NULL_CONVERT LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLE) LOCAL_MODULE_TAGS := debug LOCAL_MODULE := rdjpgcom include $(BUILD_EXECUTABLE) ###################################################### ### wrjpgcom ### ###################################################### include $(CLEAR_VARS) # From autoconf-generated Makefile wrjpgcom_SOURCES = wrjpgcom.c LOCAL_SRC_FILES:= $(wrjpgcom_SOURCES) LOCAL_SHARED_LIBRARIES := libjpeg LOCAL_C_INCLUDES := $(LOCAL_PATH) LOCAL_CFLAGS := -DANDROID -DANDROID_TILE_BASED_DECODE -DENABLE_ANDROID_NULL_CONVERT LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLE) LOCAL_MODULE_TAGS := debug LOCAL_MODULE := wrjpgcom include $(BUILD_EXECUTABLE) endif # TARGET_SIMULATOR != true
Application.mk使用举例：
# Build both ARMv5TE and ARMv7-A machine code. #APP_ABI := armeabi #APP_ABI := armeabi-v7a APP_ABI := armeabi armeabi-v7a # APP_OPTIM := release OR debug #By default, the headers and libraries for the minimal C++ runtime system #library (/system/lib/libstdc++.so) are used when building C++ sources. # #You can however select a different implementation by setting the variable #APP_STL to something else in your Application.mk, for example: # #system -> Use the default minimal C++ runtime library. #stlport_static -> Use STLport built as a static library. #stlport_shared -> Use STLport built as a shared library. #gnustl_static -> Use GNU libstdc++ as a static library. APP_STL := stlport_static #APP_STL := stlport_shared #APP_STL := gnustl_static #STLPORT_FORCE_REBUILD := true
# Build both ARMv5TE and ARMv7-A machine code. APP_PLATFORM :=android-14 APP_MODULES := jpegTest APP_ABI := armeabi armeabi-v7a APP_STL := stlport_static APP_CPPFLAGS += -fexceptions #for using c++ features,you need to enable these in your Makefile APP_CPP_FEATURES += exceptions rtti
参考文献：
1、http://blog.csdn.net/smfwuxiao/article/details/8530742
2、http://www.oschina.net/question/565065_93983
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
