手机用psp模拟器ppsspp打开游戏后无反应怎么办？_百度知道
手机用psp模拟器ppsspp打开游戏后无反应怎么办？
提问者采纳
用小鸡模拟器吧
很好用 不止psp模拟器还有其他的。里面有游戏下载
提问者评价
太给力了，你的回答完美解决了我的问题！
其他类似问题
psp模拟器的相关知识
按默认排序
其他2条回答
游戏设置不正确，请到ppsspp吧查找该游戏的设置
手机配置不够
我是盖世5啊
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁Android.mk和Application.mk文件语法规范说明及举例 -
网络资源是无限的
- 博客频道 - CSDN.NET
1264人阅读
以下英文内容摘自：http://www.kandroid.org/ndk/docs/OVERVIEW.htmlThe 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++ (3)、Writing an Android. (4)、Writing an Application.mk build file (optional); (5)、Invoke the NDK (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).so3、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).a4、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-v7aNOTE: 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.mk3、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 := foo3、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.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 := .cxx6、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/fooOr even:LOCAL_C_INCLUDES := $(LOCAL_PATH)/../fooThese are placed before any corresponding inclusion flag in LOCAL_CFLAGS / LOCAL_CPPFLAGSThe 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 inshared 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 := -lzIt 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 := armNote that you can also instruct the build system to only build specific sources in arm mode by appending an '.arm' suffix to its source filename. For example, with:LOCAL_SRC_FILES := foo.c bar.c.armTells 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 ARMv7based 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.neonIn 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 usesthis 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.cExported 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 := myasmfilterfoo.c --1--& $OBJS_DIR/foo.S.original --2--& $OBJS_DIR/foo.S --3--& $OBJS_DIR/foo.obar.S & & & & & & & & & & & & & & & & --2--& $OBJS_DIR/bar.S --3--& $OBJS_DIR/bar.oWere &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.Smyasmfilter bar.S $OBJS_DIR/bar.SThe 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.mk2、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.mkIf 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-v7aOr to support the IA-32 instruction set, use:APP_ABI := x86Or to support the MIPS instruction set, use:APP_ABI := mipsOr to support all at the same time, use:APP_ABI := armeabi armeabi-v7a x86 mipsOr even better, since NDK r7, you can also use the special value 'all' which means &all ABIs supported by this NDK release&:APP_ABI := all9、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 library10、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 rttiIMPORTANT: 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使用举例(/questions//libjpeg-turbo-for-android)：# Makefile for libjpeg-turbo
ifneq ($(TARGET_SIMULATOR),true)
##################################################
##################################################
LOCAL_PATH := $(my-dir)
include $(CLEAR_VARS)
ifeq ($(ARCH_ARM_HAVE_NEON),true)
LOCAL_CFLAGS += -D__ARM_HAVE_NEON
# 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)
######################################################
######################################################
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)
######################################################
######################################################
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)
######################################################
######################################################
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)
######################################################
######################################################
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)
######################################################
######################################################
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)
######################################################
######################################################
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)
# TARGET_SIMULATOR != trueApplication.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:
-& 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/85307422、http://www.oschina.net/question/83
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：864567次
积分：11151
积分：11151
排名：第499名
原创：194篇
转载：188篇
评论：757条
(4)(9)(10)(4)(4)(4)(5)(4)(4)(6)(9)(12)(1)(4)(11)(4)(5)(4)(1)(1)(3)(3)(2)(1)(2)(1)(1)(2)(3)(4)(1)(2)(2)(4)(2)(4)(2)(6)(2)(5)(4)(7)(12)(9)(1)(15)(18)(11)(16)(23)(4)(18)(24)(15)(23)(18)(2)(1)(2)