一种连续升级的方法及装置的制造方法
一种连续升级的方法及装置的制造方法
【技术领域】
[0001] 本发明涉及软件升级领域，尤其涉及一种连续升级的方法及装置。
【背景技术】
[0002]目前的软件版本升级一般通过下载服务器端提供的、针对客户端当前软件版本的 差分升级包，并将差分升级包通过打补丁的方式更新到当前软件版本中，实现客户端软件 版本的升级。
[0003] 为了实现将当前版本一次性升级到目标版本，目前采取的一种实现方式为：在服 务器端配置各个版本到目标版本的差分升级包，例如，目前目标版本由V4升级到了V5,则 在服务器端已有￥2，1，￥3，1，￥3,2，￥4，1，￥4,2，￥4,3差分升级包的基础上，增加配 置V5-V1，V5-V2,V5-V3,V5-V4这四个差分升级包，从而各个版本的用户通过下载对应的差 分升级包，就能实现一步到位的升级，但是这种方式需要在服务器端制作n(n-1)/2个差分 文件升级包，进一步地，为了减少服务器端的差分升级包的数量，目前还存在另一种实现方 式，也称为连续升级方式，具体为：在服务器端配置相邻两个版本的差分升级包，比如依然 假设目标版本由V4升级到了V5,在这种实现方式中，在服务器端已有V2-V1，V3-V2,V4-V3 差分升级包的基础上，只需增加配置V5-V4这一个差分升级包。在升级时，客户端下载软件 版本升级所需的所有差分升级包，并根据各个差分升级包的升级顺序逐步对软件版本进行 升级即可。比如，假设客户端当前的软件版本是V3,则需从服务器端下载V4-V3,V5-V4这 两个差分升级包，并根据V4-V3将软件升级到V4,之后再根据V5-V4将版本从V4升级到V5 即可。
[0004] 软件版本升级的过程通常涉及多个分区，包括：b〇〇t分区（引导分区)、recovery 分区(恢复分区)、system分区（系统分区）等。对于上述的连续升级方式，客户端的软件版 本从V3升级到V4的过程中，首先将V4-V3差分升级包中的patch文件(该patch文件为V4 版本的boot分区和V4版本的recovery分区的差分文件）打到system分区中，完成V3到 V4的升级，之后，再将V5-V4差分升级包中的patch文件（该patch文件为V5版本的boot 分区和V5版本的recovery分区的差分文件）打到system分区中，完成V5-V4的升级，此 时，实现了将软件版本从V3升级到了V5,然后，启动主系统的开机流程，将system分区中 的patch文件打到recovery分区中，实现对recovery分区的升级。但是，如果V4-V3的差 分升级包中对recovery分区进行了修改，并且这个修改影响到V5-V4的升级，从上面的描 述，可以知道recovery分区的升级修改只有在升级到目标版本后，启动主系统的开机流程 时，才将system中的patch文件打到recovery分区中实现对recovery分区的升级，也就 是说，在V4-V3的升级过程中，是不对recovery分区进行升级的，因此，这种情况下，V5-V4 的差分升级包就会升级失败。
[0005] 综上，在现有的连续升级方式中，如果在当前版本升级到目标版本的过程中，某个 中间版本的recovery分区进行了修改，且这个修改影响下一个差分升级包的升级时，修改 后的recovery分区并不能带入下一个差分升级包的升级，导致之后的升级过程无法继续 进行，最终导致连续升级失败。
【发明内容】
[0006] 本发明的实施例提供一种连续升级的方法及装置，实现了在连续升级过程中，下 一次的单包升级都能在上一次单包升级中升级后的recovery分区中执行升级，解决了由 于在原始版本(连续升级前的版本）和目标版本之间的任一中间软件版本的recovery分区 的修改，所导致的后续连续升级失败的问题。
[0007] 为达到上述目的，本发明的实施例采用如下技术方案： 一方面，本发明实施例提供了一种连续升级的方法，包括：判断软件的当前版本是否是 目标版本；若否，从所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包 中，查找在先版本与所述当前版本相同的差分升级包；其中，任意一个差分升级包只包含相 邻两个版本的升级信息；将查找到的差分升级包中的补丁包打到所述当前版本的system 分区中；检测是否需要对所述当前版本的recovery分区进行升级；若是，则重启所述当前 版本的recovery分区，挂载升级后的system分区，将所述升级后的system分区中的补丁 包打到所述recovery分区，实现对所述当前版本的recovery分区的升级。
[0008] 另一方面，本发明实施例提供了一种连续升级装置，包括：判断单元，用于判断软 件的当前版本是否是目标版本，并将判断结果发送给查找单元；查找单元，用于若接收到的 所述判断单元发送的所述判断结果为否，从所述软件由所述当前版本升级到所述目标版本 所需的所有差分升级包中，查找在先版本与所述当前版本相同的差分升级包；其中，任意一 个差分升级包只包含相邻两个版本的升级信息；升级system分区单元，用于将查找到的差 分升级包中的补丁包打到所述当前版本的system分区；检测单元，用于检测是否需要对所 述当前版本的recovery分区进行升级，并将检测结果发送给升级recovery分区单元；升级 recovery分区单元，用于若接收到的所述检测单元发送的检测结果为是，则重启所述当前 版本的recovery分区，挂载升级后的system分区，将所述升级后的system分区中的补丁 包打到所述recovery分区，实现对所述当前版本的recovery分区的升级。
[0009] 综上，本发明实施例提供了一种连续升级的方法及装置，首先对设备当前软件的 版本是否是目标版本进行判断，如果不是目标版本，则从该软件由当前版本升级到目标版 本所需的所有差分升级包中，查找在先版本与当前版本相同的差分升级包，查找到该差分 升级包之后，将该差分升级包中的补丁包打到当前版本的system分区中，然后，检测是否 需要对当前版本的recovery分区进行升级，如果需要，则重启当前版本的recovery分区， 挂载升级后的system分区，将升级后的system分区中的补丁包打到当前版本的recovery 分区，实现对当前版本的recovery分区的升级。如果还需要对boot分区等其他分区进行升 级，则还要对其他分区进行升级，经过上述步骤，将当前版本升级到查找到的差分升级包所 对应的在后版本，实现连续升级方式中的一个单包升级，升级之后，再对当前版本是否是目 标版本进行判断，如果不是目标版本，则重复上述过程，直至将当前版本升级到目标版本， 则终止升级过程。
[0010] 与现有技术中recovery分区的升级通常是在软件的当前版本升级到目标版本之 后，再对软件的recovery分区进行升级，使得recovery分区的版本与目标版本相匹配的过 程不同，在上述的升级过程中，首先将查找到的差分升级包中的补丁包打到system分区， 实现对system分区的升级，当升级后版本的recovery分区相对于升级前版本的recovery分区有修改时，重启recovery分区，加载前述升级后的system分区，因为加载了升级后 的system分区，所以可以通过执行升级recovery分区的服务，将升级后的system分区中 的patch文件打到recovery分区中，实现当前版本的recovery分区的升级，综上，由于每 一次的单包升级都对是否需要对当前版本的recovery分区是否升级进行判断，在需要对 当前版本的recovery分区进行升级的情况下，通过加载system分区，实现对recovery分 区的升级，这样，不需要对差分升级包做任何处理，下一次的单包升级就能在上一个单包升 级后的recovery分区的基础上进行，而recovery分区中包含了控制单包升级的升级流程 的函数，所以本发明中，原始版本(连续升级前的版本）和目标版本之间的任一中间版本的 recovery分区的修改都能带入下一个差分升级包的升级，进而，即使中间版本的recovery 分区做了修改，也不会影响下一个差分升级包的升级流程，使得连续升级过程可以顺利进 行，从而避免了现有技术中所容易出现的每次升级过程中由recovery分区的更改所导致 的下一次单包升级的失败，提高了连续升级的成功率。
【附图说明】
[0011] 为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中 所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实 施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图 获得其他的附图。
[0012] 图1为本发明实施例提供的一种连续升级的方法的流程示意图； 图2为本发明实施例提供的一种连续升级的装置的功能示意图。
【具体实施方式】
[0013] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完 整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于 本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他 实施例，都属于本发明保护的范围。
[0014] 本发明实施例提供了一种连续升级的方法，如图1所示， 包括： S101、判断软件的当前版本是否是目标版本； 需要说明的是，这里的目标版本可以是服务器端存储的最新版本，也可以不是服务器 端存储的最新版本，只要目标版本高于终端的当前版本即可。比如，假设最新版本为V5,终 端的当前版本为V3,但是在升级流程中，增加了当电量低于30%的时候，停止升级的条件， 如果当终端从V3升级到了V4之后，电量就满足了低于30%的条件，那么，此时的目标版本 就是V4。再比如，在用户选择并执行了升级操作之后，可以在终端的用户界面上给出当前可 升级的版本信息，比如，给出"升级到V4"以及"升级到V5"的两个选项，当用户选择"升级 到V4"的选项时，目标版本为V4,当用户选择"升级到V5"的选项时，目标版本就为最新版 本V5〇
[0015] 具体实现时，在这一步骤之前还包括步骤：检测软件的当前版本是否低于服务器 端相应的目标版本；若低于，则从服务器端获取软件由当前版本升级到目标版本所需的所 有差分升级包并保存。检测过程可以是终端首先向服务器发送携带有当前版本的请求消 息，该请求消息可以携带目标版本的信息，也可以不携带目标版本的信息，当请求消息不携 带有目标版本的信息时，服务器端可以默认该终端升级到最新版本，当然服务器也可以通 过判断终端的实时电量，来判断得出目标版本，本实施例以终端由当前版本升级到最新版 本为例进行说明。
[0016] 服务器根据请求消息获得终端的当前版本，并将该当前版本与服务器上存储的最 新版本做比较，如果发现该当前版本与最新版本相同，则向终端发送当前版本已经是最新 版本的响应消息，终端接收到该响应消息后，在一定时间内，不再向服务器发送请求消息， 当然也不执行任何升级操作；如果服务器经过比较后，发现该当前版本低于最新版本，则向 终端发送携带有最新版本的响应消息，终端接收到该响应消息后，确定系统的当前版本不 是最新版本，或者服务器端也可以将该终端的软件由当前版本升级到最新版本所需的所有 差分升级包发送给终端作为响应消息，终端接收到服务器发送的所有差分升级包后，确定 软件的当前版本不是最新版本。
[0017] 可选地，当服务器端将终端由当前版本升级到最新版本所需的所有差分升级包发 送给终端作为响应消息时，终端接收到服务器端发送的所有差分升级包之后，将所有差分 升级包保存在缓存中。或者，当服务器端向终端发送携带有最新版本的响应消息后，终端再 向服务器发送连续升级到最新版本的请求，服务器端接收到该请求后，将该终端由当前版 本升级到最新版本所需的所有差分升级包发送给终端。
[0018] 可选地，服务器端将终端由当前版本升级到最新版本所需的所有差分升级包发送 给终端作为响应消息，终端接收到服务器端发送的所有差分升级包之后，将所有差分升级 包保存在缓存之前，先对终端是否支持连续升级进行判断，具体的，终端可以设置标识位， 并根据该标识位，判断终端是否支持连续升级，或者服务器中存储有能够支持连续升级的 终端的产品型号，在获取到终端的产品型号的情况下，确定终端是否支持连续升级，如果确 定终端支持连续升级，则将从服务器端获取的所有差分升级包保存，如果确定终端不支持 连续升级，则忽略服务器端发送的差分升级包。
[0019] 同样地，服务器端向终端发送携带有最新版本的响应消息后，终端根据该响应消 息，向服务器发送连续升级到最新版本的请求之前，也先对终端是否支持连续升级进行判 断，如果确定终端支持连续升级，则终端向服务器端发送连续升级到最新版本的请求。
[0020] 在本实施例中，假设终端当前的软件版本为V3,服务器端存储的最新版本为V5， 则按照其中任一的实现方式，终端都可以从服务器端获取到由当前版本V3升级到最新版 本V5所需的V4-V3,V5-V4两个差分升级包，并将这两个差分升级包保存在/cache目录下。
[0021] 可选地，将软件由当前版本升级到最新版本所需的所有差分升级包都保存之后， 还可以获取所保存的所有差分升级包的存储路径，并将每一差分升级包的存储路径按照每 一差分升级包的升级顺序依次进行排列。而且，由于在升级过程中缓存分区不会发生进行 升级，所以可以将获取的存储路径保存在缓存分区中。
[0022] 在本发明实施例中，假设获取到差分升级包V4-V3的存储路径为/cache/update/ V4-V3,获取到差分升级包V5-V4的存储路径为/caChe/update/V5-V4,则将这两个存储 路径进行排序，因为需要先根据差分升级包V4-V3进行升级，因此，将存储路径/cache/ update/V4_V3排在存储路径/cache/update/V5_V4之前，进一步地，也可以对存储路径 按照序号进行排序，比如，设置存储路径/caChe/update/V4-V3为序号1，设置存储路径/cache/update/V5_V4为序号2,进一步地，还可以将序号、差分升级包，差分升级包对应的 存储路径三者的对应关系作为数据表存储在设备中，如表1所示： 表1差分升级包及其存储路径对应关系表
当设备根据差分升级包对软件升级成功后，将该差分升级包对应的存储路径删除，也 就是说，在连续升级过程中的每次单包升级中，当设备根据差分升级包对软件升级成功后， 将该差分升级包对应的数据表中的记录删除。
[0023]S102、若否，从软件由当前版本升级到目标版本所需的所有差分升级包中，查找在 先版本与当前版本相同的差分升级包。其中，任意一个差分升级包只包含相邻两个版本的 升级信息。
[0024] 其中，当前版本是终端正在使用的版本，目标版本是终端在连续升级后预计达到 的版本。所有差分升级包包括从当前版本升级到目标版本所需的差分升级包。其中的每一 差分升级包都携带有两个版本号：在先版本号和在后版本号，其中，在先版本号用于指示该 差分升级包需要对哪一版本进行升级，在后版本号用于指示根据该差分升级包将终端升级 到哪一版本。所有差分升级包中一定有一个差分升级包的在先版本为当前版本，同时，也一 定有一个差分升级包的在后版本为目标版本。
[0025] 这里仍然以最新版本为目标版本为例进行说明。具体的，从终端获取终端当前使 用的版本的版本号，然后查找所有差分升级包中是否有在先版本号与终端的当前版本的版 本号相同的差分升级包，在确定有该差分升级包的情况下，将查找到的差分升级包确定为 在先版本与设备的当前版本相同的差分升级包。本实施例中的所有差分升级包就是V4-V3， V5-V4,而V4-V3的在先版本为V3,则在先版本与当前版本相同的差分升级包就可以确定为 V4-V3。可选地，步骤S102还可以为，查找所有差分升级包的存储路径中排序最靠前的差分 升级包。即，通过查找表1，存储路径中排序最靠前的差分升级包为V4-V3,因此，在连续升 级过程中的第一个单包升级过程中，可以确定V4-V3是与当前版本相同的差分升级包，当 将软件从V3升级到V4之后，将V4-V3对应的存储路径删除，则排序最靠前的差分升级包就 变为V5-V4,则在根据V5-V4进行单包升级时，就将V5-V4确定为查找到的、与当前版本相同 的差分升级包。当将软件由V4升级到V5之后，将V5-V4对应的存储路径删除，直至存储路 径为空，即表1的数据记录为空。
[0026] 进一步地，在执行步骤S101时，判断软件的当前版本是否是目标版本，还可以通 过判断所有差分升级包的存储路径是否为空，如果存储路径为空，则说明终端的软件已经 升级到了目标版本。
[0027]S103 :将查找到的差分升级包中的补丁包打到当前版本的system分区中。
[0028] 本实施例中，经过步骤102,查找到在先版本与当前版本V3相同的差分升级包，即 差分升级包V4-V3时，将V4-V3中的补丁包，即V4版本的boot分区和V4版本的recovery 分区的差分包，打到V3版本的system分区中。
[0029]S104、检测是否需要对当前版本的recovery分区进行升级。
[0030] 经过前述的步骤S102之后，在连续升级过程的第一个单包升级中，本实施例已 经确定了查找到的差分升级包为V4-V3,则在步骤S104中，检测是否需要对当前版本的 recovery分区进行升级，检测的过程是通过执行升级脚本来实现的，需要说明的是，在制 作差分升级包的同时，要制作升级脚本，该升级脚本是在进入recovery模式后，由运行 的recovery服务来执行的。在连续升级的每个单包升级过程中，如果升级后的版本的 recovery分区相对于升级前的recovery分区有修改，也就是说，如果差分升级包的在后版 本的recovery分区相对于在先版本的recovery分区有修改，则会在所制作的升级脚本中， 增加指示升级recovery分区的执行过程，因此，在recovery服务执行升级脚本的过程中， 如果在升级脚本中有指示升级recovery的执行过程，则步骤S104的检测结果就可确定为 要对当前版本的recovery分区进行升级。相反地，如果在recovery服务执行升级脚本的 过程中，发现升级脚本中没有指示升级recovery分区的执行过程，则检测结果就可确定为 不需要对当前版本的recovery分区进行升级。应用在本实施例中，如果检测结果为需要对 当前版本V3的recovery分区进行升级，则执行步骤S105 :重启所述当前版本的recovery 分区，挂载升级后的sys tem分区，以便将所述升级后的system分区中的补丁包打到所述 recovery分区，实现对所述当前版本的recovery分区的升级。具体应用在根据差分升级 包V4-V3对当前版本V3升级时表现为：重启当前版本V3的recovery分区，在重启时，执 行recovery分区的init进程，由于一方面，本发明实施例相比于现有技术来说，在init进 程中增加了挂载system分区的步骤，那么，在执行V3的init进程时，就能够挂载已经升级 到V4版本的system分区，另一方面，本发明实施例相比于现有技术，在init进程中还增 加了用于升级recovery分区的服务，那么，在挂载升级后的system分区之后，通过执行该 用于升级recovery分区的服务，实现将升级后的system分区中的patch文件打到V3的 recovery分区中，进而在不需要对差分升级包V4-V3做出任何处理的情况下，实现V3版本 的recovery分区的升级。如果还需对boot分区等其他分区进行升级，则还需执行其他分 区的升级，最终完成将当前版本升级到查找到的差分升级包对应的在后版本。当软件版本 由V3升级到V4之后，再回到步骤S101，判断升级后的V4版本是否为目标版本V5,结果为 否，则再执行上述步骤，直至将软件版本升级至V5。
[0031] 在升级后的版本与升级前的版本的recovery分区有修改的情况下，本实施例 中的recovery分区的init进程不同于现有技术的init进程，在这种情况下，本实施例 中的recovery分区中的init进程包含了挂载升级后的system分区的步骤和用于升级 recovery分区的服务，在recovery分区有修改的情况下，先对system分区进行升级，再对 recovery分区进行升级，当然，如果boot分区等其他分区需要升级的话，也要对其他分区 进行升级。比如，如本发明实施例所述，需要将软件版本由V3升级到V4,再由V4升级到V5， 则先将V3的system分区升级到V4,再将V3的recovery分区升级到V4,这样，再根据差分 升级包V5-V4进行升级的时候，就可以在V4的recovery分区的基础上执行，就不会出现现 有技术中存在的当V4的recovery分区有修改的时候，在根据差分升级包V5-V4升级的时 候，仍然用版本V3的recovery分区升级，而导致的根据V5-V4升级失败的问题。
[0032] 综上，本发明实施例不对差分升级包做任何处理，而是在recovery分区的init进 程中增加了挂载system分区的步骤和用于升级recovery分区的服务，使得在保持差分升 级包占用服务器的存储空间较小，以及下载差分升级包时节省流量的情况下，实现了软件 版本的连续升级。
[0033] 在进行一次单包升级之后，即在本实施例中，完成软件版本从V3升级到V4之后， 返回到步骤S101，继续判断软件的当前版本是否是目标版本。在本实施例中，目标版本为V5,所以此时的当前版本V4仍然不是目标版本，所以继续执行步骤S102、S103、S104、S105， 直至将软件版本升级到目标版本V5。
[0034] 其中，终端的当前版本是终端当前使用的版本，终端的当前版本在连续升级的过 程中根据升级后的新版本动态变化。在终端成功进行连续升级后，终端的当前版本就是目 标版本。
[0035] 需要说明的是，由于所有差分升级包中包含从当前版本升级到目标版本所需的所 有差分升级包，各升级包的版本号是连续的，从所有差分升级包中依次查找到的差分升级 包，就是将终端从当前版本升级至目标版本依次所需的升级包。需要说明的是，若能够查找 到在先版本与当前版本相同的差分升级包，则说明终端的当前版本还不是目标版本，所以 终端还需要继续升级；若不能够查找到在先版本与当前版本相同的差分升级包，则说明终 端的当前版本就是目标版本，此时连续升级完毕。
[0036] 需要说明的是，终端在连续升级的过程中，可能某一次的单包升级发生升级失败， 那么就可能导致连续升级的失败。为了避免其中一次单包升级失败后，影响终端继续升级， 所以在每一单包升级之后，还可以加入检测步骤，检测此次升级是否成功，在单包升级成功 的情况下，才进行下一个单包升级在单包升级失败的情况下，可以提示用户升级失败，不执 行之后的升级。
[0037] 综上，本发明实施例提供了一种连续升级的方法，首先对设备当前软件的版本是 否是目标版本进行判断，如果不是目标版本，则从该软件由当前版本升级到目标版本所需 的所有差分升级包中，查找在先版本与当前版本相同的差分升级包，查找到该差分升级包 之后，将该差分升级包中的补丁包打到当前版本的system分区中，然后，检测是否需要对 当前版本的recovery分区进行升级，如果需要，则重启当前版本的recovery分区，挂载升 级后的system分区，将升级后的system分区中的补丁包打到当前版本的recovery分区， 实现对当前版本的recovery分区的升级。如果还需要对boot分区等其他分区进行升级， 则还要对其他分区进行升级，经过上述步骤，将当前版本升级到查找到的差分升级包所对 应的在后版本，实现连续升级方式中的一个单包升级，升级之后，再对当前版本是否是目标 版本进行判断，如果不是目标版本，则重复上述过程，直至将当前版本升级到目标版本，则 终止升级过程。
[0038] 与现有技术中recovery分区的升级通常是在软件的当前版本升级到目标版本之 后，再对软件的recovery分区进行升级，使得recovery分区的版本与目标版本相匹配的过 程不同，在上述的升级过程中，首先将查找到的差分升级包中的补丁包打到system分区， 实现对system分区的升级，当升级后版本的recovery分区相对于升级前版本的recovery 分区有修改时，重启recovery分区，加载前述升级后的system分区，因为加载了升级后 的system分区，所以可以通过执行升级recovery分区的服务，将升级后的system分区中 的patch文件打到recovery分区中，实现当前版本的recovery分区的升级，综上，由于每 一次的单包升级都对是否需要对当前版本的recovery分区是否升级进行判断，在需要对 当前版本的recovery分区进行升级的情况下，通过加载system分区，实现对recovery分 区的升级，这样，不需要对差分升级包做任何处理，下一次的单包升级就能在上一个单包升 级后的recovery分区的基础上进行，而recovery分区中包含了控制单包升级的升级流程 的函数，所以本发明中，原始版本(连续升级前的版本）和目标版本之间的任一中间版本的 recovery分区的修改都能带入下一个差分升级包的升级，进而，即使中间版本的recovery 分区做了修改，也不会影响下一个差分升级包的升级流程，使得连续升级过程可以顺利进 行，从而避免了现有技术中所容易出现的每次升级过程中由recovery分区的更改所导致 的下一次单包升级的失败，提高了连续升级的成功率。
[0039] 基于同样的发明构思，本发明实施例还提供了一种连续升级装置，该连续升级装 置可以是具备安卓系统的手机、电视或者机顶盒等设备。如图2所示，装置包括：判断单元 201，用于判断软件的当前版本是否是目标版本，并将判断结果发送给查找单元；查找单元 202,用于若接收到的所述判断单元201发送的所述判断结果为否，从所述软件由所述当前 版本升级到所述目标版本所需的所有差分升级包中，查找在先版本与所述当前版本相同的 差分升级包；其中，任意一个差分升级包只包含相邻两个版本的升级信息；升级system分 区单元203,用于将查找到的差分升级包中的补丁包打到所述当前版本的system分区；检 测单元204,用于检测是否需要对所述当前版本的recovery分区进行升级，并将检测结果 发送给升级recovery分区单元205 ;升级recovery分区单元205,用于若接收到的所述 检测单元204发送的检测结果为是，则重启所述当前版本的recovery分区，挂载升级后的 system分区，将所述升级后的system分区中的补丁包打到所述recovery分区，实现对所述 当前版本的recovery分区的升级。
[0040] 可选地，本发明实施例中的装置还包括获取存储路径单元，用于获取所有差分升 级包的存储路径，并将每一差分升级包的存储路径按照每一差分升级包的升级顺序依次进 行排列； 可选地，查找单元可以具体用于查找所有差分升级包的存储路径中排序最靠前的差分 升级包。
[0041] 可选地，该装置还包括删除单元，用于在升级recovery分区单元对当前版本的 recovery分区进行升级之后，删除存储路径中排序最靠前的差分升级包的存储路径。
[0042] 可选地，判断单元可以具体用于判断所有差分升级包的存储路径是否为空。
[0043] 综上，本发明实施例提供了一种连续升级的装置，首先对设备当前软件的版本是 否是目标版本进行判断，如果不是目标版本，则从该软件由当前版本升级到目标版本所需 的所有差分升级包中，查找在先版本与当前版本相同的差分升级包，查找到该差分升级包 之后，将该差分升级包中的补丁包打到当前版本的system分区中，然后，检测是否需要对 当前版本的recovery分区进行升级，如果需要，则重启当前 版本的recovery分区，挂载升 级后的system分区，将升级后的system分区中的补丁包打到当前版本的recovery分区， 实现对当前版本的recovery分区的升级。如果还需要对boot分区等其他分区进行升级， 则还要对其他分区进行升级，经过上述步骤，将当前版本升级到查找到的差分升级包所对 应的在后版本，实现连续升级方式中的一个单包升级，升级之后，再对当前版本是否是目标 版本进行判断，如果不是目标版本，则重复上述过程，直至将当前版本升级到目标版本，则 终止升级过程。
[0044] 与现有技术中recovery分区的升级通常是在软件的当前版本升级到目标版本之 后，再对软件的recovery分区进行升级，使得recovery分区的版本与目标版本相匹配的过 程不同，在上述的升级过程中，首先将查找到的差分升级包中的补丁包打到system分区， 实现对system分区的升级，当升级后版本的recovery分区相对于升级前版本的recovery 分区有修改时，重启recovery分区，加载前述升级后的system分区，因为加载了升级后 的system分区，所以可以通过执行升级recovery分区的服务，将升级后的system分区中 的patch文件打到recovery分区中，实现当前版本的recovery分区的升级，综上，由于每 一次的单包升级都对是否需要对当前版本的recovery分区是否升级进行判断，在需要对 当前版本的recovery分区进行升级的情况下，通过加载system分区，实现对recovery分 区的升级，这样，不需要对差分升级包做任何处理，下一次的单包升级就能在上一个单包升 级后的recovery分区的基础上进行，而recovery分区中包含了控制单包升级的升级流程 的函数，所以本发明中，原始版本(连续升级前的版本）和目标版本之间的任一中间版本的 recovery分区的修改都能带入下一个差分升级包的升级，进而，即使中间版本的recovery 分区做了修改，也不会影响下一个差分升级包的升级流程，使得连续升级过程可以顺利进 行，从而避免了现有技术中所容易出现的每次升级过程中由recovery分区的更改所导致 的下一次单包升级的失败，提高了连续升级的成功率。
[0045] 在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以 通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分， 仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以 结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论 的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或 通信连接，可以是电性，机械或其它的形式。
[0046] 作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的 部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络 单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。 [0047]另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以 是各个单元单独物理包括，也可以两个或两个以上单元集成在一个单元中。上述集成的单 元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
[0048] 上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存 储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机 设备(可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例方法的部分步 骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（Read-OnlyMemory，简称R0M)、随 机存取存储器（RandomAccessMemory，简称RAM)、磁碟或者光盘等各种可以存储程序代码 的介质。
[0049] 最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽 管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然 可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替 换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精 神和范围。
【主权项】
1. 一种连续升级的方法，其特征在于，包括： 判断软件的当前版本是否是目标版本； 若否，从所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包中，查 找在先版本与所述当前版本相同的差分升级包；其中，任意一个差分升级包只包含相邻两 个版本的升级信息； 将查找到的差分升级包中的补丁包打到所述当前版本的system分区中； 检测是否需要对所述当前版本的recovery分区进行升级； 若是，则重启所述当前版本的recovery分区，挂载升级后的system分区，将所述升级 后的system分区中的补丁包打到所述recovery分区，实现对所述当前版本的recovery分 区的升级。2. 如权利要求1所述的方法，其特征在于，所述判断软件的当前版本是否是目标版本 之前，还包括： 检测所述软件的所述当前版本是否低于服务器端相应的目标版本； 若是，则从所述服务器端获取所述软件由所述当前版本升级到所述目标版本所需的所 有差分升级包并保存。3.如权利要求1所述的方法，其特征在于，所述从所述软件由所述当前版本升级到所 述目标版本所需的所有差分升级包中，查找在先版本与所述当前版本相同的差分升级包之 前，还包括： 获取所述所有差分升级包的存储路径，并将每一差分升级包的存储路径按照每一差分 升级包的升级顺序依次进行排列； 所述查找在先版本与所述当前版本相同的差分升级包具体包括： 查找所述所有差分升级包的存储路径中排序最靠前的差分升级包。4.如权利要求3所述的方法，其特征在于，所述实现对所述当前版本的recovery分区 的升级之后还包括： 删除所述存储路径中排序最靠前的差分升级包的存储路径。5.如权利要求3或4所述的方法，其特征在于，所述判断软件的当前版本是否是目标版 本还可以为： 判断所述所有差分升级包的存储路径是否为空。6. 如权利要求2所述的方法，其特征在于，所述从服务器端获取所述软件由所述当前 版本升级到所述目标版本所需的所有差分升级包并保存之前，还包括： 判断是否支持连续升级； 若是，则从所述服务器端获取所述软件由所述当前版本升级到所述目标版本所需的所 有差分升级包并保存。7. -种连续升级装置，其特征在于，包括： 判断单元，用于判断软件的当前版本是否是目标版本，并将判断结果发送给查找单 元； 查找单元，用于若接收到的所述判断单元发送的所述判断结果为否，从所述软件由所 述当前版本升级到所述目标版本所需的所有差分升级包中，查找在先版本与所述当前版本 相同的差分升级包；其中，任意一个差分升级包只包含相邻两个版本的升级信息； 升级system分区单元，用于将查找到的差分升级包中的补丁包打到所述当前版本的system分区； 检测单元，用于检测是否需要对所述当前版本的recovery分区进行升级，并将检测结 果发送给升级recovery分区单元； 升级recovery分区单元，用于若接收到的所述检测单元发送的检测结果为是，则重启 所述当前版本的recovery分区，挂载升级后的system分区，将所述升级后的system分区 中的补丁包打到所述recovery分区，实现对所述当前版本的recovery分区的升级。8. 如权利要求7所述的装置，其特征在于，所述装置还包括： 获取存储路径单元，用于获取所述所有差分升级包的存储路径，并将每一差分升级包 的存储路径按照每一差分升级包的升级顺序依次进行排列； 所述查找单元具体用于查找所述所有差分升级包的存储路径中排序最靠前的差分升 级包。9. 如权利要求8所述的装置，其特征在于，所述装置还包括： 删除单元，用于在所述升级recovery分区单元对所述当前版本的recovery分区进行 升级之后，删除所述存储路径中排序最靠前的差分升级包的存储路径。10. 如权利要求8或9所述的装置，其特征在于，所述判断单元具体用于判断所述所有 差分升级包的存储路径是否为空。
【专利摘要】本发明实施例提供了一种连续升级的方法及装置,涉及软件升级领域，用以解决由于中间软件版本的recovery分区的修改所导致的后续连续升级失败的问题。该方法包括：判断软件的当前版本是否是目标版本；若否，从软件由当前版本升级到目标版本所需的所有差分升级包中，查找在先版本与当前版本相同的差分升级包；其中，任意一个差分升级包只包含相邻两个版本的升级信息；将查找到的差分升级包中的补丁包打到当前版本的system分区中；检测是否需要对当前版本的recovery分区进行升级；若是，则重启当前版本的recovery分区，挂载升级后的system分区，将升级后的system分区中的补丁包打到recovery分区，实现对当前版本的recovery分区的升级。
【IPC分类】G06F9/445
【公开号】CN104899066
【申请号】CN201510343541
【发明人】朱晓亮, 杨楠楠
【申请人】青岛海信移动通信技术股份有限公司
【公开日】2015年9月9日
【申请日】2015年6月19日
【技术领域】
[0001] 本发明涉及软件升级领域，尤其涉及一种连续升级的方法及装置。
【背景技术】
[0002]目前的软件版本升级一般通过下载服务器端提供的、针对客户端当前软件版本的 差分升级包，并将差分升级包通过打补丁的方式更新到当前软件版本中，实现客户端软件 版本的升级。
[0003] 为了实现将当前版本一次性升级到目标版本，目前采取的一种实现方式为：在服 务器端配置各个版本到目标版本的差分升级包，例如，目前目标版本由V4升级到了V5,则 在服务器端已有￥2，1，￥3，1，￥3,2，￥4，1，￥4,2，￥4,3差分升级包的基础上，增加配 置V5-V1，V5-V2,V5-V3,V5-V4这四个差分升级包，从而各个版本的用户通过下载对应的差 分升级包，就能实现一步到位的升级，但是这种方式需要在服务器端制作n(n-1)/2个差分 文件升级包，进一步地，为了减少服务器端的差分升级包的数量，目前还存在另一种实现方 式，也称为连续升级方式，具体为：在服务器端配置相邻两个版本的差分升级包，比如依然 假设目标版本由V4升级到了V5,在这种实现方式中，在服务器端已有V2-V1，V3-V2,V4-V3 差分升级包的基础上，只需增加配置V5-V4这一个差分升级包。在升级时，客户端下载软件 版本升级所需的所有差分升级包，并根据各个差分升级包的升级顺序逐步对软件版本进行 升级即可。比如，假设客户端当前的软件版本是V3,则需从服务器端下载V4-V3,V5-V4这 两个差分升级包，并根据V4-V3将软件升级到V4,之后再根据V5-V4将版本从V4升级到V5 即可。
[0004] 软件版本升级的过程通常涉及多个分区，包括：b〇〇t分区（引导分区)、recovery 分区(恢复分区)、system分区（系统分区）等。对于上述的连续升级方式，客户端的软件版 本从V3升级到V4的过程中，首先将V4-V3差分升级包中的patch文件(该patch文件为V4 版本的boot分区和V4版本的recovery分区的差分文件）打到system分区中，完成V3到 V4的升级，之后，再将V5-V4差分升级包中的patch文件（该patch文件为V5版本的boot 分区和V5版本的recovery分区的差分文件）打到system分区中，完成V5-V4的升级，此 时，实现了将软件版本从V3升级到了V5,然后，启动主系统的开机流程，将system分区中 的patch文件打到recovery分区中，实现对recovery分区的升级。但是，如果V4-V3的差 分升级包中对recovery分区进行了修改，并且这个修改影响到V5-V4的升级，从上面的描 述，可以知道recovery分区的升级修改只有在升级到目标版本后，启动主系统的开机流程 时，才将system中的patch文件打到recovery分区中实现对recovery分区的升级，也就 是说，在V4-V3的升级过程中，是不对recovery分区进行升级的，因此，这种情况下，V5-V4 的差分升级包就会升级失败。
[0005] 综上，在现有的连续升级方式中，如果在当前版本升级到目标版本的过程中，某个 中间版本的recovery分区进行了修改，且这个修改影响下一个差分升级包的升级时，修改 后的recovery分区并不能带入下一个差分升级包的升级，导致之后的升级过程无法继续 进行，最终导致连续升级失败。
【发明内容】
[0006] 本发明的实施例提供一种连续升级的方法及装置，实现了在连续升级过程中，下 一次的单包升级都能在上一次单包升级中升级后的recovery分区中执行升级，解决了由 于在原始版本(连续升级前的版本）和目标版本之间的任一中间软件版本的recovery分区 的修改，所导致的后续连续升级失败的问题。
[0007] 为达到上述目的，本发明的实施例采用如下技术方案： 一方面，本发明实施例提供了一种连续升级的方法，包括：判断软件的当前版本是否是 目标版本；若否，从所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包 中，查找在先版本与所述当前版本相同的差分升级包；其中，任意一个差分升级包只包含相 邻两个版本的升级信息；将查找到的差分升级包中的补丁包打到所述当前版本的system 分区中；检测是否需要对所述当前版本的recovery分区进行升级；若是，则重启所述当前 版本的recovery分区，挂载升级后的system分区，将所述升级后的system分区中的补丁 包打到所述recovery分区，实现对所述当前版本的recovery分区的升级。
[0008] 另一方面，本发明实施例提供了一种连续升级装置，包括：判断单元，用于判断软 件的当前版本是否是目标版本，并将判断结果发送给查找单元；查找单元，用于若接收到的 所述判断单元发送的所述判断结果为否，从所述软件由所述当前版本升级到所述目标版本 所需的所有差分升级包中，查找在先版本与所述当前版本相同的差分升级包；其中，任意一 个差分升级包只包含相邻两个版本的升级信息；升级system分区单元，用于将查找到的差 分升级包中的补丁包打到所述当前版本的system分区；检测单元，用于检测是否需要对所 述当前版本的recovery分区进行升级，并将检测结果发送给升级recovery分区单元；升级 recovery分区单元，用于若接收到的所述检测单元发送的检测结果为是，则重启所述当前 版本的recovery分区，挂载升级后的system分区，将所述升级后的system分区中的补丁 包打到所述recovery分区，实现对所述当前版本的recovery分区的升级。
[0009] 综上，本发明实施例提供了一种连续升级的方法及装置，首先对设备当前软件的 版本是否是目标版本进行判断，如果不是目标版本，则从该软件由当前版本升级到目标版 本所需的所有差分升级包中，查找在先版本与当前版本相同的差分升级包，查找到该差分 升级包之后，将该差分升级包中的补丁包打到当前版本的system分区中，然后，检测是否 需要对当前版本的recovery分区进行升级，如果需要，则重启当前版本的recovery分区， 挂载升级后的system分区，将升级后的system分区中的补丁包打到当前版本的recovery 分区，实现对当前版本的recovery分区的升级。如果还需要对boot分区等其他分区进行升 级，则还要对其他分区进行升级，经过上述步骤，将当前版本升级到查找到的差分升级包所 对应的在后版本，实现连续升级方式中的一个单包升级，升级之后，再对当前版本是否是目 标版本进行判断，如果不是目标版本，则重复上述过程，直至将当前版本升级到目标版本， 则终止升级过程。
[0010] 与现有技术中recovery分区的升级通常是在软件的当前版本升级到目标版本之 后，再对软件的recovery分区进行升级，使得recovery分区的版本与目标版本相匹配的过 程不同，在上述的升级过程中，首先将查找到的差分升级包中的补丁包打到system分区， 实现对system分区的升级，当升级后版本的recovery分区相对于升级前版本的recovery分区有修改时，重启recovery分区，加载前述升级后的system分区，因为加载了升级后 的system分区，所以可以通过执行升级recovery分区的服务，将升级后的system分区中 的patch文件打到recovery分区中，实现当前版本的recovery分区的升级，综上，由于每 一次的单包升级都对是否需要对当前版本的recovery分区是否升级进行判断，在需要对 当前版本的recovery分区进行升级的情况下，通过加载system分区，实现对recovery分 区的升级，这样，不需要对差分升级包做任何处理，下一次的单包升级就能在上一个单包升 级后的recovery分区的基础上进行，而recovery分区中包含了控制单包升级的升级流程 的函数，所以本发明中，原始版本(连续升级前的版本）和目标版本之间的任一中间版本的 recovery分区的修改都能带入下一个差分升级包的升级，进而，即使中间版本的recovery 分区做了修改，也不会影响下一个差分升级包的升级流程，使得连续升级过程可以顺利进 行，从而避免了现有技术中所容易出现的每次升级过程中由recovery分区的更改所导致 的下一次单包升级的失败，提高了连续升级的成功率。
【附图说明】
[0011] 为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中 所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实 施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图 获得其他的附图。
[0012] 图1为本发明实施例提供的一种连续升级的方法的流程示意图； 图2为本发明实施例提供的一种连续升级的装置的功能示意图。
【具体实施方式】
[0013] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完 整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于 本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他 实施例，都属于本发明保护的范围。
[0014] 本发明实施例提供了一种连续升级的方法，如图1所示， 包括： S101、判断软件的当前版本是否是目标版本； 需要说明的是，这里的目标版本可以是服务器端存储的最新版本，也可以不是服务器 端存储的最新版本，只要目标版本高于终端的当前版本即可。比如，假设最新版本为V5,终 端的当前版本为V3,但是在升级流程中，增加了当电量低于30%的时候，停止升级的条件， 如果当终端从V3升级到了V4之后，电量就满足了低于30%的条件，那么，此时的目标版本 就是V4。再比如，在用户选择并执行了升级操作之后，可以在终端的用户界面上给出当前可 升级的版本信息，比如，给出"升级到V4"以及"升级到V5"的两个选项，当用户选择"升级 到V4"的选项时，目标版本为V4,当用户选择"升级到V5"的选项时，目标版本就为最新版 本V5〇
[0015] 具体实现时，在这一步骤之前还包括步骤：检测软件的当前版本是否低于服务器 端相应的目标版本；若低于，则从服务器端获取软件由当前版本升级到目标版本所需的所 有差分升级包并保存。检测过程可以是终端首先向服务器发送携带有当前版本的请求消 息，该请求消息可以携带目标版本的信息，也可以不携带目标版本的信息，当请求消息不携 带有目标版本的信息时，服务器端可以默认该终端升级到最新版本，当然服务器也可以通 过判断终端的实时电量，来判断得出目标版本，本实施例以终端由当前版本升级到最新版 本为例进行说明。
[0016] 服务器根据请求消息获得终端的当前版本，并将该当前版本与服务器上存储的最 新版本做比较，如果发现该当前版本与最新版本相同，则向终端发送当前版本已经是最新 版本的响应消息，终端接收到该响应消息后，在一定时间内，不再向服务器发送请求消息， 当然也不执行任何升级操作；如果服务器经过比较后，发现该当前版本低于最新版本，则向 终端发送携带有最新版本的响应消息，终端接收到该响应消息后，确定系统的当前版本不 是最新版本，或者服务器端也可以将该终端的软件由当前版本升级到最新版本所需的所有 差分升级包发送给终端作为响应消息，终端接收到服务器发送的所有差分升级包后，确定 软件的当前版本不是最新版本。
[0017] 可选地，当服务器端将终端由当前版本升级到最新版本所需的所有差分升级包发 送给终端作为响应消息时，终端接收到服务器端发送的所有差分升级包之后，将所有差分 升级包保存在缓存中。或者，当服务器端向终端发送携带有最新版本的响应消息后，终端再 向服务器发送连续升级到最新版本的请求，服务器端接收到该请求后，将该终端由当前版 本升级到最新版本所需的所有差分升级包发送给终端。
[0018] 可选地，服务器端将终端由当前版本升级到最新版本所需的所有差分升级包发送 给终端作为响应消息，终端接收到服务器端发送的所有差分升级包之后，将所有差分升级 包保存在缓存之前，先对终端是否支持连续升级进行判断，具体的，终端可以设置标识位， 并根据该标识位，判断终端是否支持连续升级，或者服务器中存储有能够支持连续升级的 终端的产品型号，在获取到终端的产品型号的情况下，确定终端是否支持连续升级，如果确 定终端支持连续升级，则将从服务器端获取的所有差分升级包保存，如果确定终端不支持 连续升级，则忽略服务器端发送的差分升级包。
[0019] 同样地，服务器端向终端发送携带有最新版本的响应消息后，终端根据该响应消 息，向服务器发送连续升级到最新版本的请求之前，也先对终端是否支持连续升级进行判 断，如果确定终端支持连续升级，则终端向服务器端发送连续升级到最新版本的请求。
[0020] 在本实施例中，假设终端当前的软件版本为V3,服务器端存储的最新版本为V5， 则按照其中任一的实现方式，终端都可以从服务器端获取到由当前版本V3升级到最新版 本V5所需的V4-V3,V5-V4两个差分升级包，并将这两个差分升级包保存在/cache目录下。
[0021] 可选地，将软件由当前版本升级到最新版本所需的所有差分升级包都保存之后， 还可以获取所保存的所有差分升级包的存储路径，并将每一差分升级包的存储路径按照每 一差分升级包的升级顺序依次进行排列。而且，由于在升级过程中缓存分区不会发生进行 升级，所以可以将获取的存储路径保存在缓存分区中。
[0022] 在本发明实施例中，假设获取到差分升级包V4-V3的存储路径为/cache/update/ V4-V3,获取到差分升级包V5-V4的存储路径为/caChe/update/V5-V4,则将这两个存储 路径进行排序，因为需要先根据差分升级包V4-V3进行升级，因此，将存储路径/cache/ update/V4_V3排在存储路径/cache/update/V5_V4之前，进一步地，也可以对存储路径 按照序号进行排序，比如，设置存储路径/caChe/update/V4-V3为序号1，设置存储路径/cache/update/V5_V4为序号2,进一步地，还可以将序号、差分升级包，差分升级包对应的 存储路径三者的对应关系作为数据表存储在设备中，如表1所示： 表1差分升级包及其存储路径对应关系表
当设备根据差分升级包对软件升级成功后，将该差分升级包对应的存储路径删除，也 就是说，在连续升级过程中的每次单包升级中，当设备根据差分升级包对软件升级成功后， 将该差分升级包对应的数据表中的记录删除。
[0023]S102、若否，从软件由当前版本升级到目标版本所需的所有差分升级包中，查找在 先版本与当前版本相同的差分升级包。其中，任意一个差分升级包只包含相邻两个版本的 升级信息。
[0024] 其中，当前版本是终端正在使用的版本，目标版本是终端在连续升级后预计达到 的版本。所有差分升级包包括从当前版本升级到目标版本所需的差分升级包。其中的每一 差分升级包都携带有两个版本号：在先版本号和在后版本号，其中，在先版本号用于指示该 差分升级包需要对哪一版本进行升级，在后版本号用于指示根据该差分升级包将终端升级 到哪一版本。所有差分升级包中一定有一个差分升级包的在先版本为当前版本，同时，也一 定有一个差分升级包的在后版本为目标版本。
[0025] 这里仍然以最新版本为目标版本为例进行说明。具体的，从终端获取终端当前使 用的版本的版本号，然后查找所有差分升级包中是否有在先版本号与终端的当前版本的版 本号相同的差分升级包，在确定有该差分升级包的情况下，将查找到的差分升级包确定为 在先版本与设备的当前版本相同的差分升级包。本实施例中的所有差分升级包就是V4-V3， V5-V4,而V4-V3的在先版本为V3,则在先版本与当前版本相同的差分升级包就可以确定为 V4-V3。可选地，步骤S102还可以为，查找所有差分升级包的存储路径中排序最靠前的差分 升级包。即，通过查找表1，存储路径中排序最靠前的差分升级包为V4-V3,因此，在连续升 级过程中的第一个单包升级过程中，可以确定V4-V3是与当前版本相同的差分升级包，当 将软件从V3升级到V4之后，将V4-V3对应的存储路径删除，则排序最靠前的差分升级包就 变为V5-V4,则在根据V5-V4进行单包升级时，就将V5-V4确定为查找到的、与当前版本相同 的差分升级包。当将软件由V4升级到V5之后，将V5-V4对应的存储路径删除，直至存储路 径为空，即表1的数据记录为空。
[0026] 进一步地，在执行步骤S101时，判断软件的当前版本是否是目标版本，还可以通 过判断所有差分升级包的存储路径是否为空，如果存储路径为空，则说明终端的软件已经 升级到了目标版本。
[0027]S103 :将查找到的差分升级包中的补丁包打到当前版本的system分区中。
[0028] 本实施例中，经过步骤102,查找到在先版本与当前版本V3相同的差分升级包，即 差分升级包V4-V3时，将V4-V3中的补丁包，即V4版本的boot分区和V4版本的recovery 分区的差分包，打到V3版本的system分区中。
[0029]S104、检测是否需要对当前版本的recovery分区进行升级。
[0030] 经过前述的步骤S102之后，在连续升级过程的第一个单包升级中，本实施例已 经确定了查找到的差分升级包为V4-V3,则在步骤S104中，检测是否需要对当前版本的 recovery分区进行升级，检测的过程是通过执行升级脚本来实现的，需要说明的是，在制 作差分升级包的同时，要制作升级脚本，该升级脚本是在进入recovery模式后，由运行 的recovery服务来执行的。在连续升级的每个单包升级过程中，如果升级后的版本的 recovery分区相对于升级前的recovery分区有修改，也就是说，如果差分升级包的在后版 本的recovery分区相对于在先版本的recovery分区有修改，则会在所制作的升级脚本中， 增加指示升级recovery分区的执行过程，因此，在recovery服务执行升级脚本的过程中， 如果在升级脚本中有指示升级recovery的执行过程，则步骤S104的检测结果就可确定为 要对当前版本的recovery分区进行升级。相反地，如果在recovery服务执行升级脚本的 过程中，发现升级脚本中没有指示升级recovery分区的执行过程，则检测结果就可确定为 不需要对当前版本的recovery分区进行升级。应用在本实施例中，如果检测结果为需要对 当前版本V3的recovery分区进行升级，则执行步骤S105 :重启所述当前版本的recovery 分区，挂载升级后的sys tem分区，以便将所述升级后的system分区中的补丁包打到所述 recovery分区，实现对所述当前版本的recovery分区的升级。具体应用在根据差分升级 包V4-V3对当前版本V3升级时表现为：重启当前版本V3的recovery分区，在重启时，执 行recovery分区的init进程，由于一方面，本发明实施例相比于现有技术来说，在init进 程中增加了挂载system分区的步骤，那么，在执行V3的init进程时，就能够挂载已经升级 到V4版本的system分区，另一方面，本发明实施例相比于现有技术，在init进程中还增 加了用于升级recovery分区的服务，那么，在挂载升级后的system分区之后，通过执行该 用于升级recovery分区的服务，实现将升级后的system分区中的patch文件打到V3的 recovery分区中，进而在不需要对差分升级包V4-V3做出任何处理的情况下，实现V3版本 的recovery分区的升级。如果还需对boot分区等其他分区进行升级，则还需执行其他分 区的升级，最终完成将当前版本升级到查找到的差分升级包对应的在后版本。当软件版本 由V3升级到V4之后，再回到步骤S101，判断升级后的V4版本是否为目标版本V5,结果为 否，则再执行上述步骤，直至将软件版本升级至V5。
[0031] 在升级后的版本与升级前的版本的recovery分区有修改的情况下，本实施例 中的recovery分区的init进程不同于现有技术的init进程，在这种情况下，本实施例 中的recovery分区中的init进程包含了挂载升级后的system分区的步骤和用于升级 recovery分区的服务，在recovery分区有修改的情况下，先对system分区进行升级，再对 recovery分区进行升级，当然，如果boot分区等其他分区需要升级的话，也要对其他分区 进行升级。比如，如本发明实施例所述，需要将软件版本由V3升级到V4,再由V4升级到V5， 则先将V3的system分区升级到V4,再将V3的recovery分区升级到V4,这样，再根据差分 升级包V5-V4进行升级的时候，就可以在V4的recovery分区的基础上执行，就不会出现现 有技术中存在的当V4的recovery分区有修改的时候，在根据差分升级包V5-V4升级的时 候，仍然用版本V3的recovery分区升级，而导致的根据V5-V4升级失败的问题。
[0032] 综上，本发明实施例不对差分升级包做任何处理，而是在recovery分区的init进 程中增加了挂载system分区的步骤和用于升级recovery分区的服务，使得在保持差分升 级包占用服务器的存储空间较小，以及下载差分升级包时节省流量的情况下，实现了软件 版本的连续升级。
[0033] 在进行一次单包升级之后，即在本实施例中，完成软件版本从V3升级到V4之后， 返回到步骤S101，继续判断软件的当前版本是否是目标版本。在本实施例中，目标版本为V5,所以此时的当前版本V4仍然不是目标版本，所以继续执行步骤S102、S103、S104、S105， 直至将软件版本升级到目标版本V5。
[0034] 其中，终端的当前版本是终端当前使用的版本，终端的当前版本在连续升级的过 程中根据升级后的新版本动态变化。在终端成功进行连续升级后，终端的当前版本就是目 标版本。
[0035] 需要说明的是，由于所有差分升级包中包含从当前版本升级到目标版本所需的所 有差分升级包，各升级包的版本号是连续的，从所有差分升级包中依次查找到的差分升级 包，就是将终端从当前版本升级至目标版本依次所需的升级包。需要说明的是，若能够查找 到在先版本与当前版本相同的差分升级包，则说明终端的当前版本还不是目标版本，所以 终端还需要继续升级；若不能够查找到在先版本与当前版本相同的差分升级包，则说明终 端的当前版本就是目标版本，此时连续升级完毕。
[0036] 需要说明的是，终端在连续升级的过程中，可能某一次的单包升级发生升级失败， 那么就可能导致连续升级的失败。为了避免其中一次单包升级失败后，影响终端继续升级， 所以在每一单包升级之后，还可以加入检测步骤，检测此次升级是否成功，在单包升级成功 的情况下，才进行下一个单包升级在单包升级失败的情况下，可以提示用户升级失败，不执 行之后的升级。
[0037] 综上，本发明实施例提供了一种连续升级的方法，首先对设备当前软件的版本是 否是目标版本进行判断，如果不是目标版本，则从该软件由当前版本升级到目标版本所需 的所有差分升级包中，查找在先版本与当前版本相同的差分升级包，查找到该差分升级包 之后，将该差分升级包中的补丁包打到当前版本的system分区中，然后，检测是否需要对 当前版本的recovery分区进行升级，如果需要，则重启当前版本的recovery分区，挂载升 级后的system分区，将升级后的system分区中的补丁包打到当前版本的recovery分区， 实现对当前版本的recovery分区的升级。如果还需要对boot分区等其他分区进行升级， 则还要对其他分区进行升级，经过上述步骤，将当前版本升级到查找到的差分升级包所对 应的在后版本，实现连续升级方式中的一个单包升级，升级之后，再对当前版本是否是目标 版本进行判断，如果不是目标版本，则重复上述过程，直至将当前版本升级到目标版本，则 终止升级过程。
[0038] 与现有技术中recovery分区的升级通常是在软件的当前版本升级到目标版本之 后，再对软件的recovery分区进行升级，使得recovery分区的版本与目标版本相匹配的过 程不同，在上述的升级过程中，首先将查找到的差分升级包中的补丁包打到system分区， 实现对system分区的升级，当升级后版本的recovery分区相对于升级前版本的recovery 分区有修改时，重启recovery分区，加载前述升级后的system分区，因为加载了升级后 的system分区，所以可以通过执行升级recovery分区的服务，将升级后的system分区中 的patch文件打到recovery分区中，实现当前版本的recovery分区的升级，综上，由于每 一次的单包升级都对是否需要对当前版本的recovery分区是否升级进行判断，在需要对 当前版本的recovery分区进行升级的情况下，通过加载system分区，实现对recovery分 区的升级，这样，不需要对差分升级包做任何处理，下一次的单包升级就能在上一个单包升 级后的recovery分区的基础上进行，而recovery分区中包含了控制单包升级的升级流程 的函数，所以本发明中，原始版本(连续升级前的版本）和目标版本之间的任一中间版本的 recovery分区的修改都能带入下一个差分升级包的升级，进而，即使中间版本的recovery 分区做了修改，也不会影响下一个差分升级包的升级流程，使得连续升级过程可以顺利进 行，从而避免了现有技术中所容易出现的每次升级过程中由recovery分区的更改所导致 的下一次单包升级的失败，提高了连续升级的成功率。
[0039] 基于同样的发明构思，本发明实施例还提供了一种连续升级装置，该连续升级装 置可以是具备安卓系统的手机、电视或者机顶盒等设备。如图2所示，装置包括：判断单元 201，用于判断软件的当前版本是否是目标版本，并将判断结果发送给查找单元；查找单元 202,用于若接收到的所述判断单元201发送的所述判断结果为否，从所述软件由所述当前 版本升级到所述目标版本所需的所有差分升级包中，查找在先版本与所述当前版本相同的 差分升级包；其中，任意一个差分升级包只包含相邻两个版本的升级信息；升级system分 区单元203,用于将查找到的差分升级包中的补丁包打到所述当前版本的system分区；检 测单元204,用于检测是否需要对所述当前版本的recovery分区进行升级，并将检测结果 发送给升级recovery分区单元205 ;升级recovery分区单元205,用于若接收到的所述 检测单元204发送的检测结果为是，则重启所述当前版本的recovery分区，挂载升级后的 system分区，将所述升级后的system分区中的补丁包打到所述recovery分区，实现对所述 当前版本的recovery分区的升级。
[0040] 可选地，本发明实施例中的装置还包括获取存储路径单元，用于获取所有差分升 级包的存储路径，并将每一差分升级包的存储路径按照每一差分升级包的升级顺序依次进 行排列； 可选地，查找单元可以具体用于查找所有差分升级包的存储路径中排序最靠前的差分 升级包。
[0041] 可选地，该装置还包括删除单元，用于在升级recovery分区单元对当前版本的 recovery分区进行升级之后，删除存储路径中排序最靠前的差分升级包的存储路径。
[0042] 可选地，判断单元可以具体用于判断所有差分升级包的存储路径是否为空。
[0043] 综上，本发明实施例提供了一种连续升级的装置，首先对设备当前软件的版本是 否是目标版本进行判断，如果不是目标版本，则从该软件由当前版本升级到目标版本所需 的所有差分升级包中，查找在先版本与当前版本相同的差分升级包，查找到该差分升级包 之后，将该差分升级包中的补丁包打到当前版本的system分区中，然后，检测是否需要对 当前版本的recovery分区进行升级，如果需要，则重启当前 版本的recovery分区，挂载升 级后的system分区，将升级后的system分区中的补丁包打到当前版本的recovery分区， 实现对当前版本的recovery分区的升级。如果还需要对boot分区等其他分区进行升级， 则还要对其他分区进行升级，经过上述步骤，将当前版本升级到查找到的差分升级包所对 应的在后版本，实现连续升级方式中的一个单包升级，升级之后，再对当前版本是否是目标 版本进行判断，如果不是目标版本，则重复上述过程，直至将当前版本升级到目标版本，则 终止升级过程。
[0044] 与现有技术中recovery分区的升级通常是在软件的当前版本升级到目标版本之 后，再对软件的recovery分区进行升级，使得recovery分区的版本与目标版本相匹配的过 程不同，在上述的升级过程中，首先将查找到的差分升级包中的补丁包打到system分区， 实现对system分区的升级，当升级后版本的recovery分区相对于升级前版本的recovery 分区有修改时，重启recovery分区，加载前述升级后的system分区，因为加载了升级后 的system分区，所以可以通过执行升级recovery分区的服务，将升级后的system分区中 的patch文件打到recovery分区中，实现当前版本的recovery分区的升级，综上，由于每 一次的单包升级都对是否需要对当前版本的recovery分区是否升级进行判断，在需要对 当前版本的recovery分区进行升级的情况下，通过加载system分区，实现对recovery分 区的升级，这样，不需要对差分升级包做任何处理，下一次的单包升级就能在上一个单包升 级后的recovery分区的基础上进行，而recovery分区中包含了控制单包升级的升级流程 的函数，所以本发明中，原始版本(连续升级前的版本）和目标版本之间的任一中间版本的 recovery分区的修改都能带入下一个差分升级包的升级，进而，即使中间版本的recovery 分区做了修改，也不会影响下一个差分升级包的升级流程，使得连续升级过程可以顺利进 行，从而避免了现有技术中所容易出现的每次升级过程中由recovery分区的更改所导致 的下一次单包升级的失败，提高了连续升级的成功率。
[0045] 在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以 通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分， 仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以 结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论 的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或 通信连接，可以是电性，机械或其它的形式。
[0046] 作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的 部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络 单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。 [0047]另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以 是各个单元单独物理包括，也可以两个或两个以上单元集成在一个单元中。上述集成的单 元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
[0048] 上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存 储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机 设备(可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例方法的部分步 骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（Read-OnlyMemory，简称R0M)、随 机存取存储器（RandomAccessMemory，简称RAM)、磁碟或者光盘等各种可以存储程序代码 的介质。
[0049] 最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽 管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然 可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替 换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精 神和范围。
【主权项】
1. 一种连续升级的方法，其特征在于，包括： 判断软件的当前版本是否是目标版本； 若否，从所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包中，查 找在先版本与所述当前版本相同的差分升级包；其中，任意一个差分升级包只包含相邻两 个版本的升级信息； 将查找到的差分升级包中的补丁包打到所述当前版本的system分区中； 检测是否需要对所述当前版本的recovery分区进行升级； 若是，则重启所述当前版本的recovery分区，挂载升级后的system分区，将所述升级 后的system分区中的补丁包打到所述recovery分区，实现对所述当前版本的recovery分 区的升级。2. 如权利要求1所述的方法，其特征在于，所述判断软件的当前版本是否是目标版本 之前，还包括： 检测所述软件的所述当前版本是否低于服务器端相应的目标版本； 若是，则从所述服务器端获取所述软件由所述当前版本升级到所述目标版本所需的所 有差分升级包并保存。3.如权利要求1所述的方法，其特征在于，所述从所述软件由所述当前版本升级到所 述目标版本所需的所有差分升级包中，查找在先版本与所述当前版本相同的差分升级包之 前，还包括： 获取所述所有差分升级包的存储路径，并将每一差分升级包的存储路径按照每一差分 升级包的升级顺序依次进行排列； 所述查找在先版本与所述当前版本相同的差分升级包具体包括： 查找所述所有差分升级包的存储路径中排序最靠前的差分升级包。4.如权利要求3所述的方法，其特征在于，所述实现对所述当前版本的recovery分区 的升级之后还包括： 删除所述存储路径中排序最靠前的差分升级包的存储路径。5.如权利要求3或4所述的方法，其特征在于，所述判断软件的当前版本是否是目标版 本还可以为： 判断所述所有差分升级包的存储路径是否为空。6. 如权利要求2所述的方法，其特征在于，所述从服务器端获取所述软件由所述当前 版本升级到所述目标版本所需的所有差分升级包并保存之前，还包括： 判断是否支持连续升级； 若是，则从所述服务器端获取所述软件由所述当前版本升级到所述目标版本所需的所 有差分升级包并保存。7. -种连续升级装置，其特征在于，包括： 判断单元，用于判断软件的当前版本是否是目标版本，并将判断结果发送给查找单 元； 查找单元，用于若接收到的所述判断单元发送的所述判断结果为否，从所述软件由所 述当前版本升级到所述目标版本所需的所有差分升级包中，查找在先版本与所述当前版本 相同的差分升级包；其中，任意一个差分升级包只包含相邻两个版本的升级信息； 升级system分区单元，用于将查找到的差分升级包中的补丁包打到所述当前版本的system分区； 检测单元，用于检测是否需要对所述当前版本的recovery分区进行升级，并将检测结 果发送给升级recovery分区单元； 升级recovery分区单元，用于若接收到的所述检测单元发送的检测结果为是，则重启 所述当前版本的recovery分区，挂载升级后的system分区，将所述升级后的system分区 中的补丁包打到所述recovery分区，实现对所述当前版本的recovery分区的升级。8. 如权利要求7所述的装置，其特征在于，所述装置还包括： 获取存储路径单元，用于获取所述所有差分升级包的存储路径，并将每一差分升级包 的存储路径按照每一差分升级包的升级顺序依次进行排列； 所述查找单元具体用于查找所述所有差分升级包的存储路径中排序最靠前的差分升 级包。9. 如权利要求8所述的装置，其特征在于，所述装置还包括： 删除单元，用于在所述升级recovery分区单元对所述当前版本的recovery分区进行 升级之后，删除所述存储路径中排序最靠前的差分升级包的存储路径。10. 如权利要求8或9所述的装置，其特征在于，所述判断单元具体用于判断所述所有 差分升级包的存储路径是否为空。
【专利摘要】本发明实施例提供了一种连续升级的方法及装置,涉及软件升级领域，用以解决由于中间软件版本的recovery分区的修改所导致的后续连续升级失败的问题。该方法包括：判断软件的当前版本是否是目标版本；若否，从软件由当前版本升级到目标版本所需的所有差分升级包中，查找在先版本与当前版本相同的差分升级包；其中，任意一个差分升级包只包含相邻两个版本的升级信息；将查找到的差分升级包中的补丁包打到当前版本的system分区中；检测是否需要对当前版本的recovery分区进行升级；若是，则重启当前版本的recovery分区，挂载升级后的system分区，将升级后的system分区中的补丁包打到recovery分区，实现对当前版本的recovery分区的升级。
【IPC分类】G06F9/445
【公开号】CN104899066
【申请号】CN201510343541
【发明人】朱晓亮, 杨楠楠
【申请人】青岛海信移动通信技术股份有限公司
【公开日】2015年9月9日
【申请日】2015年6月19日
最新回复(0)