CN115686569A - 一种ota升级的方法及其相关组件 - Google Patents

Abstract

本申请涉及系统升级技术领域，公开了一种OTA升级的方法及其相关组件，包括：下载待升级包，并解析待升级包得到解析结果，当基于解析结果确定待升级包满足升级条件时，将待升级包传输至Slave端进行升级，获取Slave端发送的硬件信号，并在根据该硬件信号确定Slave端升级成功后，进入升级模式。可见，硬件信号不受通信协议影响，Host端在任意情况下均可获取Slave端发送的硬件信号以确定Slave端的升级状态，由此避免基于通信协议进行交互的方式在通信协议发生改变时，两端间无法正常通信的情况，提升升级可靠性。同时，Host端在确定Slave端升级成功后才继续升级，进一步提升升级可靠性。

Description

一种OTA升级的方法及其相关组件

技术领域

本申请涉及系统升级技术领域，特别是涉及一种OTA升级的方法及其相关组件。

背景技术

空间下载技术(Over-the-Air Technology，简称OTA)升级是Android系统提供的标准软件升级方式，一种通过移动通信(GSM或CDMA)的空中接口对SIM卡数据及应用进行远程管理的技术。

随着智能设备等的快速发展，设备对性能和资源的要求越来越高，由于单芯片对智能设备性能的支持逐渐乏力，无法满足实际需求，而提高单芯片配置后，各模块在后台运行占用资源影响待机功耗，为了解决此问题，目前智能设备采用了双系统设计。

双系统在升级时，主要采用系统依次单独升级的方式，在Slave端升级后，通过通信协议通知Host端进行升级，采用这样的方式进行双系统升级时，若Slave端和Host端的通信协议发生修改，Slave端和Host端之间则无法进行通信，进而无法获知对方当前的升级状态。

由此可见，如何避免双系统升级时Slave端和Host端通信协议被修改，保证Slave端和Host端间正常通信，提高升级可靠性和成功率，是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种OTA升级的方法及其相关组件，避免系统升级时Slave端和Host端通信协议被修改，保证Slave端和Host端间正常通信，提高升级可靠性和成功率，进而提升用户体验感。

为解决上述技术问题，本申请提供一种OTA升级的方法，包括：

下载待升级包，并解析所述待升级包得到解析结果；

基于所述解析结果判断所述待升级包中自身升级版本号与对应的当前版本号，以及Slave端的升级版本号与对应的当前版本号是否均不同以确定所述待升级包是否满足升级条件；

在确定所述待升级包满足升级条件时，将所述待升级包传输至Slave端以便所述Slave端进行升级；

获取所述Slave端发送的硬件信号以确定所述Slave端的当前升级状态；

在确定所述Slave端的当前升级状态为升级成功后，进入升级模式。

优选地，若确定所述Slave端的当前升级状态为升级失败后还包括：

判断当前系统是否处于开机状态；

若处于开机状态，将升级失败信号传输至服务器，并向所述服务器请求升级前的完整包以便进行系统恢复；

若处于关机状态，将关机信号和请求恢复版本号信号传输至所述服务器，以便所述服务器下发全新升级包，并进入强制烧录模式进行升级。

优选地，所述获取所述Slave端发送的硬件信号以确定所述Slave端的当前升级状态包括：

通过预设规则与所述Slave端进行握手协议；

获取所述Slave端发送的所述硬件信号；

基于所述握手协议解析所述硬件信号得到升级状态解析结果；

根据所述升级状态解析结果确定所述Slave端的当前升级状态。

优选地，所述通过预设规则与所述Slave端进行握手协议包括：

将M组N个高电平信号和M组N个低电平信号作为所述握手协议的一组握手信号与所述Slave端进行握手协议；其中，M和N为大于零的自然数；

则基于所述握手协议解析所述硬件信号包括：

依据所述M组N个高电平信号和所述M组N个低电平信号占用的总时长计算单个信号占用时长；

根据所述单个信号占用时长解析所述硬件信号。

优选地，在所述获取所述Slave端发送的所述硬件信号之后还包括：

将所述硬件信号设置为低电平信号；

在根据所述升级状态解析结果确定所述Slave端的当前升级状态为升级成功时，将所述硬件信号设置为高电平信号，以便所述Slave端在预设时长后根据所述硬件信号确定所述Host端的当前升级状态；

在根据所述升级状态解析结果确定所述Slave端的当前升级状态为升级失败时，保持所述硬件信号为低电平信号，以便所述Slave端在预设时长后判断当前所述硬件信号为低电平信号的判断次数是否达到预设次数，若未达到，则进入所述通过预设规则与所述Slave端进行握手协议的步骤，若达到，则终止升级。

优选地，在所述下载待升级包之前还包括：

接收升级指令；

确定当前系统的剩余电量是否允许进行升级；

若允许，则进入所述下载待升级包的步骤；

若不允许，则发送提示信号至终端。

优选地，所述Slave端进行升级包括：

获取Host端传输的所述待升级包；

确定系统的当前剩余存储空间是否允许升级；

若允许，则在校验所述待升级包完整性后，基于所述待升级包进行升级；

若不允许，则发送提示信号至终端；

发送所述硬件信号至所述Host端以便所述Host端在确定所述Slave端的当前升级状态为升级成功后进入升级模式。

为了解决上述技术问题，本申请还提供了一种OTA升级的装置，包括：

预处理模块，用于下载待升级包，并解析所述待升级包得到解析结果；

判断模块，用于基于所述解析结果判断所述待升级包中自身升级版本号与对应的当前版本号，以及Slave端的升级版本号与对应的当前版本号是否均不同以确定所述待升级包是否满足升级条件；

传输模块，用于在确定所述待升级包满足升级条件时，将所述待升级包传输至Slave端以便所述Slave端进行升级；

第一获取模块，用于获取所述Slave端发送的硬件信号以确定所述Slave端的当前升级状态；

确定模块，用于在确定所述Slave端的当前升级状态为升级成功后，进入升级模式。

为了解决上述技术问题，本申请还提供了一种智能手机，包括存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现所述的OTA升级的方法的步骤。

为了解决上述技术问题，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时所述的OTA升级的方法的步骤。

本发明所提供的一种OTA升级的方法，包括：下载待升级包，并解析待升级包得到解析结果，当基于解析结果确定待升级包满足升级条件时，将待升级包传输至Slave端。然后，在Slave端通过待升级包升级完成后，获取Slave端发送的硬件信号，并在根据该硬件信号确定Slave端升级成功后，进入升级模式进行升级。由此可见，本申请所提供的技术方案，硬件信号不受通信协议影响，Host端在任意情况下均可获取Slave端发送的硬件信号以确定Slave端的升级状态，由此避免基于通信协议进行交互的方式在通信协议发生改变时，Host端和Slave端之间无法正常通信的情况，提升升级可靠性。同时，Host端在确定Slave端升级成功后才继续升级，进一步提升升级效率和可靠性，提升用户体验感。

此外，本申请还提供一种OTA升级的装置和介质，与上述的OTA升级的方法相对应，效果同上。

附图说明

为了更清楚地说明本申请实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例所提供的一种OTA升级的方法的流程图；

图2为本申请实施例所提供的另一种OTA升级的方法的流程图；

图3为本申请实施例所提供的一种OTA升级的装置的结构图；

图4为本申请另一实施例提供的一种电子设备的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下，所获得的所有其他实施例，都属于本申请保护范围。

本申请的核心是提供一种OTA升级的方法及其相关组件，利用硬件信号不受通信协议影响的特点，在双系统间使用硬件信号进行交互，以便确定待升级两侧间的升级状态，提升升级准确性和可靠性。

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。

随着科技的不断发展，例如智能手机等电子设备对性能和资源的要求越来越高，此时，传统单芯片的设备已经无法满足用户需求，而提高单芯片配置后，各模块在后台运行占用资源影响待机功耗，为了解决此问题，双系统设计走进人们的生活。

为了提升系统性能，每隔一段时间需要对双系统进行升级，在升级时，主要采用系统依次单独升级的方式，在Slave端升级后，通过通信协议通知Host端进行升级，采用这样的方式进行双系统升级时，若Slave端和Host端的通信协议发生修改，Slave端和Host端之间则无法进行通信，进而无法获知对方当前的升级状态。

为了解决上述技术问题，避免Slave端和Host端之间的通信协议在升级时被修改，导致两侧无法获取对方当前的升级状态，本申请实施例提供了一种OTA升级的方法，利用硬件信号不受通信协议影响的特点，在Slave端和Host端之间使用硬件信号进行交互，进而保证在任何状态下，Slave端和Host端均可获取对方当前的升级状态，提升升级可靠性。

为了便于理解，下面对本申请所涉及的应用环境进行介绍，本申请所提供的OTA升级的方法可应用于任意双机通信的设备，例如，可应用于智能手表、虚拟现实设备和增强现实设备等。在对OTA升级进行升级时，Host端通常为安卓(Android)操作系统，而Slave端通常为微控制单元(Microcontroller Unit，简称MCU)，当然，也可将Slave端和Host端反过来使用，对此本申请不作具体限定。

图1为本申请实施例所提供的一种OTA升级的方法的流程图，如图1所示，该方法包括：

S10：下载待升级包，并解析待升级包得到解析结果；

S11：基于解析结果判断待升级包中自身升级版本号与对应的当前版本号，以及Slave端的升级版本号与对应的当前版本号是否均不同以确定待升级包是否满足升级条件；

在具体实施例中，双系统需要进行升级时，Host端需要先下载待升级包，得到待升级包后，先判断系统当前的电量是否满足当前的升级需求，可以理解的是，完成整个升级过程需要耗费一定的时间，因此为了保证系统顺利升级成功，在升级前需要先判断当前系统的电量是否足够支撑整个升级过程。

在确认系统当前电量满足升级需求时，对下载的待升级包进行解析得到解析结果，并根据解析结果判断待升级包中Host端的升级版本号与对应的当前版本号是否相同，以及判断Slave端的升级版本号与对应的当前版本号是否相同，当两端的升级版本号均与升级前的版本号不同时，确定待升级包满足升级条件。

当然，在实施中一次升级并不是Host端和Slave端均需要升级，因此，在对待升级包进行解析后，需要先根据解析结果先确定Slave端是否需要升级，若需要升级在对Slave端的升级版本号进行判断。

S12：在确定待升级包满足升级条件时，将待升级包传输至Slave端以便Slave端进行升级；

S13：获取Slave端发送的硬件信号以确定Slave端的当前升级状态；

通过步骤S11确定待升级包满足升级条件后，Host端将待升级包传输至Slave端，Slave端在接收到待升级包后，为了保证升级的成功率，需要先对待升级包的完整性进行确认，此外，还需要判断系统当前的存储空间是否满足升级需求。当确定待升级包完整，且系统当前的存储空间满足升级需求时，Slave端进入升级阶段。

Host端在预先设定的等待时长后，获取Slave端发送的硬件信号，并解析硬件信号以确定Slave端的当前升级状态。需要说明的是，Host端获取硬件信号也可以是实时获取，对此本申请不作限定。

S14：在确定Slave端的当前升级状态为升级成功后，进入升级模式。

进一步的，Host端在解析硬件信号确定Slave端的当前升级状态为升级成功时，确定自身可进入升级，此时进入升级模式进行升级。当然，若确定Slave端的当前升级状态为升级失败时，则终止升级。

本申请实施例所提供的OTA升级的方法，包括：下载待升级包，并解析待升级包得到解析结果，当基于解析结果确定待升级包满足升级条件时，将待升级包传输至Slave端。然后，在Slave端通过待升级包升级完成后，获取Slave端发送的硬件信号，并在根据该硬件信号确定Slave端升级成功后，进入升级模式进行升级。由此可见，本申请所提供的技术方案，硬件信号不受通信协议影响，Host端在任意情况下均可获取Slave端发送的硬件信号以确定Slave端的升级状态，由此避免基于通信协议进行交互的方式在通信协议发生改变时，Host端和Slave端之间无法正常通信的情况，提升升级可靠性。同时，Host端在确定Slave端升级成功后才继续升级，进一步提升升级效率和可靠性，提升用户体验感。

实施中，Slave端升级失败可能出现系统可开机或系统不可开机的两种情况，为了进一步提升系统升级成功率，在确定Slave端的当前升级状态为升级失败后还包括：

判断当前系统是否处于开机状态；

若处于开机状态，将升级失败信号传输至服务器，并向服务器请求升级前的完整包以便进行系统恢复；

若处于关机状态，将关机信号和请求恢复版本号信号传输至服务器，以便服务器下发全新升级包，并进入强制烧录模式进行升级。

当确定系统处于开机状态时，即可确定升级失败是其他原因造成，此时将升级失败信号传输至服务器，并向服务器请求升级前的完成包，以便对系统进行恢复，由此可保证系统在升级失败后可及时恢复至升级前的版本。

当确定系统处于关机状态时，即，系统无法开机时，升级失败的原因可能是系统无法开机导致的，此时，将系统无法开机的信号(关机信号)和请求恢复版本号信号传输至服务器，以便服务器下载全新的升级包，并将下载的全新升级包强制烧录实现升级。

本申请实施例所提供的OTA升级的方法，在确定Slave端的当前升级状态为升级失败时，若确定当前系统处于开机状态，则将升级失败信号传输至服务器，并向服务器请求升级前的完整包以便进行系统恢复，进而保证系统升级失败后能快速恢复至升级前的版本，保证用户可正常使用。若确定当前系统处于关机状态，则将关机信号和请求恢复版本号信号传输至服务器，以便服务器下发全新升级包，并进入强制烧录模式进行升级，由此，避免系统开机无法开机导致升级失败，进一步保证升级成功率和可靠性。

可以理解的是，纯硬件信号不受通信协议影响，在Slave端和Host端进行信号交互前，需要先通过预设规则进行握手协议，也就是让Slave端和Host端在信号交互前先认识一下，然后再基于握手协议进行交互。建立握手协议后，Host获取Slave端发送的硬件信号，并基于握手协议解析该硬件信号以确定Slave端的当前升级状态。

其中，通过预设规则与Slave端进行握手协议包括：将N个高电平信号和N个低电平信号作为握手协议的一组握手信号与Slave端进行握手协议，N为大于零的自然数。

进一步的，基于握手协议在解析硬件信号时，依据N个高电平信号和N个低电平信号占用的总时长计算单个信号占用时长，然后根据单个信号占用时长即可解析硬件信号。为了便于理解，下面将举例说明。

例如，硬件信号以GPIO信号为例，M为3，N为10，则以3组10个高电平信号和3组10个低电平信号作为握手协议的一组握手信号与Slave端进行握手协议，GPIO默认为低电平，Host端在收到高电平时开始进行握手协议和确定Slave端的升级状态。

假设，3组10个高电平信号和3组10个低电平信号所占用的总时长为60秒，则单个电平信号占用时长为1秒，Host端在获取到Slave端发送的硬件信号后，根据1秒时长进行解析。若解析结果000111111000代表升级成功时，其他解析结果则表示升级失败，例如000111000则代表升级失败，由此，可基于硬件信号确定Slave端的升级状态。

当然，实施中，为了确定进一步快速确定Slave端升级失败的原因，预先设定硬件信号对应的不同解析结果，在基于Slave端传输的硬件信号进行解析时，根据解析结果确定当前Slave端升级失败的原因。例如，若解析结果000111111000代表升级成功时，其他解析结果表征升级失败时，其中，000100000000表示待升级包传输失败，000110000000表示对待升级包校验失败，000111000000表示Slave端启动失败，当然，还可以包括其他类型的升级失败原因，本申请对升级失败的解析结果和对应的失败类型不作限定。

本申请实施例所提供的OTA升级的方法，以硬件信号进行信号传输，解析简单且不受通信协议的影响，可保证Host端在任意情况下均可获取Slave端的升级状态，提升升级准确性。

图2为本申请实施例所提供的另一种OTA升级的方法的流程图，作为优选的实施例，如图2所示，在获取Slave端发送的硬件信号之后还包括：

S20：将硬件信号设置为低电平信号；

S21：在根据升级状态解析结果确定Slave端的当前升级状态为升级成功时，将硬件信号设置为高电平信号，以便Slave端在预设时长后根据硬件信号确定Host端的当前升级状态；

实施中，Host端在获取到Slave端发送的硬件信号，即，在获取到用户解析Slave端升级状态的信号后，先将通信的信号设置为低电平。此时，Host端根据升级状态解析结果判断Slave端是否升级成功，若升级成功，则将通信信号设置为高电平，即，将当前的硬件信号设置为高电平，以便于Slave端在预设时长后根据当前硬件信号确定Host端的当前升级状态。

事实上，Host端在确定Slave端升级成功后，会自动进入升级模式进行升级，此时Slave端可根据高电平信号确定Host端正在升级中。进一步的，Host端在自身升级成功后，可再次将硬件信号设置为低电平，此时Slave端即可根据硬件信号确定Host端升级成功。

S22：在根据升级状态解析结果确定Slave端的当前升级状态为升级失败时，保持硬件信号为低电平信号，以便Slave端在预设时长后判断当前硬件信号为低电平信号的次数是否达到预设次数，若未达到，则进入通过预设规则与Slave端进行握手协议的步骤，若达到，则终止升级。

当然，若根据升级状态解析结果确定Slave端的当前升级状态为升级失败，则保持当前硬件信号为低电平信号，此时，为了避免传输的硬件信号出错导致对升级状态的误判，Slave端在预设时长后，先判断当前硬件信号为低电平信号的判断次数是否达到预设次数，若未达到，则重新通过预设规则与Slave端进行握手协议，即，使Host端重新获取硬件信号进行解析确定Slave端的升级状态，若达到，则确定Slave端升级失败，终止升级。

本申请实施例所提供的OTA升级的方法，在获取到Slave端发送的硬件信号之后，通过控制硬件信号的置高和置低以通知Slave端当前Host端对硬件信号的解析结果，以及Host端的当前升级状态，进而保证Host端和Slave端均可获取双方的升级状态，提升升级可靠性。

在具体实施例中，为了进一步保证OTA升级的可靠性，在下载待升级包之前，且在接收到升级指令后，先对系统的剩余电量进行判断，确定当前剩余电量是否允许进行升级，若允许，则进行待升级包的下载，若不允许，则发送提示信号至终端，以便提醒用户系统当前剩余电量不足，终止升级。

本申请实施例所提供的OTA升级的方法，在接收到升级指令后，先确定当前系统的剩余电量是否允许进行升级，若允许，才下载待升级包，避免电量不足导致中途升级失败，提升升级可靠性，同时，还可减少不必要的操作，节约资源。

可以理解的是，对OTA升级需要占用一定的系统存储空间，为了保证升级的储成功率和可靠性，Slave端在获取到Host端传输的待升级包后，先对系统的当前剩余存储空间进行检测以确定剩余存储空间是否允许升级，若允许进行升级，则进一步对待升级包的完整性进行校验，当确定待升级包完整后，基于待升级包进行升级。

若系统的当前剩余存储空间不允许升级时，则将提示信号传输至终端，以便提示用户当前存储空间不足，终止升级。当然，若在校验待升级包完整性时，确定待升级包不完整，同样发送提示信号至终端，以便提至用户升级失败。

进一步的，在升级完成后，发送硬件信号至Host端以便Host端在确定Slave端的当前升级状态为升级成功后进入升级模式。

本申请实施例所提供的OTA升级的方法，Slave端在进行升级时，先对系统的剩余存储空间，以及待升级包进行校验，进而提升升级成功率和可靠性。

在上述实施例中，对于应用于Host端的OTA升级的方法进行了详细描述，本申请还提供应用于Host端的OTA升级的装置对应的实施例。需要说明的是，本申请从两个角度对装置部分的实施例进行描述，一种是基于功能模块的角度，另一种是基于硬件结构的角度。

图3为本申请实施例所提供的一种OTA升级的装置的结构图，如图3所述，该装置包括：

预处理模块10，用于下载待升级包，并解析待升级包得到解析结果；

判断模块11，用于基于解析结果判断待升级包中自身升级版本号与对应的当前版本号，以及Slave端的升级版本号与对应的当前版本号是否均不同以确定待升级包是否满足升级条件；

传输模块12，用于在确定待升级包满足升级条件时，将待升级包传输至Slave端以便Slave端进行升级；

第一获取模块13，用于获取Slave端发送的硬件信号以确定Slave端的当前升级状态；

确定模块14，用于在确定Slave端的当前升级状态为升级成功后，进入升级模式。

由于装置部分的实施例与方法部分的实施例相互对应，因此装置部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

本申请实施例所提供的OTA升级的装置，包括：下载待升级包，并解析待升级包得到解析结果，当基于解析结果确定待升级包满足升级条件时，将待升级包传输至Slave端。然后，在Slave端通过待升级包升级完成后，获取Slave端发送的硬件信号，并在根据该硬件信号确定Slave端升级成功后，进入升级模式进行升级。由此可见，本申请所提供的技术方案，硬件信号不受通信协议影响，Host端在任意情况下均可获取Slave端发送的硬件信号以确定Slave端的升级状态，由此避免基于通信协议进行交互的方式在通信协议发生改变时，Host端和Slave端之间无法正常通信的情况，提升升级可靠性。同时，Host端在确定Slave端升级成功后才继续升级，进一步提升升级效率和可靠性，提升用户体验感。

图4为本申请另一实施例提供的一种电子设备的结构图，如图4所示，电子设备包括：存储器20，用于存储计算机程序；

处理器21，用于执行计算机程序时实现如上述实施例所提到的OTA升级的方法的步骤。

本实施例提供的电子设备可以包括但不限于智能手机、智能手表、虚拟现实设备、增强现实设备、平板电脑、笔记本电脑或台式电脑等。

其中，处理器21可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器21可以采用数字信号处理器(Digital Signal Processor，简称DSP)、现场可编程门阵列(Field－Programmable Gate Array，简称FPGA)、可编程逻辑阵列(ProgrammableLogic Array，简称PLA)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称中央处理器(Central Processing Unit，简称CPU)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以集成有图像处理器(GraphicsProcessing Unit，简称GPU)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器21还可以包括人工智能(Artificial Intelligence，简称AI)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器20可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器20还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器20至少用于存储以下计算机程序201，其中，该计算机程序被处理器21加载并执行之后，能够实现前述任一实施例公开的OTA升级的方法的相关步骤。另外，存储器20所存储的资源还可以包括操作系统202和数据203等，存储方式可以是短暂存储或者永久存储。其中，操作系统202可以包括Windows、Unix、Linux等。数据203可以包括但不限于OTA升级的方法中涉及的相关数据等。

在一些实施例中，电子设备还可包括有显示屏22、输入输出接口23、通信接口24、电源25以及通信总线26。

本领域技术人员可以理解，图4中示出的结构并不构成对电子设备的限定，可以包括比图示更多或更少的组件。

本申请实施例提供的电子设备，包括存储器和处理器，处理器在执行存储器存储的程序时，能够实现如下方法：OTA升级的方法。

本申请实施例所提供的电子设备，由于硬件信号不受通信协议影响，因此，通过硬件信号进行交互，Host端在任意情况下均可获取Slave端发送的硬件信号以确定Slave端的升级状态，由此避免基于通信协议进行交互的方式在通信协议发生改变时，Host端和Slave端之间无法正常通信的情况，提升升级可靠性。同时，Host端在确定Slave端升级成功后才继续升级，进一步提升升级效率和可靠性，提升用户体验感。

最后，本申请还提供一种计算机可读存储介质对应的实施例。计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述方法实施例(可以是Host端对应的方法、也可以是Slave端对应的方法，还可以是Host端和Slave端对应的方法)中记载的步骤。

可以理解的是，如果上述实施例中的方法以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上对本申请所提供的一种OTA升级的方法及其相关组件进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种OTA升级的方法，其特征在于，包括：

下载待升级包，并解析所述待升级包得到解析结果；

基于所述解析结果判断所述待升级包中自身升级版本号与对应的当前版本号，以及Slave端的升级版本号与对应的当前版本号是否均不同以确定所述待升级包是否满足升级条件；

在确定所述待升级包满足所述升级条件时，将所述待升级包传输至Slave端以便所述Slave端进行升级；

获取所述Slave端发送的硬件信号以确定所述Slave端的当前升级状态；

在确定所述Slave端的当前升级状态为升级成功后，进入升级模式。

2.根据权利要求1所述的OTA升级的方法，其特征在于，若确定所述Slave端的当前升级状态为升级失败后还包括：

判断当前系统是否处于开机状态；

若处于开机状态，将升级失败信号传输至服务器，并向所述服务器请求升级前的完整包以便进行系统恢复；

若处于关机状态，将关机信号和请求恢复版本号信号传输至所述服务器，以便所述服务器下发全新升级包，并进入强制烧录模式进行升级。

3.根据权利要求1所述的OTA升级的方法，其特征在于，所述获取所述Slave端发送的硬件信号以确定所述Slave端的当前升级状态包括：

通过预设规则与所述Slave端进行握手协议；

获取所述Slave端发送的所述硬件信号；

基于所述握手协议解析所述硬件信号得到升级状态解析结果；

根据所述升级状态解析结果确定所述Slave端的当前升级状态。

4.根据权利要求3所述的OTA升级的方法，其特征在于，所述通过预设规则与所述Slave端进行握手协议包括：

将M组N个高电平信号和M组N个低电平信号作为所述握手协议的一组握手信号与所述Slave端进行握手协议；其中，M和N为大于零的自然数；

则基于所述握手协议解析所述硬件信号包括：

依据所述M组N个高电平信号和所述M组N个低电平信号占用的总时长计算单个信号占用时长；

根据所述单个信号占用时长解析所述硬件信号。

5.根据权利要求4所述的OTA升级的方法，其特征在于，在所述获取所述Slave端发送的所述硬件信号之后还包括：

将所述硬件信号设置为低电平信号；

在根据所述升级状态解析结果确定所述Slave端的当前升级状态为升级成功时，将所述硬件信号设置为高电平信号，以便所述Slave端在预设时长后根据所述硬件信号确定所述Host端的当前升级状态；

在根据所述升级状态解析结果确定所述Slave端的当前升级状态为升级失败时，保持所述硬件信号为低电平信号，以便所述Slave端在预设时长后判断当前所述硬件信号为低电平信号的判断次数是否达到预设次数，若未达到，则进入所述通过预设规则与所述Slave端进行握手协议的步骤，若达到，则终止升级。

6.根据权利要求1所述的OTA升级的方法，其特征在于，在所述下载待升级包之前还包括：

接收升级指令；

确定当前系统的剩余电量是否允许进行升级；

若允许，则进入所述下载待升级包的步骤；

若不允许，则发送提示信号至终端。

7.根据权利要求1所述的OTA升级的方法，其特征在于，所述Slave端进行升级包括：

获取Host端传输的所述待升级包；

确定系统的当前剩余存储空间是否允许升级；

若允许，则在校验所述待升级包完整性后，基于所述待升级包进行升级；

若不允许，则发送提示信号至终端；

发送所述硬件信号至所述Host端以便所述Host端在确定所述Slave端的当前升级状态为升级成功后进入升级模式。

8.一种OTA升级的装置，其特征在于，包括：

预处理模块，用于下载待升级包，并解析所述待升级包得到解析结果；

判断模块，用于基于所述解析结果判断所述待升级包中自身升级版本号与对应的当前版本号，以及Slave端的升级版本号与对应的当前版本号是否均不同以确定所述待升级包是否满足升级条件；

传输模块，用于在确定所述待升级包满足所述升级条件时，将所述待升级包传输至Slave端以便所述Slave端进行升级；

第一获取模块，用于获取所述Slave端发送的硬件信号以确定所述Slave端的当前升级状态；

确定模块，用于在确定所述Slave端的当前升级状态为升级成功后，进入升级模式。

9.一种电子设备，其特征在于，包括存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至7任一项所述的OTA升级的方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的OTA升级的方法的步骤。

Images