CN114035830A - 软件升级方法、装置及电子设备 - Google Patents

Abstract

本申请适用于计算机应用技术领域，提供了一种软件升级方法、装置及电子设备，该方法包括：在接收到服务平台发送的升级请求后，向交易终端发送升级询问指令；接收所述交易终端反馈的询问结果，所述询问结果为所述交易终端通过待升级软件中集成的软件工具开发包执行所述升级询问指令生成的；根据所述询问结果，确定是否对所述交易终端中的所述待升级软件进行升级。通过本申请，可以解决在交易过程中升级软件时发生数据丢失或软件闪退的问题，提高软件升级的可靠性及灵活性。

Description

软件升级方法、装置及电子设备

技术领域

本申请属于计算机应用技术领域，尤其涉及一种软件升级方法、装置及电子设备。

背景技术

随着互联网的发展，移动支付遍布生活的各个角落；支付终端也支持越来越丰富的交易软件。

目前，在交易终端上，由于交易软件经常处于客户交易或支付过程中，交易数据对于交易软件极为重要，在执行客户交易或者支付过程中，对交易终端上的交易软件贸然升级，将导致交易数据发生丢失，或者导致正在运行的交易软件发生闪退的现象。

发明内容

本申请实施例提供了一种软件升级方法、装置及电子设备，可以解决在交易过程中升级软件时发生数据丢失或软件闪退的问题。

第一方面，本申请提供了一种软件升级方法，该方法可以包括：

在接收到服务平台发送的升级请求后，向交易终端发送升级询问指令；

接收所述交易终端反馈的询问结果，所述询问结果为所述交易终端通过待升级软件中集成的软件工具开发包执行所述升级询问指令生成的；

根据所述询问结果，确定是否对所述交易终端中的所述待升级软件进行升级。

在第一方面的一种可能的实现方式中，所述升级请求包括所述待升级软件的升级版本；在接收到服务平台发送的升级请求后，所述方法还包括：

根据一个或多个所述升级请求，分别下载与每个所述升级请求对应的所述升级版本的安装包；

根据所述待升级软件的应用包名称，查询所述交易终端上的所述待升级软件；

调用所述待升级软件对应的询问接口，向所述交易终端发送所述升级询问指令；

其中，所述安装包用于基于统一的安装接口对所述交易终端中的所述待升级软件进行升级。

在第一方面的一种可能的实现方式中，所述询问结果包括响应结果和认证凭据；所述根据所述询问结果，确定是否对所述交易终端中的所述待升级软件进行升级，包括：

通过调用所述服务平台的认证接口，对所述认证凭据进行验证；

若所述认证凭据通过，则根据所述响应结果判断是否升级所述交易终端中的所述待升级软件；

若所述认证凭据未通过，则对所述交易终端中的所述待升级软件进行升级；

其中，所述响应结果和所述认证凭据分别为所述交易终端基于所述软件工具开发包中的跨进程交互方法和凭据生成方法而生成的。

在第一方面的一种可能的实现方式中，所述根据所述响应结果判断是否升级所述交易终端中的所述待升级软件，包括：

若所述响应结果为更新，则升级所述交易终端中的所述待升级软件；

若所述响应结果为不更新，则启动多次询问机制，所述多次询问机制用于在预设时长后向所述交易终端再次发送所述升级询问指令。

在第一方面的一种可能的实现方式中，所述对所述交易终端中的所述待升级软件进行升级，包括：

通过二进制文件差分算法，计算所述待升级软件对应的所述升级版本的安装包和旧版本的安装包之间的二进制数据的差异；

根据所述二进制数据的差异生成差分文件；所述差分文件用于指示所述交易终端根据所述旧版本的安装包和所述差分文件合成升级安装包，以及根据所述升级安装包升级所述待升级软件。

在第一方面的一种可能的实现方式中，所述方法还包括：

基于跨进程通信，通过第一线程向所述交易终端发送所述升级询问指令；

通过第二线程对所述询问结果中的认证凭据进行验证并确定是否对所述待升级软件进行升级；

其中，所述第二线程为在所述第一线程之前下载所述升级版本的安装包的进程。

第二方面，本申请提供了一种软件升级方法，该方法可以包括：

接收客户端针对待升级软件发送的升级询问指令，所述升级询问指令为所述客户端在接收到服务平台发送的升级请求后生成的；

调用所述待升级软件中集成的软件工具开发包，执行所述升级询问指令，生成询问结果；

向所述客户端发送所述询问结果，所述询问结果用于指示所述客户端确定是否对所述待升级软件进行升级。

在第二方面的一种可能的实现方式中，，所述软件开发工具包还包括认证密钥，所述询问结果包括响应结果和认证凭据；

所述调用所述待升级软件中集成的软件工具开发包，执行所述升级询问指令，生成询问结果，包括：

调用所述软件工具开发包中的跨进程交互方法，执行所述升级询问指令，生成所述响应结果；

调用所述软件工具开发包中的凭据生成方法，根据所述认证密钥，生成所述认证凭据；

其中，所述认证密钥为所述服务平台针对开发软件生成的；所述认证凭据用于所述客户端对所述待升级软件的旧版本进行验证；所述响应结果用于所述客户端在对所述旧版本对应的认证凭据验证通过后，判断是否对所述待升级软件进行升级。

第三方面，本申请实施例提供了一种软件升级装置，该装置可以包括：

发送单元，用于在接收到服务平台发送的升级请求后，向交易终端发送升级询问指令；

接收单元，用于接收所述交易终端反馈的询问结果，所述询问结果为所述交易终端通过待升级软件中集成的软件工具开发包执行所述升级询问指令生成的；

处理单元，用于根据所述询问结果，确定是否对所述交易终端中的所述待升级软件进行升级。

第四方面，本申请实施例提供了一种电子设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现第一方面或者第二方面所述的方法。

第五方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现第一方面或第二方面所述的方法。

第六方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面或第二方面所述的方法。

可以理解的是，上述第二方面至第六方面的有益效果可以参见第一方面中的相关描述，在此不再赘述。

本申请与现有技术相比存在的有益效果是：本申请实施例中，客户端在接收到服务平台发送的升级请求后，向交易终端发送升级询问指令；客户端接收交易终端反馈的询问结果，改询问结果为交易终端根据升级询问指令通过待升级软件中集成的软件工具开发包生成的；客户端根据所述询问结果，确定是否对所述交易终端中的所述待升级软件进行升级；通过客户端向交易终端进行询问以及交易终端通过软件工具开发包生成询问结果并响应，由客户端根据询问结果决定是否升级，可以实现对交易终端中的待升级软件的灵活升级，且可以避开在交易过程中升级软件，从而避免在交易过程中由于软件升级而导致的数据丢失及软件闪退的现象，提高软件升级的可靠性及适用性；具有较强的易用性与实用性。

附图说明

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

图1是本申请实施例提供的系统应用场景的架构示意图；

图2是本申请实施例提供的软件升级方法的实现流程示意图；

图3是本申请实施例提供的服务平台推送应用的界面示意图；

图4是本申请实施例提供的触发升级软件的界面示意图；

图5是本申请实施例提供的生成认证密钥的界面示意图；

图6是本申请实施例提供的软件升级方法的实现流程示意图；

图7是本申请实施例提供的软件升级装置的结构示意图；

图8是本申请实施例提供的电子设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

在交易终端上，由于很多软件(例如交易应用)没有与其对应的后台服务，软件的升级需要终端管理平台完成，并且交易数据一般都保存在软件本地，若在交易过程中对软件进行升级，则可能导致数据丢失或软件闪退，从而打断用户当前的交易过程，用户体验也非常不好。

本申请实施例针对上述问题，提出一种软件升级方法，可以应用在管理交易终端的应用程序的客户端；其中，在管理交易终端的应用程序的客户端可以是PAXSTORE客户端，该PAXSTORE客户端可以是运行在一个单独的不同于交易终端的硬件设备上，也可以是运行在交易终端上的应用程序。在执行软件升级之前，增加询问升级以及基于响应判断是否升级的逻辑；根据交易终端的运行状态，灵活控制升级过程，例如该客户端询问该交易终端中的交易应用是否处于交易状态，如果处于交易状态则会启动相应的策略，待下次时机到来时继续询问，反之则执行软件升级。

请参见图1，图1是本申请实施例提供的系统应用场景的架构示意图。如图1所示，该系统包括客户端10、交易终端20和服务平台30。客户端10分别与交易终端20、服务平台30进行交互通信，服务平台30与交易终端20之间也可以进行通信。

其中，客户端10管理交易终端20上的应用程序，包括远程安装升级软件。服务平台30为客户端10的后台服务端，可以接收第三方开发并上传的应用程序以及拥有交易终端的用户输入的推送指令等。例如第三方可以通过服务平台30的前端网页界面登录后，服务平台30接收第三方上传新开发或升级的应用程序；或者拥有交易终端的用户通过服务平台30的前端网页界面登录后，服务平台30接收用户输入推送指令等。

示例性的，服务平台30在接收到推送指令后，可以向客户10端发送推送消息；客户端10在接收到推送消息后，可以从服务平台30下载并安装新版本的软件安装包。或者，服务平台30在接收到推送指令后，还可以直接向交易终端20发送推送消息，推送新版本的软件；交易终端20在接收到推送消息后，接收用户输入的更新指令，并向客户端10发送更新信息；客户端10接收到更新信息后，可以从服务平台下载并安装新版本的软件安装包。

需要说明的是，服务平台30可以实时地向客户端10或交易终端20发送推送信息，实时推送应用程序的新版本。示例性的，该服务平台可以是PAXSTORE平台，交易终端可以是POS终端。交易终端的拥有者代理商可以通过服务平台(如PAXSTORE平台)向客户端推送应用，以更新交易终端中旧版本的应用程序。

本申请实施例，客户端10在接收到服务平台30发送的推送消息或交易终端20发送的更新信息后，开始与交易终端20进行交互通信，询问交易终端20是否处于可升级状态，基于交易终端20反馈的询问结果，判断是否执行升级进程。从而提高了软件升级过程的灵活性，可以有效的避开软件正处于交易过程中而导致数据丢失或软件闪退的缺陷；询问过程、判断过程以及升级过程均通过客户端10与交易终端20的后台交互实现，在用户无感知的状态下执行并完成，在保证交易顺利进行以及软件升级的及时性的同时，大大提升了用户的使用体验感。

基于以上的概述，下面对本申请提供的软件升级方法的流程进行详细说明。需要说明的是，图1中的客户端10可以作为一个独立的硬件设备，执行相应的流程步骤，例如在该客户端10上可以运行PAXSTORE客户端的程序，实现对交易终端20上的交易应用的管理；客户端10还可以作为交易终端20中集成的应用程序的代码模块(例如PAXSTORE客户端的程序代码)，由交易终端作为执行主体实现该代码模块对应的管理交易应用的功能，例如在交易终端上运行PAXSTORE客户端的程序，实现对交易终端20上的应用程序的管理。

如图2所示，本申请实施例提供的软件升级方法的实现流程示意图。该方法执行主题可以是图1所示的系统中的客户端10；还可以是交易终端中可以实现客户端相关的功能，即此时执行主体还可以是交易终端20，交易终端20中可以执行该代码模块以实现客户端相应的功能步骤。为便于描述，本申请实施例以客户端10作为独立的实体，并作为本申请实施例的执行主体进行介绍，该方法可以包括以下步骤：

S201，客户端在接收到服务平台发送的升级请求后，向交易终端发送升级询问指令。

在一些实施例中，该客户端可以是负责管理各个交易终端的应用程序的设备，例如PAXSTORE客户端；该客户端可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。

示例性的，该升级请求可以是由图1中的服务平台20发送的；也可以是图1中的交易终端20触发更新机制后，该客户端接收服务平台30发送的。

如图3中的(a)图所示的服务平台的界面示意图，该界面图可以为用户通过服务平台对应的应用程序APP或网页打开并登录呈现的界面。在该界面上包括交易终端的设备号、交易终端对应的代理商信息、已安装的应用程序(例如应用程序APP1和APP2)、应用的来源信息(第三方应用以及应用商店等)以及版本信息等；同时还包括推送应用的控件以及推送应用的历史记录，例如历史记录中包括已经推送过版本号为2.0的应用程序APP1。

示例性的，服务平台接收交易终端的拥有者通过点击“推送应用”的控件输入的指令；基于该指令，服务平台跳转至如图3中的(b)图所示的界面，该界面可以包括高版本的应用程序，例如版本号为3.0的应用程序APP1，该版本号高于已安装的APP1的版本。在服务平台接收到用户通过点击选中控件以及确定控件输入的指令后，向客户端发送升级请求，以推送应用程序的新版本。

示例性的，如图4所示的触发升级的界面示意图，该界面示意图可以为交易终端的界面示意图，服务平台还可以向指定的交易终端实时推送应用程序的新版本，交易终端接收到推送信息后，会显示如图4所示的界面，提示应用程序存在可以升级的新版本，例如图4中版本号为3.0的应用程序APP1。交易终端可以接收用户通过点击更新控件输入的指令，交易终端根据该指令执行应用程序升级逻辑，或者根据该指令向服务平台发送更新信息，由客户端接收服务平台基于该更新信息推送的升级请求。

需要说明的是，上述图3和图4所示的界面仅示例性说明，在服务平台对应的推送应用的显示界面，在添加推送的应用程序时，还可以同时选中多个新版本的应用程序，从而客户端可以同时接收到与之相对应的多个升级请求。

在一些实施例中，该升级请求可以包括待升级软件的升级版本；在客户端接收到服务平台发送的升级请求后，该方法还包括：

客户端根据一个或多个升级请求，分别下载与每个所述升级请求对应的所述升级版本的安装包；客户端根据所述待升级软件的应用包名称，查询所述交易终端上的所述待升级软件；调用所述待升级软件对应的询问接口，向所述交易终端发送所述升级询问指令。

其中，该安装包用于基于统一的安装接口对交易终端中的待升级软件进行升级。

示例性的，客户端可以接收服务平台针对多个新版本的应用程序推送的多个升级请求；客户端接收到升级请求后，根据升级请求中的升级版本信息下载对应的应用程序的安装包。升级请求中还可以包括待升级软件对应的应用包名称，或者客户端中存储有待升级软件的应用包。从而客户端可以根据待升级软件的应用包名称，查询到交易终端上的待升级软件，然后调用该待升级软件中的询问更新服务对应的询问接口，向该交易终端发送升级询问指令。

其中，该升级询问指令用于调用交易终端中待升级软件集成的询问更新服务，以指示交易终端根据该执行询问更新服务中的判定方法，得到询问结果。该待升级软件可以是第三方开发的应用程序，客户端所发送的升级询问指令是针对该待升级软件中的内部逻辑，并不是交易终端的使用者，整个询问过程不需要用户人为介入，更不需要等待任何用户输入，所有过程都是在交易终端后台进行，对终端使用者无感知。

示例性的，该安装包可以用于客户端通过调用统一的安装接口，向多个型号的交易终端安装升级版本的应用程序，对交易终端中的待升级软件进行升级。其中，客户端上统一的安装接口可以为服务平台定义的统一规范，不同厂商机型的交易终端可以根据该统一规范实现静默安装升级版本的应用程序的功能。其中，静默安装对比普通安装，不会弹出任何确认框等待用户操作，所有安装过程在后台静默执行；而普通应用安装，每一次执行安装都有弹出框等待用户确认。本申请实施例进一步提升了用户体验。

示例性的，当服务平台或者交易终端触发了更新条件时，客户端可以同时基于触发的升级请求下载多个安装包，并根据多个安装包的应用包名称查询已安装在交易终端上的旧版本的应用程序(即待升级软件)，在确认交易终端已安装旧版本的应用程序的同时，还会查询该旧版本的应用程序是否集成了软件开发工具包中的询问升级服务的功能；若交易终端安装有旧版本的应用程序，以及该旧版本的应用程序中集成了软件开发工具包中的询问升级服务，则向交易终端发送升级询问指令。

S202，客户端接收交易终端反馈的询问结果，该询问结果为交易终端通过待升级软件中集成的软件工具开发包执行升级询问指令生成的。

在一些实施例中，交易终端中的待升级软件可以集成有软件开发工具包，该软件开发工具包中包含询问更新服务；该询问更新服务可以实现判定待升级软件是否处于交易或繁忙状态的方法接口。

其中，客户端向交易终端发送升级询问指令后，可以调用交易终端中的待升级软件集成的软件开发工具包的跨进程交互方法以及生成认证凭据的方法；从而交易终端基于该升级询问指令，在后台执行该跨进程交互方法和生成认证凭据的方法，以响应客户端的升级询问指令。在交易终端执行该待升级软件集成的软件开发工具包中的各种方法时，均可以基于通用的安全算法执行，服务平台针对每个应用程序可以生成对应的安全密钥。

示例性的，客户端在向交易终端发送升级询问指令后，通过调用交易终端中待升级软件的判定接口，从而客户端接收到交易终端根据待升级软件的业务逻辑生成的询问结果。

S203，客户端根据询问结果，确定是否对所述交易终端中的所述待升级软件进行升级。

在一些实施例中，客户端向交易终端发送升级询问指令，询问交易终端中的待升级软件所处的状态是否为交易或繁忙状态，如果待升级软件正在交易则启用多次询问机制，如果处于空闲状态则执行应用的升级以及安装包的安装。

在一些实施例中，该询问结果可以包括响应结果和认证凭据；客户端根据所述询问结果，确定是否对交易终端中的待升级软件进行升级，包括：

客户端通过调用所述服务平台的认证接口，对所述认证凭据进行验证；若认证凭据通过，则根据响应结果判断是否升级所述交易终端中的所述待升级软件；若认证凭据未通过，则对交易终端中的待升级软件进行升级。

其中，响应结果和认证凭据分别为交易终端基于软件工具开发包中的跨进程交互方法和凭据生成方法而生成的。

示例性的，客户端在接收到询问结果后，会调用服务平台的接口验证询问结果中的认证凭据是否合法；在认证凭据不合法，未通过验证，则在交易终端安装的旧版本的软件可能存在非法软件占用包名或者软件被破解等情况，所以直接根据新版本的安装包升级交易终端的待升级软件；若认证凭据合法，通过验证，则继续根据响应结果判断是否升级所述交易终端中的所述待升级软件。

在一些实施例中，所述根据所述响应结果判断是否升级所述交易终端中的所述待升级软件，包括：

若所述响应结果为更新，则升级所述交易终端中的所述待升级软件；若所述响应结果为不更新，则启动多次询问机制，所述多次询问机制用于在预设时长后向所述交易终端再次发送所述升级询问指令。

示例性的，若响应结果未更新，则直接升级交易终端的待升级软件；若响应结果为正在交易或处于繁忙状态不能更新，则保留安装包并等待该待升级软件处理自身逻辑(如保存交易数据等)，然后启动多次询问机制。

具体的，由于询问是由客户端触发的，所以客户端负责控制询问的策略，如果客户端收到交易终端的待升级软件返回的认证信息验证通过，且返回的响应结果不可以更新时，会在接下来每分钟重新询问一次，当达到10次询问都是不可以更新时，会根据策略降低询问频率(如降到1小时询问一次)，当交易终端返回可以更新后，会将多次询问机制恢复至初始状态；同时，如果认证凭据通过验证，客户端还会缓存该验证结果，从第二次询问开始不会再发起网络请求调用接口API来重复验证认证凭据，根据第一次验证通过的结果直接执行是否更新的操作，以此实现节省流量的目的。

另外，当客户端作为交易终端中集成的代码模块时，交易终端作为整个交互过程的唯一执行主体，本申请实施例的整个过程都可以在交易终端(例如POS终端)内部进行，不需要借助额外的硬件和设备，有效阻止了多终端交互时可能存在信息(如询问结果、输入的密码等)被其他设备内其他应用或者其他设备窃取甚至篡改的可能性。采用安全的平台认证方式，防止出现非法软件占用包名或软件被破解导致无法正常升级的问题。

在一些实施例中，客户端对交易终端中的待升级软件进行升级，包括：

客户端通过二进制文件差分算法，计算待升级软件对应的升级版本的安装包和旧版本的安装包之间的二进制数据的差异；根据二进制数据的差异生成差分文件；该差分文件用于指示交易终端根据旧版本的安装包和差分文件合成升级安装包，以及根据升级安装包升级待升级软件。

示例性的，客户端使用二进制文件差分法，通过二进制文件的差分算法计算出升级版本的安装包和旧版本的安装包之间在二进制数据上的差异，然后根据该差异生成差分文件并下载到交易终端，交易终端根据已安装的旧版本的安装包和该差分文件合成出最新的升级版本的安装包，最后安装升级版本的安装包，以达到软件更新的目的。通过本申请实施例，不需要每个软件定制自己的文件对比清单，可以适用于所有的软件包的更新升级，从而在实现上具有统一性和通用性。

其中，差分算法可以采用很多种，不同的差分算法在计算差分文件的效率上、生成的差分文件大小、以及合成的效率上均有差异，可以根据实际应用场景的需要进行选择。

在一些实施例中，该方法还包括：

基于跨进程通信，客户端通过第一线程向所述交易终端发送所述升级询问指令；客户端通过第二线程对所述询问结果中的认证凭据进行验证并确定是否对所述待升级软件进行升级。

其中，第二线程可以为在第一线程之前下载升级版本的安装包的进程。

示例性的，客户端基于多线程以及Messenger的通信方式，让客户端针对每个应用的下载和安装从线程池中起一个线程执行，跨进程通讯的询问部分根据应用包的包名通过Messenger向各自对应的旧版本的待升级软件发起升级询问指令，然后让获取的各个待升级软件的询问结果回到该待升级软件对应的之前起的线程中执行认证和安装；如果对询问结果验证通过且交易终端中的待升级软件正忙(返回的响应结果为不更新)，则缓存验证结果，并根据多次询问机制等待下一次更新。各个线程之间没有相互的依赖关系，从而可以实现多个软件的同时询问升级。

本申请实施例，客户端通过采用安卓Android Messenger的通信方式，可以保证客户端和交易终端中的待升级软件的跨进程通讯的线程安全性。客户端在多个软件同时进行更新的过程中不会相互影响，针对询问和返回结果的线程安全，通过基于安卓AndroidMessenger的通信方式，不同线程之间不会共享数据，由客户端控制和触发询问过程，以队列的方式每次询问一个结果，且交易终端中待升级的第三方应用为被询问方，其内部不会存在高并发的场景，因而在支持多个软件同时询问及升级的同时，还可以保证线程安全性。

在一些实施例中，客户端向服务平台同步升级结果，其中升级结果包括升级成功和升级失败。

示例性的，如果待升级软件能够正常更新升级，则客户端会直接与服务平台同步升级成功的结果；如果询问更新的过程中待升级软件处于交易状态，未能执行更新升级，则客户端会根据多次询问机制下次继续询问，直到所有的询问均不能满足，则客户端会直接与服务平台同步升级失败的结果。

通过本申请实施例，可以打破原有的交易状态只属于支付应用自身的业务逻辑，而其他应用不可见的束缚，让支付应用的交易状态在应用升级前对管理交易终端的客户端可知。而传统的应用管理平台对应用升级时并不会考虑应用自身是否处于空闲状态；从而可以避免由于升级导致交易数据的丢失。

另外，通常安卓Android平台执行应用升级的过程时，系统直接进行安装更新，并不会考虑应用内部是否有事务正在处理(比如交易正在进行，交易数据未保存等情况)，此时贸然安装更新，往往会引起还在内存部分(未持久化)的交易数据丢失，而造成损失。通过本申请实施例，由客户端询问更新的方案，在执行更新时，待升级软件会执行开发者预置的业务逻辑程序，并返回是否会有未保存的交易数据，如果有则会返回正在交易、不能更新的提示，当客户端接收到响应结果后会根据多次询问机制等待下次询问，直到应用处理和保存所有重要的数据并返回可以更新才会执行更新操作；从而可以避免打断用户的交易过程，做到空闲时升级，升级体验也更加友好；通过待升级软件中集成的软件工具开发包，可让支付应用支持询问升级的功能，而不必关心具体的跨进程通讯以及复杂的询问策略和安装逻辑；基于完全开放自定义的支付状态返回接口，满足所有支付应用各种支付场景。

结合上述实施例实现的方式，本申请实施例还提供了一种软件升级方法。如图6所示，该软件升级方法的执行主体可以是交易终端，基于客户端的调用，交易终端可以执行待升级软件中集成的软件开发工具包的方法，实现对自身运行逻辑的判断以及对客户端的响应。具体的实现步骤可以包括：

S601，交易终端接收客户端针对待升级软件发送的升级询问指令，该升级询问指令为客户端在接收到服务平台发送的升级请求后生成的。该步骤与上述实施例的实现原理相同，在此不再赘述。

S602，交易终端调用所述待升级软件中集成的软件工具开发包，执行所述升级询问指令，生成询问结果。

示例性的，交易终端中安装的软件可以包括第三方开发的应用程序或者应用市场中的应用程序。软件开发工具包为客户端提供的，用于集成在第三方应用中。软件开发工具包可以包含已经实现的用于响应客户端询问升级的通讯服务。

示例性的，针对服务平台上的应用程序和其对应的开发者，客户端可以提供封装好的软件开发工具包(Software Development Kit，SDK)，用于集成在第三方应用中；使得集成后的第三方应用可以具备如询问更新、参数下载、同步附属设备信息、业务数据上送以及云消息CloudMessage推送等功能。

示例性的，在开发者对应用程序集成上述SDK的过程中，只需要调用StoreSdk.initInquirer()方法，然后交易终端可以根据应用程序的自身业务逻辑实现isReadyUpdate()方法，并反馈相应的询问结果(其中，每个应用程序的业务逻辑的判定规则可能存在差异)，客户端在更新待升级软件之前调用交易终端中待升级软件集成的询问更新服务，带升级软件继承的SDK内部执行isReadyUpdate()方法并将询问结果中的响应结果和认证凭据返回给客户端，客户端根据该方法返回是否执行更新的操作的决定。

其中，此交互过程不需要交易终端的用户人为参与，客户端会自动与交易终端中第三方应用集成的SDK中的询问更新服务在后台进行交互处理。

在一些实施例中，软件开发工具包还包括认证密钥，询问结果包括响应结果和认证凭据；交易终端调用待升级软件中集成的软件工具开发包，执行升级询问指令，生成询问结果，包括：

调用所述软件工具开发包中的跨进程交互方法，执行所述升级询问指令，生成所述响应结果；调用所述软件工具开发包中的凭据生成方法，根据所述认证密钥，生成所述认证凭据。

其中，所述认证密钥为所述服务平台针对开发软件生成的；所述认证凭据用于所述客户端对所述待升级软件的旧版本进行验证；所述响应结果用于所述客户端在对所述旧版本对应的认证凭据验证通过后，判断是否对所述待升级软件进行升级。

在一些实施例中，开发者在应用市场内创建应用程序时，服务平台可以为每个应用程序生成认证密钥(Key和Secret密钥对)。开发者在应用程序中集成SDK时，将对应的认证密钥写在代码中。在询问过程中，交易终端的带升级软件启动时，集成的SDK会将认证密钥初始化；在需要认证时，SDK使用认证密钥生成认证凭据(例如签名Token)，并将该认证凭据返回给客户端，由客户端将该认证凭据传输到服务平台后，由服务平台基于与其对应的软件对其进行验证。从而可以根据验签结果确定交易终端当前安装的旧版本的软件是否被破解或者被恶意占用包名，进一步可以让交易终端更新到正版应用。

示例性的，开发者在服务平台开发并创建应用程序时，获得用于认证该应用程序的AppKey和AppSecret，然后根据使用文档在应用程序中集成客户端的SDK的询问升级服务，在集成过程中会预埋之前该应用对应的AppKey和AppSecret。如图5所示的服务平台的显示界面，开发者在服务平台创建应用程序时，服务平台会给每个应用自动生成对应的AppKey和AppSecret，开发者可以通过开发者中心→应用管理→选中应用路径，点击“APPKEYS”(应用KEY)查看，如图5中的(a)图所示；服务平台在接收到用户通过点击“应用KEY”输入的指令后，显示如图5中的(b)图所示的界面，该界面显示该应用程序对应的接口地址APIURL以及认证密钥(APP KEY和APP Secret)等信息。具体的，开发者将AppKey和AppSecret写在应用程序的代码中，通过调用SDK的初始化方法完成对该认证密钥初始化。

S603，向所述客户端发送所述询问结果，所述询问结果用于指示所述客户端确定是否对所述待升级软件进行升级。该步骤与上述实施例的实现原理相同，在此不再赘述。

通过本申请实施例，可以有效防止恶意返回询问结果，本申请实施例中的询问升级方案采用的是服务平台生成密钥，并且有由服务平台进行验证，询问结果会包含基于旧版本的应用程序的认证密钥生成的签名信息(即认证凭据)，有效阻止了待升级软件被破解或者恶意占用包名等导致软件无法升级到正确的版本的情况，由于破解者无法获取应用程序的原始密钥，从而也没有办法拒绝交易终端的拥有者将该应用软件升级成正版软件；从而保证了软件升级过程的安全性以及交易终端中安装的软件的安全性。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

对应于上文实施例所述的智能合约的开发方法，图7示出了本申请实施例提供的软件升级装置的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图7，该装置包括：

发送单元71，用于在接收到服务平台发送的升级请求后，向交易终端发送升级询问指令；

接收单元72，用于接收所述交易终端反馈的询问结果，所述询问结果为所述交易终端通过待升级软件中集成的软件工具开发包执行所述升级询问指令生成的；

处理单元73，用于根据所述询问结果，确定是否对所述交易终端中的所述待升级软件进行升级。

对应于上文实施例所述的软件升级方法，本申请实施例提供的软件升级装置的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。

该装置包括：

接收单元，用于接收客户端针对待升级软件发送的升级询问指令，所述升级询问指令为所述客户端在接收到服务平台发送的升级请求后生成的；

执行单元，用于调用所述待升级软件中集成的软件工具开发包，执行所述升级询问指令，生成询问结果；

发送单元，用于向所述客户端发送所述询问结果，所述询问结果用于指示所述客户端确定是否对所述待升级软件进行升级。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。

图8为本申请一实施例提供的电子设备8的结构示意图。如图8所示，该实施例的电子设备8包括：至少一个处理器80(图8中仅示出一个)、存储器81以及存储在所述存储器81中并可在所述至少一个处理器80上运行的计算机程序82，所述处理器80执行所述计算机程序82时实现上述实施例中的步骤。

所述电子设备8可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。该电子设备8可包括，但不仅限于，处理器80、存储器81。本领域技术人员可以理解，图8仅仅是电子设备8的举例，并不构成对电子设备8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。

所称处理器80可以是中央处理单元(Central Processing Unit，CPU)，该处理器80还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器81在一些实施例中可以是所述电子设备8的内部存储单元，例如电子设备8的硬盘或内存。所述存储器81在另一些实施例中也可以是所述电子设备8的外部存储设备，例如所述电子设备8上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器81还可以既包括所述电子设备8的内部存储单元也包括外部存储设备。所述存储器81用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器81还可以用于暂时地存储已经输出或者将要输出的数据。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/网络设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/网络设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种软件升级方法，其特征在于，所述方法包括：

在接收到服务平台发送的升级请求后，向交易终端发送升级询问指令；

接收所述交易终端反馈的询问结果，所述询问结果为所述交易终端通过待升级软件中集成的软件工具开发包执行所述升级询问指令生成的；

根据所述询问结果，确定是否对所述交易终端中的所述待升级软件进行升级。

2.如权利要求1所述的方法，其特征在于，所述升级请求包括所述待升级软件的升级版本；在接收到服务平台发送的升级请求后，所述方法还包括：

根据一个或多个所述升级请求，分别下载与每个所述升级请求对应的所述升级版本的安装包；

根据所述待升级软件的应用包名称，查询所述交易终端上的所述待升级软件；

调用所述待升级软件对应的询问接口，向所述交易终端发送所述升级询问指令；

其中，所述安装包用于基于统一的安装接口对所述交易终端中的所述待升级软件进行升级。

3.如权利要求1或2所述的方法，其特征在于，所述询问结果包括响应结果和认证凭据；所述根据所述询问结果，确定是否对所述交易终端中的所述待升级软件进行升级，包括：

通过调用所述服务平台的认证接口，对所述认证凭据进行验证；

若所述认证凭据通过，则根据所述响应结果判断是否升级所述交易终端中的所述待升级软件；

若所述认证凭据未通过，则对所述交易终端中的所述待升级软件进行升级；

其中，所述响应结果和所述认证凭据分别为所述交易终端基于所述软件工具开发包中的跨进程交互方法和凭据生成方法而生成的。

4.如权利要求3所述的方法，其特征在于，所述根据所述响应结果判断是否升级所述交易终端中的所述待升级软件，包括：

若所述响应结果为更新，则升级所述交易终端中的所述待升级软件；

若所述响应结果为不更新，则启动多次询问机制，所述多次询问机制用于在预设时长后向所述交易终端再次发送所述升级询问指令。

5.如权利要求3或4所述的方法，其特征在于，所述对所述交易终端中的所述待升级软件进行升级，包括：

通过二进制文件差分算法，计算所述待升级软件对应的所述升级版本的安装包和旧版本的安装包之间的二进制数据的差异；

根据所述二进制数据的差异生成差分文件；所述差分文件用于指示所述交易终端根据所述旧版本的安装包和所述差分文件合成升级安装包，以及根据所述升级安装包升级所述待升级软件。

6.如权利要求1至5任一项所述的方法，其特征在于，所述方法还包括：

基于跨进程通信，通过第一线程向所述交易终端发送所述升级询问指令；

通过第二线程对所述询问结果中的认证凭据进行验证并确定是否对所述待升级软件进行升级；

其中，所述第二线程为在所述第一线程之前下载所述升级版本的安装包的进程。

7.一种软件升级方法，其特征在于，所述方法包括：

接收客户端针对待升级软件发送的升级询问指令，所述升级询问指令为所述客户端在接收到服务平台发送的升级请求后生成的；

调用所述待升级软件中集成的软件工具开发包，执行所述升级询问指令，生成询问结果；

向所述客户端发送所述询问结果，所述询问结果用于指示所述客户端确定是否对所述待升级软件进行升级。

8.如权利要求7所述的方法，其特征在于，所述软件开发工具包还包括认证密钥，所述询问结果包括响应结果和认证凭据；

所述调用所述待升级软件中集成的软件工具开发包，执行所述升级询问指令，生成询问结果，包括：

调用所述软件工具开发包中的跨进程交互方法，执行所述升级询问指令，生成所述响应结果；

调用所述软件工具开发包中的凭据生成方法，根据所述认证密钥，生成所述认证凭据；

其中，所述认证密钥为所述服务平台针对开发软件生成的；所述认证凭据用于所述客户端对所述待升级软件的旧版本进行验证；所述响应结果用于所述客户端在对所述旧版本对应的认证凭据验证通过后，判断是否对所述待升级软件进行升级。

9.一种软件升级装置，其特征在于，所述装置包括：

发送单元，用于在接收到服务平台发送的升级请求后，向交易终端发送升级询问指令；

接收单元，用于接收所述交易终端反馈的询问结果，所述询问结果为所述交易终端通过待升级软件中集成的软件工具开发包执行所述升级询问指令生成的；

处理单元，用于根据所述询问结果，确定是否对所述交易终端中的所述待升级软件进行升级。

10.一种电子设备，其特征在于，所述电子设备包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6或者权利要求7至8任一项所述方法的步骤。

Images