CN118819603A - 应用更新方法、通信系统及电子设备 - Google Patents

Abstract

本申请公开了一种应用更新方法、通信系统及电子设备，涉及终端技术领域，能够解决开发者证明更换后应用无法正常更新的问题，无需用户手动卸载开发者证明更换前的旧版本应用。该方案中，服务器上架新版本的第一应用后，终端设备可从服务器下载该新版本的第一应用。其中，新版本的第一应用包括第一证明以及证明变更信息，第一证明为新版本的第一应用的开发者证明。终端设备在完成对该新版本的第一应用的下载后，判断本地已安装的旧版本的第一应用的开发者证明与第一证明是否一致，若不一致，则终端设备根据证明变更信息，判断是否允许将旧版本的第一应用更新为新版本的第一应用。若一致，则终端设备对第一应用执行第一版本到第二版本的正常更新。

Description

应用更新方法、通信系统及电子设备

技术领域

本申请涉及终端技术领域，尤其涉及一种应用更新方法、通信系统及电子设备。

背景技术

当前，在一些操作系统中，使用应用的包名(PackageName)作为应用的唯一标识，在安装、升级、运行应用时，相同包名的应用会被识别为相同应用。当前也有一些系统基于开放性的考虑，支持从多方市场/渠道(例如浏览器、应用内安装)安装应用。然而不同开发者在不同渠道分发的不同应用，包名无法保证全局唯一，这会诱发诸多的包名冲突问题，影响了应用在系统中的正常工作，同时对开发者的体验较差。为此，当前应用的唯一标识普遍采用“包名+开发者证明”的方式，其中，开发者证明用于唯一标识开发该应用的开发者身份。

然而，该应用的开发者证明发生变化时，该应用的唯一标识也会发生变化。当需要在系统上安装开发者证明变化后的新版应用时，需要用户手动卸载开发者证明变化前的旧版应用后，才可安装开发者证明变化后的新版应用，用户体验不佳。

发明内容

本申请提供一种应用更新方法、通信系统及电子设备，用户终端从应用市场下载开发者证明变化后的新版应用时，能够利用新版应用中携带的证明更换信息进行正常更新的校验。如此，可在校验成功后直接安装该新版应用，并覆盖本地已安装的开发者证明变化前的旧版应用，无需用户手动卸载旧版应用。

为达到上述目的，本申请采用如下技术方案：

第一方面，提供一种应用更新方法，应用于包括第一终端设备和服务器的通信系统，其中，服务器与第一终端设备建立通信连接。在上述方法中，服务器向第一终端设备发送第二版本的第一应用，该第二版本的第一应用中包括第一证明以及证明变更信息。其中，第一证明为第二版本的第一应用的开发者证明。第一终端设备从服务器获取到该第二版本的第一应用后，可判断本地已安装的第一版本的第一应用的开发者证明与上述第一证明是否一致。若不一致，说明第二版本的第一应用相较于第一版本的第一应用而言，开发者证明已发生变化。现有的第一终端设备会将两者当作不同开发者开发的不同应用，无法将两者识别为同一应用的不同版本，且会因为包名冲突而无法正常安装，需要用户手动卸载第一版本的第一应用后，才能正常安装第二版本的第一应用。

而在本申请提供的方案中，由于第一终端设备获取到第二版本的第一应用中包括证明变更信息，因此，若检测到第一版本的第一应用的开发者证明与上述第一证明不一致，则此时第一终端设备可根据该证明变更信息，判断是否允许将第一版本的第一应用更新为第二版本的第一应用。

当然，若检测到第一版本的第一应用的开发者证明与上述第一证明一致，则此时第一终端设备能够将第二版本的第一应用与第一版本的第一应用，识别为同一应用的不同版本，第一终端设备可进行正常更新，也即此时第一终端设备可对第一应用执行第一版本到第二版本的更新安装。

可选地，上述开发者证明可以是开发者证书、开发者公钥或其衍生、或其它可用于证明开发者身份的凭证等。上述第一应用可以是视频类应用、聊天类应用、游戏类应用等任意可安装于终端设备的本地操作系统中的应用程序。以第一应用为游戏应用A为例，第一版本的第一应用可以是游戏应用A的1.0版本，该版本应用的开发者证明可以是应用研发阶段所用的测试公钥，第二版本的第一应用可以是游戏应用A的2.0版本，该版本应用的开发者证明可以是应用上线阶段所用的商用公钥。

上述第一方面提供的方案，当开发者发布的新版本应用采用的是变更后的新开发者证明时，服务器(或者称应用市场、应用商店)下发的新版本应用中会携带有证明变更信息。因此，第一终端设备(或者称为用户设备、用户终端)从服务器处获取到新版本应用后，可以先利用通过新版本应用中携带的证明更换信息进行正常更新的校验。如此，可在校验成功后第一终端设备可对本地已安装的开发者证明变化前的旧版本应用进行正常更新，即直接安装该新版本应用并覆盖旧版本应用。而不是直接提醒用户手动卸载本地已安装的开发者证明变化前的旧版本应用，再进行新版本应用的安装。

在一种可能的实施方式中，证明变更信息包括开发者证明列表，开发者证明列表中包括允许更新为第二版本的第一应用的开发者证明。例如，以开发者证明为开发者公钥为例，开发者证明列表可以是开发者公钥列表，其中包括允许更新为第二版本的第一应用的一个或多个历史使用过的开发者公钥。又例如，以开发者证明为开发者证书为例，开发者证明列表可以是开发者证书列表，其中包括允许更新为第二版本的第一应用的一个或多个历史使用过的开发者证书。如此，当开发者发布的新版本应用需要采用变更后的新开发者证明时，通过在证明变更信息中写入所有允许更新为新版本应用的历史开发者证明，以向第一终端设备准确声明开发者证明列表中的所有开发者证明对应版本应用都能够正常更新为新版本应用。

在一种可能的实施方式中，若第一终端设备检测到第一版本的第一应用的开发者证明与上述第一证明不一致，则此时第一终端设备从证明变更信息中获取上述开发者证明列表，以判断开发者证明列表中是否包含第一版本的第一应用的开发者证明。也即，第一终端设备所执行的正常更新的校验，可以是通过校验本地安装的旧版本应用的开发者证明是否在证明变更信息的开发者证明列表中。

在一种可能的实施方式中，若第一终端设备检测到开发者证明列表中包含第一版本的第一应用的开发者证明，相当于证明变更信息中已准确声明了第一版本的第一应用允许更新为第二版本的第一应用，则此时可以认为正常更新的校验通过，第一终端设备直接安装该新版本应用并覆盖旧版本应用。

例如，以第二版本的第一应用的开发者证明为开发者公钥E，开发者公钥列表记录有开发者公钥A、B、C为例，若第一版本的第一应用的开发者证明为开发者公钥A，则第一终端设备在下载第二版本的第一应用后，对证明变更信息的校验会通过(开发者公钥列表中包含A)，第一终端设备执行第二版本的第一应用的正常覆盖更新。

若第一版本的第一应用的开发者证明为开发者公钥D，则第一终端设备在下载第二版本的第一应用后，对证明变更信息的校验会不通过(开发者公钥列表中不包含D)，第一终端设备不会执行第二版本的第一应用的正常覆盖更新。此时第一终端设备可以提醒用户手动卸载本地已安装的开发者证明变化前的旧版本应用，再进行新版本应用的安装。

在一种可能的实施方式中，证明变更信息包括更新路径，更新路径中包括第一应用的至少两个开发者证明之间的更新规则。例如，以开发者证明为开发者公钥为例，更新路径可以是开发者公钥A->开发者公钥B->开发者公钥C，相当于声明了只允许开发者公钥A对应的版本应用更新到开发者公钥B对应的版本应用，开发者公钥B对应的版本应用更新到开发者公钥C对应的版本应用，而不允许开发者公钥A对应的版本应用跳跃更新到开发者公钥C对应的版本应用。

如此，当开发者发布的新版本应用需要采用变更后的新开发者证明时，通过在证明变更信息中写入应用的各个开发者证明之间的更新路径规则，以向第一终端设备准确声明证明变更信息中的哪些开发者证明对应版本应用能够正常更新为新版本应用，证明变更信息中的哪些开发者证明对应版本应用不能够正常更新为新版本应用。也即证明变更信息中可能会存在一些开发者证明对应版本应用，是不允许正常更新为当前所下载的新版本应用的。适用于存在有兼容的版本应用更新和不兼容的版本应用更新的场景。

在一种可能的实施方式中，若第一终端设备检测到第一版本的第一应用的开发者证明与上述第一证明不一致，则此时第一终端设备可以从证明变更信息中获取上述更新路径，以判断第一版本的第一应用与第二版本的第一应用之间，是否满足更新路径的更新规则。也即，第一终端设备所执行的正常更新的校验，可以是通过校验新旧版本应用的开发者证明之间是否符合证明变更信息所记载的更新路径规则。

在一种可能的实施方式中，若第一终端设备检测到第一版本的第一应用与第二版本的第一应用之间满足更新路径的更新规则，相当于证明变更信息中已准确声明了第一版本的第一应用允许更新为第二版本的第一应用，则此时可以认为正常更新的校验通过，第一终端设备直接安装该新版本应用并覆盖旧版本应用。

例如，以第二版本的第一应用的开发者证明为开发者公钥B，证明变更信息中记录有开发者公钥A->开发者公钥B->开发者公钥C的更新路径，以及开发者公钥D->开发者公钥E->开发者公钥C的更新路径为例。若第一版本的第一应用的开发者证明为开发者公钥A，则第一终端设备在下载第二版本的第一应用后，对证明变更信息的校验会通过(存在开发者公钥A->开发者公钥B的更新路径规则)，第一终端设备执行第二版本的第一应用的正常覆盖更新。

若第一版本的第一应用的开发者证明为开发者公钥D，则第一终端设备在下载第二版本的第一应用后，对证明变更信息的校验会不通过(不存在开发者公钥D->开发者公钥B的更新路径规则)，第一终端设备不会执行第二版本的第一应用的正常覆盖更新。

在一种可能的实施方式中，证明变更信息包括其他开发者证明对第一证明的签名信息，其他开发者证明为允许更新为第二版本的第一应用的开发者证明。如此，当开发者发布的新版本应用需要采用变更后的新开发者证明时，可以利用允许更新的旧版本应用的开发者证明对该新开发者证明进行签名。然后证明变更信息中可以写入这些签名信息，以向第一终端设备准确声明所有对新开发者证明签名过的旧开发者证明所对应版本应用，都能够正常更新为新版本应用。

可选地，开发者证明为开发者签名密钥，开发者签名密钥包括开发者私钥和开发者公钥。上述其他开发者证明对第一证明的签名信息，可以是其他开发者私钥对第一开发者私钥(即第一证明)的签名。可以理解，由于开发者私钥都是开发者私人持有，而开发者公钥都是公开。因此，如果开发者使用旧私钥对新私钥进行签名，证明两个私钥都为开发者持有，可以说明开发者允许旧私钥对应的版本应用更新为新私钥对应的版本应用。需要说明的是，如果开发者没有旧私钥(私钥丢失)，则无法为新密钥签名。因此，这种实施方式适用于开发者仍持有旧私钥的场景。

在一种可能的实施方式中，若第一终端设备检测到第一版本的第一应用的开发者证明与上述第一证明不一致，则此时第一终端设备从证明变更信息中获取上述签名信息，以判断签名信息中是否包含第一版本的第一应用的开发者证明对第一证明的签名信息。也即，第一终端设备所执行的正常更新的校验，可以是通过校验证明变更信息中是否有本地安装的旧版本应用的开发者证明对第一证明的签名。

可选地，签名密钥中私钥签名的内容可由公钥解密。因此，第一终端设备可以使用本地安装的旧版本应用的开发者公钥对证明变更信息中签名信息进行解密。若成功解密出签名信息中的第一证明，则第一终端设备可以认为正常更新的校验通过。第一终端设备直接安装该新版本应用并覆盖旧版本应用。若未解密出签名信息或者解密出的开发者证明并非第一证明，则第一终端设备可以认为正常更新的校验不通过，第一终端设备不会执行第二版本的第一应用的正常覆盖更新。

在一种可能的实施方式中，证明变更信息包括第一应用的至少两个开发者证明之间的签名信息。其中，该签名信息中可以包括其他开发者证明对第一证明的签名信息。例如，以开发者证明为开发者签名密钥为例，证明变更信息包括开发者密钥A签名开发者密钥B->开发者密钥B签名开发者密钥C->开发者密钥C签名开发者密钥D。

当第一证明为开发者密钥D时，作为一种实施方式，由于这些签名信息中一旦当前的签名信息被成功解密，后续的签名信息都会被解密，相当于声明了这些被解密的签名信息对应的版本应用都可以更新到新版本应用。作为另一种实施方式，由于这些签名信息中一旦当前的签名信息被成功解密，后续的签名信息都会被解密，相当于声明了这些被解密的签名信息对应的版本应用的更新路径，因此，可以按照前面的更新路径的校验方式，判断是否能够更新到新版本应用。这种通过签名的方式来声明是否允许更新为新版本应用的开发者证明，可以具有更强的安全性。

在一种可能的实施方式中，在服务器向第一终端设备发送第二版本的第一应用之前，服务器向第一终端设备发送第一版本的第一应用，其中，第一版本的第一应用包括第二证明，第二证明为第一版本的第一应用的开发者证明。也就是说，此时由于第一应用的开发者证明还未发生变化，服务器下发的第一应用不会携带了证明变更信息。第一终端设备从服务器获取到第一版本的第一应用后，第一终端设备可以正常安装第一版本的第一应用。

可选地，上述服务器可以是用于对应用程序进行管理和分发的应用分发服务器，如提供应用市场业务的云端服务器，或者其他可供终端用户对应用进行下载的应用分发渠道。

在一种可能的实施方式中，通信系统还包括第二终端设备，在服务器向第一终端设备发送第二版本的第一应用之前，第二终端设备向服务器发送针对第一应用的证明变更请求，服务器接收到第二终端设备的证明变更请求时，根据证明变更请求生成证明变更信息，服务器将证明变更信息发送给第二终端设备。如此，当开发者需要变更第一应用的开发者证明时，可以通过第二终端设备向服务器申请证明变更，从而服务器可以根据该申请，向开发者颁发用于证明旧开发者证明对应的版本应用合法更新为新开发者证明对应的版本应用的证明变更信息。从而通过服务器统一管控开发者证明的变更，可以有效防止开发者证明的滥用、盗用、篡改。

可选地，上述服务器可以是用于对开发者证书进行统一签发和管理的证书服务器。可选地，上述证书服务器与应用分发服务器可以为两个独立的服务器，也可以是同一服务器中两个不同的功能模块。

在一种可能的实施方式中，在服务器向第一终端设备发送第二版本的第一应用之前，第二终端设备向服务器发送第二版本的第一应用，第二版本的第一应用包括第一证明以及证明变更信息。如此，开发者通过第二终端设备获取到服务器颁发的合法证明变更信息后，若发布的新版本应用采用的是变更后的新开发者证明，则可以将该证明更新信息添加到该新版本应用中并上传服务器以待第一终端设备下载。从而第一终端设备从服务器下载该新版本应用后，可以利用新版本应用中携带的合法证明变更信息对该应用进行正常更新校验，校验通过后可以允许新版本应用直接在旧版本应用上正常更新。

在一种可能的实施方式中，通信系统还包括第二终端设备，在服务器向第一终端设备发送第一版本的第一应用之前，第二终端设备向服务器发送第一版本的第一应用，第一版本的第一应用包括第二证明。也就是说，此时开发者发布的旧版本应用的开发者证明还未发生变化，因此，不用添加证明更新信息到旧版本应用中，直接上传到服务器即可。

在一种可能的实施方式中，在第一终端设备从服务器获取第二版本的第一应用之后，第一终端设备根据第二版本的第一应用的包名，获取与包名对应的第一版本的第一应用。以通过判断本地是否有相同包名的应用，来确定第一终端设备之前是否安装过该应用的其他版本。

第二方面，提供一种应用更新方法，应用于通信系统中的第一终端设备，该通信系统包括第一终端设备和服务器，其中，服务器与第一终端设备建立通信连接。该方法中，第一终端设备可以从服务器获取到第二版本的第一应用，该第二版本的第一应用中包括第一证明以及证明变更信息。其中，第一证明为第二版本的第一应用的开发者证明。然后第一终端设备可判断本地已安装的第一版本的第一应用的开发者证明与上述第一证明是否一致。若不一致，则第一终端设备可根据该证明变更信息，判断是否允许将第一版本的第一应用更新为第二版本的第一应用。若一致，则第一终端设备对第一应用执行第一版本到第二版本的更新安装。

在一种可能的实施方式中，证明变更信息包括开发者证明列表，开发者证明列表中包括允许更新为第二版本的第一应用的开发者证明。

在一种可能的实施方式中，第一终端设备从证明变更信息中获取开发者证明列表后，可以判断开发者证明列表中是否包含第一版本的第一应用的开发者证明。

在一种可能的实施方式中，若第一终端设备检测到开发者证明列表中包含第一版本的第一应用的开发者证明，则第一终端设备对第一应用执行第一版本到第二版本的更新安装。

在一种可能的实施方式中，证明变更信息包括更新路径，更新路径中包括第一应用的至少两个开发者证明之间的更新规则。

在一种可能的实施方式中，第一终端设备从证明变更信息中获取更新路径后，可以判断第一版本的第一应用与第二版本的第一应用之间，是否满足更新路径的更新规则。

在一种可能的实施方式中，若第一终端设备检测到第一版本的第一应用与第二版本的第一应用之间，满足更新路径的更新规则，则第一终端设备对第一应用执行第一版本到第二版本的更新安装。

在一种可能的实施方式中，证明变更信息包括其他开发者证明对第一证明的签名信息，其他开发者证明为允许更新为第二版本的第一应用的开发者证明。

在一种可能的实施方式中，在第一终端设备从服务器获取第二版本的第一应用之前，第一终端设备从服务器获取第一版本的第一应用，其中，第一版本的第一应用包括第二证明，第二证明为第一版本的第一应用的开发者证明，然后第一终端设备可正常安装第一版本的第一应用。

在一种可能的实施方式中，在第一终端设备从服务器获取第二版本的第一应用之后，第一终端设备根据第二版本的第一应用的包名，获取与包名对应的第一版本的第一应用。

第三方面，提供一种应用更新方法，应用于通信系统中的服务器，该通信系统包括第一终端设备和服务器，其中，服务器与第一终端设备建立通信连接。该方法中，服务器向第一终端设备发送第二版本的第一应用，该第二版本的第一应用包括第一证明以及证明变更信息，第一证明为第二版本的第一应用的开发者证明。其中，第二版本的第一应用用于第一终端设备在检测到其本地安装的第一版本的第一应用的开发者证明与第一证明不一致时，根据证明变更信息，判断是否允许将第一版本的第一应用更新为第二版本的第一应用；第二版本的第一应用还用于第一终端设备在检测到其本地安装的第一版本的第一应用的开发者证明与第一证明一致时，对第一应用执行第一版本到第二版本的更新安装。

在一种可能的实施方式中，证明变更信息包括开发者证明列表，开发者证明列表中包括允许更新为第二版本的第一应用的开发者证明。

在一种可能的实施方式中，证明变更信息包括更新路径，更新路径中包括第一应用的至少两个开发者证明之间的更新规则。

在一种可能的实施方式中，证明变更信息包括其他开发者证明对第一证明的签名信息，其他开发者证明为允许更新为第二版本的第一应用的开发者证明。

在一种可能的实施方式中，在服务器向第一终端设备发送第二版本的第一应用之前，服务器向第一终端设备发送第一版本的第一应用，其中，第一版本的第一应用包括第二证明，第二证明为第一版本的第一应用的开发者证明。该第一版本的第一应用用于第一终端设备安装在本地系统中。

在一种可能的实施方式中，通信系统还包括第二终端设备，在服务器向第一终端设备发送第二版本的第一应用之前，服务器可以接收到来自第二终端设备的针对第一应用的证明变更请求。之后，服务器可根据证明变更请求生成证明变更信息。然后服务器将证明变更信息发送给第二终端设备。

在一种可能的实施方式中，在服务器向第一终端设备发送第二版本的第一应用之前，服务器可以接收第二终端设备发送的第二版本的第一应用，该第二版本的第一应用包括第一证明以及证明变更信息。

在一种可能的实施方式中，通信系统还包括第二终端设备，在服务器向第一终端设备发送第一版本的第一应用之前，服务器可以接收第二终端设备发送第一版本的第一应用，该第一版本的第一应用包括第二证明。

第四方面，提供一种通信系统，包括第一终端设备和服务器，服务器与第一终端设备建立通信连接。其中：

服务器，用于向第一终端设备发送第二版本的第一应用，第二版本的第一应用包括第一证明以及证明变更信息，第一证明为第二版本的第一应用的开发者证明；

第一终端设备，用于从服务器获取第二版本的第一应用。第一终端设备，还用于若检测到第一版本的第一应用的开发者证明与第一证明不一致，则根据证明变更信息，判断是否允许将第一版本的第一应用更新为第二版本的第一应用，其中，第一版本的第一应用为第一终端设备本地已安装的应用。第一终端设备，还用于若检测到第一版本的第一应用的开发者证明与第一证明一致，则对第一应用执行第一版本到第二版本的更新安装。

第五方面，提供一种电子设备，包括存储器、一个或多个处理器；存储器与处理器耦合；其中，存储器中存储有计算机程序代码，计算机程序代码包括计算机指令，当计算机指令被处理器执行时，使得电子设备执行如第二方面及其任一实现方式中的应用更新方法，或者执行如第三方面及其任一实现方式中的应用更新方法。

第六方面，提供一种计算机可读存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行如第二方面及其任一实现方式中的应用更新方法，或者执行如第三方面及其任一实现方式中的应用更新方法。

第七方面，提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如第二方面及其任一实现方式中的应用更新方法，或者执行如第三方面及其任一实现方式中的应用更新方法。

可以理解地，上述第二方面的应用更新方法、第三方面的应用更新方法、第四方面的通信系统，第五方面的电子设备，第六方面的计算机可读存储介质，第七方面的计算机程序产品所能达到的有益效果，可参考第一方面及其任一种可能的设计方式中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种密钥更换后的安装失败示意图；

图2为本申请实施例提供的通用技术中的应用更新方法的示意图；

图3为本申请实施例提供的一种应用场景示意图；

图4为本申请实施例提供的一种应用更新方法的系统示意图；

图5为本申请实施例提供的一种应用更新方法的流程示意图；

图6为本申请实施例提供的证明更换文件的示意图一；

图7为本申请实施例提供的证明更换文件的示意图二；

图8为本申请实施例提供的证明更换文件的示意图三；

图9为本申请实施例提供的应用更新时的界面示意图；

图10为本申请实施例提供的另一种应用更新方法的流程示意图；

图11为本申请实施例提供的应用成功更新的示意图；

图12为本申请实施例提供的一种应用更新方法的整体流程示意图。

具体实施方式

在本申请的描述中，除非另有说明，“/”表示前后关联的对象是一种“或”的关系，例如，A/B可以表示A或B；本申请中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，其中A，B可以是单数或者复数。

在本申请的描述中，除非另有说明，“多个”是指两个或多于两个。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a和b，a和c，b和c，a和b和c，其中a，b，c可以是单个，也可以是多个。

另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

在本申请实施例中，“示例性地”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性地”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性地”或者“例如”等词旨在以具体方式呈现相关概念，便于理解。

本申请中的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。在本申请的各种实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本申请实施例中的一些可选的特征，在某些场景下，可以不依赖于其他特征，而独立实施，解决相应的技术问题，达到相应的效果，也可以在某些场景下，依据需求与其他特征进行结合。

本申请中，除特殊说明外，各个实施例之间相同或相似的部分可以互相参考。在本申请中各个实施例中，如果没有特殊说明以及逻辑冲突，不同的实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。本申请实施方式并不构成对本申请保护范围的限定。

此外，本申请实施例描述的业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

首先，为了便于理解，下面先对本申请实施例可能涉及的相关术语和概念进行介绍。

1、密钥

密钥可用于对信息进行加密或解密。密钥可以分为非对称密钥和对称密钥，对称密钥是指加密和解密所采用的密钥是相同的，非对称密钥是指加密和解密所采用的密钥是不同的。

非对称密钥可以包括公钥和私钥两种密钥，即公私钥对。公钥是公开的，能够被所有人或者相关人员获知，私钥是私密的，只有该公私钥对的所有者才能获取。公钥和私钥是互相对应的，利用公钥加密的信息，能够用对应的私钥进行解密。类似的，利用私钥加密的信息，可以用对应的公钥进行解密。

在一些应用场景中，公私钥对的所有者可以利用私钥对一些信息进行签名(其本质为加密)，生成签名信息。然后获知公钥的人可以利用公钥对该签名信息进行安全验证，能够确定该签名信息是否是被私钥(只有所有者拥有)进行签名生成的，进而实现对提供签名信息的一方进行身份验证，并可以确认被签名的信息的完整性。

在本申请实施例中以用于对应用签名的密钥是非对称密钥为例进行说明。在这种情况下，应用所有方即开发者并不是将用于对应用签名的私钥发送给接收方，而是将该私钥对应的公钥发送给接收方，自己私密且安全存储用于对应用签名的私钥。

2、包名

包名用于标识应用身份，可以是PackageName、BundleId、AppId等，不同市场/渠道的包名的叫法不同。例如，应用1的包名可以为“com.123”。

3、开发者证明

开发者证明用于标识应用所有方即开发者唯一身份。开发者证明可以是开发者证书、开发者签名密钥或其衍生、其它可用于证明开发者身份的凭证等。本申请实施例并不对开发者证明进行限定。

4、开发者签名密钥

开发者签名密钥可以是指由开发者自己生成并持有的公私钥对，其可以包括用于签名的开发者私钥，以及用于验证的开发者公钥。

开发者在开发应用时可以通过该开发者的私钥对该应用进行签名。在一些实施例中，当应用通过开发者私钥签名后，可以使用“包名+开发者公钥”作为应用的唯一标识。在一些场景中，开发者在发布该应用时可以将该开发者私钥对应的开发者公钥随着应用一起发布，从而安装方在安装该应用时，可以通过该开发者公钥对签名后的应用进行安全验证。

可选地，开发者签名密钥也可以是开发者公钥衍生的其他密钥，如对开发者公钥进行进一步加密后的密钥。本申请实施例并不对可用于证明开发者身份的签名密钥进行限定。

5、开发者证书

开发者证书可以指由证书颁发机构(certificate authority，CA)签发的一种用于标识开发者身份信息的证书文件，也可以称为数字证书、公钥证书等。CA是负责签发和管理开发者证书的权威机构。CA作为网络中受信任的第三方，可以验证申请开发者证书的开发者的身份，管理和更新开发者证书等。

例如，开发者使用自己生成的开发者公钥A，向CA申请合法的开发者证书时，CA在对该申请的合法性校验通过后，可以基于该开发者公钥A为该开发者签发开发者证书。可选地，开发者证书可以包括开发者的公钥信息、开发者的身份信息以及CA的签名信息(即CA对该开发者证书进行签名时生成的证书签名)等。通过对开发者证书的验证可以确定该开发者证书中公钥的合法性。

在一些实施例中，当应用通过开发者私钥签名后，可以使用“包名+开发者证书”作为应用的唯一标识。

5、根证书

根证书，是CA与其他设备建立信任关系的基础，是CA的数字证书，是信任链的起始点。验证一份开发者证书的真伪(即验证CA对该开发者证书信息的签名是否有效)，需要用CA的公钥验证，而CA的公钥存在于对这份开发者证书进行签名的证书内，即CA的公钥存在于CA的根证书内，因此若设备需要验证一份开发者证书的真伪，则需要在该设备内预置一份根证书。

目前，在一些操作系统中，应用的唯一标识包含包名和开发者证明两部分。也即相同的“包名+开发者证明”才能唯一证明某款应用。然而，在一些场景中，会存在包名未变而开发者证明发生变化的情况。而该应用的开发者证明发生变化时，该应用的唯一标识也会发生变化。目前的操作系统并不支持开发者证明的切换，开发者证明切换后的新应用无法从开发者证明切换前的旧应用上进行更新，端侧用户体验较差。

例如，请参阅图1，开发者生成签名密钥A(包括私钥A和公钥A)时，通过公钥A从应用市场(包括CA签发模块)申请到合法的开发者证书A后，开发者可以使用私钥A对未签名应用1.0版本(旧版本)进行签名，并在开发者签名后的应用1.0中写入开发者证书A，然后上传到应用市场。应用市场可以将该开发者签名后的应用1.0进行上架，上架后的应用1.0可供各个用户设备(如手机、平板电脑等)查询和下载。其中，应用市场上架的应用1.0可以携带有应用1.0的包名以及开发者证书A。

用户设备可通过应用市场将该应用1.0下载并安装到本地系统中。作为一种具体的实现，用户设备在本地系统上安装应用1.0时，需要校验应用的唯一标识。即用户设备可以提取待安装应用1.0的“包名+开发者证书A”，并与本地系统中已安装应用的“包名+开发者证书”进行比对。用户设备可以检测到包名并不相同，可以将待安装应用1.0识别为全新应用，应用可独立安装，与已安装应用不冲突，可同时存在。

之后，开发者需要上架应用2.0版本(新版本)时，发现签名密钥A的存储介质损坏无法修复(或其它必须更换密钥的情况)，无法使用私钥A执行应用2.0的签名。此时，开发者可以生成新的签名密钥B(包括私钥B和公钥B)。开发者可通过公钥B从应用市场申请到合法的开发者证书B后，开发者可以使用私钥B对未签名应用2.0版本(新版本)进行签名，并在开发者签名后的应用2.0中写入开发者证书B，然后上传到应用市场。

用户设备通过应用市场将该应用1.0下载并安装到本地系统中时，提取待安装应用2.0的“包名+开发者证书A”，并与本地系统中已安装应用的“包名+开发者证书B”进行比对。此时，用户设备可以检测到待安装应用2.0的包名与本地系统中已安装应用1.0的包名相同，但开发者证书不一致，即校验出应用的唯一标识发生变化。应用不允许安装/更新(升级)，必须卸载旧版本应用后方可安装新版本应用。

其中，开发者证明的更换比较常见。以开发者证明为开发者签名密钥为例，通常可以包含以下更换场景：

开发者签名密钥丢失：开发者切换开发环境导致密钥丢失，或密钥保存介质损坏等，必须更换密钥；

开发者签名密钥泄露：开发者私钥泄露，或密钥复杂度过低，出于安全考虑更换开发者私钥；

应用转移/出售：应用由开发者A转移/出售给开发者B，转移/出售后的开发者B需更换密钥。

可以理解，目前的安卓Android操作系统中，应用的唯一标识采用“包名+证书签名(或证书指纹)”的方式，证书签名发生变化后，应用的唯一标识也会发生变化。同样会面临应用无法正常更新(升级)，需要先卸载旧版本应用后再安装新版本应用的问题。

作为一种可能的方案，如图2所示，在新版本应用和旧版本应用之间可以增加中间版本应用。开发者可先将从旧版本应用(签名密钥为A)升级到中间版本应用，该中间版本应用携带有密钥A签名以及密钥A对密钥B的签名。以证明该旧版本应用(密钥A)可以升级到新版本应用(密钥B)。然后开发者才可以将中间版本应用升级到新版本应用(密钥B)，密钥更换完成。

然后，上述方案必须开发者持有旧密钥A。如果旧密钥A丢失，则无法实现上述方案。且开发者需要通过中间版本才能完成应用的密钥更换。此外，由于安卓生态的开放性，应用的证书签名都是开发者自证实的，并无统一的证书CA认证机制。因此，上述方案本质上是要求开发者通过规范“自己证明密钥更换的合法性”，并不适用于其他拥有统一证书管控的系统。

可以理解，在苹果iOS操作系统中，由于生态的全封闭性，iOS应用仅能通过应用商店(App Store)进行分发，App Store持有所有上架的应用信息，因此可以保证应用的包名(BundleId)的全局唯一。因此，在iOS操作系统中是直接使用应用的包名(BundleId)作为应用的唯一标识，其虽然会校验开发者证书的合法性，但开发者证书并不计算入应用的唯一标识中。因此密钥切换后，只要基于新密钥申请的开发者证书合法，便可正常更新(升级)。因此，目前的iOS操作系统不存在密钥更换后应用无法正常更新(升级)的问题。

但对于其它非全封闭且统一管控开发者证书的应用生态，由于允许多个分发平台(例如浏览器、应用市场)并存，无法保证应用的包名的全局唯一，因此应用唯一标识中添加了开发者证明信息(开发者证书、开发者公钥或其它标识开发者唯一性的信息)。这就导致开发者证明发生变化时，目前的操作系统无法正常更新(升级)应用，需要先卸载旧版本应用后再安装新版本应用的问题。因此，亟需一种可用于解决开发者证明更换后应用无法正常升级的方法。

为了解决上述问题，本申请实施例提供一种应用更新方法，通过服务器统一管控，在开发者需要更换开发者证明时，向开发者分配用于证明新旧开发者证明合法更换的证明更换文件。之后由开发者将证明更换文件加入到应用中并上传到应用市场。如此，用户设备从应用市场下载该应用并安装时，可以利用应用中携带的证明更换文件对该应用进行校验，校验通过后可以允许应用正常更新(升级)，即直接覆盖开发者证明变化前的旧版应用，直接安装开发者证明变化后的新版应用。解决了开发者证明更换后应用无法正常更新(升级)的问题。

需要说明的是，本申请实施例提供的应用更新方法适用于非全封闭且统一管控开发者证书的应用生态。例如，可以应用于鸿蒙Harmony系统，电脑应用市场等，也可以应用于未来基于OpenHarmony构建的三方应用生态，还可以应用于安卓系统未来可能构建的应用生态。可以理解，目前已存在一些系统强制要求开发者将密钥及证书托管至系统，以实现开发者证书的统一管控。在证书管控能力达到一定阶段后，本申请实施例提供的应用更新方法同样也适用于这些系统。

以下结合附图，对本申请实施例所提供的方法进行详细说明。

请参阅图3，图3为本申请实施例所提供一种应用场景的示意图。该应用场景包括终端设备310和服务器320。

其中，终端设备310可以是手机、平板电脑、笔记本电脑、超级移动个人计算机、个人数字助理(personal digital assisitant，PDA)、电视、智能手表、增强现实(augmentedreality，AR)/虚拟现实(virtual reality，VR)设备等电子设备。本申请中对终端设备的设备类型不予具体限定。

服务器320可以是本地或远端的服务器集群，或者单个服务器，本申请对此不做限定。可选地，本申请的服务器可以是专为实现本申请提供的应用更新方法而搭建的服务器，或者，也可以是在已有服务器的基础上增加本申请提供的应用更新服务。

可选地，终端设备310包括应用开发者设备和用户设备。其中，应用开发者设备为应用开发者所在的终端设备，用户设备为需要下载和安装应用的任意终端设备。可选地，应用开发者设备上设置有为开发者提供的开发者平台，应用的开发者可在该开发平台上对应用进行开发。

可选地，服务器320包括用于对应用程序进行管理和分发的应用分发服务器。例如，应用分发服务器可以为提供应用市场业务的云端服务器，或者其他可供终端用户对应用进行下载的应用分发渠道，对此本申请实施例并不进行限定。可选地，用户设备可以为访问应用市场的普通用户所在的终端设备。

以应用分发服务器为支持应用市场业务的云端服务器为例，应用开发者设备将目标应用发送给应用分发服务器，以使得目标应用可以在应用市场中上架，可供其他用户从该应用市场中下载该目标应用。

可选地，服务器320包括用于对开发者证书进行统一签发和管理的证书服务器，可以实现对开发者证书的统一管控，避免开发者证书被伪造和被篡改。如此，终端设备侧可信任该开发者证书所传达的密钥信息。

本申请实施例中，证书服务器除了提供统一的开发者证书签发和管理系统，也提供了统一的证明更换文件签发和管理系统。其中，证明更换文件为用于证明应用的开发者证明是否允许合法更换的证明凭据。其中，开发者证明可以是开发者证书、开发者签名密钥或其衍生、其它可用于证明开发者身份的凭证等。

可以理解，证明更换文件由统一管控开发者证书的证书服务器颁发并签名，可以防止证明更换文件被伪造和被篡改。如此，终端设备侧可信任该证明更换文件所传达的证明更换信息。

在本申请实施例中，请参阅图4，证书服务器可以包括CA签发模块、证书管理模块以及更换证明模块。

其中，CA签发模块负责统一签名开发者证书、证明更换文件等。CA签发模块签名开发者证书、证明更换文件时生成的CA签名信息(签发CA证书)可以用来证明证书服务器颁发的开发者证书、证明更换文件等的合法性。即证明该开发者证书、证明更换文件等签发来源的合法性。

可选地，只有获取合法的开发者证书的开发者才允许上架应用至应用市场，从而实现对应用生态的安全管控。

证书管理模块负责统一颁发和管理开发者证书。该开发者证书包括开发者的签名密钥，用于开发者签名其应用。在本申请实施例中，证书管理模块可以记录有开发者申请的所有历史证书信息，可以为开发者证明的更换提供历史数据支撑，也可以为开发者证明更换的合法性判断提供支撑。

在一些场景中，应用开发者设备在生成的签名密钥A(包括开发者公钥A和开发者私钥A)后，开发者私钥A仅由应用开发者设备所有，用于解密和签名。开发者公钥A可以向外部公开，用于加密和验证签名。

如图4中的(a)所示，应用开发者设备可以将开发者公钥A发送给证书服务器，以申请签发开发者证书。证书服务器在接收到开发者公钥A后，证书服务器的证书管理模块可以校验开发者身份的合法性，在校验通过后，可以通过CA签发模块对开发者公钥A进行签名，得到包含有开发者证书A的签名文件(profile)。然后证书管理模块可以将该签名文件返回给应用开发者设备。同时证书管理模块可以将该开发者证书A进行存储。从而应用开发者设备可以获取到CA签发的开发者证书A以及签名文件。

在一些场景中，应用开发者设备在获取到CA签发的开发者证书A以及签名文件后，可以使用开发者私钥A对应用进行签名，并在签名后的应用中写入包含有开发者证书A的签名文件(profile)。然后上架到应用市场供任意终端设备查询和下载。

更换证明模块可以负责接收来自应用开发者设备的证明更换请求、验证开发者证明更换的合法性以及统一颁发证明更换文件。其中，证明更换请求用于申请对开发者证明进行更换。证明更换文件为用于证明应用的开发者证明是否允许合法更换的证明凭据。

例如，以开发者证明为开发者签名密钥为例，证明更换请求可以是用于申请对开发者签名密钥进行更换。证明更换文件可以是证明应用的开发者签名密钥是否允许合法更换的证明凭据。作为一种方式，证明更换文件中可以包括旧的兼容密钥列表，以证明所有存在于该列表中的旧密钥均允许更新(升级)。

在一些场景中，应用开发者设备在已使用签名密钥A签名应用并上架到应用市场后，若需要上架该应用的新版本，且发现签名密钥A的存储介质损坏无法修复(或其它需要更换密钥的情况)，则应用开发者设备可以生成新的签名密钥B(包括开发者公钥B和开发者私钥B)。并向证书服务器申请使用签名密钥B替代签名密钥A。为了便于说明，这里将之前上架的应用即为应用1.0版本，当前需要上架的应用为应用2.0版本。

如图4中的(b)所示，应用开发者设备可以将开发者公钥B发送给证书服务器，以申请使用签名密钥B替代签名密钥A。证书服务器在接收到开发者公钥B的更换请求后，证书服务器的更换证明模块可以校验该更换请求的合法性，例如开发者身份合法性、更换合法性、频率限制、密钥合法性等。在校验通过后，可以通过CA签发模块对开发者公钥B进行签名，得到包含有开发者证书B、证明更换文件的签名文件(profile)。然后更换证明模块可以将该签名文件返回给应用开发者设备。同时证书管理模块可以将该开发者证书B进行存储。从而应用开发者设备可以获取到CA签发的包含有开发者证书B、证明更换文件的签名文件。

在一些场景中，应用开发者设备在获取到CA签发的包含有开发者证书B、证明更换文件的签名文件后，可以使用开发者私钥B对未签名的应用2.0版本进行签名，并在签名后的应用2.0中写入包含有开发者证书B、证明更换文件的签名文件(profile)。然后上架到应用市场供任意终端设备查询和下载。

在一些场景中，终端设备从应用市场下载应用2.0后，可以通过证明更换文件判断是否执行签名密钥的更换。从而判断是否允许应用1.0正常更新(升级)到应用2.0。

可选地，更换证明模块也可以记录有开发者申请的历史证明更换信息，可以为开发者证明的更换提供历史数据支撑，也可以为开发者证明更换的合法性判断提供支撑。

在一些实施例中，证书服务器与应用分发服务器可以为两个独立的服务器，也可以是同一服务器中两个不同的功能模块，对此本申请实施例并不进行限定。例如，服务器320可以为支持应用市场业务的云端服务器，该运动服务器中可以包括CA签发模块、证书管理模块以及更换证明模块。

请参阅图5，图5为本申请实施例所提供一种应用更新方法的示意图，应用于证书服务器或应用分发服务器。如图5所示，本申请实施例所提供的应用更新方法包括：

S510、证书服务器接收来自应用开发者设备的证明更换请求。

可以理解，同一开发者可以生成多个签名密钥。例如，对开发者甲而言，在目标应用的开发阶段，需要生成目标应用的调试签名密钥A；在目标应用上线阶段，需要生成目标应用的商用签名密钥B。又例如，对开发者甲而言，在旧的签名密钥A丢失、泄露等情况下，也需要生成新的签名密钥B。

可选地，由于签名密钥通常为开发者独自持有，因此签名密钥可以唯一标识开发者的身份。因此可以将开发者的签名密钥或其衍生、其它可用于证明开发者身份的凭证，如开发者证书、对开发者的签名密钥加密后的新密钥等，作为开发者证明，与应用的包名一起作为应用的唯一标识。可以理解，当开发者的签名密钥发生变化时，对应的开发者证明也会发生变化。

可选地，当应用开发者设备需要更换开发者证明时，可以向证书服务器发送证明更换请求。其中，证明更换请求中可以包括更换后的新的开发者证明。

在一种场景中，当应用开发者设备需要更换签名密钥时，应用开发者设备可以使用更换后的新的签名密钥向证书服务器申请开发者证书。然后证书服务器可以接收到应用开发者设备的申请请求以及更换后的新的签名密钥。若证书服务器中已记录有应用开发者设备的签名密钥，则此时证书服务器可以将接收到的证书申请请求，作为接收到的来自应用开发者设备的证明更换请求。

可选地，若证书服务器中并未记录有应用开发者设备的签名密钥，则证书服务器可以认为该应用开发者设备为全新开发者设备，在校验该应用开发者设备的身份合法性通过后，可以对其申请的签名密钥进行签名，并生成合法的开发者证书。

在本申请实施例中，证明更换请求中记录有允许旧的开发者证明进行变更的证据。

在一些场景中，证明更换请求中记录有允许变更的旧开发者证明以及，变更后的新开发者证明。

可选地，证明更换请求中包括新的开发者证明所要替换的旧的开发者证明，以便证书服务器可以知晓哪些旧的开发者证明允许合法更换。

可选地，证明更换请求中包括新旧开发者证明的变更路径，以便证书服务器可以知晓历史开发者证明中各个旧的开发者证明允许的合法更换路径。例如，证明更换请求中对于旧开发者证明A所要求的变更路径为：旧开发者证明A—>旧开发者证明B—>新开发者证明C时，不允许旧开发者证明A直接更新(升级)到新开发者证明C。

可选地，证明更换请求中包括新旧开发者证明的互签认证。例如，以开发者证明为开发者签名密钥为例，证明更换请求中可以使用旧签名密钥A为新签名密钥B签名，这样可以证明新旧签名密钥均由该开发者持有，因为如果开发者没有旧签名密钥，则无法为新签名密钥执行签名。

在一些场景中，开发者证明是基于开发者签名密钥生成的，因此，允许开发者签名密钥进行变更的证据，也可以作为允许对应的开发者证明进行变更的证据。因此，证明更换请求中也可以直接记录有允许变更的旧的开发者签名密钥。

可选地，证明更换请求中包括新的开发者签名密钥所要替换的旧的开发者签名密钥。或者证明更换请求中包括新旧开发者签名密钥的变更路径。或者证明更换请求中包括新旧开发者签名密钥的互签认证。

可选地，在应用开发者设备发送证明更换请求后，证书服务器可以接收到来自应用开发者发送的证明更换请求。然后证书服务器可以对证明更换请求进行处理。

可选地，证书服务器与应用分发服务器是同一服务器中两个不同的功能模块时，可以是该同一服务器接收并处理来自应用开发者设备的证明更换请求。例如，以支持应用市场业务的云端服务器为例，该云端服务器可以接收来自应用开发者设备的证明更换请求，并对该证明更换请求进行处理。

S520、证书服务器对证明更换请求进行校验。

本申请实施例汇总，证书服务器可以对证明更换请求的合法性进行校验，可以避免开发者证明更换的滥用。

可选地，可以是证书服务器对开发者身份的合法性进行校验。例如，可以通过邮箱校验、指纹校验、身份证等方式，对发送证明更换请求的开发者身份进行验证。当验证发现不是开发者本人时，开发者身份不合法，证明更换请求的合法性校验不通过。

可选地，当校验开发者身份的合法性通过时，证书服务器可以确定证明更换请求的合法性校验通过，也可以继续校验其他的合法性，其他合法性均通过时证书服务器可以确定证明更换请求的合法性校验通过。

可选地，可以是证书服务器对证明更换行为的合法性进行校验。例如，若开发者之前并没有旧的开发者证明，则证书服务器可判断出无法进行证明更换，证明更换行为不合法，证明更换请求的合法性校验不通过。又例如，开发者的历史开发者证明比较多时，如果证明更换请求中并未明确指示可允许的新旧开发者证明的合法更换，则证书服务器可判断出无法进行证明更换，证明更换行为不合法，证明更换请求的合法性校验不通过。又例如，证书服务器付费更换证明服务，此时证书服务器可以检测开发者是否成功付费，如果未成功付费，则证书服务器可判断出证明更换行为不合法，证明更换请求的合法性校验不通过。

可选地，当校验证明更换行为的合法性通过时，证书服务器可以确定证明更换请求的合法性校验通过，也可以继续校验其他的合法性，其他合法性均通过时证书服务器可以确定证明更换请求的合法性校验通过。

可选地，可以是证书服务器对证明更换的频率进行校验。例如，若证书服务器本次接收到证明更换请求的时间距离上一次接收到证明更换请求的时间小于预设时间阈值，则证书服务器可以判断出证明更换的频率过高，证明更换的频率不合法，证明更换请求的合法性校验不通过。又例如，若证书服务器在预设时间段内接收到证明更换请求的次数大于预设次数，则证书服务器可以判断出证明更换次数超过限制，证明更换的频率不合法，证明更换请求的合法性校验不通过。其中，预设时间阈值、证明更换的频率、预设次数可以根据实际应用场景合理设定，本申请实施例对此并不作限定。

可选地，当校验证明更换的频率的合法性通过时，证书服务器可以确定证明更换请求的合法性校验通过，也可以继续校验其他的合法性，其他合法性均通过时证书服务器可以确定证明更换请求的合法性校验通过。

可选地，可以是证书服务器对更换后的开发者证明的规范性进行校验。例如，若更换后的开发者证明超过第一长度阈值、或者存在特殊字符、或者小于第二长度阈值等，则证书服务器可以判断出更换后的开发者证明的不规范，证明更换请求的合法性校验不通过。

可选地，当校验更换后的开发者证明的规范性的合法性通过时，证书服务器可以确定证明更换请求的合法性校验通过，也可以继续校验其他的合法性，其他合法性均通过时证书服务器可以确定证明更换请求的合法性校验通过。

本申请实施例并不限定对证明更换请求的合法性的具体校验过程，可以是上述至少两种可能实施方式的组合，也可以是其他合法性校验。

可选地，证书服务器与应用分发服务器是同一服务器中两个不同的功能模块时，可以是该同一服务器对证明更换请求进行校验。例如，以支持应用市场业务的云端服务器为例，该云端服务器可以在接收来自应用开发者设备的证明更换请求后，对该证明更换请求进行校验。

S530、校验通过后，证书服务器将证明更换文件发送给应用开发者设备。

本申请实施例中，证书服务器对证明更换请求的合法性校验通过时，证书服务器可以生成证明更换文件，并将该证明更换文件发送给应用开发者设备。从而应用开发者设备可以将该证明更换文件写入待更新的应用中并上架到应用市场。以在用户设备从应用市场下载该更新的应用时，可以根据证明更换文件，识别应用的开发者证明是否允许合法更换。并在识别到允许合法更换后，更换应用的开发者证明，并允许应用的正常更新。

可选地，上述待更新的应用为与之前的应用版本内容存在不同的应用。如此，可以通过统一管控的服务器颁发的证明更换文件，快速实现应用的更新(升级)安装，无需用户手动卸载之前的应用版本。

可选地，上述待更新的应用为与之前的应用版本内容相同的应用，仅是应用的开发者证明发生改变。如此，可以通过统一管控的服务器颁发的证明更换文件，快速实现应用的开发者证明切换，无需用户手动卸载之前的应用版本。可选地，由于仅涉及应用的开发者证明改变，可以不用重新安装应用，直接变更有关信息即可。

在一些实施例中，证书服务器生成的证明更换文件可以经由CA签发，得到包含有证明更换文件的签名文件(profile)。然后证书服务器可以将该签名文件返回给应用开发者设备。其中，由于CA是受应用开发者设备和用户设备信任的认证中心。因此CA签发证明更换文件时生成的CA签名信息可以用来证明证书服务器颁发的证明更换文件的合法性，即证明该证明更换文件签发来源的合法性。在该证明更换文件签发来源的合法性校验通过时，应用开发者设备和用户设备信任该证明更换文件传达的开发者证明更换信息。

可选地，签名文件中还包括应用的新的开发者证明，以便后续用户设备根据证明更换文件识别到应用的开发者证明允许合法更换时，可以直接更换为新的开发者证书。

可选地，由于开发者证明是基于开发者签名密钥生成的，因此签名文件中还可以包括CA对新的开发者签名密钥签名生成的开发者证书，以便后续用户设备根据证明更换文件识别到应用的开发者证明允许合法更换时，也可以直接根据新的开发者证书中的新的开发者签名密钥，生成新的开发者证明。

本申请实施例中，证书服务器生成的证明更换文件可以记录有允许旧开发者证明变更的凭据。从而应用开发者设备可以将该证明更换文件写入待更新的应用中并上架到应用市场后，用户设备可以从应用市场下载该更新的应用，并可以根据证明更换文件，识别自身安装的应用的开发者证明是否允许合法更换。并在识别到允许合法更换后，更换为应用的新开发者证明，并允许应用的正常更新。

可以理解，由于证书服务器的统一管控，证书服务器可以基于有开发者申请的历史开发者证明信息，因此，证书服务器可以通过提取开发者申请的历史开发者证明信息，生成证明更换文件。如此，在该证明更换文件的签发来源的合法性校验通过时，用户设备可信任该证明更换文件传达的开发者证明更换信息。

可选地，证明更换文件中可以包括应用的新的开发者证明。

可选地，上述证明更换文件包括历史开发者证明列表，以证明所有存在于列表中的旧开发者证明均允许变更为新的开发者证明。如此，用户设备在更新应用时，可以判断自身安装的应用的开发者证明是否存在于证明更换文件的历史开发者证明列表中，若存在，则将自身安装的应用的原来的开发者证明，更换为应用的新开发者证明，并允许自身安装的应用正常更新。

例如，以开发者证明为开发者签名密钥为例，如图6所示，经由CA签发的签名文件中可以包括写有旧的兼容密钥列表的证明更换文件610，以及新的签名密钥X620。所有存在于列表中的旧签名密钥1、2、3等均允许变更为新签名密钥X。

可以理解，由于开发者签名密钥中的开发者私钥为开发者私有，不对外开发，因此，本申请实施例中开发者证书、开发者证明中涉及开发者签名密钥的内容均是指开发者公钥。例如，图6所示的证明更换文件610可以为开发者的历史公钥列表。

可选地，证明更换文件包括新旧开发者证明的变更路径，以证明满足变更路径规则的旧开发者证明才允许变更为新的开发者证明。例如，证明更换请求中对于旧开发者证明A所要求的变更路径为：旧开发者证明A—>旧开发者证明B—>新开发者证明C时，不允许旧开发者证明A直接升级到新开发者证明C。如此，用户设备在更新应用时，可以将自身安装的应用的开发者证明与新旧开发者证明的变更路径进行匹配，以判断自身安装的应用的开发者证明是否满足变更路径规则，若满足，则将自身安装的应用的原来的开发者证明，更换为应用的新开发者证明C，并允许自身安装的应用正常更新。

例如，以开发者证明为开发者签名密钥为例，如图7所示，经由CA签发的签名文件中可以包括写有新旧签名的升级路径的证明更换文件710，以及当前应用所使用的签名密钥720。若CA签发的签名文件中当前应用所使用的签名密钥为签名密钥B，只有签名密钥A的旧应用才允许变更为签名密钥B。若当前应用所使用的签名密钥为签名密钥E，只有签名密钥D的旧应用才允许变更为签名密钥E。若当前应用所使用的签名密钥为签名密钥F，只有签名密钥D的旧应用才允许变更为签名密钥F。若当前应用所使用的签名密钥为签名密钥C，只有签名密钥B、签名密钥E、签名密钥F的旧应用才允许变更为签名密钥C。

在一些场景中，新版本应用更新的内容有可能与一些开发者证明对应的版本应用无法兼容，因此，有必要对一些新旧开发者证明的变更路径进行设计，因此向用户设备准确声明哪些旧开发者证明对应的版本应用允许更新，哪些旧开发者证明对应的版本应用不允许更新。

可选地，证明更换文件包括新旧开发者证明的互签认证。例如，以旧开发者证明A对新开发者证明B签名，以证明允许旧开发者证明A切换至新开发者证明B。可以理解，此方式适用于开发者持有旧开发者证明的场景，由于新旧开发者证明均由本开发者持有，因此，开发者能够使用旧开发者证明签名新开发者证明。如果开发者没有旧开发者证明，则无法为新开发者证明执行签名。

例如，以开发者证明为开发者签名密钥为例，如图8中的(a)所示，经由CA签发的签名文件中可以包括写有新旧签名的互签名的证明更换文件810。其中，使用最旧的签名密钥A对签名密钥B对进行签名时，可以证明允许开发者签名密钥从最旧的签名密钥A切换至签名密钥B。使用签名密钥C对最新的签名密钥D820进行签名时，可以证明允许开发者签名密钥从签名密钥C切换至最新的签名密钥D820。

作为一种实施方式，如图8中的(a)所示，当变更后的开发者签名密钥为开发者签名密钥D时，由于签名密钥A、B、C、D互签，因此，签名密钥A、B、C对应的版本应用都允许更新为签名密钥D对应的版本应用。作为另一种实施方式，如图8中的(b)所示，经由CA签发的签名文件中可以包括写有签名密钥A对签名密钥D的签名830和签名密钥C对签名密钥D的签名840。当变更后的开发者签名密钥为开发者签名密钥D时，由于签名密钥A对签名密钥D签名，签名密钥C对签名密钥D签名，签名密钥A和签名密钥C之间并没有互签，因此，此时可以根据签名的指向性，确定合法的签名密钥变更路径，从而可以证明该变更路径对应的版本应用的合法更新。例如，若用户设备本地安装的旧版本的应用的开发者签名密钥为签名密钥A，则由于签名文件中存在签名密钥A对签名密钥D的签名，因此，可以证明允许该用户设备本地安装的旧版本应用，更新为签名密钥D对应的新版本应用。

在一些场景中，当应用开发者设备需要更换签名密钥时，应用开发者设备可以使用更换后的新的签名密钥向证书服务器申请签发新的开发者证书。然后证书服务器可以对更换新的签名密钥合法性进行校验，校验通过后，可以通过CA签发模块对新的签名密钥进行签名，生成包含有新的开发者证书、证明更换文件等的签名文件(profile)。然后证书服务器可以将经过CA签名的签名文件(profile)发送给应用开发者设备。

在一些场景中，当应用开发者设备开发了应用的升级版本并期望更新上架至应用市场时，可以使用更换后的新的签名密钥为升级版本的应用进行签名，然后再在升级版本的应用的软件包中写入从证书服务器获取的包含有新的开发者证书、证明更换文件等的签名文件(profile)。并上架至应用市场。

用户设备从应用市场下载该更新的升级版本的应用后可以执行安装，从升级版本的应用的签名文件中可以获取证明更换文件，以识别证明更换文件中是否正确声明了应用可允许由之前的签名密钥切换到新的签名密钥。并在识别到允许切换后，允许执行应用从之前的签名密钥切换为新的签名密钥。并在切换后，用户可识别到旧版应用可以正常升级到升级版本的应用。应用升级安装后用户设备上仅存有升级版本的应用，应用升级成功，签名密钥切换成功。

在一些场景中，证书服务器与应用分发服务器是同一服务器中两个不同的功能模块时，可以是该同一服务器在对证明更换请求的校验通过后，将证明更换文件发送给应用开发者设备。例如，以支持应用市场业务的云端服务器为例，该云端服务器可以在对证明更换请求的校验通过后，将证明更换文件发送给应用开发者设备。

本申请实施例提供的应用更新方法，证书服务器可以支持应用开发者设备提交开发者证明更换申请，并支持校验开发者证明更换的合法性，还支持证明更换文件的颁发，通过CA签发模块对证明更换文件进行签名，可以证明颁发的证明更换文件来源合法，应用开发者设备和用户设备可信任证明更换文件中的开发者证明更换信息。如此，证书服务器或应用分发服务器通过统一管控、验证开发者证书和开发者证明更换，可以防止开发者证书和开发者证明被伪造和被篡改。

请继续参阅图5，本申请实施例所提供的应用更新方法还包括：

S540、应用开发者设备从证书服务器处获取证明更换文件。

可选地，证明更换文件经过证书服务器中的CA签发模块统一签名。由于CA是受应用开发者设备和用户设备信任的认证中心。因此CA签发证明更换文件时生成的签名信息可以用来证明证书服务器颁发的证明更换文件的合法性，即证明该证明更换文件签发来源的合法性。

可选地，应用开发者设备向证书服务器申请更换开发者证明时，应用开发者设备可以从证书服务器处获取到证明更换文件。

可选地，应用开发者设备使用开发者签名密钥向证书服务器申请开发者证书时，证书服务器可以根据应用开发者设备是否存在有历史的开发者证书，判断应用开发者设备是否具有开发者证明的更换需求。

可选地，当证书服务器检测到应用开发者设备不存在有历史的开发者证书时，证书服务器可认为该应用开发者设备是新注册的开发者设备。证书服务器在校验该应用开发者设备身份的合法性后，可以根据其申请的开发者签名密钥签发开发者证书。在一些场景中，证书服务器签发开发者证书时，可以生成包含有开发者证书的签名文件(profile)。然后证书服务器可以将该签名文件(profile)发送给应用开发者设备。从而应用开发者设备可以接收到来自证书服务器的开发者证书。

可选地，当证书服务器检测到应用开发者设备存在有历史的开发者证书时，证书服务器可认为该应用开发者设备不是新注册的开发者设备，证书服务器可认为应用开发者设备是请求将其申请的签名密钥替换掉历史的签名密钥，即存在签名密钥的变更。此时，证书服务器可以认为，作为基于签名密钥而生成的开发者证明，其在签名密钥变更时，也会发生变更。因此，证书服务器可判断出应用开发者设备具有开发者证明的更换需求。证书服务器在校验该开发者证明的更换和合法性后，可以根据其申请的开发者签名密钥，签发新的开发者证书以及证明更换文件。

在一些场景中，证书服务器签发新的开发者证书以及证明更换文件时，可以生成包含有新的开发者证书、证明更换文件的签名文件(profile)。然后证书服务器可以将该签名文件(profile)发送给应用开发者设备。从而应用开发者设备可以接收到来自证书服务器的证明更换文件。

可选地，应用开发者设备在获取到证明更换文件时，可以检验该证明更换文件的完整性，防止该证明更换文件被破坏或篡改。作为一种方式，由于证明更换文件经过证书服务器中的CA签发模块统一签名，因此应用开发者设备在获取到证明更换文件时，也会获取到证明更换文件的签名信息。应用开发者设备可以通过证明更换文件的签名信息，对检验该证明更换文件的完整性，防止证明更换文件被篡改。

可选地，应用开发者设备在获取到证明更换文件时，也可以检验该证明更换文件的合法性，以判定该证明更换文件来源是否合法。作为一种方式，应用开发者设备可以从证明更换文件的签名信息解析该签名的来源(根证书)。当该签名的来源与应用开发者设备信任的签名来源一致时，可以判断该证明更换文件来源合法。例如，应用开发者设备信任的签名来源包括证书服务器的CA签发机构时，如果从证明更换文件的签名信息解析该签名的来源来自CA，属于应用开发者设备信任的签名来源，此时应用开发者设备可判断该证明更换文件来源合法。

可选地，应用开发者设备可以预置有信任的签名来源列表。该签名来源列表可以包括本申请的证书服务器的根CA证书或者其他可信任的根证书。

可选地，在证明更换文件的合法性均校验通过时，应用开发者设备可以信任该证明更换文件传达的开发者证明更换信息。

同理，应用开发者设备也可以校验证书服务器所签发新的开发者证书的完整性和合法性。

在一些场景中，证书服务器与应用分发服务器是同一服务器中两个不同的功能模块时，可以是应用开发者设备从该同一服务器处获取证明更换文件。例如，以支持应用市场业务的云端服务器为例，应用开发者设备可以从该云端服务器处获取证明更换文件。

S550、应用开发者设备将更换证明文件添加到目标应用中。

在本申请实施例中，应用开发者设备在接收到证明更换文件后，可以使用开发者签名密钥对目标应用进行签名，并将该更换证明文件打包到目标应用的软件包中。

可选地，应用开发者设备从证书服务器处获取的是包含有新的开发者证书、证明更换文件的签名文件(profile)时，应用开发者设备也可以将该签名文件(profile)打包到目标应用的软件包中。其中，目标应用可以是需要变更开发者证明的第一应用。

可选地，应用开发者设备可以开发者证明变更前，可以在使用开发者签名密钥对第一应用进行签名后，将第一应用上架至应用市场。其中，应用开发者设备在第一应用中添加有包名和变更前的开发者证明，以通过“包名+开发者证明”的方式唯一标识第一应用，并在第一应用中写入包含有开发者证书的签名文件(profile)。然后用户设备可以从应用市场下载该第一应用并将其安装在本地系统中。

当应用开发者设备因为开发者证明泄露、丢失等情况，需要更换开发者证明时，应用开发者设备可以生成新的开发者证明，并基于新的开发者证明向证书服务器申请证明更换时，可以从证书服务器处获取到证明更换文件。然后应用开发者设备在使用开发者签名密钥对第一应用进行签名后，可以使用新的开发者证明将第一应用重新上架到应用市场。这里可以将需要变更开发者证明而重新上架的第一应用记为目标应用。其中，应用开发者设备可以在目标应用中添加有包名和变更后的开发者证明，并将包含开发者证书以及证明更换文件的签名文件(profile)打包到目标应用中。然后用户设备可以从应用市场下载该目标应用并执行安装。

例如，以开发者证明为开发者签名密钥为例，目标应用可以是需要变更开发者签名密钥的第一应用。这里为了便于说明，可以将变更前的开发者签名密钥记为签名密钥A，变更后的开发者签名密钥记为签名密钥B。

应用开发者设备可以在使用签名密钥A对第一应用进行签名后，将第一应用上架至应用市场。其中，应用开发者设备在第一应用中添加有包名和签名密钥A，并在第一应用中写入包含有开发者证书A的签名文件(profile)。然后用户设备可以从应用市场下载该第一应用并将其安装在本地系统中。

当应用开发者设备因为开发者签名密钥泄露、丢失等情况，需要更换开发者签名密钥时，应用开发者设备可以生成新的开发者签名密钥B，并基于新的签名密钥A向证书服务器申请密钥更换时，可以从证书服务器处获取到证明更换文件以及开发者证书B。然后应用开发者设备在使用更换后的签名密钥B对第一应用进行签名后，将第一应用重新上架到应用市场。这里可以将需要变更开发者签名密钥而重新上架的第一应用记为目标应用。其中，应用开发者设备可以在目标应用中添加有包名和签名密钥B，并将包含开发者证书B以及证明更换文件的签名文件(profile)打包到目标应用中。然后用户设备可以从应用市场下载该目标应用并执行安装。

S560、应用开发者设备将目标应用发送给应用分发服务器。

本申请实施例中，应用分发服务器用于对应用程序进行管理和分发，例如，应用分发服务器可以为提供应用市场业务的云端服务器，或者其他可供终端用户对应用进行下载的应用分发渠道，对此本申请实施例并不进行限定。以应用分发服务器为支持应用市场业务的云端服务器为例，应用开发者设备将目标应用发送给应用分发服务器，以使得目标应用可以在应用市场中上架，可供其他用户从该应用市场中下载该目标应用。

上述应用分发服务器可以是代表其中一个应用市场所在的服务器。作为一种具体的实现，还可以有多个应用分发服务器，每个服务器分别对应不同的应用市场或应用分发渠道，其中，每个服务器的具体工作方式可以与应用分发服务器相同，因此本申请实施例不再赘述。

在一些场景中，证书服务器与应用分发服务器可以是同一服务器中两个不同的功能模块，即可以是应用开发者设备将目标应用发送到该同一服务器处。例如，以支持应用市场业务的云端服务器为例，应用开发者设备可以从该云端服务器处获取证明更换文件后，可以将证明更换文件打包到目标应用中并上传到云端服务器以供其他用户下载该目标应用。

本申请实施例提供的应用更新方法，证书服务器或应用分发服务器通过统一验证、颁发和管理开发者证书和开发者证明更换文件，可以使得应用开发者设备在上传应用时，可以将携带有开发者证书和开发者证明更换文件的签名文件(profile)一起打包到该应用中。从而当这些应用上传到应用分发服务器时，应用分发服务器可以将这些应用分发到各个用户设备。如此，利用统一管控开发者证书和开发者证明更换文件的服务器所签发的签名文件(profile)，来携带开发者证明更换文件，可以避免该开发者证明更换文件到达用户设备侧时被篡改、被伪造。

在一些实施例中，应用分发服务器将目标应用进行上架后，用户设备可以从服务器中获取到目标应用。以应用分发服务器为提供应用市场业务的云端服务器为例，用户设备上可以安装有“应用市场”应用。云端服务器将目标应用进行上架后，用户设备上“应用市场”应用的显示界面中可以显示有目标应用的安装选项(或者下载选项)或更新选项。可选地，若用户设备之前已安装过某个应用的旧版本，则云端服务器将该应用的新版本进行上架后，用户设备上“应用市场”应用的显示界面中可以显示有该应用的更新选项。

可选地，若用户设备本地未安装有某个应用的任意版本，则云端服务器将该应用的新版本进行上架后，用户设备上“应用市场”应用的显示界面中可以显示有该新新版本应用的安装选项(或者下载选项)。

示例性地，如图9所示，以目标应用为“XX音乐”的2.0版本，第一应用为“XX音乐”的1.0版本为例，若用户设备之前已安装过“XX音乐”的1.0版本，此时云端服务器将“XX音乐”的2.0版本进行上架后，用户设备上“应用市场”应用的显示界面中可以显示有“XX音乐”的更新选项，从而提示用户“XX音乐”当前有新版本可以使用。

用户可以根据自己的需求选择是否更新(或者升级)“XX音乐”。若用户选择更新“XX音乐”，则可以在用户设备上通过点击、触摸等操作触发“XX音乐”的更新选项，如图9所示。从而用户设备可以从云端服务器处获取该“XX音乐”的2.0版本的软件包。

可选地，用户设备也可以自动触发“XX音乐”的更新，无需用户手动操作。

请参阅图10，图10为本申请实施例所提供一种应用更新方法的示意图，应用于用户设备。如图10所示，本申请实施例所提供的应用更新方法包括。

S1000、用户设备从应用分发服务器处获取第一应用。

其中，第一应用可以以软件包(安装包)的形式被用户设备从应用市场(应用分发服务器)下载到用户设备本地，该第一应用的软件包内包括第一应用的包名和开发者证明。

可选的，第一应用可以是上述“XX音乐”的1.0版本。

可选地，用户设备在检测用户作用于第一应用的第一操作时，响应于该第一操作，从用分发服务器处下载第一应用的软件包。其中，第一操作可以是单击、双击、长按等触控操作，本申请实施例对第一操作并不作限定。

在本申请实施例中，第一应用的软件包里携带有经过CA的私钥所签发的签名文件(profile)，该签名文件包含有经过CA签发的开发者证书。

在一些实施例中，用户设备从应用分发服务器处下载得到的第一应用的软件包后，可以从第一应用的软件包的签名信息中获取开发者证书，以校验开发者证书的合法性。

在一些场景中，用户设备可以包括预置的签发CA模块，存储有用户设备所信任的CA证书，可以用于校验开发者证书的签名来源合法。

可选地，用户设备可以从开发者证书的签名信息中获取签发CA证书，以解析签名来源。然后判断开发者证书的签发来源即签发CA证书是否与预置的可信CA证书一致，一致时用户设备判断第一应用来自合法的开发者及合法的应用市场(应用分发服务器)，允许安装。不一致时用户设备判断第一应用来自非法的开发者及非法的应用市场(应用分发服务器)，不允许安装。

作为一种方式，预置的可信CA证书可以是完整的CA证书内容，也可以是CA证书的部分信息，如颁发机构，证书的主题，CA证书的公钥等信息。本申请实施例对预置的可信CA证书的形式并不作限定。

可选地，在校验开发者证书的合法性通过后，用户设备可以从软件包中提取第一应用的包名和开发者证明，以在对该第一应用安装之前执行安装验证。

S1010、用户设备判断第一应用的包名与本地应用的包名不一致。

本申请实施例中，用户设备可以将提取的第一应用的包名与本地系统中安装的所有应用的包名进行比对，以确定第一应用是一个全新的应用，还是本地应用对应的更新版本应用。

可选地，用户设备可以判断第一应用的包名与本地应用的包名是否一致。若与本地应用的包名都不一致，则可以判断该第一应用是一个全新的应用。若存在一个本地应用的包名与第一应用的包名一致，则可以判断该第一应用可能是该本地应用对应的更新版本应用。

S1020、用户设备安装第一应用。

本申请实施例中，用户设备在判断第一应用的包名与本地应用的包名不一致时，可以认为该第一应用可独立安装，与已安装应用不冲突，可同时存在。因此，用户设备可以将该第一应用安装到本地系统中。

S1030、用户设备从应用分发服务器处获取目标应用。

其中，目标应用也可以以软件包(安装包)的形式被用户设备从应用市场(应用分发服务器)下载到用户设备本地，该目标应用的软件包内包括目标应用的包名和开发者证明。

可选地，用户设备在检测用户作用于目标应用的第一操作时，响应于该第一操作，从用分发服务器处下载目标应用的软件包。其中，第一操作可以是单击、双击、长按等触控操作，本申请实施例对第一操作并不作限定。

可选地，目标应用可以是第一应用的更新版本。用户设备可自动从应用分发服务器处获取目标应用，以实现应用的自动更新。例如，当第一应用为上述“XX音乐”的1.0版本，目标应用可以是上述“XX音乐”的2.0版本。

作为一种方式，目标应用可以是包名和开发者证明与第一应用一致，但版本内容不同的升级包。作为另一种方式，目标应用可以是包名和版本内容与第一应用一致，但开发者证明与第一应用不一致的开发者证明更新包。作为又一种方式，目标应用也可以是包名与第一应用一致，但开发者证明和版本内容与第一应用都不一致的开发者证明更新的升级包。

在一些场景中，当目标应用为第一应用的开发者证明变更后的应用时，目标应用的软件包里携带有经过CA签发的签名文件(profile)，该签名文件可以包含有经过CA签发的开发者证书和证明变更文件。

在一些实施例中，用户设备从应用分发服务器处下载得到的目标应用的软件包后，与第一应用类似，也可以从目标应用的软件包的签名信息中获取开发者证书，判断开发者证书的签发来源即签发CA证书是否与预置的可信CA证书一致，一致时用户设备判断目标应用来自合法的开发者及合法的应用市场(应用分发服务器)，允许安装。不一致时用户设备判断目标应用来自非法的开发者及非法的应用市场(应用分发服务器)，不允许安装。

可选地，目标应用也可以是与第一应用无关的应用。

可选地，在校验开发者证书的合法性通过后，用户设备可以从软件包中提取目标应用的包名和开发者证明，以在对该目标应用安装之前执行安装验证。

S1040、用户设备判断目标应用的包名与本地的第一应用的包名一致。

本申请实施例中，用户设备可以将提取的目标应用的包名与本地系统中安装的所有应用的包名进行比对，以确定目标应用是一个全新的应用，还是本地安装的应用所对应的更新版本应用。

可选地，用户设备可以判断目标应用的包名与本地安装的应用的包名是否一致。若与本地所安装应用的包名都不一致，则可以判断该目标应用是一个全新的应用。若存在一个本地安装应用的包名与目标应用的包名一致，则可以判断该目标应用可能是该本地安装应用对应的更新版本应用。

在本申请实施例中，若用户设备判断存在一个本地安装的应用的包名与该目标应用的包名一致，则用户设备可以执行下述应用更新步骤，即校验开发者证明的一致性，识别出不一致时，校验证明更换文件的合法性。这里为了便于说明，设定与目标应用的包名一致的本地应用可以是前述安装的第一应用。

S1050、用户设备判断目标应用的开发者证明与第一应用的开发者证明不一致。

本申请实施例中，用户设备在检测到目标应用的包名与本地的第一应用的包名一致时，可以执行对第一应用的应用更新方法。其中，用户设备可以先判断目标应用的开发者证明与第一应用的开发者证明是否一致。

可以理解，若目标应用的开发者证明与第一应用的开发者证明一致，则用户设备可以识别出目标应用和第一应用为同一应用的不同版本，用户设备可以对第一应用进行正常升级，直接覆盖升级为目标应用，无需用户手动卸载第一应用。

若目标应用的开发者证明与第一应用的开发者证明不一致，在现有技术中，用户设备会识别出目标应用和第一应用为不同开发者开发的不同应用，用户设备无法对第一应用进行正常升级，需要用户手动卸载第一应用，才能安装目标应用。而在本申请实施例，用户设备可以执行下述应用更新步骤，即通过校验目标应用的证明更换文件的合法性，实现第一应用的正常升级，无需用户手动卸载第一应用。

示例性地，以开发者证明为开发者证书为例，若目标应用的开发者证书中的开发者公钥与第一应用的开发者证书中的开发者公钥不一致，则校验目标应用的证明更换文件的合法性。

S1060、用户设备获取目标应用的证明更换文件。

其中，证明更换文件为前述实施例中添加到目标应用中的更换证明凭据。此次不作赘述。

本申请实施例中，当用户设备检测目标应用的开发者证明与第一应用的开发者证明不一致时，可以从目标应用的软件包的签名文件(profile)中获取证明更换文件，以根据该证明更换文件，校验针对第一应用的开发者证明切换是否合法。

可选地，用户设备从目标应用的软件包中获取签名文件(profile)后，可以校验签名文件的完整性。作为一种方式，用户可以从签名文件的签名信息中，提取CA的公钥信息，以根据CA的公钥信息，校验签名文件的完整性，防止签名文件被破坏或篡改。

可选地，第一应用的软件包可以写有签名文件的原始数据内容，用户设备可以根据签名文件的原始数据内容生成第一摘要信息。其中，第一摘要信息可以是根据签名文件的原始数据内容生成的哈希值，签名文件原始数据内容的变更会引起该哈希值的变更，因此第一摘要信息可以准确地表示当前签名文件的原始数据内容。然后用户设备通过CA的公钥对签名文件进行解密后，可以得到签名文件的第二摘要信息，当第二摘要信息与第一摘要信息一致时，可以认为校验签名文件的完整性通过。当第二摘要信息与第一摘要信息不一致时，可以认为校验签名文件的完整性不通过，不允许执行本申请实施例提供的应用更新方法。

可选地，第一应用的软件包也可以直接写有签名文件的原始数据内容的第一摘要信息，用户设备通过CA的公钥对签名文件进行解密后，可以得到签名文件的第二摘要信息，当第二摘要信息与第一摘要信息一致时，可以认为校验签名文件的完整性通过。当第二摘要信息与第一摘要信息不一致时，可以认为校验签名文件的完整性不通过，不允许执行本申请实施例提供的应用更新方法。

可选地，用户设备从目标应用的软件包中获取签名文件(profile)后，也可以校验签名文件的合法性。作为一种方式，用户设备可以从签名文件的签名信息中解析签名来源即签发CA证书。用户设备可以判断签名来源是否与预置的可信CA证书一致，一致时用户设备判断签名文件的来源合法。不一致时用户设备判断签名文件来源不合法，不允许执行本申请实施例提供的应用更新方法。

S1070、用户设备对证明更换文件进行校验。

本申请实施例中，用户设备可以读取证明更换文件里所记录的允许旧开发者证明变更的凭据，并判断第一应用的开发者证明是否是可允许变更的旧开发者证明。

也就是说，用户设备可以通过证明更换文件所记载的内容，判断是否正确声明了第一应用的开发者证明可切换为目标应用的开发者证明。

若证明更换文件正确声明了第一应用的开发者证明可切换为目标应用的开发者证明，则用户设备校验证明更换文件通过，识别出第一应用的开发者证明切换行为合法，允许执行第一应用的开发者证明切换为目标应用的开发者证明。

若证明更换文件未正确声明第一应用的开发者证明可切换为目标应用的开发者证明，则用户设备校验证明更换文件不通过，可识别出第一应用的开发者证明切换行为不合法，不允许执行第一应用的开发者证明切换为目标应用的开发者证明。可选地，此时，用户可手动卸载第一应用后，再安装第二应用。

以开发者证明为开发者签名密钥为例，示例性地，如图6所示的证明更换文件610，若第一应用的签名密钥为旧签名密钥3，目标应用的签名密钥为新签名密钥X，则可以判断证明更换文件610的历史密钥列表中是否包含第一应用的签名密钥。如图6所示，证明更换文件610中包含第一应用的签名密钥，用户设备可以判断证明更换文件610中明确声明了应用可由旧签名密钥3切换为新签名密钥X。用户设备校验证明更换文件通过，识别出第一应用的签名密钥切换行为合法，允许执行第一应用的旧签名密钥3切换为目标应用的新签名密钥X。

示例性地，如图7所示的证明更换文件710，若第一应用的签名密钥为旧签名密钥B，目标应用的签名密钥为签名密钥E，则证明更换文件710中并未声明了应用可由旧签名密钥B切换为签名密钥E。用户设备校验证明更换文件不通过，识别出第一应用的签名密钥切换行为不合法，不允许执行第一应用的旧签名密钥B切换为目标应用的签名密钥E。

示例性地，如图8中的(a)所示的证明更换文件810，若第一应用的签名密钥为最旧的签名密钥A，目标应用的签名密钥为签名密钥B，则证明更换文件810中明确声明了应用可由最旧的签名密钥A切换为签名密钥B。用户设备校验证明更换文件通过，识别出第一应用的签名密钥切换行为合法，允许执行第一应用的最旧的签名密钥A切换为目标应用的签名密钥B。

S1080、校验通过后，用户设备根据目标应用对第一应用进行覆盖安装。

本申请实施例中，用户设备校验证明更换文件通过后，用户设备可以识别目标应用可正常由第一应用升级，执行应用覆盖安装，无需用户手动卸载第一应用。安装完后用户设备仅存有目标应用，第一应用升级成功，开发者证明切换成功。

以开发者证明为开发者签名密钥为例，示例性地，如图11所示，若第一应用的签名密钥为开发者公钥A，目标应用的签名密钥为开发者公钥B，证明更换文件中明确声明了应用可由开发者公钥A切换为开发者公钥B，则用户设备校验证明更换文件通过，识别出第一应用的签名密钥切换行为合法，允许执行第一应用的开发者公钥A切换为目标应用的开发者公钥B。然后用户设备可以识别目标应用可正常由第一应用升级，从而用户设备直接覆盖第一应用，直接安装目标应用。如图11所示，安装完后用户设备仅存有目标应用，第一应用升级成功，开发者密钥切换成功。

示例性地，以上述第一应用为“XX音乐”的1.0版本和上述目标应用为“XX音乐”的2.0版本为例，请参阅图12，图12示出了本申请实施例提供的应用更新方法的整体流程示意图。

开发者使用应用开发者设备先上传“XX音乐”的1.0版本到应用分发服务器，该“XX音乐”的1.0版本使用签名密钥A进行签名，并将签名密钥A作为“XX音乐”应用的开发者证明。然后用户设备从应用分发服务器下载“XX音乐”的1.0版本并成功安装到本地操作系统中。

之后，开发者希望上架“XX音乐”的2.0版本，但此时开发者发现签名密钥A的存储介质损坏无法修复(或其它必须更换密钥的情况)，无法使用签名密钥A执行“XX音乐”的2.0版本的签名，开发者生成了新的签名密钥B，并向应用分发服务器申请使用签名密钥B替代签名密钥A。应用分发服务器对该申请的合法性进行校验通过后，可以颁发经过CA签名的签名文件给开发者，该签名文件中包含证明更换文件。

之后，开发者后续开发了“XX音乐”的2.0版本并希望更新上架，需要使用新的签名密钥B为“XX音乐”的2.0版本进行签名，并在该“XX音乐”的2.0版本的软件包中写入从应用分发服务器获取的签名文件，该签名文件中包含证明更换文件。

然后开发者使用应用开发者设备上传“XX音乐”的2.0版本到应用分发服务器，并将签名密钥B作为“XX音乐”应用的开发者证明。然后用户设备从应用分发服务器下载“XX音乐”的2.0版本，并在执行安装时，检测到本地存在“XX音乐”的1.0版本(通过相同的包名判断)，执行应用更新逻辑，校验“XX音乐”的1.0版本和“XX音乐”的2.0版本的开发者证明一致性。

此时用户设备会检测到“XX音乐”的1.0版本和“XX音乐”的2.0版本的开发者证明不一致，用户设备可以从“XX音乐”的2.0版本的软件包中获取签名文件，并在校验签名文件的完整性和合法性通过后，从签名文件中获取到证明更换文件。然后用户设备校验该证明更换文件，以判断该证明更换文件是否正确声明了“XX音乐”的开发者证明由签名密钥A切换为签名密钥B。若校验成功，则用户设备可识别为密钥更换合法，允许签名密钥A对应的“XX音乐”的1.0版本正常更新为签名密钥B对应“XX音乐”的2.0版本。此时，用户设备可以直接执行“XX音乐”的2.0版本的覆盖安装，安装完后用户设备上仅存有“XX音乐”的2.0版本。无需用户手动卸载“XX音乐”的1.0版本后再安装“XX音乐”的2.0版本。

如此，解决了现有一些操作系统中开发者证明更换后应用无法正常升级的问题。本申请实施例提供的应用更新方法适用于开发者证明丢失的场景，即使开发者不持有旧开发者证明仍可实施。且本申请通过云端profile文件携带证明更换文件，该证明更换文件由合法的应用市场(应用分发服务器)或证书服务器颁发并签名，可以有效防止滥用、盗用、篡改等问题。此外，该证明更换文件经由CA签发，因此用户设备安装应用时，信任云端服务器颁发的证明更换文件。且开发者证明行为由云端服务器统一管控，可防止开发者证明更换被滥用。

需要说明的是，本申请实施例提供的开发者证明更换方法，也适用于任意两个电子设备之间的安全通信中的密钥更换场景。

示例性地，电子设备1具有公钥A和私钥A时，电子设备可以向证书服务器发送公钥A，证书服务器可以基于该公钥A签发数字证书A。然后电子设备1可以将该数字证书A发送给电子设备2，电子设备2在校验数字证书A的合法性后可以得到电子设备1的公钥A信息。从而电子设备1利用私钥A加密待传输的消息后，可以发送给电子设备2，电子设备2可以利用公钥A解密该加密信息，从而实现安全通信。

当电子设备1因为私钥A丢失、泄露或其他需要更换密钥的场景时，电子设备可以生成新的公私钥对即公钥B和私钥B。然后电子设备可以向证书服务器发送公钥B，以申请更换密钥，证书服务器在校验该密钥更换请求合法性通过后，可以基于该公钥B签发数字证书B以及密钥更换证明文件。然后电子设备可以将该数字证书B和密钥更换证明文件发送给电子设备2。电子设备2在校验数字证书B和密钥更换证明文件的合法性后，可以将与电子设备1通信的密钥从公钥A切换为公钥B。从而电子设备1利用私钥B加密待传输的消息后，可以发送给电子设备2，电子设备2可以利用公钥B解密该加密信息，从而实现安全通信中的密钥更换，可以有效防止密钥更改证明文件被篡改、被伪造的问题。

可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块可以采用硬件的形式实现。需要说明的是，本实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

本申请实施例还提供了一种电子设备，包括存储器、处理器以及存储在该存储器中并可在处理器上运行的计算机程序，处理器执行所述计算机程序时，使得电子设备实现上述各个方法实施例中证书服务器、应用分发服务器、应用开发者设备或用户设备执行的各个功能或者步骤。其中，电子设备可以是证书服务器，也可以是应用分发服务器，还可以是以支持应用市场业务的云端服务器，证书服务器和应用分发服务器为该云端服务器中的两个不同的功能模块，还可以是应用开发者设备或用户设备。

本申请实施例还提供一种应用更新装置，该装置可以应用于上述电子设备。该装置用于执行上述方法实施例中证书服务器、应用分发服务器、应用开发者设备或用户设备执行的各个功能或者步骤。

本申请实施例还提供一种芯片系统，该芯片系统包括至少一个处理器和至少一个接口电路。处理器和接口电路可通过线路互联。接口电路可读取存储器中存储的指令，并将该指令发送给处理器。当所述指令被处理器执行时，可使得电子设备执行上述方法实施例中车辆执行的各个功能或者步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供一种计算机存储介质，该计算机存储介质包括计算机指令，当所述计算机指令在上述电子设备上运行时，使得该电子设备执行上述方法实施例中证书服务器、应用分发服务器、应用开发者设备或用户设备执行的各个功能或者步骤。

本申请实施例还提供一种计算机程序产品，当所述计算机程序产品在电子设备上运行时，使得所述电子设备执行上述方法实施例中证书服务器、应用分发服务器、应用开发者设备或用户设备执行的各个功能或者步骤。

其中，本实施例提供的电子设备、应用更新装置、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (25)

1.一种应用更新方法，其特征在于，应用于包括第一终端设备和服务器的通信系统，所述方法包括：

所述服务器向所述第一终端设备发送第二版本的第一应用，其中，所述第二版本的第一应用包括第一证明以及证明变更信息，所述第一证明为所述第二版本的第一应用的开发者证明；

所述第一终端设备从所述服务器获取所述第二版本的第一应用；

若所述第一终端设备检测到第一版本的所述第一应用的开发者证明与所述第一证明不一致，则所述第一终端设备根据所述证明变更信息，判断是否允许将所述第一版本的所述第一应用更新为所述第二版本的第一应用，其中，所述第一版本的所述第一应用为所述第一终端设备本地已安装的应用；

若所述第一终端设备检测到所述第一版本的所述第一应用的开发者证明与所述第一证明一致，则所述第一终端设备对所述第一应用执行所述第一版本到所述第二版本的更新安装。

2.根据权利要求1所述的方法，其特征在于，所述证明变更信息包括开发者证明列表，所述开发者证明列表中包括允许更新为所述第二版本的第一应用的开发者证明。

3.根据权利要求2所述的方法，其特征在于，所述第一终端设备根据所述证明变更信息，判断是否允许将所述第一版本的所述第一应用更新为所述第二版本的第一应用，包括：

所述第一终端设备从所述证明变更信息中获取所述开发者证明列表；

所述第一终端设备判断所述开发者证明列表中是否包含所述第一版本的所述第一应用的开发者证明。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

若所述第一终端设备检测到所述开发者证明列表中包含所述第一版本的所述第一应用的开发者证明，则所述第一终端设备对所述第一应用执行所述第一版本到所述第二版本的更新安装。

5.根据权利要求1所述的方法，其特征在于，所述证明变更信息包括更新路径，所述更新路径中包括所述第一应用的至少两个开发者证明之间的更新规则。

6.根据权利要求5所述的方法，其特征在于，所述第一终端设备根据所述证明变更信息，判断是否允许将所述第一版本的所述第一应用更新为所述第二版本的第一应用，包括：

所述第一终端设备从所述证明变更信息中获取所述更新路径；

所述第一终端设备判断所述第一版本的所述第一应用与所述第二版本的第一应用之间，是否满足所述更新路径的所述更新规则。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

若所述第一终端设备检测到所述第一版本的所述第一应用与所述第二版本的第一应用之间满足所述更新路径的所述更新规则，则所述第一终端设备对所述第一应用执行所述第一版本到所述第二版本的更新安装。

8.根据权利要求1所述的方法，其特征在于，所述证明变更信息包括其他开发者证明对所述第一证明的签名信息，所述其他开发者证明为允许更新为所述第二版本的第一应用的开发者证明。

9.根据权利要求1-8任一项所述的方法，其特征在于，在所述服务器向所述第一终端设备发送第二版本的第一应用之前，所述方法还包括：

所述服务器向所述第一终端设备发送所述第一版本的所述第一应用，其中，所述第一版本的所述第一应用包括第二证明，所述第二证明为所述第一版本的所述第一应用的开发者证明；

所述第一终端设备从所述服务器获取所述第一版本的所述第一应用；

所述第一终端设备安装所述第一版本的所述第一应用。

10.根据权利要求1-9任一项所述的方法，其特征在于，所述通信系统还包括第二终端设备，在所述服务器向所述第一终端设备发送第二版本的第一应用之前，所述方法还包括：

所述第二终端设备向所述服务器发送针对所述第一应用的证明变更请求；

所述服务器接收到所述第二终端设备的所述证明变更请求时，根据所述证明变更请求生成证明变更信息；

所述服务器将所述证明变更信息发送给所述第二终端设备。

11.根据权利要求10所述的方法，其特征在于，在所述服务器向所述第一终端设备发送第二版本的第一应用之前，所述方法还包括：

所述第二终端设备向所述服务器发送所述第二版本的第一应用，所述第二版本的第一应用包括所述第一证明以及所述证明变更信息。

12.根据权利要求9所述的方法，其特征在于，所述通信系统还包括第二终端设备，在所述服务器向所述第一终端设备发送所述第一版本的所述第一应用之前，所述方法还包括：

所述第二终端设备向所述服务器发送所述第一版本的所述第一应用，所述第一版本的所述第一应用包括所述第二证明。

13.根据权利要求1-12任一项所述的方法，其特征在于，在所述第一终端设备从所述服务器获取所述第二版本的第一应用之后，所述方法还包括：

所述第一终端设备根据所述第二版本的第一应用的包名，获取与所述包名对应的所述第一版本的所述第一应用。

14.一种应用更新方法，其特征在于，应用于通信系统中的第一终端设备，所述方法包括：

从所述服务器获取第二版本的第一应用，其中，所述第二版本的第一应用包括第一证明以及证明变更信息，所述第一证明为所述第二版本的第一应用的开发者证明；

若检测到第一版本的所述第一应用的开发者证明与所述第一证明不一致，则根据所述证明变更信息，判断是否允许将所述第一版本的所述第一应用更新为所述第二版本的第一应用，其中，所述第一版本的所述第一应用为所述第一终端设备本地已安装的应用；

若检测到所述第一版本的所述第一应用的开发者证明与所述第一证明一致，则对所述第一应用执行所述第一版本到所述第二版本的更新安装。

15.根据权利要求14所述的方法，其特征在于，所述证明变更信息包括开发者证明列表，所述开发者证明列表中包括允许更新为所述第二版本的第一应用的开发者证明。

16.根据权利要求15所述的方法，其特征在于，所述根据所述证明变更信息，判断是否允许将所述第一版本的所述第一应用更新为所述第二版本的第一应用，包括：

从所述证明变更信息中获取所述开发者证明列表；

判断所述开发者证明列表中是否包含所述第一版本的所述第一应用的开发者证明。

17.根据权利要求16所述的方法，其特征在于，所述方法还包括：

若检测到所述开发者证明列表中包含所述第一版本的所述第一应用的开发者证明，则对所述第一应用执行所述第一版本到所述第二版本的更新安装。

18.根据权利要求14所述的方法，其特征在于，所述证明变更信息包括更新路径，所述更新路径中包括所述第一应用的至少两个开发者证明之间的更新规则。

19.根据权利要求18所述的方法，其特征在于，所述根据所述证明变更信息，判断是否允许将所述第一版本的所述第一应用更新为所述第二版本的第一应用，包括：

从所述证明变更信息中获取所述更新路径；

判断所述第一版本的所述第一应用与所述第二版本的第一应用之间，是否满足所述更新路径的所述更新规则。

20.根据权利要求19所述的方法，其特征在于，所述方法还包括：

若检测到所述第一版本的所述第一应用与所述第二版本的第一应用之间，满足所述更新路径的所述更新规则，则对所述第一应用执行所述第一版本到所述第二版本的更新安装。

21.根据权利要求14所述的方法，其特征在于，所述证明变更信息包括其他开发者证明对所述第一证明的签名信息，所述其他开发者证明为允许更新为所述第二版本的第一应用的开发者证明。

22.根据权利要求14-21任一项所述的方法，其特征在于，在所述从所述服务器获取第二版本的第一应用之前，所述方法还包括：

从所述服务器获取所述第一版本的所述第一应用，其中，所述第一版本的所述第一应用包括第二证明，所述第二证明为所述第一版本的所述第一应用的开发者证明；

安装所述第一版本的所述第一应用。

23.根据权利要求14-22任一项所述的方法，其特征在于，在所述从所述服务器获取第二版本的第一应用之后，所述方法还包括：

根据所述第二版本的第一应用的包名，获取与所述包名对应的所述第一版本的所述第一应用。

24.一种电子设备，其特征在于，所述电子设备包括存储器和一个或多个处理器；所述存储器和所述处理器耦合；所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述处理器执行所述计算机指令时，所述电子设备执行如权利要求14-23中任一项所述的方法。

25.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求14-23中任一项所述的方法。