Android4.2.2源代码文件夹结构分析
撰写不易,转载请注明出处：http://blog.csdn.net/jscese/article/details/40897277#t17
导读：
关于的Android文件夹分析。网上有非常多资料。在此不做全面介绍.
本文仅仅简介Android中我常涉及的到的一些文件夹与文件,文中都属个人观点。仅供參考～以google官方Android4.2.2源代码为例.
各个厂商平台可能会有出入.
以android源代码文件夹为“/”根文件夹.
——jscese
2014/11/3
/bootable
这个文件夹下存放android部分启动相关代码，包括android的recovery模式，一般用于进行OTA升级，由C++编写，能够看到用于显示的ui.cpp和安装的install.cpp,模式入口为recovery.cpp的main.
/build
这是android源代码中编译核心所在地，把这个文件夹下的全部mk搞清楚，android的编译体系就基本了如指掌了.
./envsetup.sh
编译初始化shell脚本，编译配置命令lunch.m.mm.mmm等发源地，所以android在
编译的初始阶段须要source*。其终于目的都会执行到这个脚本。把这个脚本中的变量以及函数设置到当前终端的暂时变量中。供兴许使用.
由此脚本中的lunch选取product_name引入到core中的mk等一系列的初始配置。最后会打印出TARGET变量等.供源代码中编译使用！
这里详情可參考Android——编译系统初始化设置
./core/main.mk
Make-j*时的makefile入口文件，会对编译体系中的变量进行一些校对。编译类型之类的，而且载入整个源代码下的Android.mk文件。总体的编译框架，终极目标.PHONY:droid
./core/Makefile
由上面的main.mk引入，算作android真正的主makefile，由它再依赖到各个子编译体系.
./core/base_rules.mk
android总体编译时。会载入根文件夹下全部的Android.mk文件。而且依据文件里的MODULE依次分析相关属性，生成编译规则，当中不同的MODULE类型就须要在Android.mk中include$(**)载入相应mk，分别相应core文件夹下的mk.
比方编译apk的Android.mk须要末尾include$(BUILD_PACKAGE),此时解析到这里的时候就会载入core下的package.mk，当中会载入进java.mk在这里会载入到base_rules.mk中计算一些变量值。创建一些主要的依赖规则，再又java.mk中调用函数$(transform-**)编译。相似：
$(transform-java-to-classes.jar)把java文件编译成classes.jar
其他模块类型相似.
./core/definitions.mk
这个文件下都是一些编译的函数宏定义，比方上面调用transform-java-to-classes.jar
以及经常出如今Android.mk中的all-java-files-under等等...都可在这里找到详细实现！
./target/product/security
这个文件以下存放的就是当前编译系统使用的签名密钥对。用于系统不同组件在编译的时候进行数字签名，android原生默认使用testkey，这文件夹下有README以及密钥对制作脚本make_key。能够用来制作属于自己的签名密钥，使整个系统签名独一无二，更具安全性！关于android的签名机制，详情可參考Android——编译release版签名系统
./tools/releasetools
Build的tools文件夹，全是一些用于编译的工具脚本和可执行工具，当中releasetools下是用于编译制作androidOTA刷机包时的python脚本集合。由上面说到的主Makefile中调用进ota_from_target_files中的defmain(argv):
/cts
google提供的CompatibilityTest Suite (CTS) 兼容性測试组。用于測试android系统的兼容性以及稳定性，发測试report给google过了这个认证，算是得到google的认可的.一般的android源代码都是有这个组件源代码的。可是不在主编译流程中，须要使用makects编译出android-cts文件夹供使用，也可去http://source.android.com/compatibility/downloads.html下载相应版本号最新的组件.作为一个android产品。这个測试还是非常有意义的。据传不懂CTS就不算一个合格的android开发者～
./tests/tests
存放CTS測试用例的地方，全是androidapk，加入自己的測试用例也在此.
./CtsTestCaseList.mk
这是cts模块组件的编译选项配置mk，由上面说到的build中的cts.mk调用，对于自己加入的測试用例须要加入进这里面的cts_test_packages变量中.
/tools/tradefed-host/src/com/android/cts/tradefed/build/CtsBuildProvider.java
能够这里看CTS_BUILD_VERSION确定你当前源代码中的cts版本号.
./tools/tradefed-host/README
google提供的readme，有介绍怎样配置cts环境以及使用的经常使用命令
关CTS 可參考我之前的博客：Android—— ubuntu下【CTS】測试TV真机
/device
这个作为android源代码中对产品的描写叙述文件夹，各个平台的差异还是比較大的，可是怎么修改，本意是不变的，仅仅是作为要编译的产品的配置文件夹。这里简单以google源代码中存放的samsung为例.
./samsung/tuna/AndroidProducts.mk
一般的存放规则是/device/厂商文件夹/产品文件夹，这个mk里面通常是定义当前产品的主配子mk,对于这个AndroidProducts.mk什么时候被载入，详细可去看android编译初始化阶段，lunch选取产品之后的一系列mk初始化操作.
./samsung/tuna/BoardConfig.mk
这个配置文件。看名字就知道了，定义的都是跟硬件配置相关的.这个mk依赖级别在产品角度算是最高的了，假设想加入一些控制宏，能够考虑加在这里.
./samsung/tuna/device.mk
这里配置最多的就是产品编译须要的组件了，一般配置最多的PRODUCT_COPY_FILES以及PRODUCT_PACKAGES，这两个变量在编译体系中的作用不多做介绍～
Android——编译体系中的【PRODUCT_COPY_FILES】【ALL_PREBUILT】【BUILD_PREBUILT】
./samsung/tuna/recovery.fstab
熟悉linux的对这个fstab应该比較熟悉了，这里配置的就是recovery模式下的分区。会用于制作OTA刷机包时对分区的配置參数.
vendorsetup.sh
通常会将产品的编译信息存在这个文件里。相似add_lunch_combofull_maguro-userdebug
在编译初始阶段由lunch载入供编译者选择，这当中full代表总体编译，maguro代表产品名。userdebug代表编译类型。android的产品编译类型可另行參考，不多做介绍～
可參考上面的Android——编译安装Module的控制因素
/external
这是android存放外部工具组件的地方。以文件夹为单一模块，终于编译出来的有可执行文件，jar包，动静态库，东西比較混杂。google已经移植了非常多工具在这里面，假设自己想移植一些模块进android系统，能够加在这里，写好Android.mk，在上面提到的device.mk中加入PRODUCT_PACKAGES变量中.
像这样的移植可參考：Android——4.2 - 3G移植之路之usb-modeswitch (二)
/frameworks
android的执行框架集合。包括系统执行的各种服务框架。向app层提供api，依据JNI机制或者socket往下层调用，也可使用hw_get_module调用到hardware层的module.
./base/core
字面意思，核心所在，包括java以及jni。核心组件的java类以及native方法的jni映射，当中内容太多,比方java中app相关的ActivityManager.java，启动相关的ZygoteInit.java，当中的jni文件夹会被编译成libandroid_runtime.so作为android执行时的动态库供相关的java载入.
./base/services
框架层中的系统服务存放文件夹，包括系统时间服务以及输入子系统服务，同上java文件夹下就是服务的java类了。能够看到各种子服务模块，比方pm。net，display，假设想详细了解当前系统启动了多少服务，能够參考SystemServer.java
./opt/telephony
android电话子系统存放文件夹，向上提供api接口。向下通过RIL.javasocket通信.
/hardware
硬件抽象层。描写叙述对linuxkernel中的相关驱动模块的详细操作，而在kernel中的驱动模块仅仅拥有通用操作接口，比方设置寄存器值。IO拉高拉低，可是详细设置什么值，拉高拉低的时序都写在hardware层相相应的module中，这就是google对于硬件驱动的商业保护.
./libhardware/hardware.c
hardware机制核心所在。定义了相关规则。比方load打开modules编译生成的.so，抽象成一个module，向上层提供hw_get_module接口以及module配置宏.
./libhardware/modules
这里就是与kernel相相应的module存放的地方。头文件存在同级文件夹的include中。在当中定义module结构。接口方法以及唯一的moduleID.
当中像gralloc就是控制kernel中显示屏驱动的module，用于管理控制fb缓冲区，将来自上层display的SurfaceFlinger服务传下来的图像推送到lcd/led显示屏上.其他相似.
./ril
android电话系统的ril驱动文件文件夹，当中包括：
rild— ril主体控制机制，
libril— ril与上层socket通信。
reference-ril— ril与serial设备AT指令通信
这三个文件夹，当中reference-ril是第三方驱动，依据不同的设备选择不同.
关于android的RIL机制不多做介绍～
/system
android系统底层的文件系统，应用组件，包括一些系统库，以及启动的配置文件
./core/init/init.c
作为系统启动到android层的第一个进程，也将一直作为守护进程，解析init.rc配置文件，
启动相关服务,当中就有比較经常使用的属性服务，之后一直执行于init进程中，详细可參考property_service.c，android层系统启动从这里開始,详情另行參考～
./core/rootdir
存放配置文件，当中init.rc作为启动配置。ueventd.rc作为linux文件系统中文件事件配置，还包括磁盘挂载所须要的vold.fstab配置文件等...
./core/include/private/android_filesystem_config.h
这个头文件定义了。android文件系统中文件的权限配置.
./vold
android舍弃了linux的udev机制，自己弄了一套磁盘挂载管理机制。就是vold，作为系统服务在init.rc配置启动，用于磁盘的挂载等相关操作，通过netlinksocket接收来自kernel的uevent，与上层MountService通过一个名为vold的socket通信，入口为main.cpp中的main函数。vold机制详情另行參考～
关于Vold机制可參考我之前的专栏：Android— 4.2 Vold
/out
作为android源代码编译结果存放文件夹，当中包括各种中间文件以及目标文件.像obj中存放的中间件以及hostlinux-x86存放的本地编译项.
./target/product/product_name/system.img
android系统编译出来的镜像文件，也是整个源代码的终于目标文件.
./target/product/product_name/system
编译之后的系统文件夹，也是system.img的主要构成，当中app文件夹下都是apk文件，android中规定此文件夹下的apk作为系统内置应用，在文件系统中拥有系统权限，普通用户没有权限删除更改，详情可參考PackageManager.当中的bin代表可执行文件，etc下存放的都是系统配置文件。lib中都是些动态库，分别相应到文件系统中.
./target/product/product_name/system/build.prop
这个文件里收集了编译中的全部属性，包括编译的主机环境，编译目标的各种配置信息等等...生成过程可參考主Makefile,在初始化阶段会被property_service服务载入，作为系统属性.
./target/product/product_name/data/
此文件夹作为user的data存储文件夹。相应文件系统中的/data文件夹，平时用户安装的apk就会被copy到这个该文件夹的app文件夹下。android系统中apk所产生的数据，比方数据库等都会存放在/data/data中，以包名区分.
当中一般还有recovery,root等文件夹。存放相相应的产物。不同平台编译出来的out文件夹会有所出入.
