源码目录结构分析

1. 导读
2. /bootable
3. /build

3.1 /envsetup.sh
3.2 /core/main.mk
3.3 /core/Makefile
3.4 /core/base_rules.mk
3.5 /core/definitions.mk
3.6 /target/product/security
3.7 /tools/releasetools

4. /cts

4.1 /tests/tests
4.2 /CtsTestCaseList.mk
4.3 /tools/tradefed-host/src/com/android/cts/tradefed/build/CtsBuildProvider.java
4.4 /tools/tradefed-host/README

5. /device

5.1 /samsung/tuna/AndroidProducts.mk
5.2 /samsung/tuna/BoardConfig.mk
5.3 /samsung/tuna/device.mk
5.4 /samsung/tuna/recovery.fstab
5.5 /vendorsetup.sh

6. /external
7. /frameworks

7.1 /base/core
7.2 /base/services
7.3 /opt/telephony

8. /hardware

8.1 /libhardware/hardware.c
8.2 /libhardware/modules
8.3 /ril

9. /system

9.1 /core/init/init.c
9.2 /core/rootdir
9.3 /core/include/private/android_filesystem_config.h
9.4 /vold

10. /out

10.1 /target/product/product_name/system.img
10.2 /target/product/product_name/system
10.3 /target/product/product_name/system/build.prop
10.4 /target/product/product_name/data/

1. 导读

以 android 源码目录为“ /” 根目录 .

2. /bootable

这个目录下存放 android 部分启动相关代码，包括 android 的 recovery 模式，一般用于进行 OTA 升级，由 C++ 编写，可以看到用于显示的 ui.cpp 和安装的 install.cpp, 模式入口为 recovery.cpp 的 main。

3. /build

这是 android 源码中编译核心所在地，把这个目录下的所有 mk 搞清楚， android 的编译体系就基本了如指掌了。

3.1 /envsetup.sh

编译初始化 shell 脚本，编译配置命令 lunch.m.mm.mmm 等发源地，所以 android 在编译的初始阶段需要 source* ，其最终目的都会执行到这个脚本，把这个脚本中的变量以及函数设置到当前终端的临时变量中，供后续使用。
由此脚本中的 lunch 选取 product_name 引入到 core 中的 mk 等一系列的初始配置，最后会打印出 TARGET 变量等 . 供源码中编译使用！
这里详情可参考 Android——编译系统初始化设置

3.2 /core/main.mk

Make -j* 时的 makefile 入口文件，会对编译体系中的变量进行一些校对，编译类型之类的，并且加载整个源码下的 Android.mk 文件，整体的编译框架，终极目标 .PHONY:droid。

3.3 /core/Makefile

由上面的 main.mk 引入，算作 android 真正的主 makefile ，由它再依赖到各个子编译体系。

3.4 /core/base_rules.mk

android 整体编译时，会加载根目录下所有的 Android.mk 文件，并且根据文件中的 MODULE 依次分析相关属性，生成编译规则，其中不同的 MODULE 类型就需要在 Android.mk 中 include $(* *) 加载对应 m k ，分别对应 c o r e 目录下的 m k 。比如编译 a p k 的 A n d r o i d . m k 需要末尾 i n c l u d e$ (BUILD_PACKAGE), 此时解析到这里的时候就会加载 core 下的 package.mk ，其中会加载进 Java.mk 在这里会加载到 base_rules.mk 中计算一些变量值，创建一些基本的依赖规则，再又 java.mk 中调用函数 $(transform-**) 编译，类似：
$(transform-java-to-classes.jar) 把 java 文件编译成 classes.jar
其它模块类型类似。

3.5 /core/definitions.mk

这个文件下都是一些编译的函数宏定义，比如上面调用 transform-java-to-classes.jar 以及常常出现在 Android.mk 中的 all-java-files-under 等等 … 都可在这里找到具体实现！

3.6 /target/product/security

这个文件下面存放的就是当前编译系统使用的签名密钥对，用于系统不同组件在编译的时候进行数字签名，android 原生默认使用 testkey，这目录下有 README 以及密钥对制作脚本 make_key，可以用来制作属于自己的签名密钥，使整个系统签名独一无二，更具安全性！
关于android的签名机制，详情可参考 Android——编译release版签名系统

3.7 /tools/releasetools

Build 的 tools 目录，全是一些用于编译的工具脚本和可执行工具，其中 releasetools 下是用于编译制作 androidOTA 刷机包时的 Python 脚本集合，由上面说到的主 Makefile 中调用进 ota_from_target_files 中的 defmain(argv)。

4. /cts

google 提供的 CompatibilityTest Suite (CTS) 兼容性测试组，用于测试 android 系统的兼容性以及稳定性，发测试 report 给 google 过了这个认证，算是得到 google 的认可的。一般的 android 源码都是有这个组件源码的，但是不在主编译流程中，需要使用 makects 编译出 android-cts 目录供使用，也可去 http://source.android.com/compatibility/downloads.html下载对应版本最新的组件。作为一个 android 产品，这个测试还是很有意义的。

4.1 /tests/tests

存放 CTS 测试用例的地方，全是 androidapk ，添加自己的测试用例也在此。

4.2 /CtsTestCaseList.mk

这是 cts 模块组件的编译选项配置 mk ，由上面说到的 build 中的 cts.mk 调用，对于自己添加的测试用例需要添加进这里面的 cts_test_packages 变量中。

4.3 /tools/tradefed-host/src/com/android/cts/tradefed/build/CtsBuildProvider.java

可以这里看 CTS_BUILD_VERSION 确定你当前源码中的 cts 版本。

4.4 /tools/tradefed-host/README

google 提供的 readme ，有介绍如何配置 cts 环境以及使用的常用命令，关于CTS 可参考Android—— ubuntu下【CTS】测试TV真机

5. /device

这个作为 android 源码中对产品的描述文件夹，各个平台的差异还是比较大的，但是怎么改动，本意是不变的，只是作为要编译的产品的配置文件夹，这里简单以 google 源码中存放的 samsung 为例。

5.1 /samsung/tuna/AndroidProducts.mk

一般的存放规则是 /device/厂商目录/产品目录，这个 mk 里面一般是定义当前产品的主配子 mk, 对于这个 AndroidProducts.mk 什么时候被加载，具体可去看 android 编译初始化阶段，lunch 选取产品之后的一系列 mk 初始化操作。

5.2 /samsung/tuna/BoardConfig.mk

这个配置文件，看名字就知道了，定义的都是跟硬件配置相关的。这个 mk 依赖级别在产品角度算是最高的了，如果想添加一些控制宏，可以考虑加在这里。

5.3 /samsung/tuna/device.mk

这里配置最多的就是产品编译需要的组件了，一般配置最多的 PRODUCT_COPY_FILES 以及 PRODUCT_PACKAGES。
可参考：
Android——编译安装Module的控制因素
Android——编译体系中的【PRODUCT_COPY_FILES】【ALL_PREBUILT】【BUILD_PREBUILT】

5.4 /samsung/tuna/recovery.fstab

熟悉 Linux 的对这个 fstab 应该比较熟悉了，这里配置的就是 recovery 模式下的分区，会用于制作 OTA 刷机包时对分区的配置参数。

5.5 /vendorsetup.sh

一般会将产品的编译信息存在这个文件中，类似 add_lunch_combofull_maguro-userdebug
在编译初始阶段由 lunch 加载供编译者选择，这其中 full 代表整体编译， maguro 代表产品名， userdebug 代表编译类型， android 的产品编译类型可另行参考，不多做介绍～
可参考上面的Android——编译安装Module的控制因素

6. /external

这是 android 存放外部工具组件的地方，以文件夹为单一模块，最终编译出来的有可执行文件， jar 包，动静态库，东西比较混杂， google 已经移植了很多工具在这里面，如果自己想移植一些模块进 android 系统，可以加在这里，写好 Android.mk ，在上面提到的 device.mk 中加入 PRODUCT_PACKAGES 变量中。
像这种移植可参考：Android——4.2 - 3G移植之路之usb-modeswitch (二)

7. /frameworks

android 的运行框架集合，包含系统运行的各种服务框架，向 app 层提供 api ，根据 JNI 机制或者 socket 往下层调用，也可使用 hw_get_module 调用到 hardware 层的 module。

7.1 /base/core

字面意思，核心所在，包含 java 以及 jni，核心组件的 java 类以及 native 方法的 jni 映射，其中内容太多 , 比如 java 中 app 相关的 ActivityManager.java，启动相关的 ZygoteInit.java ，其中的 jni 目录会被编译成 libandroid_runtime.so 作为 android 运行时的动态库供相关的 java 加载。

7.2 /base/services

框架层中的系统服务存放目录，包含系统时间服务以及输入子系统服务，同上 java 目录下就是服务的 java 类了，可以看到各种子服务模块，比如 pm，net，display，如果想具体了解当前系统启动了多少服务，可以参考 SystemServer.java。

7.3 /opt/telephony

android 电话子系统存放目录，向上提供 api 接口，向下通过 RIL.javasocket 通信。

8. /hardware

硬件抽象层，描述对 linuxkernel 中的相关驱动模块的具体操作，而在 kernel 中的驱动模块只拥有通用操作接口，比如设置寄存器值，IO 拉高拉低，但是具体设置什么值，拉高拉低的时序都写在 hardware 层相对应的 module 中，这就是 google 对于硬件驱动的商业保护。

8.1 /libhardware/hardware.c

hardware 机制核心所在，定义了相关规则，比如 load 打开 modules 编译生成的 .so ，抽象成一个 module ，向上层提供 hw_get_module 接口以及 module 配置宏。

8.2 /libhardware/modules

这里就是与 kernel 相对应的 module 存放的地方，头文件存在同级目录的 include 中，在其中定义 module 结构，接口方法以及唯一的 moduleID。
其中像 gralloc 就是控制 kernel 中显示屏驱动的 module，用于管理控制 fb 缓冲区，将来自上层 display 的 SurfaceFlinger 服务传下来的图像推送到 lcd/led 显示屏上 . 其它类似。

8.3 /ril

android 电话系统的 ril 驱动文件目录，其中包含：
rild— ril 主体控制机制，
libril— ril 与上层 socket 通信，
reference-ril— ril 与 serial 设备 AT 指令通信
这三个文件夹，其中 reference-ril 是第三方驱动，根据不同的设备选择不同 .
可参考：Android——RIL 机制源码分析

9. /system

android 系统底层的文件系统，应用组件，包含一些系统库，以及启动的配置文件。

9.1 /core/init/init.c

作为系统启动到 android 层的第一个进程，也将一直作为守护进程，解析 init.rc 配置文件，
启动相关服务 , 其中就有比较常用的属性服务，之后一直运行于 init 进程中，具体可参考 property_service.c，android 层系统启动从这里开始。
可参考：Android——启动过程详解

9.2 /core/rootdir

存放配置文件，其中 init.rc 作为启动配置， ueventd.rc 作为 linux 文件系统中文件事件配置，还包含磁盘挂载所需要的 vold.fstab 配置文件等 …

9.3 /core/include/private/android_filesystem_config.h

这个头文件定义了， android 文件系统中文件的权限配置。

9.4 /vold

android 舍弃了 linux 的 udev 机制，自己弄了一套磁盘挂载管理机制，就是 vold，作为系统服务在 init.rc 配置启动，用于磁盘的挂载等相关操作，通过 netlinksocket 接收来自 kernel 的 uevent，与上层 MountService 通过一个名为 vold 的 socket 通信，入口为 main.cpp 中的 main 函数。

10. /out

作为 android 源码编译结果存放目录，其中包含各种中间文件以及目标文件。像 obj 中存放的中间件以及 hostlinux-x86 存放的本地编译项。

10.1 /target/product/product_name/system.img

android 系统编译出来的镜像文件，也是整个源码的最终目标文件。

10.2 /target/product/product_name/system

编译之后的系统文件夹，也是 system.img 的主要构成，其中 app 目录下都是 apk 文件， android 中规定此目录下的 apk 作为系统内置应用，在文件系统中拥有系统权限，普通用户没有权限删除更改，详情可参考 PackageManager. 其中的 bin 代表可执行文件， etc 下存放的都是系统配置文件， lib 中都是些动态库，分别对应到文件系统中。

10.3 /target/product/product_name/system/build.prop

这个文件中收集了编译中的所有属性，包括编译的主机环境，编译目标的各种配置信息等等 … 生成过程可参考主 Makefile, 在初始化阶段会被 property_service 服务加载，作为系统属性。
可参考： Android——build.prop 解析

10.4 /target/product/product_name/data/

此目录作为 user 的 data 存储目录，对应文件系统中的 /data 目录，平时用户安装的 apk 就会被 copy 到这个该目录的 app 目录下， android 系统中 apk 所产生的数据，比如数据库等都会存放在 /data/data 中，以包名区分。
其中一般还有 recovery,root 等目录，存放相对应的产物，不同平台编译出来的 out 目录会有所出入。

Android——4.2.2 源码目录结构分析