CN104965736A - 一种连续升级的方法及装置 - Google Patents
一种连续升级的方法及装置 Download PDFInfo
- Publication number
- CN104965736A CN104965736A CN201510343007.8A CN201510343007A CN104965736A CN 104965736 A CN104965736 A CN 104965736A CN 201510343007 A CN201510343007 A CN 201510343007A CN 104965736 A CN104965736 A CN 104965736A
- Authority
- CN
- China
- Prior art keywords
- upgrading
- version
- current version
- subregion
- difference aku
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Landscapes
- Stored Programmes (AREA)
Abstract
本发明实施例提供了一种连续升级的方法及装置,涉及软件升级领域,用以解决由于中间软件版本的recovery分区的修改所导致的后续连续升级失败的问题。该方法包括:判断软件的当前版本是否是目标版本;若否,从软件由当前版本升级到目标版本所需的所有差分升级包中,查找在先版本与当前版本相同的差分升级包;其中,任意一个差分升级包只包含相邻两个版本的升级信息;检测是否需要对当前版本的recovery分区进行升级;若是,则根据查找到的差分升级包对当前版本的recovery分区进行升级,并将升级后的recovery分区加载到内存;根据查找到的差分升级包对当前版本的system分区进行升级。
Description
技术领域
本发明涉及软件升级领域,尤其涉及一种连续升级的方法及装置。
背景技术
目前的软件版本升级一般通过下载服务器端提供的、针对客户端当前软件版本的差分升级包,并将差分升级包通过打补丁的方式更新到当前软件版本中,实现客户端软件版本的升级。
为了实现将当前版本一次性升级到目标版本,目前采取的一种实现方式为:在服务器端配置各个版本到目标版本的差分升级包,例如,目前目标版本由V4升级到了V5,则在服务器端已有V2-V1,V3-V1,V3-V2, V4-V1, V4-V2, V4-V3差分升级包的基础上,增加配置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即可。
软件版本升级的过程通常涉及多个分区,包括:boot分区(引导分区)、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的差分升级包就会升级失败。
综上,在现有的连续升级方式中,如果在当前版本升级到目标版本的过程中,某个中间版本的recovery分区进行了修改,且这个修改影响下一个差分升级包的升级时,下一个差分升级包对应的单包升级并不能在修改后的recovery分区中进行,导致之后的升级过程无法继续进行,最终导致连续升级失败。
发明内容
本发明的实施例提供一种连续升级的方法及装置,实现了在连续升级过程的每次单包升级中,都能在最新的recovery分区中执行升级,解决了由于中间软件版本的recovery分区的修改所导致的后续连续升级失败的问题。
为达到上述目的,本发明的实施例采用如下技术方案:
一方面,本发明实施例提供了一种连续升级的方法,包括:
判断软件的当前版本是否是目标版本;若否,从所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包中,查找在先版本与所述当前版本相同的差分升级包;其中,任意一个差分升级包只包含相邻两个版本的升级信息;检测是否需要对所述当前版本的recovery分区进行升级;若是,则根据查找到的差分升级包对所述当前版本的recovery分区进行升级,并将升级后的recovery分区加载到内存;根据所述查找到的差分升级包对所述当前版本的system分区进行升级。
另一方面,本发明实施例提供了一种连续升级装置,包括:判断单元,用于判断软件的当前版本是否是目标版本,并将判断结果发送给查找单元;查找单元,用于若接收到的所述判断单元发送的所述判断结果为否,从所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包中,查找在先版本与所述当前版本相同的差分升级包;其中,任意一个差分升级包只包含相邻两个版本的升级信息;检测单元,用于检测是否需要对所述当前版本的recovery分区进行升级,并将检测结果发送给升级recovery分区单元;升级recovery分区单元,用于若接收到的所述检测单元发送的检测结果为是,则根据查找到的差分升级包对所述当前版本的recovery分区进行升级,并将升级后的recovery分区加载到内存;升级system分区单元,用于根据所述查找到的差分升级包对所述当前版本的system分区进行升级。
综上,本发明实施例提供了一种连续升级的方法及装置,首先对设备当前软件的版本是否是目标版本进行判断,如果不是目标版本,则从该软件由当前版本升级到目标版本所需的所有差分升级包中,查找在先版本与当前版本相同的差分升级包,然后,检测是否需要对当前版本的recovery分区进行升级,如果是,则根据查找到的差分升级包对当前版本的recovery分区进行升级,并将升级后的recovery分区加载到内存,之后,再根据前面所述的查找到的差分升级包对当前版本的system分区进行升级,即将补丁包打到system分区中,如果还需要对除system分区之外的其他分区进行升级,则还要对其他分区进行升级,以使得当前版本升级到差分升级包所对应的在后版本,实现连续升级方式中的一个单包升级,升级之后,再对当前版本是否是目标版本进行判断,如果不是目标版本,则重复上述过程,直至将当前版本升级到目标版本,则终止升级过程。
与现有技术中recovery分区的升级通常是在软件的当前版本升级到目标版本之后,再对软件的recovery分区进行升级,使得recovery分区的版本与目标版本相匹配的过程不同,在上述的升级过程中,当升级后的版本的recovery分区相对于升级前的版本的recovery分区有修改时,在差分升级包中增加了recovery分区文件(即recovery.img文件),每一次的单包升级都先对是否需要对当前版本的recovery分区是否升级进行判断,在需要对当前版本的recovery分区进行升级的情况下,根据差分升级包中的recovery分区文件对当前版本的recovery分区升级,然后再对system分区进行升级,这样,下一次的单包升级就能在升级后的recovery分区的基础上进行,而recovery分区中包含了控制单包升级的升级流程的函数,所以本发明中,即使原始版本(连续升级前的版本)和目标版本之间的任一中间版本的recovery分区做了修改,也不会影响下一个差分升级包的升级流程,使得连续升级过程可以顺利进行,从而避免了现有技术中所容易出现的每次升级过程中由recovery分区的更改所导致的下一次单包升级的失败,提高了连续升级的成功率。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种连续升级的方法的流程示意图;
图2为本发明实施例提供的另一种连续升级的方法的流程示意图;
图3为本发明实施例提供的一种连续升级的装置的功能示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例提供了一种连续升级的方法,如图1所示,包括:
S101、判断软件的当前版本是否是目标版本;
需要说明的是,这里的目标版本可以是服务器端存储的最新版本,也可以不是服务器端存储的最新版本,只要目标版本高于终端的当前版本即可。比如,假设最新版本为V5,终端的当前版本为V3,但是在升级流程中,增加了当电量低于30%的时候,停止升级的条件,如果当终端从V3升级到了V4之后,电量就满足了低于30%的条件,那么,此时的目标版本就是V4。再比如,在用户选择并执行了升级操作之后,可以在终端的用户界面上给出当前可升级的版本信息,比如,给出“升级到V4”以及“升级到V5”的两个选项,当用户选择“升级到V4”的选项时,目标版本为V4,当用户选择“升级到V5”的选项时,目标版本就为最新版本V5。
具体实现时,在这一步骤之前还包括步骤:检测软件的当前版本是否低于服务器端相应的目标版本;若低于,则从服务器端获取软件由当前版本升级到目标版本所需的所有差分升级包并保存。检测过程可以是终端首先向服务器发送携带有当前版本的请求消息,该请求消息可以携带目标版本的信息,也可以不携带目标版本的信息,当请求消息不携带有目标版本的信息时,服务器端可以默认该终端升级到最新版本,当然服务器也可以通过判断终端的实时电量,来判断得出目标版本,本实施例以终端由当前版本升级到最新版本为例进行说明。
服务器根据请求消息获得终端的当前版本,并将该当前版本与服务器上存储的最新版本做比较,如果发现该当前版本与最新版本相同,则向终端发送当前版本已经是最新版本的响应消息,终端接收到该响应消息后,在一定时间内,不再向服务器发送请求消息,当然也不执行任何升级操作;如果服务器经过比较后,发现该当前版本低于最新版本,则向终端发送携带有最新版本的响应消息,终端接收到该响应消息后,确定系统的当前版本不是最新版本,或者服务器端也可以将该终端的软件由当前版本升级到最新版本所需的所有差分升级包发送给终端作为响应消息,终端接收到服务器发送的所有差分升级包后,确定软件的当前版本不是最新版本。
可选地,当服务器端将终端由当前版本升级到最新版本所需的所有差分升级包发送给终端作为响应消息时,终端接收到服务器端发送的所有差分升级包之后,将所有差分升级包保存在缓存中。或者,当服务器端向终端发送携带有最新版本的响应消息后,终端再向服务器发送连续升级到最新版本的请求,服务器端接收到该请求后,将该终端由当前版本升级到最新版本所需的所有差分升级包发送给终端。
可选地,服务器端将终端由当前版本升级到最新版本所需的所有差分升级包发送给终端作为响应消息,终端接收到服务器端发送的所有差分升级包之后,将所有差分升级包保存在缓存之前,先对终端是否支持连续升级进行判断,具体的,终端可以设置标识位,并根据该标识位,判断终端是否支持连续升级,或者服务器中存储有能够支持连续升级的终端的产品型号,在获取到终端的产品型号的情况下,确定终端是否支持连续升级,如果确定终端支持连续升级,则将从服务器端获取的所有差分升级包保存,如果确定终端不支持连续升级,则忽略服务器端发送的差分升级包。
同样地,服务器端向终端发送携带有最新版本的响应消息后,终端根据该响应消息,向服务器发送连续升级到最新版本的请求之前,也先对终端是否支持连续升级进行判断,如果确定终端支持连续升级,则终端向服务器端发送连续升级到最新版本的请求。
在本实施例中,假设终端当前的软件版本为V3,服务器端存储的最新版本为V5,则按照其中任一的实现方式,终端都可以从服务器端获取到由当前版本V3升级到最新版本V5所需的V4-V3,V5-V4两个差分升级包,并将这两个差分升级包保存在/cache目录下。
可选地,将软件由当前版本升级到最新版本所需的所有差分升级包都保存之后,还可以获取所保存的所有差分升级包的存储路径,并将每一差分升级包的存储路径按照每一差分升级包的升级顺序依次进行排列。而且,由于在升级过程中缓存分区不会发生进行升级,所以可以将获取的存储路径保存在缓存分区中。
在本发明实施例中,假设获取到差分升级包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 差分升级包及其存储路径对应关系表
序号 | 差分升级包 | 存储路径 |
1 | V4-V3 | /cache/update/V4-V3 |
2 | V5-V4 | /cache/update/V5-V4 |
当设备根据差分升级包对软件升级成功后,将该差分升级包对应的存储路径删除,也就是说,在连续升级过程中的每次单包升级中,当设备根据差分升级包对软件升级成功后,将该差分升级包对应的数据表中的记录删除。
S102、若否,从软件由当前版本升级到目标版本所需的所有差分升级包中,查找在先版本与当前版本相同的差分升级包。其中,任意一个差分升级包只包含相邻两个版本的升级信息。
其中,当前版本是终端正在使用的版本,目标版本是终端在连续升级后预计达到的版本。所有差分升级包包括从当前版本升级到目标版本所需的差分升级包。其中的每一差分升级包都携带有两个版本号:在先版本号和在后版本号,其中,在先版本号用于指示该差分升级包需要对哪一版本进行升级,在后版本号用于指示根据该差分升级包将终端升级到哪一版本。所有差分升级包中一定有一个差分升级包的在先版本为当前版本,同时,也一定有一个差分升级包的在后版本为目标版本。
这里仍然以最新版本为目标版本为例进行说明。具体的,从终端获取终端当前使用的版本的版本号,然后查找所有差分升级包中是否有在先版本号与终端的当前版本的版本号相同的差分升级包,在确定有该差分升级包的情况下,将查找到的差分升级包确定为在先版本与设备的当前版本相同的差分升级包。本实施例中的所有差分升级包就是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的数据记录为空。
进一步地,在执行步骤S101时,判断软件的当前版本是否是目标版本,还可以通过判断所有差分升级包的存储路径是否为空,如果存储路径为空,则说明终端的软件已经升级到了目标版本。
S103、检测是否需要对当前版本的recovery分区进行升级。
经过前述的步骤S102之后,在连续升级过程的第一个单包升级中,本实施例已经确定了查找到的差分升级包为V4-V3,则在步骤S103中,检测是否需要对当前版本的recovery分区进行升级,检测的过程是通过执行升级脚本来实现的,需要说明的是,在制作差分升级包的同时,要制作升级脚本,该升级脚本是在进入recovery模式后,由运行的recovery服务来执行的。在连续升级的每个单包升级过程中,如果升级后的版本的recovery分区相对于升级前的recovery分区有修改,也就是说,如果差分升级包的在后版本的recovery分区相对于在先版本的recovery分区有修改,则会在所制作的升级脚本中,增加指示升级recovery分区的执行过程,因此,在recovery服务执行升级脚本的过程中,如果在升级脚本中有指示升级recovery的执行过程,则步骤S103的检测结果就可确定为要对当前版本的recovery分区进行升级。相反地,如果在recovery服务执行升级脚本的过程中,发现升级脚本中没有指示升级recovery分区的执行过程,则检测结果就可确定为不需要对当前版本的recovery分区进行升级。应用在本实施例中,如果检测结果为需要对当前版本V3的recovery分区进行升级,则执行步骤S104:根据查找到的差分升级包对当前版本的recovery分区进行升级,并将升级后的recovery分区进行升级。具体应用在根据差分升级包V4-V3对当前版本V3升级时表现为:从差分升级包V4-V3中获取到recovery.img文件,用获取到的recovery.img文件替代当前版本V3的recovery.img文件,实现当前版本V3的recovery分区的升级,之后,重启recovery分区,使得升级后的recovery分区加载到运行内存中。
可选地,在升级后的版本与升级前的版本的recovery分区有修改的情况下,本实施例中的差分升级包不同于现有技术的差分升级包,在这种情况下,本实施例中的差分升级包中包含了recovery.img文件,而且,在recovery.img文件被修改的情况下,先对recovery分区进行升级,再对system分区进行升级,当然,如果除system分区之外的其他分区需要升级的话,也要对其他分区进行升级。
可选地,因为在对recovery分区进行升级之后,需要对recovery分区进行重启,才能将升级后的recovery分区加载到运行内存中,而重启recovery后,recovery服务中的参数就会被清除,为了避免在连续升级过程中对recovery分区误重启,本发明实施例在对当前版本的recovery分区进行升级之后,在misc分区中设置recovery分区升级标识,在当前版本的recovery分区升级完成后,置位该升级标识。
可选地,这里所提到的置位recovery升级标识和复位recovery升级标识只是举例说明,在实际实现时,也可以在当前的recovery分区进行升级之后,对recovery升级标识复位或者清空,在这里不做限定。
可选地,recovery分区升级标识可以预先被初始化为复位状态。需要说明的是,初始化recovery分区升级标识为复位状态也只是具体说明,具体实现时,也可以初始化recovery分区升级标识为置位状态,这里同样不做具体限定。
当初始化recovery分区升级标识为复位状态时,当执行步骤S104之前,首先判断recovery分区升级标识是否为复位状态,如果是复位状态,说明当前版本的recovery分区还未进行升级,这个时候执行步骤S104;如果是置位状态,说明当前版本的recovery分区已经进行了升级,则继续执行步骤S105即可。
S105、根据查找到的差分升级包对当前版本的system分区进行升级。
经过步骤S104,当前版本的recovery分区已经是升级之后的recovery分区,因此,步骤S105就是在最新的recovery分区的基础上进行的升级。本实施例中,在最新的recovery分区基础上,根据V4-V3对当前版本V3的system分区进行升级。具体实现时,将差分升级包V4-V3中的patch文件打到system分区中,实现系统从版本V3升级到V4。当然,如果还需要对除system分区以外的分区进行升级,则在升级完system分区之后,还要对其他分区进行升级。
可选地,在执行步骤S105之前,先确定recovery分区升级标识是否被置位,当该升级标识被置位时,再将差分升级包V4-V3中的patch文件打到system分区中,实现系统从版本V3升级到V4。升级到V4之后,再对misc分区中的recovery分区升级标识复位,并在system分区升级完成时,置位system分区升级标识。
可选地,本实施例也可以初始化system分区升级标识为复位状态,同样,具体实现时,也可以初始化system分区升级标识为置位状态,这里不做具体限定。当初始化为复位状态时,在对当前的recovery分区升级完成后,对system分区升级前,对system分区升级标识是否为复位状态进行判断,如果是复位状态,在本实施例中,将V4-V3中的patch文件打到system分区中,实现将软件版本由V3升级到V4。升级之后,置位system分区升级标识,并对misc分区中的recovery分区升级标识复位。
需要说明的是,recovery分区升级标识和system分区升级标识也可以用一个升级标识进行表示,例如,用1bit表示升级标识,该升级标识为0时,用于指示升级recovery分区,当对recovery分区升级成功后,将该升级标识置为1,用于指示升级system分区。可选地,在根据查找到的差分升级包对当前版本的recovery分区进行升级之前,初始化该升级标识为0,那么连续升级的一个单包升级过程可以如图2所示,首先执行步骤S201:判断升级标识是否为0,若为0 ,则执行步骤2011:根据查找到的差分升级包对当前版本的recovery分区进行升级;之后,执行步骤2013:置位升级标识为1,最后执行步骤2015:重启recovery分区,以将升级后的recovery分区加载到内存;若升级标识为1,执行步骤2012:根据查找到的差分升级包对当前版本的system分区及其他分区进行升级,若在执行步骤2014之后,判断得知系统升级成功,且升级标识为1后,则执行步骤2016:复位升级标识为0。具体实现时,升级标识可以设置在misc分区中。
相应地,在本实施例中,当V4版本的recovery分区相对于V3版本的recovery分区有所修改时,则首先需要判断misc分区中的升级标识是否被复位或者是否为空,如果被复位或者为空,则升级V3版本的recovery分区,并在升级之后对misc分区中的升级标识置位,之后重启recovery分区。当对V3版本的system分区及其他分区进行升级时,首先判断misc分区中的升级标识是否被置位,若被置位,则对V3版本的system分区进行升级,并在升级之后清空或者复位misc分区中的升级标识,当将软件的版本由V3升级到V4之后,再根据差分升级包V5-V4进行升级时,也执行同样的过程,直至将软件版本升级到V5。
可选地,不管用一个升级标识表示升级recovery分区和system分区,还是分别用recovery升级标识表示升级recovery分区,用system分区升级标识表示升级system分区,都将升级标识存储在misc分区。
在进行一次单包升级之后,即在本实施例中,完成软件版本从V3升级到V4之后,返回到步骤S101,继续判断软件的当前版本是否是目标版本。在本实施例中,目标版本为V5,所以此时的当前版本V4仍然不是目标版本,所以继续执行步骤S102、S103、S104、S105,直至将软件版本升级到目标版本V5。
其中,终端的当前版本是终端当前使用的版本,终端的当前版本在连续升级的过程中根据升级后的新版本动态变化。在终端成功进行连续升级后,终端的当前版本就是目标版本。
需要说明的是,由于所有差分升级包中包含从当前版本升级到目标版本所需的所有差分升级包,各升级包的版本号是连续的,从所有差分升级包中依次查找到的差分升级包,就是将终端从当前版本升级至目标版本依次所需的升级包。需要说明的是,若能够查找到在先版本与当前版本相同的差分升级包,则说明终端的当前版本还不是目标版本,所以终端还需要继续升级;若不能够查找到在先版本与当前版本相同的差分升级包,则说明终端的当前版本就是目标版本,此时连续升级完毕。
需要说明的是,终端在连续升级的过程中,可能某一次的单包升级发生升级失败,那么就可能导致连续升级的失败。为了避免其中一次单包升级失败后,影响终端继续升级,所以在每一单包升级之后,还可以加入检测步骤,检测此次升级是否成功,在单包升级成功的情况下,才进行下一个单包升级在单包升级失败的情况下,可以提示用户升级失败,不执行之后的升级。
综上,本发明实施例提供了一种连续升级的方法,首先对设备当前软件的版本是否是目标版本进行判断,如果不是目标版本,则从该软件由当前版本升级到目标版本所需的所有差分升级包中,查找在先版本与当前版本相同的差分升级包,然后,检测是否需要对当前版本的recovery分区进行升级,如果是,则根据查找到的差分升级包对当前版本的recovery分区进行升级,并将升级后的recovery分区加载到内存,之后,再根据前面所述的查找到的差分升级包对当前版本的system分区进行升级,即将补丁包打到system分区中,实现连续升级方式中的一个单包升级,升级之后,再对当前版本是否是目标版本进行判断,如果不是目标版本,则重复上述过程,直至将当前版本升级到目标版本,则终止升级过程。
与现有技术中recovery分区的升级通常是在软件的当前版本升级到目标版本之后,再对软件的recovery分区进行升级,使得recovery分区的版本与目标版本相匹配的过程不同,在上述的升级过程中,当升级后的版本的recovery分区相对于升级前的版本的recovery分区有修改时,在差分升级包中增加了recovery分区文件,每一次的单包升级都先对是否需要对当前版本的recovery分区是否升级进行判断,在需要对当前版本的recovery分区进行升级的情况下,根据差分升级包中的recovery分区文件对当前版本的recovery分区升级,然后再对system分区进行升级,这样,下一次的单包升级就能在升级后的recovery分区的基础上进行,而recovery分区中包含了控制单包升级的升级流程的函数,所以本发明中,即使中间版本的recovery分区做了修改,也不会影响下一个差分升级包的升级流程,使得连续升级过程可以顺利进行,从而避免了现有技术中所容易出现的每次升级过程中由recovery分区的更改所导致的下一次单包升级的失败,提高了连续升级的成功率。
基于同样的发明构思,本发明实施例还提供了一种连续升级装置,该连续升级装置可以是具备安卓系统的手机、电视或者机顶盒等设备。如图3所示,装置包括:判断单元301,用于判断软件的当前版本是否是目标版本,并将判断结果发送给查找单元302;查找单元,用于若接收到的判断单元301发送的判断结果为否,从软件由当前版本升级到目标版本所需的所有差分升级包中,查找在先版本与当前版本相同的差分升级包;其中,任意一个差分升级包只包含相邻两个版本的升级信息;检测单元303,用于检测是否需要对所述当前版本的recovery分区进行升级,并将检测结果发送给升级recovery分区单元304;升级recovery分区单元304,用于若接收到的检测单元303发送的检测结果为是,则根据查找到的差分升级包对所述当前版本的recovery分区进行升级,并将升级后的recovery分区加载到内存;升级system分区单元305,用于根据查找到的差分升级包对当前版本的system分区进行升级。如果还需要对system分区之外的其他分区进行升级,则升级system分区单元还要对其他分区进行升级。
综上,本发明实施例提供了一种连续升级的装置,首先对设备当前软件的版本是否是目标版本进行判断,如果不是目标版本,则从该软件由当前版本升级到目标版本所需的所有差分升级包中,查找在先版本与当前版本相同的差分升级包,然后,检测是否需要对当前版本的recovery分区进行升级,如果是,则根据查找到的差分升级包对当前版本的recovery分区进行升级,并将升级后的recovery分区加载到内存,之后,再根据前面所述的查找到的差分升级包对当前版本的system分区进行升级,即将补丁包打到system分区中,实现连续升级方式中的一个单包升级,升级之后,再对当前版本是否是目标版本进行判断,如果不是目标版本,则重复上述过程,直至将当前版本升级到目标版本,则终止升级过程。
与现有技术中recovery分区的升级通常是在软件的当前版本升级到目标版本之后,再对软件的recovery分区进行升级,使得recovery分区的版本与目标版本相匹配的过程不同,在上述的升级过程中,当升级后的版本的recovery分区相对于升级前的版本的recovery分区有修改时,在差分升级包中增加了recovery分区文件,每一次的单包升级都先对是否需要对当前版本的recovery分区是否升级进行判断,在需要对当前版本的recovery分区进行升级的情况下,根据差分升级包中的recovery分区文件对当前版本的recovery分区升级,然后再对system分区进行升级,这样,下一次的单包升级就能在升级后的recovery分区的基础上进行,而recovery分区中包含了控制单包升级的升级流程的函数,所以本发明中,即使中间版本的recovery分区做了修改,也不会影响下一个差分升级包的升级流程,使得连续升级过程可以顺利进行,从而避免了现有技术中所容易出现的每次升级过程中由recovery分区的更改所导致的下一次单包升级的失败,提高了连续升级的成功率。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理包括,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,简称ROM)、随机存取存储器(Random Access Memory,简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (10)
1.一种连续升级的方法,其特征在于,包括:
判断软件的当前版本是否是目标版本;
若否,从所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包中,查找在先版本与所述当前版本相同的差分升级包;其中,任意一个差分升级包只包含相邻两个版本的升级信息;
检测是否需要对所述当前版本的recovery分区进行升级;
若是,则根据查找到的差分升级包对所述当前版本的recovery分区进行升级,并将升级后的recovery分区加载到内存;
根据所述查找到的差分升级包对所述当前版本的system分区进行升级。
2.如权利要求1所述的方法,其特征在于,所述判断软件的当前版本是否是目标版本之前,还包括:
检测所述软件的所述当前版本是否低于服务器端相应的目标版本;
若是,则从所述服务器端获取所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包并保存。
3.根据权利要求1所述的方法,其特征在于,所述根据查找到的差分升级包对所述当前版本的recovery分区进行升级之后,还包括:
置位recovery分区升级标识;所述recovery升级标识用于指示recovery分区升级完成;
所述根据所述查找到的差分升级包对所述当前版本的system分区进行升级具体包括:
当确定所述recovery分区升级标识被置位时,根据所述查找到的差分升级包对所述当前版本的system分区进行升级。
4.如权利要求3所述的方法,其特征在于,所述根据所述查找到的差分升级包对所述当前版本的system分区进行升级之后,还包括:
复位所述recovery分区升级标识,并置位system分区升级标识,所述system分区升级标识用于指示所述system分区升级完成。
5.如权利要求3或4所述的方法,其特征在于,所述根据查找到的差分升级包对所述当前版本的recovery分区进行升级之前还包括:
初始化所述recovery分区升级标识为复位状态;
所述根据查找到的差分升级包对所述当前版本的recovery分区进行升级之前还包括:
判断所述recovery分区升级标识是否为复位状态;
若是,则根据查找到的差分升级包对所述当前版本的recovery分区进行升级。
6.如权利要求3所述的方法,其特征在于,所述根据所述查找到的差分升级包对所述当前版本的system分区进行升级之前还包括:
初始化所述system分区升级标识为复位状态;
所述根据所述查找到的差分升级包对所述当前版本的system分区进行升级之前还包括:
判断所述system分区升级标识是否为复位状态;
若是,则根据所述查找到的差分升级包对所述当前版本的system分区进行升级。
7.如权利要求1所述的方法,其特征在于,所述从所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包中,查找在先版本与所述当前版本相同的差分升级包之前,还包括:
获取所述所有差分升级包的存储路径,并将每一差分升级包的存储路径按照每一差分升级包的升级顺序依次进行排列;
所述查找在先版本与所述当前版本相同的差分升级包具体包括:
查找所述所有差分升级包的存储路径中排序最靠前的差分升级包;
所述根据所述查找到的差分升级包对所述当前版本的system分区进行升级之后还包括:
删除所述存储路径中排序最靠前的差分升级包的存储路径;
所述判断软件的当前版本是否是目标版本还可以为:
判断所述所有差分升级包的存储路径是否为空。
8.如权利要求1所述的方法,其特征在于,所述根据查找到的差分升级包对所述当前版本的recovery分区进行升级之后,还包括:
置位升级标识;
所述根据所述查找到的差分升级包对所述当前版本的system分区进行升级具体为:
判断所述升级标识是否被置位;
若是,则升级所述当前版本的system分区,并在升级完成之后,复位所述升级标识。
9.如权利要求2所述的方法,其特征在于,所述从服务器端获取所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包并保存之前,还包括:
判断是否支持连续升级;
若是,则从所述服务器端获取所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包并保存。
10.一种连续升级装置,其特征在于,包括:
判断单元,用于判断软件的当前版本是否是目标版本,并将判断结果发送给查找单元;
查找单元,用于若接收到的所述判断单元发送的所述判断结果为否,从所述软件由所述当前版本升级到所述目标版本所需的所有差分升级包中,查找在先版本与所述当前版本相同的差分升级包;其中,任意一个差分升级包只包含相邻两个版本的升级信息;
检测单元,用于检测是否需要对所述当前版本的recovery分区进行升级,并将检测结果发送给升级recovery分区单元;
升级recovery分区单元,用于若接收到的所述检测单元发送的检测结果为是,则根据查找到的差分升级包对所述当前版本的recovery分区进行升级,并将升级后的recovery分区加载到内存;
升级system分区单元,用于根据所述查找到的差分升级包对所述当前版本的system分区进行升级。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510343007.8A CN104965736B (zh) | 2015-06-19 | 2015-06-19 | 一种连续升级的方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510343007.8A CN104965736B (zh) | 2015-06-19 | 2015-06-19 | 一种连续升级的方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104965736A true CN104965736A (zh) | 2015-10-07 |
CN104965736B CN104965736B (zh) | 2018-04-27 |
Family
ID=54219771
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510343007.8A Active CN104965736B (zh) | 2015-06-19 | 2015-06-19 | 一种连续升级的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104965736B (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106658475A (zh) * | 2015-10-30 | 2017-05-10 | 上海中兴软件有限责任公司 | 一种空中下载技术升级方法和装置 |
CN107341024A (zh) * | 2016-04-28 | 2017-11-10 | 华为技术有限公司 | 系统升级方法和系统升级装置 |
CN108491214A (zh) * | 2018-02-08 | 2018-09-04 | 北京中科江南信息技术股份有限公司 | 应用系统升级部署的管理方法和管理系统 |
CN108521452A (zh) * | 2018-03-23 | 2018-09-11 | 烽火通信科技股份有限公司 | 对业务版本进行智能升级的方法及系统 |
CN108874439A (zh) * | 2018-07-02 | 2018-11-23 | 京东方科技集团股份有限公司 | 获取定制差分包的方法及装置、升级方法及装置 |
TWI644258B (zh) * | 2017-10-20 | 2018-12-11 | 中華電信股份有限公司 | 韌體管理伺服器及其韌體升版方法 |
CN109766119A (zh) * | 2019-01-24 | 2019-05-17 | 努比亚技术有限公司 | 恢复分区升级方法、终端和计算机可读存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110225413A1 (en) * | 2004-10-14 | 2011-09-15 | International Business Machines Corporation | Method, system and article of manufacture for system recovery |
CN102650947A (zh) * | 2012-04-01 | 2012-08-29 | 广东欧珀移动通信有限公司 | 一种Android手持设备连续增量的空中升级方法 |
CN103544031A (zh) * | 2013-08-27 | 2014-01-29 | Tcl集团股份有限公司 | 多分区外存储设备的Android系统升级方法和系统 |
CN103577211A (zh) * | 2012-08-08 | 2014-02-12 | 上海赤炫信息科技有限公司 | 一种新的Android ROM系统打包和烧录、更新方式 |
-
2015
- 2015-06-19 CN CN201510343007.8A patent/CN104965736B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110225413A1 (en) * | 2004-10-14 | 2011-09-15 | International Business Machines Corporation | Method, system and article of manufacture for system recovery |
CN102650947A (zh) * | 2012-04-01 | 2012-08-29 | 广东欧珀移动通信有限公司 | 一种Android手持设备连续增量的空中升级方法 |
CN103577211A (zh) * | 2012-08-08 | 2014-02-12 | 上海赤炫信息科技有限公司 | 一种新的Android ROM系统打包和烧录、更新方式 |
CN103544031A (zh) * | 2013-08-27 | 2014-01-29 | Tcl集团股份有限公司 | 多分区外存储设备的Android系统升级方法和系统 |
Non-Patent Citations (1)
Title |
---|
魏娟: "基于OMA标准的FOTA差分技术研究与实现", 《中国优秀硕士学位论文全文数据库信息科技辑》 * |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106658475A (zh) * | 2015-10-30 | 2017-05-10 | 上海中兴软件有限责任公司 | 一种空中下载技术升级方法和装置 |
CN106658475B (zh) * | 2015-10-30 | 2020-07-07 | 中兴通讯股份有限公司 | 一种空中下载技术升级方法和装置 |
CN107341024A (zh) * | 2016-04-28 | 2017-11-10 | 华为技术有限公司 | 系统升级方法和系统升级装置 |
TWI644258B (zh) * | 2017-10-20 | 2018-12-11 | 中華電信股份有限公司 | 韌體管理伺服器及其韌體升版方法 |
CN108491214A (zh) * | 2018-02-08 | 2018-09-04 | 北京中科江南信息技术股份有限公司 | 应用系统升级部署的管理方法和管理系统 |
CN108521452A (zh) * | 2018-03-23 | 2018-09-11 | 烽火通信科技股份有限公司 | 对业务版本进行智能升级的方法及系统 |
CN108521452B (zh) * | 2018-03-23 | 2020-12-08 | 烽火通信科技股份有限公司 | 对业务版本进行智能升级的方法及系统 |
CN108874439A (zh) * | 2018-07-02 | 2018-11-23 | 京东方科技集团股份有限公司 | 获取定制差分包的方法及装置、升级方法及装置 |
CN109766119A (zh) * | 2019-01-24 | 2019-05-17 | 努比亚技术有限公司 | 恢复分区升级方法、终端和计算机可读存储介质 |
CN109766119B (zh) * | 2019-01-24 | 2023-10-17 | 努比亚技术有限公司 | 恢复分区升级方法、终端和计算机可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN104965736B (zh) | 2018-04-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104899066A (zh) | 一种连续升级的方法及装置 | |
CN104965736A (zh) | 一种连续升级的方法及装置 | |
CN104836843A (zh) | 客户端应用程序更新的方法及装置 | |
CN106817411B (zh) | 业务访问请求的处理方法和相关设备 | |
CN110597542B (zh) | 软件自动ota升级方法及装置、电子设备 | |
US20050283606A1 (en) | Selecting a boot image | |
CN102929768B (zh) | 提示误装软件的方法和客户端 | |
CN104918114B (zh) | 一种操作系统升级方法及装置 | |
CN107506221A (zh) | 应用程序升级方法、装置及设备 | |
CN110032339B (zh) | 数据迁移方法、装置、系统、设备和存储介质 | |
CN106250192A (zh) | 上位机的软件升级方法及系统 | |
CN107590033B (zh) | 一种创建docker容器的方法、装置和系统 | |
CN103902696A (zh) | 一种加载资源文件的方法及装置 | |
CN102065118A (zh) | 一种网络设备升级方法及装置 | |
CN103324507A (zh) | 一种终端预置应用程序更新的方法和装置 | |
CN104267980B (zh) | 一种软件评分显示方法、终端、数据服务器及系统 | |
CN103559065A (zh) | 一种ota升级的方法和系统 | |
CN106951284B (zh) | 基于安卓系统应用的用户界面升级方法、装置及智能终端 | |
CN103034803B (zh) | 误装软件提示系统 | |
CN105553738A (zh) | 配置信息的热加载方法及装置、分布式集群系统 | |
CN108804118A (zh) | 固件升级方法、设备及存储介质 | |
CN104915226A (zh) | 一种网络设备软件启动方法、装置及网络设备 | |
CN114443081A (zh) | 终端升级的方法及终端 | |
CN103079108B (zh) | 启动机顶盒的方法及机顶盒 | |
CN109688472A (zh) | 电视系统升级方法、装置、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |