make aboot #单编abl
编译kernel image
$ make kernel -j12 #第二次编译可使用ninja kernel -j12
$ make bootimage -j12 #第二次编译可使用ninja bootimage -j12
$ make dtboimage -j12 #第二次编译可使用ninja dtboimage -j12
注：新电脑编译过程会提示缺一些模块/库，需根据错误提示安装相关模块/库 # 编译成功生成如下镜像
out/target/product/vangogh/boot.img
out/target/product/vangogh/dtbo.img
dtbo.img是手机厂商修改的镜像，dtb.img是谷歌原生的设备树镜像，dtbo.img与dtb.img是overlay关系，手机启动时会合并两者的设备树信息（dtb.img中dtbo.img未修改部分 + dtbo.img中相对于dtb.img的已修改部分）
编译vbmeta image
$ make vbmetaimage -j12 #第二次编译可使用ninja vbmetaimage -j12
编译成功生成如下镜像 out/target/product/vangogh/vbmeta.img
vbmeta.img用于安全验证，bootloader验证vbmeta的签名，再用vbmeta的key以及hash值验证dtbo、boo、system、vendor等镜像。
Android验证启动引导（Verified Boot）是确保终端用户在设备上运行的软件的完整性的过程，它通常从设备固件的只读部分开始，该部分加载代码，并在以加密方式验证代码是可信的并且没有任何已知的安全缺陷之后才执行代码。
AVB是验证引导的一个实现，而AVB中使用的中央数据结构是VBMeta结构
编译vendor image
$ make vendorimage -j12 #第二次编译可使用ninja vendorimage -j12
编译成功生成如下镜像：out/target/product/vangogh/vendor.img
编译system image
$ source build/envsetup.sh
$ lunch qssi-userdebug
$ make systemimage -j12 # 编译并生成system.img
$ make systemimage -j4 showcommands # 编译并生成system.img，同时显示编译命令
编译成功生成如下镜像:out/target/product/qssi/system.img
之后传统fastboot模式不可刷改镜像，需要进入fastbootd模式才行
或者将services.jar、framework.jar和framework-res.apk三个重要文件push到手机/system/framework/路径下
编译userdata image
$ make userdataimage -j4
userdata.img是Android系统中存放用户数据的，它被init进程通过解析init.rc文件mount到/data/目录下，默认里面是没有文件的。
编译super image
$ source build/envsetup.sh
$ lunch
$ ./build.sh dist merge_only -j**
#若上述命令不生效，则采用以下命令
$ make supernod
#or
$ make superimage-nodeps
编译vendor_boot.img
$ source build/envsetup.sh
$ lunch
$ make vendorbootimage文章来源：https://www.toymoban.com/news/detail-426824.html
更多看
https://blog.csdn.net/q921374795/article/details/88558271文章来源地址https://www.toymoban.com/news/detail-426824.html
到了这里，关于android单独编译各个img命令的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
