这篇及以后的篇幅将通过分析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/product/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/product/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/product/security/testkey.x509.pem & & & &&
& & & & & & & &build/target/product/security/testkey.pk8 。
& & & & & & & 我们用命令make otapackage制作生成的update.zip包是已签过名的，如果自己做update.zip包时必须手动对其签名。
& & & & & & & 具体的加密方法：$ java &jar gingerbread/out/host/linux/framework/signapk.jar &w gingerbread/build/target/product/security/testkey.x509.pem & & & & & & & & & & & & & & & & & & &gingerbread/build/target/product/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/product/full_tcc8800_evm_target_files-eng.mumu.059.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贴出来如下：
& & & & &&
& & & & & & 根据上面的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升级包的过程。
& & & & & & & & & &㈠ 首先看一下这个脚本开始部分的帮助文档。代码如下：
& & & & & & & & & & & & 下面简单翻译一下他们的使用方法以及选项的作用。
& & & & & & & & & & & & Usage: ota_from_target_files [flags] input_target_files output_ota_package& & & & & & & & & & & & -b 过时的。& & & & & & & & & & & & -k签名所使用的密钥& & & & & & & & & & & & -i生成增量OTA包时使用此选项。后面我们会用到这个选项来生成OTA增量包。& & & & & & & & & & & & -w是否清除userdata分区& & & & & & & & & & & & -n在升级时是否不检查时间戳，缺省要检查，即缺省情况下只能基于旧版本升级。& & & & & & & & & & & & -e是否有额外运行的脚本& & & & & & & & & & & & -m执行过程中生成脚本(updater-script)所需要的格式,目前有两种即amend和edify。对应上两种版本升级时会采用不同的解释器。缺省会同时生成两种格式的脚 本。& & & & & & & & & & & & -p定义脚本用到的一些可执行文件的路径。& & & & & & & & & & & & -s定义额外运行脚本的路径。& & & & & & & & & & & & -x定义额外运行的脚本可能用的键值对。& & & & & & & & & & & & -v执行过程中打印出执行的命令。& & & & & & & & & & & & -h命令帮助
& & & & & & & & & &㈡ 下面我们分析ota_from_target_files这个python脚本是怎样生成最终zip包的。先讲这个脚本的代码贴出来如下：
& & & & & & & & & & & &主函数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/product/tcc8800/full_tcc8800_evm-ota-eng.mumu.326.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/product/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/product/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。
& & & & & & &
三、生成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这个属性。
& & & & &在用ota_from_target_files脚本制作差分包时使用了选项-i，并且只有这种情况有三个参数，即target_zip 、source_zip、 out_zip。而出现错误的地方是target_bootloader=info.input_zip_read(&RADIO/bootloader.img&)，它使用的是input_zip，我们要怀疑这个地方是不是使用错了，而应该使用info.target_zip.read()。下面可以证实一下我们的猜测。
& & & & &从ota_from_target_files脚本中WriteFullOTAPackage()和WriteIncrementalOTAPackage这两个函数（分别用来生成全包和差分包）可以发现，在他们的开始部分都对device_specific进行了赋值。其中WriteFullOTAPackage()对应的参数是input_zip和out_zip，而WriteIncrementalOTAPackage对应的是target_zip,source_zip,out_zip，我们可以看一下在WriteIncrementalOTAPackage函数中这部分的具体实现：
& & & & & & & & &&
& & &&& & & 从上图可以发现，在WriteIncrementalOTAPackage函数对DeviceSpecificParams对象进行初始化时确实使用的是target_zip而不是input_zip。而在releasetools.py脚本中使用的却是info.input_zip.read()，所以才会出现DeviceSpecificParams对象没有input_zip这个属性。由此我们找到了问题的所在(这是不是源码中的一个Bug？)。
& & & & 将releasetools.py脚本IncrementalOTA_InstallEnd(info)函数中的 target_bootloader=info.input_zip.
read(&RADIO/bootloader.img&)为：target_bootloader=info.target_zip.read(&RADIO/bootloader.img&)，然后重新执行上面提到的制作差分包命令。就生成了我们需要的差分包update.zip。
二、&&&&&&&&&&差分包update.zip的更新测试& & &
& & & & & & & &&在上面制作差分包脚本命令中，生成差分包的原理是，参照第一个参数（target_zip），将第二个参数（source_zip）中不同的部分输出到第三个参数（output_zip）中。其中target_zip与source_zip的先后顺序不同，产生的差分包也将不同。
& & & & & 在实际的测试过程中，我们的增量包要删除之前添加的一个应用（在使用update.zip全包升级时增加的），其他的部分如内核都没有改动，所以生成的差分包很简单，只有META-INF这个文件夹。主要的不同都体现在updater-script脚本中，其中的#----start make changes& here----之后的部分就是做出改变的部分，最主要的脚本命令是：&delete(&/system/app/CheckUpdateAll.apk& , &/system/recovery.img&);在具体更新时它将删除CheckUpdateAll.apk这个应用。
& & & & & 为了大家参考，还是把这个差分包的升级脚本贴出来，：
&&&&&&&& 在做更新测试时，我们要以target_zip系统为依据，也就是更新之前的开发板系统是用target_zip包升级后的系统。否则会更新就会失败，因为在更新时会从系统对应的目录下读取设备以及时间戳等信息(updater-script脚本一开始的部分)，进行匹配正确后才进行下一步的安装。
&&&&&&&& 所有准备都完成后，将我们制作的差分包放到SD卡中，在Settings--&About Phone--&System Update--&Installed From SDCARD执行更新。最后更新完成并重启后，我们会发现之前的CheckUpdateAll.apk被成功删掉了，大功告成！
& & & &&至此终于将update.zip包以及其对应的差分包制作成功了，下面的文章开始具体分析制作的update.zip包在实际的更新中所走的过程！
转载地址：
阅读(...) 评论() &手机签到经验翻倍！快来扫一扫！
【教程】fastboot新手刷机傻瓜教程
358478浏览 / 1536回复
见好多论坛朋友对FASTBOOT刷机相当困惑和不解,抑或是相当害怕使用fastboot刷机.不管是什么原因,我只需要告诉你,其实用fastboot很简单,也很快捷。 下面把我自己总结的一些方法写出来,希望能给广大G友在刷机路上助一臂之力。
fastboot for windows 已加入附件内,请自行下载。 只有一个文件,下载后随便放在你能找到的地方.在正式讲刷机之前先讲一下G1或者称android的分区知识 splash1：开机画面，使用Nandroid backup备份系统后的文件为splash1.img
recovery：该分区是恢复模式(即开机按Home+power进入的界面)，使用Nandroid backup备份为recovery.img boot：内核启动分区，使用Nandroid backup备份为boot.img system：Android系统部分，目录表示为/system，通常为只读，使用Nandroid backup备份为system.img =cache：缓存文件夹，目录表示为/cache，事实上除了T-mobile的OTA更新外，别无用处，使用Nandroid backup备份为cache.img userdata：用户安装的软件以及各种数据，目录为/data，使用Nandroid backup备份为data.img
因此对于刷机一般可以这么理解： 1. 修改开机画面, 修改的是splash1 2. root时刷的是所有分区 3. 刷test_keys，更新的应该是recovery 4. 使用update.zip刷是更新boot、system 5. 恢复出厂设置, 清空的是userdata和cache 明白这些之后就很好理解,一般无须更新recovery.IMG,正常情况下只需要更新BOOT和SYSTEM即可.但依我看来这两者是相互依存而不可分割的.好下面开始说刷机步骤。进入无论你从哪里下载到一个包含boot.img，system.img只要含有这两个文件的文件你就可以刷机了,将刚才下载的fastboot拷贝到此文件夹,图2在windows下运行CMD这句应该能看懂吧？ 用cd命令打开fastboot所在的文件夹。如下图3&若出现我HTxxxxxxx fastboot,这就证明你已经成功了一半,ok,接下来就是擦除分区，使用fastboot erase xxxx 如下图 只需擦除boot,system，也可以是userdata也可以是recovery。。呵呵 看实际需要了。Ok 看图6依然OKAY。。userdata和recovery我就不擦了,,命令也是Fastboot erase userdata 敲完回车Fastboot erase recovery 敲完回车。Ok，擦除完了那就开始刷进去吧。。。看图8先flash boot.img。命令很简单接着flash system.img 图9
也okay，，，像之前备份的userdata或者是recovery，再未擦除就不用在flash了。若需要语法如下Fastboot flash userdata userdata.Img（确定在备份里面是这个名字或者之前又这个分区）Fastboot flash recovery recovery.imgOk下一步重启 图10
至此刷机全部结束,等待你的小G启动起来就OK了。。有时需要在电脑端安装apk程序时,这时候是不许用fastboot的,只需要进入SDK-tools下面运行 adb install xxx.apk既可，前提是你要安装的程序和adb同一目录。
1.5系统能升到2.0吗？
太棒了, 真的找了很久, 谢楼主了.
找了很多都不行,终于遇到你.感谢分享.
谢谢啊，找了好久没找到
我只能怪自己比傻瓜还傻,我实在看不明白
刷不好会不会变砖头的？？？
力顶力顶力顶力顶力顶
真的是不懂= =、
我觉得太多需要我去学习的，
但是我好懒，，，，，，
太棒了, 真的找了很久, 谢楼主了.
汗。。看迷糊了。准备再研究研究
谢谢分享正在准备root
谢谢！~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
找了很久，感谢分享
应该刷哪个Recovery版本
支持键盘翻页 ( 左右 )&
用户名/注册邮箱/注册手机号
其他第三方号登录Android的fastboot协议_Linux编程_Linux公社-Linux系统门户网站
你好，游客
Android的fastboot协议
来源：Linux社区&
fastboot协议是PC通过USB与手机上的bootloader通信的协议。适用于Linux,Windows,OSX等平台。
基本配置要求:
1、USB连接PC与手机。
2、对于high-speec USB，包的最大尺寸必须是512byte.对于full-speed USB，包的最大尺寸必须是64byte。
3、协议由PC端驱动。
协议传输过程如下：
1、PC向手机发送一个命令，命令由ASCII字符组成，必须存在在一个不大于64byte的包里。
2、手机向PC响应一个不大于64byte的包。包的最前面四个byte是“OKAY”、“FAIL”、“DATA”、“INFO”中的一个。后面如果还有byte，包含就是ASCII信息。下面具体解释
INFO：后面的60个byte代表的信息被显示完成后，跳到＃2继续执行。
FAIL：命令执行失败。后面的60个byte是需要显示给用户的失败信息。
OKAY：命令执行成功。跳到＃1.
DATA：命令执行成功，开始进入数据传输阶段。一个DATA响应包的大小是12byte，通常是DATA这样的形式，后面的8个数字代表的要传输的数据包的总大小。
3、如果＃2时，PC收到的是DATA命令的话，就开始传输数据。0byte数据会被忽略。当＃2指示的数据大小被传输完成时，数据传输结束。
Host:& "getvar:version"&&&&&&&&& 查看版本号
Client: "OKAY0.4"&&&&&&&&&&&&&&&&& 返回版本号
Host:& "getvar:nonexistant"&& 查看一些未定义的变量
Client: “OKAY”&&&&&&&&&&&&&&&&&&&&&& 返回值“”
Host:& “download:” 请求0x1234个byte的数据
Client: "DATA"&&&&&& 准备好接收数据
Host:& "& 0x1234 bytes &"&&& 发送数据
Client "OKAY"&&&&&&&&&&&&&&&&&&&&&&& 成功
Host:& "flash:bootloader"&&&&&&& 把数据刷到bootloader中。
Client "INFOerasinig flash"&&&& 指明状态或进度
&&&&&&&&& "INFOwriting flash"
&&&&&&&&& "OKAY"&&&&&&&&&&&&&&&&&&&&&& 成功
Host:& "powerdown"&&&&&&&&&&&&& 发送一个关机命令
Client: "FAILunknown command"失败
命令手册：
1、命令参数格式遵守printf-style
2、命令都是ASCII字符串，不能包含引号，不用以0byte结尾
3、本文档中的命令都是以小写字母开头，为了兼容，OEM的命令不要以小写字母开头。
"getvar:%s"
从bootloader读取一个配置／版本变量。变量值跟在OKAY响应后面返回。
“download:%08x”
把数据写入内存，这些数据会被后面执行的“boot”,"ramdisk","flash"等使用。Client的RAM如果有足够的空间的话，会返回一个“DATA%08x”。否则返回“FAIL”。数据大小会被记录下来。
"verify:%08x"
发送一个数字签名来验证下载的数据。如果bootloader当前是“secure”模式，签名会被使用。如果是“flash”和“boot”模式的话，签名被忽略。
"flash:%s"
把前面下载的image写到指定名字的分区中。
"erase:%s"
擦除指定名字的分区。
前面下载的数据是一个boot.imgand should be booted according to the normal
&procedure for a boot.img
"continue"
Continue booting as normal (if possible)
"reboot-bootloader"
重启并回到bootloader，这对那些需要先升级bootloader才能升级其它分区的升级过程很有用。
"powerdown"
关闭设备。
Client端的变量
"getvar:%s"命令可以读一些client端的变量。这些变量通常会可以告诉我们设备以及安装在设备上的软件的信息。目前已经定义的变量如下：
当前支持的FastBoot协议版本，对这个文档来说，它的值应该是“0.3”
version-bootloader
Bootloader的版本号
version-baseband
Baseband软件的版本
产品的名字
产品的序列号(serial number)
如果值是“yes”，表示这是一个secure的bootloader，在安装或者boot那些image之前需要一个签名
另外，这些变量的名字都是以小写字母开头，为了兼容性考虑，OEM的变量名字不要以小写字母开头。
相关资讯 & & &
& (07/13/:14)
& (08/11/:27)
& (05/06/:13)
& (04/17/:32)
& (05/31/:15)
& (04/02/:07)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款}