查看Android.mk文件释疑的源代码 Android.mk文件释疑 0

=== 一、hardware\led\led\Android.mk ===

<br>
<pre>
LOCAL_PATH := $(call my-dir)
</pre>
首先需要指定LOCAL_PATH变量，用于查找源文件

上面的语句的意思是将LOCAL_PATH变量定义成本文件所在目录路径，这句必须放在 include $(CLEAR_VARS)前面，否则编译会报错。

<br>
<pre>
#Android.mk中可以定义多个编译模块，每个编译模块都是以include $(CLEAR_VARS)开始，以include $(BUILD_XXX)结束。
include $(CLEAR_VARS) #开始
</pre>
问： CLEAR_VARS是什么？？

答： CLEAR_VARS由编译系统提供，指定让GNU MAKEFILE为你清除除LOCAL_PATH以外的所有LOCAL_XXX变量，如LOCAL_MODULE，LOCAL_SRC_FILES，LOCAL_SHARED_LIBRARIES，LOCAL_STATIC_LIBRARIES等。    

<br>
<pre>
LOCAL_C_INCLUDES += \
hardware/led/include/
</pre>
包含的头文件

<br>
<pre>
LOCAL_PRELINK_MODULE := false  # :=是赋值的意思
LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw 
</pre>
LOCAL_MODULE_PATH: 最后的目标安装路径
    
问： TARGET_OUT_SHARED_LIBRARIES是什么？

答： 在build/core/envsetup.mk中定义。TARGET_OUT_SHARED_LIBRARIES:= $(TARGET_OUT)/lib

*TARGET_ROOT_OUT：表示根文件系统。
*TARGET_OUT：表示system文件系统。
*TARGET_OUT_DATA：表示data文件系统。

<br>
<pre>
LOCAL_SHARED_LIBRARIES := liblog  #LOCAL_SHARED_LIBRARIES中加入所需要链接的动态库（*.so）的名称
LOCAL_SRC_FILES := led.cpp
LOCAL_MODULE :=led.default   #LOCAL_MODULE表示模块最终的名称，led后面跟有default，led.default能够保证我们的模块总能被硬象抽象层加载到
</pre>
*LOCAL_SRC_FILES中加入源文件路径，LOCAL_C_INCLUDES 中加入所需要包含的头文件路径，
*LOCAL_STATIC_LIBRARIES加入所需要链接的静态库（*.a）的名称，
*LOCAL_SHARED_LIBRARIES中加入所需要链接的动态库（*.so）的名称，
*LOCAL_MODULE表示模块最终的名称

<br>
<pre>
LOCAL_MODULE_TAGS := eng
include $(BUILD_SHARED_LIBRARY) # 结束
</pre>
*include $(BUILD_STATIC_LIBRARY)表示编译成静态库
*include $(BUILD_SHARED_LIBRARY)表示编译成动态库。
*include $(BUILD_EXECUTABLE)表示编译成可执行程序

<br>
=== 二、frameworks\base\services\forlinx_led_jni\Android.mk ===


<pre>
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
</pre>
LOCAL_PATH变量定义成本文件所在目录路径

<br>
<pre>
# [optional, user, eng] 
# eng = required
# optinal = no install on target
LOCAL_MODULE_TAGS := eng
</pre>
LOCAL_MODULE_TAGS :=optional -->> out/target/product/OK6410/symbols/system/

LOCAL_MODULE_TAGS :=eng    -->> out/target/product/Ok6410/system/

LOCAL_MODULE_TAGS defines in which build flavor this module should be installed.
Just give "user" tag, if you want the module to be installed in all of (user, userdebug, eng)

You can find full document [http://www.kandroid.org/online-pdk/guide/build_system.html here]
:
<pre>
eng     This is the default flavor. A plain make is the same as make eng.

* Installs modules tagged with: eng, debug, user, and/or development.
* Installs non-APK modules that have no tags specified.
* Installs APKs according to the product definition files, in addition to tagged APKs.
* ro.secure=0
* ro.debuggable=1
* ro.kernel.android.checkjni=1
* adb is enabled by default. 

user    make user

This is the flavor intended to be the final release bits.

* Installs modules tagged with user.
* Installs non-APK modules that have no tags specified.
* Installs APKs according to the product definition files; tags are ignored for APK modules.
* ro.secure=1
* ro.debuggable=0
* adb is disabled by default.

userdebug   make userdebug

The same as user, except:

* Also installs modules tagged with debug.
* ro.debuggable=1
* adb is enabled by default. 
</pre>
Using user tag is no longer recommended.

Instead,

Add "LOCAL_MODULE_TAGS := optional"

Then add "LOCAL_MODULE" value to PRODUCT_PACKAGES section of product makefile(<span style="color:red;">build/target/product/core.mk</span>).


<pre>    
LOCAL_MODULE:= libforlinx_runtime
</pre>
This is the target being built.

<br>
<pre>
LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)
</pre>
Target install path.

<br>
<pre>
LOCAL_SRC_FILES:= \
    LedService.cpp
</pre>
All of the source files that we will compile.

<br>
<pre>
LOCAL_SHARED_LIBRARIES := \
    libandroid_runtime \
    libcutils \
    libhardware \
    libhardware_legacy \
    libnativehelper \
    libsystem_server \
    libutils \
    libui \
    libsurfaceflinger_client
</pre>
All of the shared libraries we link against.

<br>
<pre>
LOCAL_C_INCLUDES += \
    $(JNI_H_INCLUDE) \
        hardware/led/include
</pre>
Also need the JNI headers.

<br>
<pre>
LOCAL_CFLAGS +=
</pre>
No special compiler flags.
*LOCAL_CFLAGS += -O3 -fstrict-aliasing -fprefetch-loop-arrays

通过设定编译器操作，优化级别，-O0表示没有优化,-O1为缺省值，-O3优化级别最高

*LOCAL_CFLAGS += -W -Wall
*LOCAL_CFLAGS += -fPIC -DPIC
*LOCAL_CFLAGS += -O2 -g -DADB_HOST=1 -Wall -Wno-unused-parameter
*LOCAL_CFLAGS += -D_XOPEN_SOURCE -D_GNU_SOURCE -DSH_HISTORY
*LOCAL_CFLAGS += -DUSEOVERLAY2

根据条件选择相应的编译参数

<br>
<pre>
LOCAL_PRELINK_MODULE := false
</pre>
Don't prelink this library.  For more efficient code, you may want to add this library to the prelink map and set this to true.

Prelink利用事先链接代替运行时链接的方法来加速共享库的加载，它不仅可以加快起动速度，还可以减少部分内存开销，是各种Linux架构上用于减少程序加载时间、缩短系统启动时间和加快应用程序启动的很受欢迎的一个工具。

程序运行时的动态链接尤其是重定位(relocation)的开销对于大型系统来说是很大的。动态链接和加载的过程开销很大，并且在大多数的系统上, 函数库并不会常常被更动, 每次程序被执行时所进行的链接动作都是完全相同的，对于嵌入式系统来说尤其如此。因此，这一过程可以改在运行时之前就可以预先处理好，即花一些时间利用Prelink工具对动态共享库和可执行文件进行处理，修改这些二进制文件并加入相应的重定位等信息，节约了本来在程序启动时的比较耗时的查询函数地址等工作，这样可以减少程序启动的时间，同时也减少了内存的耗用。 

Prelink的这种做法当然也有代价：每次更新动态共享库时，相关的可执行文件都需要重新执行一遍Prelink才能保证有效，因为新的共享库中的符号信息、地址等很可能与原来的已经不同了，这就是为什么 android framework代码一改动，这时候就会导致相关的应用程序重新被编译。这种代价对于嵌入式系统的开发者来说可能稍微带来一些复杂度，不过好在对用户来说几乎是可以忽略的。

<br>
<pre>
include $(BUILD_SHARED_LIBRARY)
</pre>
编译成library


参考资料：

http://www.cnblogs.com/langlang/archive/2012/04/23.html

http://stackoverflow.com/questions/9496284/what-is-the-use-of-local-module-tags

还可查看 http://hi.baidu.com/kenny_wju/item/042603c7f4f66d78ced4f83b