后使用快捷导航没有帐号？
其他登录方式
—— 新手入门 ——
—— 智友精华 ——
查看: 2887|回复: 2
在线时间497 小时最后登录阅读权限30UID9291012注册时间积分1016精华0
, 积分 1016, 距离下一级还需 184 积分
主题帖子 金币1005 元 智豆67 点
智友移动版
本帖最后由 无敌小远哥 于
06:38 编辑
版主删贴，问题已解决
在线时间67 小时最后登录阅读权限20UID5523591注册时间积分166精华0
, 积分 166, 距离下一级还需 34 积分
主题帖子 金币458 元 智豆24 点
智友移动版
那到底可不可以啊
在线时间2632 小时最后登录阅读权限90UID7331947注册时间积分20877精华0
主题帖子 金币13981 元 智豆1970 点
窝心的love 发表于
那到底可不可以啊
智豆兑换每周3下午开始兑换，请优先关注智友微博获取确切开启时间。
兑换前请仔细阅读。经验1516 米
在线时间127 小时
版本4.12.5
积分 1755, 距离下一级还需 245 积分
积分 1755, 距离下一级还需 245 积分
机型小米手机1/1S
签到次数84
MIUI版本4.12.5
如题，我想删了系统更新
分享到微信朋友圈
打开微信，点击底部的“发现”，使用 “扫一扫” 即可将网页分享到我的朋友圈。
经验67781 米
威望985 米
在线时间1871 小时
版本7.8.17
一个人走了太久，久到我已经习惯一个人
机型小米手机5S
签到次数217
MIUI版本7.8.17
本帖最后由 №迷失℃ 于
09:18 编辑
直接安装不放删除能不能呢？我没尝试,你想删掉就试试，记得告诉我一下结果，谢谢
经验36249 米
在线时间2245 小时
版本7.8.21
承诺是什么？
机型小米MIX
签到次数244
MIUI版本7.8.21
安卓优化大师可以！
（★★★室内设计俱乐部★★★↓↓↓）
经验2359 米
在线时间186 小时
版本3.4.19
头像被屏蔽
机型小米手机1/1S
签到次数49
MIUI版本3.4.19
提示: 作者被禁止或删除 内容自动屏蔽
经验2761 米
在线时间786 小时
版本6.9.29
积分 3742, 距离下一级还需 1258 积分
积分 3742, 距离下一级还需 1258 积分
机型Samsung Galaxy Note 3
签到次数87
MIUI版本6.9.29
09:33 上传
点击文件名下载附件
下载积分: 经验 -1 米
425.68 KB, 下载次数: 2164, 下载积分: 经验 -1 米
坚持就可能胜利！
经验1516 米
在线时间127 小时
版本4.12.5
积分 1755, 距离下一级还需 245 积分
积分 1755, 距离下一级还需 245 积分
机型小米手机1/1S
签到次数84
MIUI版本4.12.5
经验663 米
在线时间110 小时
积分 764, 距离下一级还需 1236 积分
积分 764, 距离下一级还需 1236 积分
机型小米手机1/1S
签到次数36
经验498 米
在线时间126 小时
版本ICS16.0
积分 778, 距离下一级还需 1222 积分
积分 778, 距离下一级还需 1222 积分
机型小米手机1/1S
MIUI版本ICS16.0
楼主估计是伤心透了 以后再也不更新了 小米小米 你叫我们这些米粉情何以堪啊
经验2570 米
在线时间115 小时
版本V8.2.27.0.NCACNEC
机型小米手机6
签到次数188
MIUI版本V8.2.27.0.NCACNEC
你的开发版很容易删除 下载个系统程序卸载软件，去应用商店里就有 然后删除。
经验625 米
在线时间229 小时
版本3.5.14
论坛扫荡者
积分 889, 距离下一级还需 1111 积分
积分 889, 距离下一级还需 1111 积分
机型小米手机1/1S
签到次数35
MIUI版本3.5.14
root了吗？（感觉在MIUI问这个问题好奇怪，但是现在就是这么奇怪了）
4.1会在国庆前后公测
4.1正在适配，耐心等待
4.1现在提上日程，看情况可能会直接上4.2
4.1升级相对4.0太少，4.2很给力
关注腾讯微博
已关注腾讯微博
关注新浪微博
已关注新浪微博
MIUI七周年
小米7周年勋章
2017米粉节晒单赢专属勋章
“澎湃S1 ”芯片纪念勋章
参与活动回帖可得
参与红米Note 4X活动
2017年小金鸡勋章
回复2016年度评选活动贴
圣诞节勋章
参与圣诞活动
APP 1000万
MIUI论坛APP注册用户突破1000万纪念勋章
MIUI 3000万
MIUI 3000万发烧友纪念勋章
MIUI 2000万
MIUI 2000万发烧友纪念勋章
1000万用户纪念勋章
MIUI1000万用户纪念勋章
MIUI 7纪念勋章
MIUI五周年
MIUI五周年纪念勋章
小米手机3终身荣誉勋章
小米手机3终身荣誉勋章
MIUI三周年
MIUI三周年纪念勋章
百万壁纸评审纪念勋章
已关注极客秀微信
已关注微信
疾风测评勋章
资源疾行活动限定勋章
MIUI6 荣誉勋章
MIUI6 荣誉勋章
应用达人勋章
发烧友俱乐部
发烧友俱乐部
MIUI 300周
MIUI 300周更新纪念勋章
小米平板首发纪念勋章
小米平板首发纪念勋章
小米手机2终身荣誉勋章
小米手机2终身荣誉勋章
MIUI 100周
100周发布纪念勋章
MIUI六周年
MIUI六周年纪念勋章
Copyright (C) 2017 MIUI
京ICP备号 | 京公网安备34号 | 京ICP证110507号后使用快捷导航没有帐号？
其他登录方式
—— 新手入门 ——
—— 智友精华 ——
查看: 18521|回复: 9
在线时间77 小时最后登录阅读权限20UID9032316注册时间积分123精华0
, 积分 123, 距离下一级还需 77 积分
主题帖子 金币381 元 智豆0 点
手机刷的是4.2.2的ZCUCMH1五件套，没锁基带，没锁BL。现在系统自动下载了4.3的更新，想删除以便节约空间，而且一直看着那更新也烦（我点稍等，也最慢3个小时要提醒我一次，很烦。），请问是在哪里删除？手机已经ROOT，是在RE里面删除文件就行了吗？
在线时间77 小时最后登录阅读权限20UID9032316注册时间积分123精华0
, 积分 123, 距离下一级还需 77 积分
主题帖子 金币381 元 智豆0 点
智友移动版
顶起来，哪位大大来解释下，这个很障眼啊
在线时间608 小时最后登录阅读权限30UID8940105注册时间积分1139精华0
, 积分 1139, 距离下一级还需 61 积分
主题帖子 金币3964 元 智豆0 点
智友移动版
本帖最后由 linwy66 于
08:47 编辑
进re管理器刪系统升级apk文件
在线时间77 小时最后登录阅读权限20UID9032316注册时间积分123精华0
, 积分 123, 距离下一级还需 77 积分
主题帖子 金币381 元 智豆0 点
智友移动版
linwy66 发表于
进re管理器刪系统升级apk文件
系统升级文件已经禁止运行了，关键那700多兆的缓存哪里删除啊？
在线时间608 小时最后登录阅读权限30UID8940105注册时间积分1139精华0
, 积分 1139, 距离下一级还需 61 积分
主题帖子 金币3964 元 智豆0 点
regforv 发表于
系统升级文件已经禁止运行了，关键那700多兆的缓存哪里删除啊？
用软件清理下缓存就是啦
在线时间289 小时最后登录阅读权限20UID9783474注册时间积分674精华0
, 积分 674, 距离下一级还需 26 积分
主题帖子 金币1482 元 智豆32 点
智友移动版
在设置那里你直接点不自动更新不就得了。。。搞那么麻烦
在线时间77 小时最后登录阅读权限20UID9032316注册时间积分123精华0
, 积分 123, 距离下一级还需 77 积分
主题帖子 金币381 元 智豆0 点
<font color="#8395758 发表于
在设置那里你直接点不自动更新不就得了。。。搞那么麻烦
说得轻松，不用系统提示很简单，但系统个已经下了700多M的更新文件，这个怎么删除？请你指点！
在线时间45 小时最后登录阅读权限20UID注册时间积分390精华0
, 积分 390, 距离下一级还需 10 积分
主题帖子 金币625 元 智豆0 点
支持一下，下载看看。
在线时间289 小时最后登录阅读权限20UID9783474注册时间积分674精华0
, 积分 674, 距离下一级还需 26 积分
主题帖子 金币1482 元 智豆32 点
→_→用RE管理器，打开这个路径，
根目录\cache\
从英文就可以看出是缓存，一般升级完会自动删除。你看不懂？
在线时间77 小时最后登录阅读权限20UID9032316注册时间积分123精华0
, 积分 123, 距离下一级还需 77 积分
主题帖子 金币381 元 智豆0 点
<font color="#8395758 发表于
→_→用RE管理器，打开这个路径，
根目录\cache\
从英文就可以看出是缓存，一般升级完会自动删除。你看不 ...
用re看过，这些缓存文件都是很小的，没发现几百M的。会不会在其他位置？
智豆兑换每周3下午开始兑换，请优先关注智友微博获取确切开启时间。
兑换前请仔细阅读。这篇及以后的篇幅将通过分析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包在实际的更新中所走的过程！
转载地址：
阅读(...) 评论() &