CN109445826A - 一种应用的更新方法、装置及*** - Google Patents

Abstract

本发明提供一种应用的更新方法、装置及***，该更新方法接收服务器端发送的更新策略，其中，更新策略中包括更新条件和更新地址，在获取到用户信息后，判断用户信息是否满足更新条件，在满足更新条件的情况下，从更新地址中获取更新安装包，完成对应用的更新。由于仅对满足更新条件的应用进行更新，因此实现了对应用的定向更新，避免了对安装该应用的客户端全部进行应用的更新，提高了应用更新的灵活性。且，对不满足更新条件的应用不执行更新操作，节省了网络流量，提高了用户体验。

Description

一种应用的更新方法、装置及***

技术领域

本发明属于应用更新技术领域，尤其涉及一种应用的更新方法、装置及***。

背景技术

现有技术中，应用安装使用过程中出现问题后，需要更新已经安装的该应用才能解决该应用出现的问题。

但是，目前对应用的更新方法为对安装了该应用的客户端全部进行应用的更新，应用的更新缺乏灵活性。

发明内容

有鉴于此，本发明的目的在于提供一种应用的更新方法、装置及***，以解决现有技术中针对应用的更新方法不灵活的问题。

技术方案如下：

本发明提供一种应用的更新方法，应用于客户端，包括：

获取用户信息；

接收服务器端发送的更新策略；所述更新策略为对应用进行更新的策略，所述更新策略中至少包括更新条件和更新地址；

判断所述用户信息是否满足所述更新条件；

若判断所述用户信息满足所述更新条件，则从所述更新地址获取更新安装包，完成对应用的更新。

可选地，所述用户信息包括以下至少一项：设备型号、地理位置、身份标识；所述更新条件为设备型号、地理位置、身份标识中的一项或多项的组合；

其中，判断所述用户信息是否满足所述更新条件包括：

依次判断所述更新条件的各项信息是否分别与所述用户信息中对应的信息相同；若所述更新条件的各项信息分别与所述用户信息中对应的信息都相同，则判断所述用户信息满足所述更新条件。

可选地，获取用户信息之后，还包括：

将获取到的用户信息发送至服务器端，以根据所述用户信息中的一项或多项生成对应用进行更新的更新策略。

可选地，所述获取用户信息之前，还包括：

启动应用；

检测是否开启应用获取权限；

若检测开启了应用获取权限，则获取用户信息。

本发明还提供了一种应用的更新方法，应用于服务器端，包括：

接收客户端发送的获取更新策略的请求；

从预先生成的更新策略中获取与所述请求对应的更新策略；

将获取到的与所述请求对应的更新策略发送至所述客户端。

可选地，采用如下方法生成更新策略：

接收到用户信息后，根据存在更新需求的应用的用户信息，生成更新条件；

确定存储有更新安装包的更新地址；其中，所述更新安装包为满足所述更新需求的安装包；

根据所述更新条件和所述更新地址，生成更新策略。

本发明还提供了一种应用的更新装置，包括：

第一获取单元，用于获取用户信息；

第一接收单元，用于接收服务器端发送的更新策略；所述更新策略为对应用进行更新的策略，所述更新策略中至少包括更新条件和更新地址；

判断单元，用于判断所述用户信息是否满足所述更新条件；

更新单元，用于若判断所述用户信息满足所述更新条件，则从所述更新地址获取更新安装包，完成对应用的更新。

可选地，还包括：

第一发送单元，用于将获取到的用户信息发送至服务器端，以根据所述用户信息中的一项或多项生成对应用进行更新的更新策略。

本发明还提供了一种应用的更新装置，包括：

第二接收单元，用于接收客户端发送的获取更新策略的请求；

第二获取单元，用于从预先生成的更新策略中获取与所述请求对应的更新策略；

第二发送单元，用于将获取到的与所述请求对应的更新策略发送至所述客户端。

本发明还提供了一种应用的更新***，其特征在于，包括：

客户端；其中，所述客户端应用如上述的更新方法；

与所述客户端连接的服务器端；所述服务器端应用如上述的更新方法。

与现有技术相比，本发明提供的上述技术方案具有如下优点：

从上述技术方案可知，本申请中接收服务器端发送的更新策略，其中，更新策略中包括更新条件和更新地址，在获取到用户信息后，判断用户信息是否满足更新条件，在满足更新条件的情况下，从更新地址中获取更新安装包，完成对应用的更新。由于仅对满足更新条件的应用进行更新，因此实现了对应用的定向更新，避免了对安装该应用的客户端全部进行应用的更新，提高了应用更新的灵活性。且，对不满足更新条件的应用不执行更新操作，节省了网络流量，提高了用户体验。

附图说明

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

图1是本发明实施例提供的一种应用的更新方法的流程图；

图2是本发明实施例提供的另一种应用的更新方法的流程图；

图3是本发明实施例提供的另一种应用的更新方法的流程图；

图4是本发明实施例提供的一种应用的更新装置的结构示意图；

图5是本发明实施例提供的另一种应用的更新装置的结构示意图。

具体实施方式

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

本实施例提供了一种应用的更新方法，应用于客户端，所述客户端安装有至少一个应用，参见图1，该实施例包括以下步骤：

S101、获取用户信息；

在本实施例中，客户端安装有至少一个应用，当客户端上已经安装的应用启动后，获取用户信息。即客户端存在处于运行状态的应用时，执行获取用户信息的操作。其中，处于运行状态的应用包括前台运行的应用以及后台运行的应用这两种。

S102、接收服务器端发送的更新策略；所述更新策略为对应用进行更新的策略，所述更新策略中至少包括更新条件和更新地址；

在服务器端预先生成有更新策略，更新策略指的是对应用进行更新的策略，不同应用对应的更新策略是不同的。

客户端接收到的服务器端发送的更新策略是与客户端中当前处于运行状态的应用对应的更新策略。若客户端当前仅存在一个处于运行状态的应用时，则仅接收到与此应用对应的更新策略，若客户端当前存在多个处于运行状态的应用，则接收到分别与每个处于运行状态的应用对应的更新策略。

对于一个应用而言，由于该应用具有多个不同的功能，不同的功能存在漏洞(Bug)时均需要进行更新，每个功能的更新对应一条更新策略，因此，一个应用可以对应多条更新策略；当然，也可以一个应用对应一条更新策略。

更新策略中至少包括更新条件和更新地址，只有满足更新条件的应用才需要执行更新操作，更新地址指的是获取更新安装包的地址，更新地址可以为网络地址，以从网络地址处下载更新安装包。其中，更新安装包与网络地址一一对应，即一个网络地址处可以获取到一个更新安装包。

若一个应用对应多条更新策略，那么从一条更新策略的更新地址获取到的更新安装包仅能实现对该应用的某项功能的更新；若一个应用对应一条更新策略，那么从这一条更新策略的更新地址获取到的更新安装包可以实现对该应用的多项功能的更新。

S103、判断所述用户信息是否满足所述更新条件；

若判断所述用户信息满足所述更新条件，则执行步骤S104；

若判断所述用户信息不满足所述更新条件，则表示不需要执行对应用的更新操作，退出流程；

客户端安装的应用，存在漏洞(Bug)时需要对应用进行更新操作，以解决Bug，但是，针对同一应用而言，并不是安装有该应用的所有客户端在使用该应用时都存在Bug，因此，并不需要对不存在Bug的应用进行更新。

本实施例中，只有满足更新条件的应用才需要执行更新操作，不满足更新条件的应用不需要执行更新操作。

若客户端仅接收到一个应用的更新策略，那么，判断用户信息是否满足与该应用对应的更新策略中的更新条件，若用户信息满足该应用的更新条件，则执行后续对该应用的更新操作。

若客户端接收到与多个应用分别对应的更新策略，则针对每个应用，分别判断用户信息是否满足与该应用对应的更新策略中的更新条件，若用户信息满足该应用的更新条件，则执行后续对该应用的更新操作，若用户信息不满足该应用的更新条件，则不执行后续对该应用的更新操作。

S104、从所述更新地址获取更新安装包，完成对应用的更新。

从更新地址获取更新安装包，并利用更新安装包对应用进行更新。具体为从网络地址中下载更新安装包，并利用下载的更新安装包对应用进行更新。本实施例中利用更新安装包对应用的更新操作与现有技术中利用安装包对应用的更新操作类似，此处不再赘述。

从上述技术方案可知，本实施例中接收服务器端发送的更新策略，其中，更新策略中包括更新条件和更新地址，在获取到用户信息后，判断用户信息是否满足更新条件，在满足更新条件的情况下，从更新地址中获取更新安装包，完成对应用的更新。由于仅对满足更新条件的应用进行更新，因此实现了对应用的定向更新，避免了对安装该应用的客户端全部进行应用的更新，提高了应用更新的灵活性。且，对不满足更新条件的应用不执行更新操作，节省了网络流量，提高了用户体验。

本实施例还公开了另一种应用的更新方法，应用于客户端，所述客户端安装有至少一个应用，参见图2，该实施例包括以下步骤：

S201、启动应用；

启动客户端上已经安装的应用，使得应用处于运行状态，其中，应用可以是处于前台运行中，也可以是处于后台运行中。

S202、检测是否开启了应用获取权限；

若检测开启了应用获取权限，则执行步骤S203；

若检测没有开启应用获取权限，则表示此应用没有获取用户信息的权限，也不能根据获取的用户信息确定是否执行更新操作，退出流程；

可以理解的是，针对没有开启应用获取权限的应用，该应用的更新方法与现有技术中应用的更新方法类似，即只要存在该应用的更新安装包，则无论此应用是否需要更新都直接对该应用执行更新操作。

在实际应用中，安装了应用则为此应用配置应用获取权限属性按钮，类似于现有客户端上设置的属性按钮，如类似于开启无线连接的按钮；默认状态下应用获取权限属性为关闭，点击应用获取权限属性按钮，则将应用获取权限属性修改为开启。

在初次开启安装的应用时，客户端的用户根据自身需求设置了该应用的应用获取权限属性后，该应用的应用获取权限属性将不发生变化，如初次开启安装的应用时将该应用的应用获取权限属性设置为开启，则下次在启动该应用时，该应用的应用获取权限属性仍然为开启，不需要用户再次设置应用获取权限属性。

S203、获取用户信息；

本实施例中用户信息包括以下至少一项：设备型号、地理位置、身份标识。

设备型号指的是安装应用的客户端的设备型号，如iphone7、华为mate10 等；通过从客户端的硬件信息中获取到设备型号。

地理位置指的是安装应用的客户端当前所处的地理位置，如上海、北京；可以通过客户端自身具备的定位功能获取到地理位置。

身份标识指的是标识客户端用户的身份信息，如管理员。

在其他实施例中，用户信息还可以包括用户姓名。

S204、将获取到的用户信息发送至服务器端，以根据所述用户信息中的一项或多项生成对应用进行更新的更新策略；

各个客户端获取到用户信息后，将用户信息发送至服务器端存储并使用，使得服务器端可以根据接收到的用户信息生成对应用的更新策略。

如针对客户端A，开启应用a后，获取到的用户信息为设备型号为华为 mate10、地理位置为上海、身份标识为管理员；针对客户端B，开启应用a 后，获取到的用户信息为设备型号为iphone7、地理位置为上海、身份标识为总管理员；客户端C，开启应用a后，获取到的用户信息为设备型号为小米5、地理位置为北京、身份标识为管理员。

服务器端接收到客户端A发送的设备型号为华为mate10、地理位置为上海、身份标识为管理员，客户端B发送的设备型号为iphone7、地理位置为上海、身份标识为总管理员；客户端C发送的设备型号为iphone7、地理位置为北京、身份标识为管理员。

若发现应用a中实现对费用管理的功能发生Bug，由于仅管理员的客户端安装的应用a具有对费用管理的功能，因此，仅管理员下载安装的应用a需要执行更新操作，从而生成的更新策略可以为对管理员客户端安装的应用a利用网址1处的更新安装包执行对费用管理功能的更新。即根据用户信息中的身份标识这一项生成对应用的更新策略。

若发现应用a中只有在安卓***上运行时实现对费用管理的功能时存在 Bug，从而生成的更新策略为对管理员所使用的安卓***客户端上安装的应用 a利用网址1处的更新安装包执行对费用管理功能的更新。即根据用户信息中的设备型号和身份标识这两项生成对应用的更新策略。

S205、接收服务器端发送的更新策略；所述更新策略为对应用进行更新的策略，所述更新策略中至少包括更新条件和更新地址；

本实施例中更新条件为设备型号、地理位置、身份标识中的一项或多项的组合；

服务器端生成针对一个应用的更新策略后，向已经安装了此应用的全部客户端发送针对该应用的更新策略。客户端接收服务器端发送的更新策略。

如客户端接收到的更新策略为对管理员客户端安装的应用a利用网址1 处的更新安装包执行对费用管理功能的更新，这一更新策略中更新条件为管理员，更新地址为网址1。即更新条件仅包括身份标识这一项。

如客户端接收到的更新策略为对管理员所使用的安卓***客户端上安装的应用a利用网址1处的更新安装包执行对费用管理功能的更新，这一更新策略中更新条件为管理员、安卓***的设备，更新地址为网址1。即更新条件为设备型号和身份标识这两项的组合。

需要注意的是，在本实施例中在步骤S203中获取到用户信息后，先执行的是步骤S204的将获取到的用户信息发送至服务器端的操作，然后再执行步骤S205的接收服务器端发送的更新策略的操作，但是在实际应用中，并不限定步骤S204和步骤S205执行的先后顺序。

S206、依次判断所述更新条件的各项信息是否分别与所述用户信息中对应的信息相同；

若所述更新条件中的各项信息分别与所述用户信息中对应的信息都相同，则判断所述用户信息满足所述更新条件，执行步骤S207；

若所述更新条件中有一项信息与所述用户信息中对应的信息不同，则判断所述用户信息不满足更新条件，退出流程；

若更新条件中仅包括一项信息，如对管理员客户端安装的应用a利用网址1处的更新安装包执行对费用管理功能的更新的这一更新策略，更新条件仅包括身份标识，判断所述更新条件中的身份标识是否与获取到的用户信息中的身份标识是否相同。例如，客户端A获取到的用户信息为设备型号为华为mate10、地理位置为上海、身份标识为管理员，判断上述更新策略中更新条件的身份标识“管理员”与客户端A的用户信息中身份标识“管理员”是否相同，判断更新策略中的身份标识与用户信息中的身份标识是相同的，则判断用户信息满足更新条件；

若更新条件中包括多项信息，如对管理员所使用的安卓***客户端上安装的应用a利用网址1处的更新安装包执行对费用管理功能的更新的这一更新策略，更新条件为设备型号和身份标识这两项的组合，则依次判断所述更新条件中的设备型号是否与用户信息中的设备型号相同，所述更新条件中的身份标识是否与用户信息中的身份标识相同。例如，客户端A获取到的用户信息为设备型号为华为mate10、地理位置为上海、身份标识为管理员，判断上述更新策略中更新条件的设备型号“安卓***”与客户端A的用户信息中的设备型号“华为mate10”是否相同，得到的判断结果为更新条件的设备型号与用户信息中的设备型号相同；再判断上述更新策略中更新条件的身份标识“管理员”与客户端A的用户信息中身份标识“管理员”是否相同，得到的判断结果为更新策略中的身份标识与用户信息中的身份标识相同。由于更新条件中的每一项分别与用户信息中对应的信息相同，则判断所述用户信息满足所述更新条件。

例如，客户端C获取到的用户信息为设备型号为iphone7、地理位置为北京、身份标识为管理员，判断上述更新策略中更新条件的设备型号“安卓***”与客户端C的用户信息中的设备型号“iphone7”是否相同，得到的判断结果为更新条件的设备型号与用户信息中的设备型号不同；再判断上述更新策略中更新条件的身份标识“管理员”与客户端C的用户信息中身份标识“管理员”是否相同，得到的判断结果为更新策略中的身份标识与用户信息中的身份标识相同。由于更新条件中两项中的一项即设备型号与用户信息中对应的设备型号这一信息是不同的，则判断所述用户信息不满足所述更新条件。

S207、从所述更新地址获取更新安装包，完成对应用的更新。

本实施例中步骤S207的实现方式与上一实施例中步骤S104的实现方式类似，此处不再赘述。

从上述技术方案可知，本实施例中接收服务器端发送的更新策略，其中，更新策略中包括更新条件和更新地址，在获取到用户信息后，判断用户信息是否满足更新条件，在满足更新条件的情况下，从更新地址中获取更新安装包，完成对应用的更新。由于仅对满足更新条件的应用进行更新，因此实现了对应用的定向更新，避免了对安装该应用的客户端全部进行应用的更新，提高了应用更新的灵活性。且，对不满足更新条件的应用不执行更新操作，节省了网络流量，提高了用户体验。同时，只有在检测开启了应用获取权限后才获取用户信息并根据获取到的用户信息以及接收到的更新策略，完成对应用的更新，使得用户可以根据自身需求选择是否要按照本发明提供的应用的更新方法实现对应用的更新。

本实施例还提供了一种应用的更新方法，应用于服务器端，参见图3，该实施例包括以下步骤：

S301、接收客户端发送的获取更新策略的请求；

本实施例中客户端为应用图1或图2所示应用的更新方法的客户端。在客户端启动已经安装的应用后，会向服务器端发送获取该启动应用的更新策略的请求。

S302、从预先生成的更新策略中获取与所述请求对应的更新策略；

服务器端预先生成有对应用进行更新的更新策略，不同应用对应的更新策略不同。从预先生成的多条更新策略中获取与所述请求对应的更新策略。

S303、将获取到的与所述请求对应的更新策略发送至所述客户端。

将获取到的与所述请求对应的更新策略发送至客户端，使得客户端得到与启动的应用对应的更新策略，从而指导该启动应用的后续更新操作。

从上述技术方案可知，本实施例中服务器端接收到客户端发送的获取更新策略的请求后，从预先生成的更新策略中获取与所述请求对应的更新策略，并将获取到的与所述请求对应的更新策略发送至所述客户端。使得客户端接收到更新策略后，指导客户端已经安装的应用的更新操作，实现了灵活地对应用的更新，可以满足多种不同场合的需求。

可选地，在本实施例中，采用如下方法生成更新策略：

步骤1：接收到用户信息后，根据存在更新需求的应用的用户信息，生成更新条件。

示例性的，服务器端接收到客户端A在启动应用a后发送的设备型号为华为mate10、地理位置为上海、身份标识为管理员，客户端B发送的设备型号为iphone7、地理位置为上海、身份标识为总管理员；客户端C发送的设备型号为iphone7、地理位置为北京、身份标识为管理员。若发现应用a中实现对费用管理的功能发生Bug，由于仅管理员的客户端安装的应用a具有对费用管理的功能，因此，仅管理员下载安装的应用a需要执行更新操作，即应用a 存在更新需求，从而针对应用a生成更新条件为管理员。

需要注意的是，在客户端A上安装了应用a和应用b，针对应用a服务器端接收到的用户信息与针对应用b服务器端接收到的用户信息存在相同的部分，如设备型号为华为mate10、地理位置为上海；但是，针对不同应用，身份标识可能是不同的，如应用a为管理应用，那么，获取到客户端A的身份标识是管理员；应用b为视频观看应用，那么获取到客户端A的身份标识是 VIP会员。而应用b不存在更新需求，进而不会生成针对应用b的更新条件。

步骤2：确定存储有更新安装包的更新地址；其中，所述更新安装包为满足所述更新需求的安装包；

应用a存在对费用管理功能的更新需求，且对应用a的费用管理功能的更新安装包存储在http://www.****.com地址下，则确定存储有对应用a的费用管理功能的更新安装包的更新地址为http://www.****.com。

步骤3：根据所述更新条件和所述更新地址，生成更新策略。

示例性的，根据更新条件管理员以及对应用a的费用管理功能的更新安装包的网络地址http://www.****.com，生成的更新策略为：对管理员客户端安装的应用a利用http://www.****.com处的更新安装包执行对费用管理功能的更新。

对应上述应用的更新方法，本发明还提供了一种应用的更新装置，所述装置可以集成到客户端，如移动设备、笔记本电脑、台式电脑等设备。

所述装置的结构示意图请参阅图4所示，本实施例中更新装置包括：

第一获取单元401、第一接收单元402、判断单元403和更新单元404；

第一获取单元401，用于获取用户信息；

第一接收单元402，用于接收服务器端发送的更新策略；所述更新策略为对应用进行更新的策略，所述更新策略中至少包括更新条件和更新地址；

判断单元403，用于判断所述用户信息是否满足所述更新条件；

在所述更新条件中包括多项信息时，如包括身份标识、设备型号这两项信息时，需要分别判断更新条件中的身份标识与用户信息中的身份标识是否相同，更新条件中的设备型号与用户信息中的设备型号是否相同。只有所述更新条件中包括的每一项信息分别与用户信息中的对应信息均相同时，才判断所述用户信息满足更新条件，只要所述更新条件中有一项信息与用户信息中对应的信息不相同，则判断所述用户信息不满足更新条件。

更新单元404，用于若判断所述用户信息满足所述更新条件，则从所述更新地址获取更新安装包，完成对应用的更新。

可选地，本实施例中，还可以包括：

第一发送单元405；

第一发送单元405，用于将获取到的用户信息发送至服务器端，以根据所述用户信息中的一项或多项生成对应用进行更新的更新策略。

从上述技术方案可知，本实施例中接收服务器端发送的更新策略，其中，更新策略中包括更新条件和更新地址，在获取到用户信息后，判断用户信息是否满足更新条件，在满足更新条件的情况下，从更新地址中获取更新安装包，完成对应用的更新。由于仅对满足更新条件的应用进行更新，因此实现了对应用的定向更新，避免了对安装该应用的客户端全部进行应用的更新，提高了应用更新的灵活性。且，对不满足更新条件的应用不执行更新操作，节省了网络流量，提高了用户体验。

对应上述应用的更新方法，本发明还提供了另一种应用的更新装置，所述装置可以集成到服务器端。

所述装置的结构示意图请参阅图5所示，本实施例中更新装置包括：

第二接收单元501、第二获取单元502和第二发送单元503；

第二接收单元501，用于接收客户端发送的获取更新策略的请求；

第二获取单元502，用于从预先生成的更新策略中获取与所述请求对应的更新策略；

本实施例中，生成更新策略的方式为：

接收到用户信息后，根据存在更新需求的应用的用户信息，生成更新条件；确定存储有更新安装包的更新地址；其中，所述更新安装包为满足所述更新需求的安装包；根据所述更新条件和所述更新地址，生成更新策略。

第二发送单元503，用于将获取到的与所述请求对应的更新策略发送至所述客户端。

从上述技术方案可知，本实施例中服务器端接收到客户端发送的获取更新策略的请求后，从预先生成的更新策略中获取与所述请求对应的更新策略，并将获取到的与所述请求对应的更新策略发送至所述客户端。使得客户端接收到更新策略后，指导客户端已经安装的应用的更新操作，实现了灵活地对应用的更新，可以满足多种不同场合的需求。

对应上述应用的更新装置，本发明还提供了一种应用的更新***，包括客户端和服务器端，客户端采用图1或图2所示的应用的更新方法实现对已经安装的应用的更新，服务器端采用图3所示的应用的更新方法生成对应用的更新策略后，发送至客户端，使得客户端根据接收到的更新策略指导对应用的更新操作。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例提供的装置而言，由于其与实施例提供的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种应用的更新方法，其特征在于，应用于客户端，包括：

获取用户信息；

接收服务器端发送的更新策略；所述更新策略为对应用进行更新的策略，所述更新策略中至少包括更新条件和更新地址；

判断所述用户信息是否满足所述更新条件；

若判断所述用户信息满足所述更新条件，则从所述更新地址获取更新安装包，完成对应用的更新。

2.根据权利要求1所述的更新方法，其特征在于，所述用户信息包括以下至少一项：设备型号、地理位置、身份标识；所述更新条件为设备型号、地理位置、身份标识中的一项或多项的组合；

其中，判断所述用户信息是否满足所述更新条件包括：

依次判断所述更新条件的各项信息是否分别与所述用户信息中对应的信息相同；

若所述更新条件的各项信息分别与所述用户信息中对应的信息都相同，则判断所述用户信息满足所述更新条件。

3.根据权利要求1所述的更新方法，其特征在于，获取用户信息之后，还包括：

将获取到的用户信息发送至服务器端，以根据所述用户信息中的一项或多项生成对应用进行更新的更新策略。

4.根据权利要求3所述的更新方法，其特征在于，所述获取用户信息之前，还包括：

启动应用；

检测是否开启应用获取权限；

若检测开启了应用获取权限，则获取用户信息。

5.一种应用的更新方法，其特征在于，应用于服务器端，包括：

接收客户端发送的获取更新策略的请求；

从预先生成的更新策略中获取与所述请求对应的更新策略；

将获取到的与所述请求对应的更新策略发送至所述客户端。

6.根据权利要求5所述的更新方法，其特征在于，采用如下方法生成更新策略：

接收到用户信息后，根据存在更新需求的应用的用户信息，生成更新条件；

确定存储有更新安装包的更新地址；其中，所述更新安装包为满足所述更新需求的安装包；

根据所述更新条件和所述更新地址，生成更新策略。

7.一种应用的更新装置，其特征在于，包括：

第一获取单元，用于获取用户信息；

第一接收单元，用于接收服务器端发送的更新策略；所述更新策略为对应用进行更新的策略，所述更新策略中至少包括更新条件和更新地址；

判断单元，用于判断所述用户信息是否满足所述更新条件；

更新单元，用于若判断所述用户信息满足所述更新条件，则从所述更新地址获取更新安装包，完成对应用的更新。

8.根据权利要求7所述的更新装置，其特征在于，还包括：

第一发送单元，用于将获取到的用户信息发送至服务器端，以根据所述用户信息中的一项或多项生成对应用进行更新的更新策略。

9.一种应用的更新装置，其特征在于，包括：

第二接收单元，用于接收客户端发送的获取更新策略的请求；

第二获取单元，用于从预先生成的更新策略中获取与所述请求对应的更新策略；

第二发送单元，用于将获取到的与所述请求对应的更新策略发送至所述客户端。

10.一种应用的更新***，其特征在于，包括：

客户端；其中，所述客户端应用如权利要求1-4任意一项所述的更新方法；

与所述客户端连接的服务器端；所述服务器端应用如权利要求5-6任意一项所述的更新方法。