android makefil
1、整编译
当中android根目录下敲击make时候，根目录下的Makefile就一句话include build/core/main.mk，即调用main.mk，以下为main.mk的依赖规则
2、模块编译
模块编译依赖各个模块目标。
3、recovery.img
(1)在TARGET_NO_RECOVERY=false,TARGET_NO_KERNEL=false时候
INSTALLED_RECOVERYIMAGE_TARGET := $(PRODUCT_OUT)/recovery.img
依赖关系如下，则会生成revovery.img
(2)在AB分区功能打开，即TARGET_NO_KERNEL=true时，INSTALLED_RECOVERYIMAGE_TARGET等于空，则后面的依赖关系不复存在，也就不会生成revovery.img了
4、boot.img
.PHONY: bootimage
bootimage: $(INSTALLED_BOOTIMAGE_TARGET)
INSTALLED_BOOTIMAGE_TARGET := $(PRODUCT_OUT)/boot.img
(1)无AB分区功能时的boot.img的依赖规则如下
（2）启用AB分区时候，BOARD_USES_RECOVERY_AS_BOOT=true，此时的依赖规则变成如下：
可以看出，此时boot.img的生成规则，与无AB分区时生成revovery.img时候的规则一样。即现在的boot.img就是以前的recovery.img
5、system.img
system.img的依赖关系
build-systemimage-target函数最终调用到build_image.py用户创建镜像
此前boot.img里面的ramdisk是recovery系统的recovery ramdisk，那之前boot.img里的ramdisk呢？系统如何来挂着system分区的呢？？？ 看下面代码，可知，原boot.img里的ramdisk挪到system.img里面了。
build_image.py 调用了BuildImage函数
BuildImage函数部分内容如下：
6、userdateimage
7、cache.img
启用AB分区时候，BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE 没有定义，这里条件不能满足，所以不会生成cache.img
8、vendor.img
和BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE宏是否定义相关。
9、有关AB分区的总结如下：
recovery.img，不再单独生成，传统方式的recovery.img现在叫做boot.img
boot.img，包含kernel和recovery模式的ramdisk
system.img，传统方式下system.img由(PRODUCT_OUT)/root和(PRODUCT_OUT)/data文件夹而成
cache.img，A/B系统下不再单独生成cache.img
vendor.img，文件的生成跟是否A/B系统无关，主要有厂家决定