android.mk文件语法,Android.mk和Application.mk文件语法规范说明及举例

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.so for a shared library module named . However you should only refer to other modules with their 'normal' name (e.g. ) 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 will always generate a static library named lib.a or a shared library named lib.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.c

NOTE: 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, 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//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 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:= 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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值