mk文件include|android 怎么找mk文件中调用的lib库

⑴ 如何把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选项的清单,标准输出到给定的文件


赞 (0)