在Android源码中编译自己的模块?
在进行Android下的jni开始时，我们编写的有些C/C++代码需要访问android中的一些C/C++的头文件，这些头文件没有在NDK中包含，不能再NDK中直接编译，只能放入到android的源码中进行编译。
编译的方法为:
1.在android的源码的development路径下创建一个文件夹,取名为screen(可以取任意的名称)，然后将需要编译的C/C++文件放入这个文件夹，然后编写makefile文件Android.mk,内容大致如下：
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_LDLIBS := -lm
-llog//这一句是可选的，如果代码中使用android中的记录日志的api,就需要加上，否则不需要加上。
LOCAL_MODULE := HelloWorld
LOCAL_SRC_FILES := HelloWorld.cpp
include $(BUILD_EXECUTABLE) 此处设置为生成可执行的目标码,如果生成so共享库，则需要修改为
include $(BUILD_SHARED_LIBRARY)
2.然后在android源码的根目录下运行make
screen就在out\target\product\generic\system\bin生产了可执行的目标码，如果mekefile中指定为生产共享库，在生产的so文件在out\target\product\generic\system\lib文件夹下。
这里我们重点说下，如何编写 Android.mk文件。
Android.mk文件语法规范
（英文原文件在/development/Ndk/Docs/android-mk.txt）
Android.mk编译文件是用来向Android NDK描述你的C,C++源代码文件的，
这篇文档描述了它的语法。在阅读下面的内容之前，假定你已经阅读了docs/OVERVIEW.TXT文件，了解了它们的脚色和用途。
一个Android.mk file用来向编译系统描述你的源代码，具体来说：该文件是GNU
Makefile的一小部分，会被编译系统解析一次或更多次的build系统。因此，您应尽量减少您声明的变量，不要认为某些变量在解析过程中不会被定义。-这个文件的语法允许把你的源代码组织成模块，一个模块属下列类型之一：静态库
只有共享库将被安装/复制到您的应用软件包。虽然静态库能被用于生成共享库。
你可以在每一个Android.mk file中定义一个或多个模块，你也可以在几个模块中使用同一个源代码文件。
-编译系统为你处理许多细节问题。例如，你不需要在你的Android.mk中列出头文件和依赖文件。NDK编译系统将会为你自动处理这些问题。这也意味着，在升级NDK后，你应该得到新的toolchain/platform支持，而且不需要改变你的Android.mk文件。
注意，这个语法同公开发布的Android平台的开源代码很接近，然而编译系统实现他们的方式却是不同的，这是故意这样设计的，可以让程序开发人员重用外部库的源代码更容易。
简单的例子:
在描述语法细节之前，咱们来看一个简单的"hello world"的例子，比如，下面的文件：
sources/helloworld/helloworld.c
sources/helloworld/Android.mk，
'helloworld.c'是一个JNI共享库，实现返回"hello world"字符串的原生方法。
相应的Android.mk文件会象下面这样：
---------- cut here ------------------
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE:= helloworld
LOCAL_SRC_FILES := helloworld.c
include $(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 := helloworld
LOCAL_MODULE变量必须定义，以标识你在Android.mk文件中描述的每个模块。名称必须是唯一的，而且不包含任何空格。注意编译系统会自动产生合适的前缀和后缀，换句话说，一个被命名为'foo'的共享库模块，将会生成'libfoo.so'文件。
重要注意事项：如果你把库命名为‘libhelloworld’，编译系统将不会添加任何的lib前缀，也会生成libhelloworld.so，这是为了支持来源于Android平台的源代码的Android.mk文件，如果你确实需要这么做的话。
LOCAL_SRC_FILES := helloworld.c
LOCAL_SRC_FILES变量必须包含将要编译打包进模块中的C或C++源代码文件。注意，你不用在这里列出头文件和包含文件，因为编译系统将会自动为你找出依赖型的文件；仅仅列出直接传递给编译器的源代码文件就好。【注意，默认的C++源码文件的扩展名是’.cpp’.
指定一个不同的扩展名也是可能的，只要定义LOCAL_DEFAULT_CPP_EXTENSION变量，不要忘记开始的小圆点（也就是定义为‘.cxx’,而不是‘cxx’）（当然这一步我们一般不会去改它）】
include $(BUILD_SHARED_LIBRARY)
BUILD_SHARED_LIBRARY是编译系统提供的变量，指向一个GNU
Makefile脚本（应该就是在build/core目录下的shared_library.mk），负责收集自从上次调用'include
$(CLEAR_VARS)'以来，定义在LOCAL_XXX变量中的所有信息，并且决定编译什么，如何正确地去做。并根据其规则生成静态库。同理对于静态库。
在sources/samples目录下有更复杂一点的例子，写有注释的Android.mk文件，你可以看看。
这是一份你应该在Android.mk中依赖或定义的变量列表，您可以定义其他变量为自己使用，
但是NDK编译系统保留下列变量名：
-以LOCAL_开头的名字（例如 LOCAL_MODULE）
-以PRIVATE_, NDK_ or APP_开头的名字（内部使用）
-小写名字（内部使用，例如’my-dir’）
如果您为了方便在Android.mk中定义自己的变量，我们建议使用MY_前缀，一个小例子：
---------- cut here ------------------
MY_SOURCES := foo.c
ifneq ($(MY_CONFIG_BAR),)
MY_SOURCES += bar.c
LOCAL_SRC_FILES += $(MY_SOURCES)
---------- cut here ------------------
- - - - - - - - - - -
这些GNU Make 变量在你的Android.mk文件解析之前，就由编译系统定义好了。
注意在某些情况下，NDK可能分析Android.mk几次，每一次某些变量的定义会有不同。
CLEAR_VARS
指向一个编译脚本，几乎所有未定义的LOCAL_XXX变量都在"Module-description"节中列出。
你必须在开始一个新模块之前包含这个脚本，include $(CLEAR_VARS)
BUILD_SHARED_LIBRARY
指向编译脚本，收集所有的你在LOCAL_XXX变量中提供的信息，并且决定如何把你列出的源代码文件编译成一个共享库。注意，你必须至少在包含这个文件之前定义LOCAL_MODULE和LOCAL_SRC_FILES，使用例子：
$(BUILD_SHARED_LIBRARY)，注意这将生成一个名为lib$(LOCAL_MODULE).so的文件。
BUILD_STATIC_LIBRARY
一个BUILD_SHARED_LIBRARY变量用于编译一个静态库。静态库不会复制到你的project/packages中，但是能够用于编译共享库，（看下面描述的LOCAL_STATIC_LIBRARIES
and LOCAL_STATIC_WHOLE_LIBRARIES）
使用例子：include $(BUILD_STATIC_LIBRARY)
注意，这将会生成一个名为lib$(LOCAL_MODULE).a的文件。
TARGET_ARCH
目标CPU平台的名字，如同在android开放源码中指定的那样。如果是’arm’，表示要生成ARM兼容的指令，与CPU架构的修订版无关。
TARGET_PLATFORM
Android.mk解析的时候，目标Android平台的名字.详情可参考/development/ndk/docs/stable-apis.txt.
android-3 -& Official Android 1.5 system images
android-4 -& Official Android 1.6 system images
android-5 -& Official Android 2.0 system images
TARGET_ARCH_ABI
暂时只支持两个value，armeabi和armeabi-v7a。在现在的版本中一般把这两个值简单的定义为arm，通过android
平台内部对它重定义来获得更好的匹配。
其他的ＡＢＩ将在以后的ＮＤＫ版本中介绍，它们会有不同的名字。注意所有基于ＡＲＭ的ＡＢＩ都会把'TARGET_ARCH'定义成‘ａｒｍ’，但是会有不同的‘TARGET_ARCH_ABI’
TARGET_ABI
　　目标平台和ABI的组合，它事实上被定义成$(TARGET_PLATFORM)-$(TARGET_ARCH_ABI)
在你想要在真实的设备中针对一个特别的目标系统进行测试时，会有用。在默认的情况下，它会是'android-3-arm'。
下面是GNU Make　‘功能’宏，必须通过使用'$(call )'来求值，他们返回文本化的信息。
返回当前Android.mk所在的目录路径，相对于ＮＤＫ编译系统的顶层。这是有用的，在Android.mk文件的开头如此定义：
LOCAL_PATH := $(call my-dir)
all-subdir-makefiles　返回一个位于当前'my-dir'路径的子目录列表。
模块描述变量:
下面的变量用于向编译系统描述你的模块。你应该定义在'include $(CLEAR_VARS)'和'include
$(BUILD_XXXXX)'之间定义。正如前面描写的那样，$(CLEAR_VARS是一个脚本，清除所有这些变量，除非在描述中显式注明。
LOCAL_PATH
　　这个变量用于给出当前文件的路径。你必须在Android.mk的开头定义，可以这样使用：
LOCAL_PATH := $(call my-dir)
这个变量不会被$(CLEAR_VARS)清除，因此每个Android.mk只需要定义一次（即使你在一个文件中定义了几个模块的情况下）。
LOCAL_MODULE
这是你模块的名字，它必须是唯一的，而且不能包含空格。你必须在包含任一的$(BUILD_XXXX)脚本之前定义它。模块的名字决定了生成文件的名字，例如，如果一个一个共享库模块的名字是，那么生成文件的名字就是lib.so。但是，在你的NDK生成文件中（或者Android.mk或者Application.mk），你应该只涉及(引用)有正常名字的其他模块。
LOCAL_SRC_FILES
这是要编译的源代码文件列表。只要列出要传递给编译器的文件，因为编译系统自动为你计算依赖。
注意源代码文件名称都是相对于LOCAL_PATH的，你可以使用路径部分，例如：
LOCAL_SRC_FILES := foo.c \
toto/bar.c
注意：在生成文件中都要使用UNIX风格的斜杠(/).windows风格的反斜杠不会被正确的处理。
LOCAL_CPP_EXTENSION
这是一个可选变量，用来指定C++代码文件的扩展名，默认是'.cpp',但是你可以改变它，比如：
LOCAL_CPP_EXTENSION := .cxx
LOCAL_C_INCLUDES ，路径的可选配置，是从根目录开始的，
all sources (C, C++ and Assembly). For example:
LOCAL_C_INCLUDES := sources/foo
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
需要在任何包含LOCAL_CFLAGS / LOCAL_CPPFLAGS标志之前。
LOCAL_CFLAGS 可选的编译器选项，在编译C代码文件的时候使用。
这可能是有用的，指定一个附加的包含路径（相对于NDK的顶层目录），宏定义，或者编译选项。
重要信息：不要在Android.mk中改变optimization/debugging级别，只要在Application.mk中指定合适的信息，就会自动地为你处理这个问题，在调试期间，会让ＮＤＫ自动生成有用的数据文件。
LOCAL_CXXFLAGS
Same as LOCAL_CFLAGS for C++ source files
LOCAL_CPPFLAGS
与LOCAL_CFLAGS相同，但是对C 和　C++ source files都适用。
LOCAL_STATIC_LIBRARIES
应该链接到这个模块的静态库列表（使用BUILD_STATIC_LIBRARY生成），这仅仅对共享库模块才有意义。
LOCAL_SHARED_LIBRARIES
这个模块在运行时要依赖的共享库模块列表，在链接时需要，在生成文件时嵌入的相应的信息。注意：这不会附加列出的模块到编译图，也就是，你仍然需要在Application.mk中把它们添加到程序要求的模块中。
LOCAL_LDLIBS
编译你的模块要使用的附加的链接器选项。这对于使用”-l”前缀传递指定库的名字是有用的。例如，下面将告诉链接器生成的模块要在加载时刻链接到/system/lib/libz.so
LOCAL_LDLIBS := -lz
看docs/STABLE-APIS.TXT获取你使用NDK发行版能链接到的开放的系统库列表。
LOCAL_ALLOW_UNDEFINED_SYMBOLS
默认情况下，在试图编译一个共享库时，任何未定义的引用将导致一个“未定义的符号”错误。这对于在你的源代码文件中捕捉错误会有很大的帮助。然而，如果你因为某些原因，需要不启动这项检查，把这个变量设为‘ｔｒｕｅ’。注意相应的共享库可能在运行时加载失败。（这个一般尽量不要去设为true）
LOCAL_ARM_MODE
默认情况下，arm目标二进制会以thumb的形式生成（16位），你可以通过设置这个变量为arm如果你希望你的module是以32位指令的形式。
'arm' (32-bit instructions) mode. E.g.:
LOCAL_ARM_MODE := arm
注意你同样可以在编译的时候告诉系统编译特定的类型，比如
LOCAL_SRC_FILES := foo.c bar.c.arm
这样就告诉系统总是将bar.c以arm的模式编译，
Android.mk使用模板
在一个Android.mk中可以生成多个可执行程序、动态库和静态库。
1，编译应用程序的模板：
LOCAL_PATH := $(call my-dir)
#include $(CLEAR_VARS)
LOCAL_SRC_FILES:= main.c
LOCAL_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 Lib
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= \helloworld.c
LOCAL_MODULE:= libtest_static
#LOCAL_C_INCLUDES :=
#LOCAL_STATIC_LIBRARIES :=
#LOCAL_SHARED_LIBRARIES :=
include $(BUILD_STATIC_LIBRARY)
一般的和上面相似，BUILD_STATIC_LIBRARY表示编译一个静态库。
3，编译动态库的模板：
#Test Shared Lib
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= \helloworld.c
LOCAL_MODULE:= libtest_shared
TARGET_PRELINK_MODULES := false
#LOCAL_C_INCLUDES :=
#LOCAL_STATIC_LIBRARIES :=
#LOCAL_SHARED_LIBRARIES :=
include $(BUILD_SHARED_LIBRARY)
一般的和上面相似，BUILD_SHARED_LIBRARY表示编译一个共享库。
以上三者的生成结果分别在如下，generic依具体target会变：
out/target/product/generic/obj/EXECUTABLE
out/target/product/generic/obj/STATIC_LIBRARY
out/target/product/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文件系统。
LOCAL_MODULE_PATH:=$(TARGET_ROOT_OUT)
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。一问易答：模块化手机为何还没有普及？_网易手机
一问易答：模块化手机为何还没有普及？
用微信扫码二维码
分享至好友和朋友圈
模块化的真正目的很可能是剥夺品牌商的创新空间和话语权，这也就解释了，为何这个项目，是由谷歌推动的了，当然，这一切也不过是一个假设，小编抛砖引玉，不过是想为大家提供一个讨论的空间，关于模块化手机，大家有什么想法呢？可以在跟帖中进行留言。
最近手机市场中各类黑科技纷纷浮出水面，可以说大大调动了消费者们对新鲜事物的兴趣，而在去年曾火爆一时的模块化概念，就在快被大家遗忘的时候，又再次被一些厂商摆到了台面上。此前模块化手机之所以会受到关注，是因为其标榜环保的属性，因为正常来说，很多人可能一年就要更换一部手机，而如果采用模块化的手机，那么可能每年，我们只需要更换一些模块即可，听起来确实蛮有道理的样子，可是这个概念已经传说了很久了，为何迟迟没有相关的产品出来呢？就算是LG刚刚推出的所谓“模块化”的手机，也只不过算是模块化概念的一个半成品。这一概念普及起来，到底有何难点呢？今天我们就来简单的解析一下。模块化手机要普及 难在哪里？1、模块的通用性首先是在通用性的设计上，模块化手机还是存在一定难度的，想象一下，因为模块的固定化，所以机身的大小肯定是最小模块的整数倍，那么对于不同尺寸的屏幕来说，如果要实现使用同一种尺寸的模块，只有两种可能性，一是前面板适应模块，二是模块适应前面板。如果前面板适应模块，那么势必会造成空间的浪费，而如果模块适应前面板，恐怕就没有通用性可言了，统一是个大问题，模块不规范，会造成碎片化严重，如果按照尺寸设定模块，那么在开放性上，又有了很大的限制，还是比较矛盾的。2、手机厚度第二点就是手机的厚度与空间利用率，如今手机日趋便携化，轻薄化，功能机时代的“大砖头”造型已经离开我们很久了，如果现在告诉你，我们要回到那个时代，用回“砖头”机，你会欣然接受吗？这同大屏化的趋势还有些区别，看起来，这更像是真正的“返璞归真”，因为要照顾到模块的通用性，所以，各类模块组合起来，一定不会使手机很轻薄，至少目前的技术来看，应该是无法实现这一点的。3、空间利用率它存在着另一个矛盾就是空间利用率，现在硬件更新换代的速度可以说是非常快了，处理器一年小一倍是很平常的，不过处理器的尺寸却绝对不会同你最小模块的大小相同，这样就会出现模块空间大，而干货小的情况，这样自然就会造成空间的浪费。对于本来空间利用率就相对较低的模块化手机来说，又造成了额外的浪费，想象一下，这会是一种怎样的体验吧。4、散热能力还有就是散热能力了，我们知道，模块化的手机，每个模块都有自己的外壳，这就相当于在热源上套了一个外套，如果选用的材料传热不好，那么很容易烧坏模块，而如果选用的材料传热太好，用户拿着则会很烫手，即使用复合材料解决了单个模块的散热问题，那么模块挨着模块，拼在一起的发热量也将会很可观。5、优化而除了硬件方面的问题，软件上的优化也是一个问题，因为要适应多种硬件组合，对于软件公司的优化能力就会有一个很高的要求，想象一下，对于普通的手机来说，在运行一些程序时还会存在闪退、软件冲突等情况，那么对于多硬件组合的模块化手机呢？当然，软件公司可以对每个模块的不同搭配做优化，但是这必然没有硬件更新的速度快，随之而来的便是成本的上升，这样就显得有些得不偿失了。6、 成本接着再说成本问题，前面我们提到的几点虽然看似很难实现，但也不排除会有厂商实现它，毕竟目前已经出现了类似的半成品商用版本，不过想实现它，那么前期必然会耗费大量的研发成本，而相信任何一家商用公司将它研发出来，都不会是想来做慈善的，那样研发费用自然会分摊到每个模块上，再加上应该不会太低的硬件成本，即使每部手机只定1元加价作为利润，那么这种手机的性价比也必然比不上目前国内的这些千元机。7、所谓的环保最后再说说所谓的环保的，不知因为什么原因，模块化手机被冠以环保这样的标签，乍一听确实好像很有道理的样子，不过事实上呢？如果你仔细想就不难发现，我们每次在想着更新模块的时候，肯定不会只更换一个模块，所以，当我们更换过后，你得到的是一部更新配置的半新手机和几个旧零件，而使用普通手机的用户，在更换完手机后，则是会得到一部全新的手机和一部旧手机，除非厂商可以提供一套回首机制，将模块循环利用，否则，环保这个说法，还真是有点站不住脚。综合来看，似乎模块化离我们并不是很近，而且深入思考，你会发现，模块化手机如果真的实现大普及，对行业并不会是一件好事，因为它会阻碍创新的脚步，将一切变得“八股文”化，现在为何安卓碎片化太严重？因为很多品牌商以及部分运营商话语权太大，硬件创新依赖品牌商来整合并实现。所以，模块化的真正目的很可能是剥夺品牌商的创新空间和话语权，这也就解释了，为何这个项目，是由谷歌推动的了，当然，这一切也不过是一个假设，小编抛砖引玉，不过是想为大家提供一个讨论的空间，关于模块化手机，大家有什么想法呢？可以在跟帖中进行留言，大家在探讨中图个乐呵。很多小伙伴在询问如何查看往期的《一问易答》，小编会在下方放出网易手机公众平台的二维码，关注后，大家在公众平台下方的选项卡中选择一问易答即可查看。好啦，今天的回答就到这里，正所谓回答有长短，问题不要停，每天跟帖问一问，轻松又开心，提问要注意些什么呢？还是老生常谈的话题，亲们要仔细看清楚哦！问题要有意义，内容不限，最好与科技相关，比如：“移动4G通话回落为何不是3G、新视野是如何飞到冥王星的、导弹发射原理神马的”但凡小编了解的，会尽量帮大家解答，而灌水内容如“小编是SB，小编又调皮了”等都是不被推崇的，当然，如果你真的发了，小编我也只能忍下。为了维护栏目优质的交流环境，希望大家能够遵守秩序，少灌水，多提问，让有需要的朋友学到知识的同时，也能够提高自己对手机的理解。一问易答已经开始正式实行上榜红名制度了，凡被采纳上榜的小伙伴都将获得为期7天的【手机学霸】红名称号，本周红名称号已发放，小伙伴们自行查收吧，不要感谢我，请叫我红领巾！
最后声明：每位上榜的小伙伴都将获得跟帖点亮红名7天的特权，想要拥有炫酷的称号和特权吗？赶快参与到互动中来吧！今天问答不给力，明天榜上就没你！
本文来源：网易手机
责任编辑：韩一冰_NT3945
用微信扫码二维码
分享至好友和朋友圈
加载更多新闻
热门产品:　　　
:　　　　　　　　
:　　　　　　　　　
热门影院：
阅读下一篇
用微信扫描二维码
分享至好友和朋友圈4286人阅读
Android（29）
1、android 5.0
including ./hardware/invensense/Android.mk ...
TARGET_2ND_ARCH--yes
build/core/shared_library.mk:12: sensors.mt: LOCAL_MODULE_PATH for shared libraries is unsupported in multiarch builds, use LOCAL_MODULE_RELATIVE_PATH instead
build/core/base_rules.mk:550: 警告：覆盖关于目标“out/target/product//system/lib/hw/sensors.mt.so”的命令
build/core/base_rules.mk:550: 警告：忽略关于目标“out/target/product//system/lib/hw/sensors.mt.so”的旧命令
build/core/dynamic_binary.mk:84: 警告：覆盖关于目标“out/target/product//symbols/system/lib/hw/sensors.mt.so”的命令
build/core/dynamic_binary.mk:84: 警告：忽略关于目标“out/target/product//symbols/system/lib/hw/sensors.mt.so”的旧命令
2、自定义模块需要添加编译指定PRODUCT_PACKAG环境变量
我们在开发中，经常会碰到需要自己添加独立模块的时候，笔者以前也没太关心这个问题，以为写好Android.mk就可以了，其实还不是这么回事。
把自定义的模块放在android顶层目录development下面，比如模块名字是libcsiJni，模块的Android.mk如下：
&& 在使用eng模式下编译，能够正常编译出来。但是在user模式下不编译，手动进入该目录，执行mm可以正常编译。Eng跟user版本的差异我们一般也知道，但是使用的optional，按道理说是所有模式下都可以编译的。什么原因呢？
从现象上看，应该是编译路径没有添加进去。搜索了一下资料，自定义的模块需要添加编译指定，PRODUCT_PACKAG环境变量。可以在device下面具体产品目录下的crane_productXXX.mk中或者build/target/product/core.mk中添加，示例如下：
&&本身这种问题就是很初级的问题，没什么技术含量，就当做个笔记吧！
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：731254次
积分：6404
积分：6404
排名：第3858名
原创：13篇
转载：243篇
评论：29条
(1)(1)(3)(11)(1)(1)(2)(4)(12)(4)(12)(9)(10)(15)(9)(7)(2)(13)(7)(5)(10)(9)(24)(10)(18)(18)(17)(5)(4)(12)}