recovery单独编译
❶ 如何编译CWM Recovery
你必须使用32位或64位Ubuntu系统，关于如何建立编译环境和同步源码的指导，请自己查找有关指导的文章。 1, 安装所需要的包 2, 建立编译的环境，并同步CWM所需的源码，CyanogenMod源码中附带CWM源码
❷ 一个百度云上搜索到的“recovery编译教程”的视频，求这个视频的原始出处，是哪个网站上的，谢谢
安卓手机recovery模式进入方法：
方法一：
1、关机。
2、同时按住电源（挂机键）+ 小房子（Home）键，直到出现Recovery界面为止。
方法二：
1、关机。
2、先按住音量+键不放。
3、然后再长按电源开机键，直到出现Recovery界面为止。
❸ 如何制作自己的recovery.img
首先，把手机硬启，手机不同其硬启方法也不同（大多是音量键+电源键），自己看说明书 1、如果你的手机已经S-OFF，就往下看，如果手机硬启后显示S-ON就不用看了，没戏。 2、用一张质量好的内存卡，在网上下载一个recovery程序（多为PG88IMG.zip） 3、手机硬启后，用音量键选择recovery，电源键确定，后手机自动找到安装文件，后提示是否安装，选择Y，确定，安装后重启即可。
❹ 【求助】编译的recovery刷入后直接重启
哥最近喜欢上了顶贴，因为，如果帖子火了，那有哥的功劳。如果帖子被顶沉了....哥也会很有成就感...因为是哥搞沉的~~大家切记~不要迷恋哥~哥只是一个传说
❺ 如何打包安卓手机Zip升级包如何签名不换Recovery，用官方Recovery
通过分析update.zip包在具体Android系统升级的过程，来理解Android系统中Recovery模式服务的工作原理。
我们先从update.zip包的制作开始，然后是Android系统的启动模式分析，Recovery工作原理，如何从我们上层开始选择system update到重启到Recovery服务，以及在Recovery服务中具体怎样处理update.zip包升级的，我们的安装脚本updater-script怎样被解析并执行的等一系列问题。分析过程中所用的Android源码是gingerbread0919（tcc88xx开发板标配的），测试开发板是tcc88xx。
一、 update.zip包的目录结构
|----boot.img
|----system/
|----recovery/
`|----recovery-from-boot.p
`|----etc/
`|----install-recovery.sh
|---META-INF/
`|CERT.RSA
`|CERT.SF
`|MANIFEST.MF
`|----com/
`|----google/
`|----android/
`|----update-binary
`|----updater-script
`|----android/
`|----metadata
二、 update.zip包目录结构详解
以上是我们用命令make otapackage 制作的update.zip包的标准目录结构。
1、boot.img是更新boot分区所需要的文件。这个boot.img主要包括kernel+ramdisk。
2、system/目录的内容在升级后会放在系统的system分区。主要用来更新系统的一些应用或则应用会用到的一些库等等。可以将Android源码编译out/target/proct/tcc8800/system/中的所有文件拷贝到这个目录来代替。
3、recovery/目录中的recovery-from-boot.p是boot.img和recovery.img的补丁(patch),主要用来更新recovery分区，其中etc/目录下的install-recovery.sh是更新脚本。
4、update-binary是一个二进制文件，相当于一个脚本解释器，能够识别updater-script中描述的操作。该文件在Android源码编译后out/target/proct/tcc8800/system bin/updater生成，可将updater重命名为update-binary得到。
该文件在具体的更新包中的名字由源码中bootable/recovery/install.c中的宏ASSUMED_UPDATE_BINARY_NAME的值而定。
5、updater-script：此文件是一个脚本文件，具体描述了更新过程。我们可以根据具体情况编写该脚本来适应我们的具体需求。该文件的命名由源码中bootable/recovery/updater/updater.c文件中的宏SCRIPT_NAME的值而定。
6、 metadata文件是描述设备信息及环境变量的元数据。主要包括一些编译选项，签名公钥，时间戳以及设备型号等。
7、我们还可以在包中添加userdata目录，来更新系统中的用户数据部分。这部分内容在更新后会存放在系统的/data目录下。
8、update.zip包的签名：update.zip更新包在制作完成后需要对其签名，否则在升级时会出现认证失败的错误提示。而且签名要使用和目标板一致的加密公钥。加密公钥及加密需要的三个文件在Android源码编译后生成的具体路径为：
out/host/linux-x86/framework/signapk.jar
build/target/proct/security/testkey.x509.pem
build/target/proct/security/testkey.pk8 。
我们用命令make otapackage制作生成的update.zip包是已签过名的，如果自己做update.zip包时必须手动对其签名。
具体的加密方法：$ java –jar gingerbread/out/host/linux/framework/signapk.jar –w gingerbread/build/target/proct/security/testkey.x509.pem gingerbread/build/target/proct/security/testkey.pk8 update.zip update_signed.zip
以上命令在update.zip包所在的路径下执行，其中signapk.jar testkey.x509.pem以及testkey.pk8文件的引用使用绝对路径。update.zip 是我们已经打好的包，update_signed.zip包是命令执行完生成的已经签过名的包。
9、MANIFEST.MF：这个manifest文件定义了与包的组成结构相关的数据。类似Android应用的mainfest.xml文件。
10、CERT.RSA：与签名文件相关联的签名程序块文件，它存储了用于签名JAR文件的公共签名。
11、CERT.SF：这是JAR文件的签名文件，其中前缀CERT代表签名者。
另外，在具体升级时，对update.zip包检查时大致会分三步：①检验SF文件与RSA文件是否匹配。②检验MANIFEST.MF与签名文件中的digest是否一致。③检验包中的文件与MANIFEST中所描述的是否一致。
三、 Android升级包update.zip的生成过程分析
1) 对于update.zip包的制作有两种方式，即手动制作和命令生成。
第一种手动制作：即按照update.zip的目录结构手动创建我们需要的目录。然后将对应的文件拷贝到相应的目录下，比如我们向系统中新加一个应用程序。可以将新增的应用拷贝到我们新建的update/system/app/下（system目录是事先拷贝编译源码后生成的system目录），打包并签名后，拷贝到SD卡就可以使用了。这种方式在实际的tcc8800开发板中未测试成功。签名部分未通过，可能与具体的开发板相关。
第二种制作方式：命令制作。Android源码系统中为我们提供了制作update.zip刷机包的命令，即make otapackage。该命令在编译源码完成后并在源码根目录下执行。 具体操作方式：在源码根目录下执行
①$ . build/envsetup.sh。
②$ lunch 然后选择你需要的配置(如17)。
③$ make otapackage。
在编译完源码后最好再执行一遍上面的①、②步防止执行③时出现未找到对应规则的错误提示。命令执行完成后生成的升级包所在位置在out/target/proct/full_tcc8800_evm_target_files-eng.mumu.20120309.111059.zip将这个包重新命名为update.zip，并拷贝到SD卡中即可使用。
这种方式(即完全升级)在tcc8800开发板中已测试成功。
2) 使用make otapackage命令生成update.zip的过程分析。
在源码根目录下执行make otapackage命令生成update.zip包主要分为两步，第一步是根据Makefile执行编译生成一个update原包（zip格式）。第二步是运行一个python脚本，并以上一步准备的zip包作为输入，最终生成我们需要的升级包。下面进一步分析这两个过程。
第一步：编译Makefile。对应的Makefile文件所在位置：build/core/Makefile。从该文件的884行（tcc8800,gingerbread0919）开始会生成一个zip包，这个包最后会用来制作OTA package 或者filesystem image。先将这部分的对应的Makefile贴出来如下：
[python] view plainprint?
# -----------------------------------------------------------------
# A zip of the directories that map to the target filesystem.
# This zip can be used to create an OTA package or filesystem image
# as a post-build step.
#
根据上面的Makefile可以分析这个包的生成过程：
首先创建一个root_zip根目录，并依次在此目录下创建所需要的如下其他目录
①创建RECOVERY目录，并填充该目录的内容，包括kernel的镜像和recovery根文件系统的镜像。此目录最终用于生成recovery.img。
②创建并填充BOOT目录。包含kernel和cmdline以及pagesize大小等，该目录最终用来生成boot.img。
③向SYSTEM目录填充system image。
④向DATA填充data image。
⑤用于生成OTA package包所需要的额外的内容。主要包括一些bin命令。
⑥创建META目录并向该目录下添加一些文本文件，如apkcerts.txt(描述apk文件用到的认证证书)，misc_info.txt(描述Flash内存的块大小以及boot、recovery、system、userdata等分区的大小信息)。
⑦使用保留连接选项压缩我们在上面获得的root_zip目录。
⑧使用fs_config(build/tools/fs_config)配置上面的zip包内所有的系统文件(system/下各目录、文件)的权限属主等信息。fs_config包含了一个头文件#include“private/android_filesystem_config.h”。在这个头文件中以硬编码的方式设定了system目录下各文件的权限、属主。执行完配置后会将配置后的信息以文本方式输出 到META/filesystem_config.txt中。并再一次zip压缩成我们最终需要的原始包。
第二步：上面的zip包只是一个编译过程中生成的原始包。这个原始zip包在实际的编译过程中有两个作用，一是用来生成OTA update升级包，二是用来生成系统镜像。在编译过程中若生成OTA update升级包时会调用（具体位置在Makefile的1037行到1058行）一个名为ota_from_target_files的python脚本，位置在/build/tools/releasetools/ota_from_target_files。这个脚本的作用是以第一步生成的zip原始包作为输入，最终生成可用的OTA升级zip包。
二 下面我们分析ota_from_target_files这个python脚本是怎样生成最终zip包的。先讲这个脚本的代码贴出来如下：
[python] view plainprint?
import sys
if sys.hexversion < 0x02040000:
print >> sys.stderr, "Python 2.4 or newer is required."
sys.exit(1)
主函数main是python的入口函数，我们从main函数开始看，大概看一下main函数（脚本最后）里的流程就能知道脚本的执行过程了。
① 在main函数的开头，首先将用户设定的option选项存入OPTIONS变量中，它是一个python中的类。紧接着判断有没有额外的脚本，如果有就读入到OPTIONS变量中。
② 解压缩输入的zip包，即我们在上文生成的原始zip包。然后判断是否用到device-specific extensions（设备扩展）如果用到，随即读入到OPTIONS变量中。
③ 判断是否签名，然后判断是否有新内容的增量源，有的话就解压该增量源包放入一个临时变量中（source_zip）。自此，所有的准备工作已完毕，随即会调用该 脚本中最主要的函数WriteFullOTAPackage(input_zip,output_zip)
④ WriteFullOTAPackage函数的处理过程是先获得脚本的生成器。默认格式是edify。然后获得metadata元数据，此数据来至于Android的一些环境变量。然后获得设备配置参数比如api函数的版本。然后判断是否忽略时间戳。
⑤ WriteFullOTAPackage函数做完准备工作后就开始生成升级用的脚本文件(updater-script)了。生成脚本文件后将上一步获得的metadata元数据写入到输出包out_zip。
⑥至此一个完整的update.zip升级包就生成了。生成位置在：out/target/proct/tcc8800/full_tcc8800_evm-ota-eng.mumu.20120315.155326.zip。将升级包拷贝到SD卡中就可以用来升级了。
四、 Android OTA增量包update.zip的生成
在上面的过程中生成的update.zip升级包是全部系统的升级包。大小有80M多。这对手机用户来说，用来升级的流量是很大的。而且在实际升级中，我们只希望能够升级我们改变的那部分内容。这就需要使用增量包来升级。生成增量包的过程也需要上文中提到的ota_from_target_files.py的参与。
下面是制作update.zip增量包的过程。
① 在源码根目录下依次执行下列命令
$ . build/envsetup.sh
$ lunch 选择17
$ make
$ make otapackage
执行上面的命令后会在out/target/proct/tcc8800/下生成我们第一个系统升级包。我们先将其命名为A.zip
② 在源码中修改我们需要改变的部分，比如修改内核配置，增加新的驱动等等。修改后再一次执行上面的命令。就会生成第二个我们修改后生成的update.zip升级包。将 其命名为B.zip。
③ 在上文中我们看了ota_from_target_files.py脚本的使用帮助，其中选项-i就是用来生成差分增量包的。使用方法是以上面的A.zip 和B.zip包作为输入，以update.zip包作 为输出。生成的update.zip就是我们最后需要的增量包。
具体使用方式是：将上述两个包拷贝到源码根目录下，然后执行下面的命令。
$ ./build/tools/releasetools/ota_from_target_files -i A.zip B.zip update.zip。
在执行上述命令时会出现未找到recovery_api_version的错误。原因是在执行上面的脚本时如果使用选项i则会调用WriteIncrementalOTAPackage会从A包和B包中的META目录下搜索misc_info.txt来读取recovery_api_version的值。但是在执行make otapackage命令时生成的update.zip包中没有这个目录更没有这个文档。
此时我们就需要使用执行make otapackage生成的原始的zip包。这个包的位置在out/target/proct/tcc8800/obj/PACKAGING/target_files_intermediates/目录下，它是在用命令make otapackage之后的中间生产物，是最原始的升级包。我们将两次编译的生成的包分别重命名为A.zip和B.zip，并拷贝到SD卡根目录下重复执行上面的命令：
$ ./build/tools/releasetools/ota_form_target_files -i A.zip B.zip update.zip。
在上述命令即将执行完毕时，在device/telechips/common/releasetools.py会调用IncrementalOTA_InstallEnd,在这个函数中读取包中的RADIO/bootloader.img。
而包中是没有这个目录和bootloader.img的。所以执行失败，未能生成对应的update.zip。可能与我们未修改bootloader（升级firmware）有关。此问题在下一篇博客已经解决。
制作增量包失败的原因，以及解决方案。
Android系统Recovery工作原理之使用update.zip升级过程分析（二）---update.zip差分包问题的解决
在上一篇末尾提到的生成差分包时出现的问题，现已解决，由于最近比较忙，相隔的时间也比较长，所以单列一个篇幅提示大家。这个问题居然是源码中的问题，可能你已经制作成功了，不过我的这个问题确实是源码中的一个问题，不知道是不是一个bug，下文会具体分析！
一、生成OTA增量包失败的解决方案
在上一篇中末尾使用ota_from_target_files脚本制作update.zip增量包时失败，我们先将出现的错误贴出来。
在执行这个脚本的最后读取input_zip中RADIO/bootloader.img时出现错误，显示DeviceSpecifiParams这个对象中没有input_zip属性。
我们先从脚本中出现错误的调用函数中开始查找。出现错误的调用地方是在函WriteIncrementalOTAPackage（443行）中的device_specific.IncrementalOTA_InstallEnd()，其位于WriteIncrementalOTAPackage()中的末尾。进一步跟踪源码发现，这是一个回调函数，他的具体执行方法位于源码中/device/telechips/common/releasetools.py脚本中的IncrementalOTA_InstallEnd()函数。下面就分析这个函数的作用。
releasetools.py脚本中的两个函数FullOTA_InstallEnd()和IncrementalOTA_InstallEnd()的作用都是从输入包中读取RADIO/下的bootloader.img文件写到输出包中，同时生成安装bootloader.img时执行脚本的那部分命令。只不过一个是直接将输入包中的bootloader.img镜像写到输出包中，一个是先比较target_zip和source_zip中的bootloader.img是否不同（使用选项-i生成差分包时），然后将新的镜像写入输出包中。下面先将这个函数(位于/device/telechips/common/releasetools.py)的具体实现贴出来：
我们的实际情况是，在用命令make otapackage时生成的包中是没有这个RADIO目录下的bootloader.img镜像文件（因为这部分更新已被屏蔽掉了）。但是这个函数中对于从包中未读取到bootloader.img文件的情况是有错误处理的，即返回。所以我们要从 出现的实际错误中寻找问题的原由。
真正出现错误的地方是：
target_bootloader=info.input_zip.read(“RADIO/bootloader.img”)。
出现错误的原因是：AttributeError：‘DeviceSpecificParams’object has no attribute ‘input_zip’，提示我们DeviceSpecificParams对象没有input_zip这个属性。
二、updater-script脚本执行流程分析：
先看一下在测试过程中用命令make otapackage生成的升级脚本如下：
[python] view plainprint?
assert(!less_than_int(1331176658, getprop("ro.build.date.utc")));
assert(getprop("ro.proct.device") == "tcc8800" ||
下面分析下这个脚本的执行过程：
①比较时间戳：如果升级包较旧则终止脚本的执行。
②匹配设备信息：如果和当前的设备信息不一致，则停止脚本的执行。
③显示进度条：如果以上两步匹配则开始显示升级进度条。
④格式化system分区并挂载。
⑤提取包中的recovery以及system目录下的内容到系统的/system下。
⑥为/system/bin/下的命令文件建立符号连接。
⑦设置/system/下目录以及文件的属性。
⑧将包中的boot.img提取到/tmp/boot.img。
⑨将/tmp/boot.img镜像文件写入到boot分区。
⑩完成后卸载/system。
三、总结
以上的九篇着重分析了Android系统中Recovery模式中的一种，即我们做好的update.zip包在系统更新时所走过的流程。其核心部分就是Recovery服务的工作原理。其他两种FACTORY RESET、ENCRYPTED FILE SYSTEM ENABLE/DISABLE与OTA INSTALL是相通的。重点是要理解Recovery服务的工作原理。另外详细分析其升级过程，对于我们在实际升级时，可以根据我们的需要做出相应的修改。
❻ android源码怎么编译生成recovery.img
recovery.img生成过程
L630-L637 依赖关系
(From: build/core/Makefile)630 $(INSTALLED_RECOVERYIMAGE_TARGET): $(MKBOOTFS) $(MKBOOTIMG) $(MINIGZIP) /631 $(INSTALLED_RAMDISK_TARGET) /632 $(INSTALLED_BOOTIMAGE_TARGET) /633 $(recovery_binary) /634 $(recovery_initrc) $(recovery_kernel) /635 $(INSTALLED_2NDBOOTLOADER_TARGET) /636 $(recovery_build_prop) $(recovery_resource_deps) /637 $(RECOVERY_INSTALL_OTA_KEYS)
INSTALLED_RECOVERYIMAGE_TARGET 为我们的编译目标：
584 INSTALLED_RECOVERYIMAGE_TARGET := $(PRODUCT_OUT)/recovery.img
它依赖很多其它目标：
1．MKBOOTFS, MINIGZIP, MKBOOTIMG，PC端工具软件：（From build/core/config.mk）265 MKBOOTFS := $(HOST_OUT_EXECUTABLES)/mkbootfs$(HOST_EXECUTABLE_SUFFIX)266 MINIGZIP := $(HOST_OUT_EXECUTABLES)/minigzip$(HOST_EXECUTABLE_SUFFIX)267 MKBOOTIMG := $(HOST_OUT_EXECUTABLES)/mkbootimg$(HOST_EXECUTABLE_SUFFIX)
2．INSTALLED_RAMDISK_TARGET，标准根文件系统 ramdisk.img：
326 BUILT_RAMDISK_TARGET := $(PRODUCT_OUT)/ramdisk.img328 # We just build this directly to the install location.329 INSTALLED_RAMDISK_TARGET := $(BUILT_RAMDISK_TARGET) 3．INSTALLED_BOOTIMAGE_TARGET， 即boot.img,标准内核及标准根文件系统：362 INSTALLED_BOOTIMAGE_TARGET := $(PRODUCT_OUT)/boot.img
4. recovery_binary, Recovery可执行程序，源码位于：bootable/recovery
590 recovery_binary := $(call intermediates-dir-for,EXECUTABLES,recovery)/recovery
5. recovery_initrc，recovery模式的init.rc, 位于 bootable/recovery/etc/init.rc
586 recovery_initrc := $(call include-path-for, recovery)/etc/init.rc
6. recovery_kernel, recovery 模式的kernel, 同标准内核
587 recovery_kernel := $(INSTALLED_KERNEL_TARGET) # same as a non-recovery system
7.INSTALLED_2NDBOOTLOADER_TARGET，我们不用。
8. recovery_build_prop， recovery 模式的build.prop, 同标准模式。589 recovery_build_prop := $(INSTALLED_BUILD_PROP_TARGET)
9. recovery_resource_deps， recovery 模式使用的res, 位于：recovery/custom/{proct_name}/res, 以及设备自定义部分（我们没用到）
591 recovery_resources_common := $(call include-path-for, recovery)/custom/$(TARGET_PRODUCT)/res592 recovery_resources_private := $(strip $(wildcard $(TARGET_DEVICE_DIR)/recovery/res))593 recovery_resource_deps := $(shell find $(recovery_resources_common) 594 $(recovery_resources_private) -type f) 10. RECOVERY_INSTALL_OTA_KEYS, ota 密钥：
618 # Generate a file containing the keys that will be read by the619 # recovery binary.620 RECOVERY_INSTALL_OTA_KEYS := /621 $(call intermediates-dir-for,PACKAGING,ota_keys)/keysL638-L655 准备内容
638 @echo ----- Making recovery image ------639 rm -rf $(TARGET_RECOVERY_OUT)640 mkdir -p $(TARGET_RECOVERY_OUT)641 mkdir -p $(TARGET_RECOVERY_ROOT_OUT)642 mkdir -p $(TARGET_RECOVERY_ROOT_OUT)/etc643 mkdir -p $(TARGET_RECOVERY_ROOT_OUT)/tmp
准备recovery目录：out/target/proct/{proct_name}/recovery 及其子目录：
./root
./root/etc
./root/tmp644 echo Copying baseline ramdisk...645 cp -R $(TARGET_ROOT_OUT) $(TARGET_RECOVERY_OUT)646 echo Modifying ramdisk contents...647 rm -rf $(TARGET_RECOVERY_ROOT_OUT)/res
从标准根文件系统拷贝所有文件， 删除其res 目录。
648 cp -f $(recovery_initrc) $(TARGET_RECOVERY_ROOT_OUT)/649 cp -f $(recovery_binary) $(TARGET_RECOVERY_ROOT_OUT)/sbin/ 拷贝recovery 模式的核心文件 init.rc 及 recovery 650 cp -rf $(recovery_resources_common) $(TARGET_RECOVERY_ROOT_OUT)/651 $(foreach item,$(recovery_resources_private), /652 cp -rf $(item) $(TARGET_RECOVERY_ROOT_OUT)/)653 cp $(RECOVERY_INSTALL_OTA_KEYS) $(TARGET_RECOVERY_ROOT_OUT)/res/keys 拷贝资源文件及密钥文件。 654 cat $(INSTALLED_DEFAULT_PROP_TARGET) $(recovery_build_prop) /655 > $(TARGET_RECOVERY_ROOT_OUT)/default.prop 生成属性文件 default.prop, 它包含了标准根文件系统的default.prop （out/target/proct/{proct_name}/root/default.prop）以及system分区的build.prop (out/target/proct/{proct_name}/system/build.prop) L656-L661 最终生成recovery.img
656 $(MKBOOTFS) $(TARGET_RECOVERY_ROOT_OUT) | $(MINIGZIP) > $(recovery_ramdisk) 压缩recovery根文件系统 657 build/quacomm/mkimage $(PRODUCT_OUT)/ramdisk-recovery.img RECOVERY > $(PRODUCT_OUT)/ramdisk_recovery.img 加一个标识头（RECOVERY） 658 mv $(PRODUCT_OUT)/ramdisk_recovery.img $(PRODUCT_OUT)/ramdisk-recovery.img659 $(MKBOOTIMG) $(INTERNAL_RECOVERYIMAGE_ARGS) --output $@660 @echo ----- Made recovery image -------- $@661 $(hide) $(call assert-max-image-size,$@,$(BOARD_RECOVERYIMAGE_PARTITION_SIZE),raw)
和内核一起，生成recovery.img附：Recovery 根文件系统目录结构
$ tree
.
├── advanced_meta_init.rc
├── data
├── default.prop
├── dev
├── etc
├── init
├── init.factory.rc
├── init.goldfish.rc
├── init.quacomm.rc
├── init.rc
├── meta_init.rc
├── proc
├── res
│ ├── images
│ │ ├── icon_error.png
│ │ ├── icon_installing.png
│ │ ├── indeterminate1.png
│ │ ├── indeterminate2.png
│ │ ├── indeterminate3.png
│ │ ├── indeterminate4.png
│ │ ├── indeterminate5.png
│ │ ├── indeterminate6.png
│ │ ├── progress_empty.png
│ │ └── progress_fill.png
│ └── keys
├── sbin
│ ├── adbd
│ ├── advanced_meta_init
│ ├── meta_init
│ ├── meta_tst
│ └── recovery
├── sys
├── system
└── tmp
❼ 如何针对特定机型，编译cwm recovery
你必须使用32位或64位Ubuntu系统，关于如何建立编译环境和同步源码的指导，请自己查找有关指导的文章。
1,
安装所需要的包
2,
建立编译的环境，并同步CWM所需的源码，CyanogenMod源码中附带CWM源码
CWM
5
-
Gingerbread
CWM
6
-
Jellybean
3,
下面我们进入真正的编译阶段，确保你已经使用“repo
sync
”命令同步了最新的源码
进入源码的目录
放出以下命令：
make
-j4
otatools
3.5,
如果你的机型不被CM10官方支持，请执行这一步
在你的手机终端上执行以下命令，
mp_image
boot
/sdcard/boot.img
这将boot镜像导出到你手机的sdcard，复制该镜像至你的home目录下
为一款新设备编译android源码，需要建立相应的配置文件和makefile文件，这通常比较麻烦，如果仅仅编译recovery镜像，会容易的多。在android源码根目录下（假设已运行envsetup.sh），运行以下命令（使用适当的名称取代命令中的名称）
build/tools/device/mkvendor.sh
device_manufacturer_name
device_name
/your/path/to/the/boot.img
例如，你拥有Samsung
Galaxy
Ace这款设备，你应该使用以下这条命令
build/tools/device/mkvendor.sh
Samsung
cooper
~/boot.img
Please
note
that
Cooper
is
the
device
name.
Only
use
"~/boot.img"
if
you
have
the
boot
image
in
your
home
directory.
Or
else
please
specify
the
correct
path.
如果所有都工作正常，你将看到"Done!"这样的确认信息。mkvendor.sh脚本也将在你的android源码树中创建以下目录：
manufacturer_name/device_name
4，
现在你已经拥有相关的配置文件
在源码目录下，在terminal终端下键入以下命令
.
build/envsetup.sh
这一步将为你建立编译环境
现在使用这条命令
lunch
full_device_name-eng
这将为你的设备建立起build
system。用文件管理器或IDE打开目录，你应该拥有以下文件：
AndroidBoard.mk,
AndroidProcts.mk,
BoardConfig.mk,
device_.mk,
kernel,
system.prop,
recovery.fstab,
和
vendorsetup.sh
对你感兴趣的应该是recovery.fstab和kernel这两个文件，kernel这个文件是你之前从boot.img文件中提取出的。recovery.fstab将适用于大部分拥有
mtd,
emmc,或者其他分区的设备。如果没有，recovery.fstab将需要优化以支持加载这些点。例如
/sdcard被加载至/dev/block/mmcblk1p1，
你需要将下面这段加入到你的BoardConfig.mk文件中
/sdcard
vfat
/dev/block/mmcblk1p1
一旦recovery.fstab已经适当的装载，你可以开始下一步了
5，
现在，我们开始编译Recovery
make
-j4
recoveryimage
这个命令用于编译recovery镜像
你能使用这个命令
make
-j4
recoveryzip
用于建立一个临时的recovery.zip刷机包在你真实的设备上测试
你编译好的recovery可以在"your_source_directory/OUT/target/proct/device/recovery.img"目录下找到。而.zip刷机包可以在相同目录下的utilities文件夹下找到。
如果各项测试正常，就可以有一个成功的recovery
一旦你编译通过了recovery，通知"koush"，在Github上，他就能根据你的编译文件发放官方版的CWM
Recovery，并使Rom
Manager提供相应的支持。
小贴士：
如果你想编译CWM6，使用以下命令同步jellybean分支源码
repo
init
-u
git://github.com/CyanogenMod/android.git
-b
jellybean
repo
sync
如果你改变了BoardConfig.mk文件，在编译期间运行"make
clobber"，否则你做的更改就不会生效。
❽ 如何编译制作recovery.img
解压后得到了recovery.img文件和一个名字为META-INF的文件夹，我想问，这个可能和我手机的版本或者其他什么相关，于是不得不手动recovery，好处就是不管x
❾ 如何构建编译TWRP touch recovery
1. 关机状态下同时长按手机电源键、音量+、音量- 这三个键，如下图： 2. 屏幕亮后松开按键，等待出现下图画面即已经进入recovery模式，如果未出现，请重复步骤1； 进入recovery模式之后，如果想双清恢复系统或是双清清除锁屏密码，请提前做好手机上个人数据的备份工作。 1. 使用音量加减键选择至“wipe data/ factory reset”,按电源键确认； 2. 使用音量加减键选择至“Yes”，按电源键确认； 3. 使用音量加减键选择至“wipe cache partition”，按电源键确认； 4. 等待手机重启。您的手机就会恢复到出厂的状态了。
❿ 如何从源代码编译TWRP Recovery
目前稳定的的分支是twrp2.4板本2.4.xx代码基地。如果你使用的CM10.1你*必须*使用twrp2.4分支。主分支代表TWRP2.2和JB-WIP TWRP2.3。选择任何你喜欢的分支，但唯一的分支越来越活跃的代码更改twrp2.4。 * CM7 ONLY* 更换整个CM7/build文件夹