具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例提供了一种在线升级终端补丁的方法、装置与系统,本实施例的终端可以是固定终端或者移动终端,移动终端可以是移动台,如手机或PDA等。本实施例虽然以手机为例进行说明,但是本发明实施例的终端并不限定于手机终端,其他需要与服务器进行软件版本更新的终端都在本发明权利要求的保护范围之内。本实施例的技术方案可以在手机正常运行的情况下在线升级补丁以修复手机存在的bug,本实施例所说的补丁大部分都是动态应用,也可能是某个文件。
图1为本发明实施例的系统连接关系图,该图显示了手机终端10与服务器20整体交互过程。手机终端10中有两个功能模块负责与服务器20交互,分别为BM(Bug Manager,补丁管理)和DM(Download Manager,下载管理),BM主要负责连接服务器20查询当前手机中还有哪些补丁没有更新,当接收到服务器的消息后进行解析,并检查手机中确认存在此bug后,启动DM使用可靠的TCP/IP协议连接服务器。服务器20根据自身的处理能力可以同时处理多个手机终端10的请求,服务器解析其请求,通过后,将请求的应用及相关补丁文件下发给手机终端10。
一种可选的方式是,当运营商在服务器20主动更新补丁后,服务器20根据自身记录的信息广播一个OTA消息给手机,手机解析后再主动去连接服务器以获取更新的补丁文件列表,该OTA广播过程在图1中以虚线描述,表明该过程是可以选择使用的。
下面通过手机侧和服务器侧的方法与装置的描述来具体说明本实施例的实现方案:
实施例1:
首先,本实施例提供了一种在线升级手机补丁的方法,该方法应用于手机终端侧。图2为该方法的整体流程图,如图2所示,该方法包括:
S201、创建终端侧的补丁数据库,典型地,该终端可以是手机终端;
可选地,S201具体包括:向服务器发送注册请求;如果注册成功则创建所述手机侧的补丁数据库;
S202、从服务器获取更新的补丁文件列表,所述补丁文件列表中包含了每个补丁的标识及其存放路径;
可选地,S202可以包含两种情况,一种是:定期向服务器发送查询请求,从所述服务器获取更新的补丁文件列表;另一种是:接收所述服务器发送的广播通知消息,向服务器发送查询请求,从所述服务器获取更新的补丁文件列表;
可选地,本实施例的更新的补丁文件列表包括:所述终端未下载的补丁和所述终端已下载补丁的更新补丁;
S203、根据所述更新的补丁文件列表下载补丁文件,并存储于本地的临时目录;
可选地,在下载并存储该补丁文件列表后,该方法还包括:将所述补丁数据库中已下载的补丁的状态信息初始化为未更新;
S204、在所述补丁数据库中添加所下载的补丁文件及其存放路径;
S205、采用所述临时目录下的补丁文件覆盖该补丁文件对应的存放路径下的原文件;
可选地,S205完成之后还包括:删除所述临时目录下的补丁文件。
可选地,S205之前,该方法还包括:备份所述补丁文件对应的存放路径下的原文件;
可选地,在S205之后,该方法还包括:将所述补丁数据库中已更新成功的补丁文件的状态信息修改为已更新。
本实施例还提供了一种终端,该终端能够实现图2所示的补丁升级方法。图3为该终端的功能框图。如图3所示,该终端10包括:数据库建立单元301,用于创建终端侧的补丁数据库;补丁管理单元(BM)302,用于从服务器获取更新的补丁文件列表,所述补丁文件列表中包含了每个补丁的标识及其存放路径;下载管理单元(DM)303,用于根据所述下更新的补丁文件列表下载补丁文件,并存储于本地的临时目录;数据库更新单元304,用于在所述补丁数据库中添加所下载的补丁文件及其存放路径;补丁生效单元305,用于采用所述临时目录下的补丁文件覆盖该补丁文件对应的存放路径下的原文件。可选地,补丁生效单元305还用于在完成补丁文件覆盖之后删除所述临时目录下的补丁文件。
可选地,本实施例的数据库建立单元301,具体用于向服务器发送注册请求,如果注册成功则创建所述终端侧的补丁数据库。
可选地,本实施例的下载管理单元DM 303,具体用于下载所述终端未下载的补丁和所述终端已下载补丁的更新补丁。
可选地,本实施例的终端10还包括:备份单元306,用于备份所述补丁文件对应的存放路径下的原文件。这样如果在补丁生效单元305进行补丁覆盖的过程中出现异常,将可以通过备份的原文件来恢复该应用原来的功能。
可选地,所述补丁数据库中还包括:所述已下载补丁是否更新的状态信息;所述数据库更新单元304,还用于将所述补丁数据库中已下载的补丁的状态信息初始化为未更新;以及将所述补丁数据库中成功更新的补丁的状态信息修改为已更新。
图3a为本实施例补丁管理单元302的细化功能框图,如图3a所示,补丁管理单元BM 302具体包括:主动获取单元3021,用于定期向服务器发送查询请求,从所述服务器获取更新的补丁文件列表;被动获取单元3022,用于接收所述服务器发送的广播通知消息,向所述服务器发送查询请求,从所述服务器获取更新的补丁文件列表。
下面以手机为例,详细说明手机侧的补丁升级原理。
由于手机数量众多,首先需要服务器注册该手机,当手机开机后,BM模块在后台运行,后台运行对用户来讲是透明的,从界面上用户是看不到的。由于BM模块要知道手机中已安装了哪些补丁,需要一个数据库来记载,但这个数据库只有在向服务器注册成功后才会被创建,所以可以用它来标识该手机是否已注册成功。如果该数据库不存在,说明手机没有向服务器注册过或还没有注册成功过,此时就需要向服务器注册。
由于IMEI号是手机的唯一标识,本实施例可以将IMEI和手机当前系统软件版本信息发送给服务器,以便让服务器端建立该IMEI号和手机版本的数据库信息。手机在异步等待服务器应答的同时设置一个定时器,如果在定时时间到达之前没有收到服务器的应答,就关闭此次连接,等待下一个周期再次向服务器注册,如果接收到服务器的注册成功消息则取消定时器,在手机中创建补丁数据库。图4为手机向服务器注册流程图。
表1手机端数据库表结构图
表1显示了手机端补丁数据库内存放补丁信息的表结构,其中:“序号”就是补丁的编号,这个编号是服务器端为每个补丁分配的标识,可以从1开始。“路径”记录的是该补丁要存放的位置,这个路径是从服务器的消息中得到的,路径可以有多个,用分号区分,当然该表结构可以根据手机中不同的操作方式有不同的定义。“是否已更新”记录着某个补丁是否被应用,因为DM下载后是将补丁存放在一个临时目录下,只有在重启手机后,BM检查该列为FALSE(表示未更新)的话,会应用新补丁,如果为TRUE(表示已更新)的话,BM模块会进行一致性检查(如将表1中路径下的文件与临时目录下的文件比较,如果完全相同的话则将临时目录下的补丁删除)。
图5为手机端补丁检查、下载流程图。手机端每隔一定周期需要向服务器查询一次是否有新的补丁需要更新,BM模块以IMEI号作为参数向服务器发起TCP查询请求连接,之后等待服务器响应的同时设置定时器,在定时时间到之前未接收到应答信息,则结束此次连接。否则,如果服务器在检查之后的应答中指示存在新补丁,则手机端取消定时器,由DM建立下载队列,这个下载队列中是按顺序存放要升级的补丁编号,每个补丁是从数字1开始的连续编号,这个编号是在服务器分配的,下载模块DM负责下载,完成后更新补丁数据库,将新下载的补丁信息添加到数据库中。更新下载队列,如果队列不为NULL,说明还有新补丁需要下载。本实施例中,每次都是将数据库中的是否已更新初始化为FALSE,表示目前并没有应用新补丁,直到系统真正更新补丁后会将该项设置为TRUE。
本实施例的BM和DM通过消息的方式进行通讯,当BM检查到有新补丁要下载时,启动DM,DM利用补丁编号向服务器发出请求下载数据,同时DM要在闪存中创建一个临时目录(这个目录一般是一个固定的位置,方便后续出现异常时的处理工作)接收数据,如果下载完成,DM再通过消息的方式通知BM更新数据库,如果下载过程中出现异常则DM需要进行异常处理,主要是删除临时目录及下载的部分数据。图6为DM进行补丁下载的详细流程图。
当下载完补丁后,需要将新补丁应用到系统中,图7展示了如何应用新补丁的过程。图7的过程是先覆盖原文件,然后删除临时路径下的补丁文件,并且事先备份了补丁覆盖路径下的原文件,一旦出现异常也可以恢复成原文件。因此,图7的方法可以避免在更新补丁过程中突然断电的情况而导致被更新的应用无法使用问题。图7的方法根据手机系统的特性可能是立即执行也可能是开机后执行,如,有些更新仅仅是替换补丁文件,那么手机可以不用重启,但如果是关键应用的更新,很多其他的应用依赖于该应用的某些功能,这时这个应用升级了以后需要重启手机使新功能生效。
本实施例的技术方案可以解决以下一些技术问题:1)可以升级手机中的任何一个动态应用;2)支持动态应用批量下载更新;3)手机定期主动检测服务器上是否有新的补丁;4)当服务器上有更新的补丁时通过OTA(over theair,空中下载)广播。
本发明实施例的补丁升级方法与手机终端可以使手机在线升级更新软件bug,而不需要用户重新升级整个系统版本,同时用户的私有数据也不会因为软件bug的修复而丢失,极大的方便了用户,提高了手机软件的稳定性,同时也会给手机制造商和运营商带来巨大的经济利益。
实施例2:
实施例1为终端的方法与功能介绍,本实施例实现了服务器侧的方法与功能,服务器侧的方法配合终端侧的方法共同实现手机的补丁升级。
本实施例提供了一种在线升级手机补丁的方法,该方法应用于服务器侧。图8为该方法的整体流程图,如图8所示,该方法包括:
S801、在服务器侧为至少一个终端创建补丁数据库;
可选地,S801包括:接收终端发送的注册请求;如果注册成功则为所述终端创建补丁数据库;
S802、向至少一个终端下发该终端需要更新的补丁文件列表,使所述终端根据所述补丁文件列表下载补丁文件,所述补丁文件列表中包含了每个补丁的标识及其存放路径;
可选地,S802可以包含两种情况,一种是:接收终端定期发送的查询请求,向该终端下发该终端需要更新的补丁文件列表;另一种是:当新增补丁文件时向相应的终端发送广播通知消息,接收所述终端根据该广播通知消息发送的查询请求,下发该终端需要更新的补丁文件列表。
可选地,S802具体包括:根据所述终端的补丁数据库中已下载的补丁文件信息,向所述终端发送该终端未下载的补丁和已下载补丁的更新补丁;
S803、当终端完成补丁下载后,在对应于该终端的补丁数据库中添加已下载补丁的信息。
本实施例还提供了一种服务器,该服务器够实现图8所示的补丁升级方法。图9为该服务器的功能框图。如图9所示,该服务器20包括:数据库建立单元901,用于为至少一个终端创建补丁数据库;更新补丁发送单元902,用于向至少一个终端下发该终端需要更新的补丁文件列表,使所述终端根据所述补丁文件列表下载补丁文件,所述补丁文件列表中包含了每个补丁的标识及其存放路径;数据库更新单元903,用于当终端完成补丁下载后,在对应于该终端的补丁数据库中添加已下载补丁的信息。
可选地,所述数据库建立单元901,具体用于接收终端发送的注册请求,如果注册成功则为所述终端创建补丁数据库。
可选地,所述更新补丁发送单元902,具体用于根据所述终端的补丁数据库中已下载的补丁文件信息,向所述终端发送该终端未下载的补丁和已下载补丁的更新补丁。
图9a为本实施例更新补丁发送单元902的细化框图,如图9a所示,本实施例更新补丁发送单元902包括:被动发送单元9021,用于接收终端定期发送的查询请求,向该终端下发该终端需要更新的补丁文件列表;主动发送单元9022,用于当新增补丁文件时向相应的终端发送广播通知消息,接收所述终端根据该广播通知消息发送的查询请求,下发该终端需要更新的补丁文件列表。
下面以手机软件更新为例,详细说明服务器侧的补丁升级原理。
由于IMEI号是手机的唯一标识,运营商或OEM厂商预先知道每种型号手机的IMEI号的范围,并将这个范围输入到数据库中,当服务器接收到手机的注册请求时,利用请求参数的IMEI号和手机版本号与数据库中的IMEI比较,如果存在,则为该手机创建目录和相应数据库。
图10为服务器目录层次组织结构示意图。服务器端以版本号version来区分各个型号手机与版本,每个版本对应一个目录,在每个目录下再创建与IMEI号对应的数据库,即每个向服务器注册过的手机都会在服务器端有一份对应该手机的数据库,这个数据库记录的是该手机已下载过的补丁信息,bug list是对应于版本的各个补丁文件夹,以补丁编号命名,这个编号从1开始顺序增加,同时每个版本有一个全局的补丁数据库,记录着在该版本上所有的补丁信息。同时还存在一个全局的IMEI号数据库(如表2所示)。
表2全局补丁数据库表结构
当在服务器新增加一个补丁后,就需要在表2中添加一项,记录该补丁的信息,编号就是补丁的索引,使用这个编号就能够找到这个补丁,依赖是指这个补丁是否需要更新,如果为0则说明该补丁有效,需要手机安装,如果不为0则说明这个补丁并不一定需要安装。假设有这样一种可能,编号为1的补丁上传到服务器后,发现补丁1有严重缺陷,之后补丁1从服务器上删除,但有些手机可能已经下载更新了该补丁,有些手机还没有下载,这就需要增加一个补丁2来更新已经下载过补丁1的手机,对于没有下载补丁1的手机则不需要下载编号为2的补丁。
具体方案是当某个手机连接服务器后查询是否有新补丁需要更新时,服务器会在以IMEI号命名的局部表中找到编号最大的值,后根据该值在表2中比较,比如某手机已经更新了补丁1,2,3,则最大值就是3,而假设表2中有1,2,3,4,5,6,共6个补丁,那么4,5,6可能就是该手机需要升级更新的补丁,具体还要查看补丁4,5,6对应的依赖是否为0,如果都为0则说明4,5,6都需要更新。这里假设5的依赖为4,说明补丁4有缺陷,补丁5是为补丁4制作的,而补丁4在该手机中并没有安装。所以最终该手机只需要升级编号为6的补丁。
上面所述技术方案能够解决当手机制造商发现上传的服务器的补丁后有严重缺陷时的一种弥补方法。
图11为本实施例的服务器工作原理详细流程图。服务器端的更新补丁发送单元802需要接收手机随时发来的查询或下载请求,当有下载请求时服务器需要创建一个新的线程进行补丁下发任务,这是由于在同一时段可能有多个手机要求下载,所以服务器端需要为每个下载任务创建一个线程。当下载完成后需要更新该IMEI号手机已下载的数据库,将新下载的补丁信息添加到此数据库中。
可选地,当服务器上有补丁更新时,服务器还可以广播OTA消息给已经注册的手机,手机收到消息后,BM模块负责解析,之后执行补丁检查和下载的流程。
可选地,本实施例在服务器上的全局补丁数据库表也可以如表3所示:
表3全局补丁数据库表结构
在表3中按编号顺序记录补丁信息,没有依赖一列,这样可以减少查询补丁时间。如果没有依赖,那么当放到服务器的补丁有缺陷时,其他没有下载该补丁的手机也必须先下载这个有缺陷的补丁,之后再下载为解决这个有缺陷的补丁而提供的新的补丁。
本发明实施例的补丁升级方法和服务器可以使手机在线升级更新软件bug,而不需要用户重新升级手机的整个系统版本,同时用户的私有数据也不会因为软件bug的修复而丢失。极大的方便了用户,提高了手机软件的稳定性,同时也会给手机制造商和运营商带来巨大的经济利益。
本发明实施例还提供一种在线升级终端补丁的系统,系统连接关系图再次参照图1。如图1所示,该系统包括:终端10,用于创建终端侧的补丁数据库;从服务器获取更新的补丁文件列表,所述补丁文件列表中包含了每个补丁的标识及其存放路径;根据所述更新的补丁文件列表下载补丁文件,并存储于本地的临时目录;在所述补丁数据库中添加所下载的补丁文件及其存放路径;采用所述临时目录下的补丁文件覆盖该补丁文件对应的存放路径下的原文件;服务器20,用于为至少一个终端创建补丁数据库;向至少一个终端下发该终端需要更新的补丁文件列表,使所述终端根据所述补丁文件列表下载补丁文件,所述补丁文件列表中包含了每个补丁的标识及其存放路径;当终端完成补丁下载后,在对应于该终端的补丁数据库中添加已下载补丁的信息。
由于终端10以及服务器20的工作原理已经在前述实施例中进行了详细说明,此处不再展开描述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory,ROM)或随机存储记忆体(Random Access Memory,RAM)等。
以上实施例仅用以说明本发明实施例的技术方案,而非对其限制;尽管参照前述实施例对本发明实施例进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明实施例各实施例技术方案的精神和范围。