拖油塔

在上一篇末尾提到的生成差分包时出现的问题，现已解决，由于最近比较忙，相隔的时间也比较长，所以单列一个篇幅提示大家。这个问题居然是源码中的问题，可能你已经制作成功了，不过我的这个问题确实是源码中的一个问题，不知道是不是一个bug，下文会具体分析！一、生成OTA增量包失败的解决方案           在上一篇中末尾使用ota_from_target_files脚本制作update.zip

目前update-script脚本格式是edify，其与amend有何区别，暂不讨论，我们只分析其中主要的语法，以及脚本的流程控制。一、update-script脚本语法简介：        我们顺着所生成的脚本来看其中主要涉及的语法。        1.assert(condition)：如果condition参数的计算结果为False，则停止脚本执行，否则继续执行脚本。

一、update_binary的执行过程分析       上一篇幅中的子进程所执行的程序binary实际上就是update.zip包中的update-binary。我们在上文中也说过，Recovery服务在做这一部分工作的时候是先将包中update-binary拷贝到内存文件系统中的/tmp/update_binary，然后再执行的。update_binary程序的源码位于gingerbrea

Recovery服务毫无疑问是Recovery启动模式中最核心的部分。它完成Recovery模式所有的工作。Recovery程序对应的源码文件位于：/gingerbread0919/bootable/recovery/recovery.c。一、 Recovery的三类服务：         先看一下在这个源码文件中开始部分的一大段注释，这将对我们理解Recovery服务的主要功能有

文章开头我们就提到update.zip包来源有两种，一个是OTA在线下载（一般下载到/CACHE分区），一个是手动拷贝到SD卡中。不论是哪种方式获得update.zip包，在进入Recovery模式前，都未对这个zip包做处理。只是在重启之前将zip包的路径告诉了Recovery服务（通过将--update_package=CACHE:some_filename.zip或--update_pack

以下的篇幅开始分析我们在上两个篇幅中生成的update.zip包在具体更新中所经过的过程，并根据源码分析每一部分的工作原理。一、       系统更新update.zip包的两种方式    1.  通过上一个文档，我们知道了怎样制作一个update.zip升级包用于升级系统。Android在升级系统时获得update.zip包的方式有两种。一种是离线升级，即手动拷贝升级包到SD卡（或NAN

这篇及以后的篇幅将通过分析update.zip包在具体Android系统升级的过程，来理解Android系统中Recovery模式服务的工作原理。我们先从update.zip包的制作开始，然后是Android系统的启动模式分析，Recovery工作原理，如何从我们上层开始选择system update到重启到Recovery服务，以及在Recovery服务中具体怎样处理update.zip包升级的

OTA（Over－the－Air Technology）空中下载技术。是通过移动通信（GSM或CDMA）的空中接口对SIM卡数据及应用进行远程管理的技术。空中接口可以采用WAP、GPRS、CDMA1X及短消息技术。OTA技术的应用，使得移动通信不仅可以提供语音和数据服务，而且还能提供新业务下载。这样，应用及内容服务商可以不受平台的局限，不断开发出更具个性化的贴近用户需求的服务，如信息点播、互动娱乐

一、       Recovery服务的核心install_package（升级update.zip特有）              和Recovery服务中的wipe_data、wipe_cache不同，install_package()是升级update.zip特有的一部分，也是最核心的部分。在这一步才真正开始对我们的update.zip包进行处理。下面就开始分析这一部分。还是先看

在使用update.zip包升级时怎样从主系统（main system）重启进入Recovery模式，进入Recovery模式后怎样判断做何种操作，以及怎样获得主系统发送给Recovery服务的命令，这一系列问题的解决是通过整个软件平台的不同部分之间的密切通信配合来完成的。为此，我们必须要了解Recovery模式的工作原理，这样才能知道我们的update.zip包是怎样一步步进入Recovery中