⑴ 如何把ndk编译出来的可执行文件伪装成so打包到apk中
ndk编译出来的共享库，eclipse会自动打包到apk中，而编译出来的可执行文件则不会。 要想可执行文件自动被打包到apk中，可以把文件名改成libxxx.so的形式，伪装成so，这样就会被打包进apk。 但是每次编译之后都改一下名字，太麻烦， 写个脚本吧，又有arm， arm ndk编译出来的共享库，eclipse会自动打包到apk中，而编译出来的可执行文件则不会。 要想可执行文件自动被打包到apk中，可以把文件名改成libxxx.so的形式，伪装成so，这样就会被打包进apk。 但是每次编译之后都改一下名字，太麻烦， 写个脚本吧，又有arm， armv7， x86的麻烦事， 想试着改LOCAL_MODULE_FILENAME来试试，NDK又不允许。 于是稍微看了下NDK的编译脚本，发现如下解决办法。 NDK是通过在Android.mk文件中include $(BUILD_EXECUTABLE)来编译可执行文件，其实就是调用了一个已经写好的脚本——build-executable.mk。（编译脚本都在NDK_ROOT/build/core目录里面） 仔细看脚本的调用过程可以发现，脚本一开始先检查一下变量合法性（前面改LOCAL_MODULE_FILENAME的方法在这里过不去），最终调用include$(BUILD_SYSTEM)/build-mole.mk来编译。 于是研究这个脚本，找到决定编译输出的变量，在调用最终的编译脚本之前改成想要的就可以了。 最终我的方案如下: 1. 为了不破坏ndk本来的脚本，将build-executable.mk拷贝一份放在自己的工程目录下面，在倒数第三行插入一句？$(evalLOCAL_BUILT_MODULE := $(TARGET_OUT)/$(MY_LOCAL_MODULE_FILENAME)) 2. 在自己的Android.mk文件中定义MY_LOCAL_MODULE_FILENAME变量，当然值就是你想要的文件名啦 3. 编译时不调用系统的include$(BUILD_EXECUTABLE)， 而改调用自己的脚本（就是上面拷贝出来且做了修改的那个脚本），为了方便，你可以给自己的脚本定义一个变量来指向它。 就是这样。 写得比较乱，贴几段关键代码吧。 修改后的build-executable.mk代码。 LOCAL_BUILD_SCRIPT := BUILD_EXECUTABLE LOCAL_MAKEFILE := $(local-makefile) $(call check-defined-LOCAL_MODULE，$(LOCAL_BUILD_SCRIPT)) $(call check-LOCAL_MODULE，$(LOCAL_MAKEFILE)) $(call check-LOCAL_MODULE_FILENAME) # we are building target objects my := TARGET_ $(call handle-mole-filename，，) $(call handle-mole-built) $(eval LOCAL_BUILT_MODULE := $(TARGET_OUT)/$(MY_LOCAL_MODULE_FILENAME)) LOCAL_MODULE_CLASS := EXECUTABLE include $(BUILD_SYSTEM)/build-mole.mk 14行就是我们加的那一行。 上面的文件放在jni根目录，跟目录下的Android.mk代码: MY_BUILD_EXECUTABLE := $(JNI_ROOT)/build-executable.mk include $(call all-subdir-makefiles) 需要编译可执行文件的模块这样写: LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_SRC_FILES := … LOCAL_MODULE := xxx MY_LOCAL_MODULE_FILENAME := libxxx.so LOCAL_C_INCLUDES := … LOCAL_LDLIBS:=-L$(SYSROOT)/usr/lib -llog LOCAL_CFLAGS := -fPIC include $(MY_BUILD_EXECUTABLE)。
⑵ C 怎么include 另一个文件夹头文件
那要看你的连接文件放在哪个目录下了，可以这样试试：#include "../../common/cutils.h"
⑶ android 怎么找.mk文件中调用的lib库
这个变量是相应库对应的jar文件的路径，格式是 别名：JAR路径引用第三方SO文件回，在 eclipse工程里编译的答时候，如果把so文件放在libs/armeabi/下的话，adt会直接给你自动把SO文件把包进去 。而在命令行下进行的话应该定义LOCAL_JNI_SHARED_LIBRARIES，LOCAL_JNI_SHARED_LIBRARIES := libBMapApiEngine 这样还不行，这样直接编译会引发错误：找不到out/target/proct/***/obj/lib/******.so这时你需要把你的so文件放到out/target/proct/***/obj/lib目录下。这样再编译就没问题了。另外在MK中文件中include $(BUILD_PACKAGE)是要编译这个工程，不加这个不会编译，MK文件具体写法请GOOGLE吧，呵呵。
⑷ Android.mk这个文件在哪里呢
我见到过的是在编译整个安卓系统的源码的时候会用到的文件,也就是安卓系统源码未make之前的。他可以强制编译自己写好的应用放进安卓系统中，或者编译修改过后的系统源码
⑸ 为什么android.mk不走include$(build_prebuilt)
一、LOCAL_CFLAGSLOCAL_CFLAGS-D，增加全局宏定义。LOCAL_CFLAGS := -DUSE_JSC相当于在所有源文件中增加一个#define USE_JSCLOCAL_CFLAGS := -DUSE_COPY_BIT=1相当于在所有源文件中增加一个#define USE_COPY_BIT 1还有其它的像-W等，都是传递给编译使用的。比如：LOCAL_CFLAGS := Werror 就是传给编译使用二、BUILD_PREBUILT这种方式把文件当成编译项目，在Android.mk中一个fileLOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) \ LOCAL_MODULE := usb_modeswitch.conf \ LOCAL_MODULE_CLASS := ETC \ LOCAL_MODULE_PATH := $(TARGET_OUT)/etc \ LOCAL_SRC_FILES :=$(LOCAL_MODULE) \ include $(BUILD_PREBUILT) 上面的就是 usb_modeswitch.conf 文件到 OUT 下面的 etc目录，这个目录常用来存放配置相关文件。上面所有的都说的是Copy File 但是如果需要 Copy 一个文件目录下所有就需要另做操作了！三、ACP ACP描述的是一个Android专用的cp命令，在生成system.img镜像文件的过程中是需要用到的。普通的cp命令在不同的平台（Mac OS X、MinGW/Cygwin和Linux）的实现略有差异，并且可能会导致一些问题，于是Android编译系统就重写了自己的cp命令，使得它在不同平台下执行具有统一的行为，并且解决普通cp命令可能会出现的问题。例如，在Linux平台上，当我们把一个文件从NFS文件系统拷贝到本地文件系统时，普通的cp命令总是会认为在NFS文件系统上的文件比在本地文件系统上的文件要新，因为前者的时间戳精度是微秒，而后者的时间戳精度不是微秒。Android专用的cp命令源码可以参考build/tools/acp目录。
⑹ mk是什么格式的文件，用什么软件打开
makefile文件格式，是一种源代码编译指令集合文件，用写字板就可以打开。
⑺ android .mk 中的 -include 是什么意思,怎么用
include 表示你要编译的模块；一个make文件中可以定义多个编译模块；每个编译模块都以include &(CLEAR_VARS)开始，include &(BUILD_XXX)结束。CLEAR_VARS由系统提供，指定让GNU MAKEFILE为你清除 除LOCAL_PATH以外的所有LOCAL_XXX变量；include &(BUILD_XXX)，指定改模块编译为什么模块，如include &(BUILD_STATIC_LIBRARY)表示编译成静态库。
⑻ android.mk文件怎么写
一个Android.mk file用来向编译系统描述你的源代码。具体来说：该文件是GNU Makefile的一小部分，会被编译系统解析一次或多次。你可以在每一个Android.mk file中定义一个或多个模块，你也可以在几个模块中使用同一个源代码文件。编译系统为你处理许多细节问题。例如，你不需要在你的Android.mk中列出头文件和依赖文件。NDK编译系统将会为你自动处理这些问题。这也意味着，在升级NDK后，你应该得到新的toolchain/platform支持，而且不需要改变你的Android.mk文件。先看一个简单的例子：一个简单的"hello world"，比如下面的文件：sources/helloworld/helloworld.csources/helloworld/Android.mk相应的Android.mk文件会象下面这样：———- cut here ——————LOCAL_PATH := $(call my-dir)include $(CLEAR_VARS)LOCAL_MODULE:= helloworldLOCAL_SRC_FILES := helloworld.cinclude $(BUILD_SHARED_LIBRARY)———- cut here ——————我们来解释一下这几行代码：LOCAL_PATH := $(call my-dir)一个Android.mk file首先必须定义好LOCAL_PATH变量。它用于在开发树中查找源文件。在这个例子中，宏函数’my-dir’, 由编译系统提供，用于返回当前路径（即包含Android.mk file文件的目录）。include $( CLEAR_VARS)CLEAR_VARS由编译系统提供，指定让GNU MAKEFILE为你清除许多LOCAL_XXX变量（例如 LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, 等等…),除LOCAL_PATH 。这是必要的，因为所有的编译控制文件都在同一个GNU MAKE执行环境中，所有的变量都是全局的。LOCAL_MODULE := helloworldLOCAL_MODULE变量必须定义，以标识你在Android.mk文件中描述的每个模块。名称必须是唯一的，而且不包含任何空格。注意编译系统会自动产生合适的前缀和后缀，换句话说，一个被命名为'foo'的共享库模块，将会生成'libfoo.so'文件。LOCAL_SRC_FILES := helloworld.cLOCAL_SRC_FILES变量必须包含将要编译打包进模块中的C或C++源代码文件。注意，你不用在这里列出头文件和包含文件，因为编译系统将会自动为你找出依赖型的文件；仅仅列出直接传递给编译器的源代码文件就好。在Android中增加本地程序或者库，这些程序和库与其所载路径没有任何关系，只和它们的Android.mk文件有关系。Android.mk和普通的Makefile有所不同，它具有统一的写法，主要包含一些系统公共的宏。在一个Android.mk中可以生成多个可执行程序、动态库和静态库。1，编译应用程序的模板：#Test ExeLOCAL_PATH := $(call my-dir)#include $(CLEAR_VARS)LOCAL_SRC_FILES:= main.cLOCAL_MODULE:= test_exe#LOCAL_C_INCLUDES :=#LOCAL_STATIC_LIBRARIES :=#LOCAL_SHARED_LIBRARIES :=include $(BUILD_EXECUTABLE)（菜鸟级别解释：:=是赋值的意思，$是引用某变量的值）LOCAL_SRC_FILES中加入源文件路径，LOCAL_C_INCLUDES 中加入所需要包含的头文件路径，LOCAL_STATIC_LIBRARIES加入所需要链接的静态库（*.a）的名称，LOCAL_SHARED_LIBRARIES中加入所需要链接的动态库（*.so）的名称，LOCAL_MODULE表示模块最终的名称，BUILD_EXECUTABLE表示以一个可执行程序的方式进行编译。2，编译静态库的模板：#Test Static LibLOCAL_PATH := $(call my-dir)include $(CLEAR_VARS)LOCAL_SRC_FILES:= /helloworld.cLOCAL_MODULE:= libtest_static#LOCAL_C_INCLUDES :=#LOCAL_STATIC_LIBRARIES :=#LOCAL_SHARED_LIBRARIES :=include $(BUILD_STATIC_LIBRARY)一般的和上面相似，BUILD_STATIC_LIBRARY表示编译一个静态库。3，编译动态库的模板：#Test Shared LibLOCAL_PATH := $(call my-dir)include $(CLEAR_VARS)LOCAL_SRC_FILES:= /helloworld.cLOCAL_MODULE:= libtest_sharedTARGET_PRELINK_MODULES := false#LOCAL_C_INCLUDES :=#LOCAL_STATIC_LIBRARIES :=#LOCAL_SHARED_LIBRARIES :=include $(BUILD_SHARED_LIBRARY)一般的和上面相似，BUILD_SHARED_LIBRARY表示编译一个静态库。以上三者的生成结果分别在如下，generic依具体target会变：out/target/proct/generic/obj/EXECUTABLEout/target/proct/generic/obj/STATIC_LIBRARYout/target/proct/generic/obj/SHARED_LIBRARY每个模块的目标文件夹分别为：可执行程序：XXX_intermediates静态库： XXX_static_intermediates动态库： XXX_shared_intermediates另外，在Android.mk文件中，还可以指定最后的目标安装路径，用LOCAL_MODULE_PATH和LOCAL_UNSTRIPPED_PATH来指定。不同的文件系统路径用以下的宏进行选择：TARGET_ROOT_OUT：表示根文件系统。TARGET_OUT：表示system文件系统。TARGET_OUT_DATA：表示data文件系统。用法如：CAL_MODULE_PATH:=$(TARGET_ROOT_OUT)
⑼ Android Makefile中是 如何识别 TARGET_PRODUCT 的
TARGET_PRODUCT 来决定编译定制proct.首先， 编译Android 代码 通常情况下使用：# make showcommands这实际上等价于下面的完整命令 （具体参见 build/core/envsetup.mk ）# TARGET_ARCH=arm TARGET_PRODUCT=generic TARGET_BUILD_TYPE=release make showcommands可见，默认情况下编译系统认为TARGET_PRODUCT 是generic 的那如何编译特定产品的Android呢？这就需要查看Android Makefile是如何解析环境变量TARGET_PRODUCT的。Android Makefile 的引用关系是这样的Makefile -> build/core/main.mk -> build/core/config.mk -> build/core/envsetup.mk -> build/core/proct_config.mk在build/core/proct_config.mk 中编译系统首先调用 build/core/proct.mk中定义的函数get-all-proct-makefiles ，来遍历整个vendor 的子目录， 找到vendor下所有的 AndroidProcts.mk, 不同子目录下的AndroidProcts.mk 中定义了不同的 PRODUCT_NAME, PRODUCT_DEVICE 等信息，（我们也可以通过 打开build/core/proct_config.mk 中的#$(mp-procts) 语句使控制台编译的时候输出所有proct 的信息） ， 接着build/core/proct_config.mk 会调用resolve-short-proct-name 将TARGET_PRODUCT匹配的AndroidProcts.mk 中定义的 PRODUCT_DEVICE 赋值给TARGET_DEVICE。有了这个TARGET_DEVICE, 再回到 build/core/config.mk，会include $(TARGET_DEVCIE)/BoardConfig.mkboard_config_mk := / $(strip $(wildcard / $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/BoardConfig.mk / vendor/*/$(TARGET_DEVICE)/BoardConfig.mk / )) include $(board_config_mk)而这个配置文件BoardConfig.mk 决定了目标系统编译属性，比如使用ALSA还是不是 GENERIC_AUDIO 等等另外在这里TARGET_DEVICE 宏也决定了TARGET_DEVICE_DIR， 因为TARGET_DEVICE_DIR 取的是上面提到的BoardConfig.mk 的路径。TARGET_DEVICE_DIR := $(patsubst %/,%,$(dir $(board_config_mk)))当然Android 的Ob目标输出也是由TARGET_DEVICE决定，见build/core/envsetup.mkTARGET_OUT_ROOT_release := $(OUT_DIR)/targetTARGET_OUT_ROOT_debug := $(DEBUG_OUT_DIR)/targetTARGET_OUT_ROOT := $(TARGET_OUT_ROOT_$(TARGET_BUILD_TYPE))TARGET_PRODUCT_OUT_ROOT := $(TARGET_OUT_ROOT)/proctPRODUCT_OUT := $(TARGET_PRODUCT_OUT_ROOT)/$(TARGET_DEVICE)再回到 build/core/main.mk, 编译系统接着做的一个件事情是，遍历所有字目录，找到所有Android.mk文件，并将这些Android.mk文件include 进来## Typical build; include any Android.mk files we can find.#subdir_makefiles := / $(shell build/tools/findleaves.py –prune=out –prune=.repo –prune=.git $(subdirs) Android.mk)include $(subdir_makefiles)我们再来看其中的./build/target/board/Android.mk，对了它引用了include $(TARGET_DEVICE_DIR)/AndroidBoard.mk由上面TARGET_DEVICE_DIR的定义，这下又进入了vendor 下TARGET_DEVICE指向的目录了，这个mk文件中定义了特定Proct需要编译和安装app 和 script.
⑽ android mk文件怎么加混淆
针对android 选择user版本进行编译的时候，会出现proguard错误，我们需要知道的事情 1.proguard是做什么的，他的作用是将java代码进行混淆的工具 2.因为proguard是混淆工具，所以android的mk文件也对其支持为两种方式： 1.指定不需要混淆的native方法与变量的proguard.flags文件 如：LOCAL_PROGUARD_FLAG_FILES := proguard.flags 2.制定编译的工程，不要使用代码混淆的工具进行代码混淆 如：LOCAL_PROGUARD_ENABLED := disabled 3.不设置，默认使用LOCAL_PROGUARD_ENABLED := full.即将该工程代码全部混淆/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////在Android项目中用到JNI，当用了proguard后，发现native方法找不到很多变量，原来是被proard优化掉了。所以，在JNI应用中该慎用progurad啊。 解决办法： 1、在Android.mk中加入一行： LOCAL_PROGUARD_FLAGS := -include $(LOCAL_PATH)/proguard.flags 2、创建proguard.flag文件，里面写入不需要proguard优化的类和方法。例如： -keep class oms.miracle.mobiletv.broadcast.ServiceContext { *; } 我的这个类是和JNI相关的，不想让proguard去优化而引起错误，向上面写就能实现。 ———-下面是网上找到的一些proguard的资料，贴出来分享： ProGuard是一个免费的java类文件压缩,优化,混淆器.它探测并删除没有使用的类,字段,方法和属性.它删除没有用的说明并使用字节码得到最大优化.它使用无意义的名字来重命名类,字段和方法. ProGuard的使用是为了: 1.创建紧凑的代码文档是为了更快的网络传输,快速装载和更小的内存占用. 2.创建的程序和程序库很难使用反向工程. 3.所以它能删除来自源文件中的没有调用的代码 4.充分利用java6的快速加载的优点来提前检测和返回java6中存在的类文件. 参数： -include {filename} 从给定的文件中读取配置参数 -basedirectory {directoryname} 指定基础目录为以后相对的档案名称 -injars {class_path} 指定要处理的应用程序jar,war,ear和目录 -outjars {class_path} 指定处理完后要输出的jar,war,ear和目录的名称 -libraryjars {classpath} 指定要处理的应用程序jar,war,ear和目录所需要的程序库文件 – 指定不去忽略非公共的库类。 – 指定不去忽略包可见的库类的成员。 保留选项 -keep {Modifier} {class_specification} 保护指定的类文件和类的成员 -keepclassmembers {modifier} {class_specification} 保护指定类的成员，如果此类受到保护他们会保护的更好 -keepclasseswithmembers {class_specification} 保护指定的类和类的成员，但条件是所有指定的类和类成员是要存在。 -keepnames {class_specification} 保护指定的类和类的成员的名称（如果他们不会压缩步骤中删除） -keepclassmembernames {class_specification} 保护指定的类的成员的名称（如果他们不会压缩步骤中删除） -keepclasseswithmembernames {class_specification} 保护指定的类和类的成员的名称，如果所有指定的类成员出席（在压缩步骤之后） -printseeds {filename} 列出类和类的成员-keep选项的清单，标准输出到给定的文件
