本申请涉及信息安全
技术领域：
：，更具体地，涉及一种应用程序包处理方法、装置、电子设备及存储介质。
背景技术：
：：随着安卓(android)系统的发展，使用android系统的用户越来越多，基于android系统开发的应用程序(application，app)也越来越多，功能也愈渐丰富。但与此同时，android也成为恶意软件开发者大为关注的操作系统。目前，许多应用程序的功能会涉及隐私、信息、财产安全等安全问题，存在被攻击的安全隐患。因此，提高android应用程序的安全防护变得尤为重要。技术实现要素：本申请实施例提出了一种应用程序包处理方法、装置、电子设备及存储介质，能够提高应用程序的安全性。第一方面，本申请实施例提供了一种应用程序包处理方法，应用于第一终端，该方法包括：获取应用程序标识对应的待保护文件和安装文件，所述安装文件作为所述应用程序标识对应的应用程序包；对所述待保护文件进行加密，获得加密后的待保护文件；将所述加密后的待保护文件作为所述应用程序标识对应的安装更新包，将所述应用程序包和所述安装更新包分开存储。第二方面，本申请实施例提供了一种应用程序包处理方法，应用于第二终端，该方法包括：基于应用程序标识对应的安装请求，获取所述应用程序标识对应的应用程序包，并根据所述应用程序包安装所述应用程序；在检测到所述应用程序首次启动时，获取所述应用程序标识对应的安装更新包，其中，所述应用程序包和所述安装更新包为第一终端根据权利要求1-5任一项所述的方法而存储的；对所述安装更新包进行解密，获得待保护文件；基于所述待保护文件对所述应用程序进行更新。第三方面，本申请实施例提供了一种应用程序包处理装置，应用于第一终端，该装置包括：文件获取模块，用于获取应用程序标识对应的待保护文件和安装文件，所述安装文件作为所述应用程序标识对应的应用程序包；文件加密模块，用于对所述待保护文件进行加密，获得加密后的待保护文件；文件存储模块，用于将所述加密后的待保护文件作为所述应用程序标识对应的安装更新包，将所述应用程序包和所述安装更新包分开存储。第四方面，本申请实施例提供了一种应用程序包处理装置，应用于第二终端，该装置包括：应用安装模块，用于基于应用程序标识对应的安装请求，获取所述应用程序标识对应的应用程序包，并根据所述应用程序包安装所述应用程序；更新获取模块，用于在检测到所述应用程序首次启动时，获取所述应用程序标识对应的安装更新包，其中，所述应用程序包和所述安装更新包为第一终端根据权利要求1-5任一项所述的方法而存储的；文件解密模块，用于对所述安装更新包进行解密，获得待保护文件；应用更新模块，用于基于所述待保护文件对所述应用程序进行更新。第五方面，本申请实施例提供了一种终端设备，包括：存储器；一个或多个处理器，与所述存储器耦接；一个或多个应用程序，其中，一个或多个应用程序被存储在存储器中并被配置为由一个或多个处理器执行，一个或多个应用程序配置用于执行上述第一方面或第二方面提供的应用程序包处理方法。第六方面，本申请实施例提供了一种计算机可读取存储介质，计算机可读取存储介质中存储有程序代码，程序代码可被处理器调用执行上述第一方面或第二方面提供的应用程序包处理方法。本申请实施例提供的一种应用程序包处理方法、装置、电子设备及存储介质，应用于第一终端，通过获取应用程序标识对应的待保护文件和安装文件，将安装文件作为应用程序标识对应的应用程序包，并对待保护文件进行加密，获得加密后的待保护文件，接着将加密后的待保护文件作为应用程序标识对应的安装更新包，将应用程序包和安装更新包分开存储。由此，本申请实施例可通过将原应用程序包包含的所有文件分为安装文件和待保护文件，仅将安装文件作为应用程序标识对应的应用程序包进行存储，而对待保护文件加密后与安装文件分开存储，使得攻击者难以获取完整的应用程序包，提高对待保护文件的安全防护，降低待保护文件被反编译导致功能遭破坏的可能性，提高了应用程序的安全性。附图说明为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1示出了本申请实施例提供的一种应用程序包处理方法的应用场景图。图2示出了本申请一个实施例提供的应用程序包处理方法的流程示意图。图3示出了本申请另一个实施例提供的应用程序包处理方法的流程示意图。图4示出了本申请又一个实施例提供的应用程序包处理方法的流程示意图。图5示出了本申请再一个实施例提供的应用程序包处理方法的流程示意图。图6示出了本申请还一个实施例提供的应用程序包处理方法的流程示意图。图7示出了本申请一个实施例提供的应用程序包处理装置的模块框图。图8示出了本申请另一个实施例提供的应用程序包处理装置的模块框图。图9示出了本申请一个实施例提供的电子设备的结构框图。图10示出了本申请另一个实施例提供的电子设备的结构框图。图11示出了本申请一个实施例提供的用于保存或者携带实现根据本申请实施例的应用程序包处理方法的程序代码的存储单元。图12示出了本申请另一个实施例提供的用于保存或者携带实现根据本申请实施例的应用程序包处理方法的程序代码的存储单元。具体实施方式为了使本
技术领域：
：的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。请参见图1，图1示出了本申请实施例提供的应用程序包处理方法的应用场景的示意图，该应用场景包括本申请实施例提供的一种通信系统10。该通信系统10包括：终端设备100以及服务器200。其中，终端设备100和服务器200位于无线网络或有线网络中，终端设备100和服务器200可以进行数据交互。在一些实施方式中，终端设备100可以为多个，服务器200可以与多个终端设备100通信连接，多个终端设备100之间也可以相互通过互联网进行通信连接，也可以将服务器200作为传输中介，并通过互联网来实现相互间的数据交互。在本申请实施例中，终端设备100可以是移动手机、智能手机、笔记本电脑、台式电脑、平板电脑、个人数字助理(personaldigitalassistant，pda)、媒体播放器、智能电视、可穿戴电子设备等，具体的终端设备类型在本申请实施例中可以不作为限定。服务器200可以是单独的服务器，也可以是服务器集群，可以是本地服务器，也可以是云端服务器，具体的服务器类型在本申请实施例中可以不作为限定。在一些实施例中，根据用户的不同，终端设备100可分为：应用程序开发者使用的第一终端101和安装应用程序的用户所使用的第二终端102。在一种实施方式中，第一终端101可将开发好的应用程序包(androidpackage，apk)上传服务器，第二终端102可通过向服务器请求该应用程序包而下载安装该应用程序包对应的应用程序，使得用户可基于第二终端102使用该应用程序。可以理解的是，在一些情况下，第一终端101和第二终端102的使用用户可以为同一用户，此时第一终端101和第二终端102可为同一终端设备。例如，应用程序的开发者也在其所使用的终端上安装应用程序。其中，apk是android系统使用的一种应用程序包文件格式，代指androidapp的安装包，用于分发和安装android应用程序及中间件。一个android应用程序的代码若需在android设备上运行，需先进行编译，然后被打包成为一个能被android系统所识别的文件才可以被运行，而这种能被android系统识别并运行的文件格式便是“apk”。通过将安装包，即完整的apk文件直接传到android模拟器或运行android系统的终端设备(简称android设备)中执行即可安装该apk文件对应的app。通常情况下，一个应用程序完整的安装包可包括多个文件，例如androidmanifest.xml文件、dex文件、elf文件、res文件和签名文件等，还可包括文件夹如assets、meta-inf等。每类文件用于存放的内容不同，被攻击者反编译后造成的安全威胁也不同，而根据需要可将安装包所需的文件分为待保护文件和安装文件。为便于描述，下面对部分文件进行示意性说明：其中，androidmanifest.xml文件是应用全局配置文件，里面包含多种信息，比如应用程序的包名、数据权限、接口权限、版本信息、安装参数等等，另外，它还可以声明应用程序的每一个组件及其属性，声明应用程序所申请的权限、进程，声明显示模式等等。其中，dex是android系统上可执行文件的类型，能够被识别、加载并执行的文件格式，dex文件时android系统上的可执行文件。dex文件被执行时，可用于实现应用程序的功能。android应用通常是用java语言开发的，它用android开发工具编译之后变成了二进制的字节码(bytecode)，这些字节码被打包成classes.dex文件，由android平台的dalvik虚拟机来解释执行。为了能够调用android系统功能，android系统提供了一套运行环境(androidframework)，android应用调用系统各功能都是通过调用androidframework的库来实现的。其中，elf是executableandlinkableformat的缩写，是android/linux操作系统中可执行文件、共享库的文件格式。android系统也支持应用程序通过jni或者nativeexecutable直接运行。此时应用执行的是直接在cpu上运行的二进制机器码，不需要经过虚拟机解释，可以直接调用android库如libc、webkit、sqlite、opengl/es等来调用系统各功能。如果android应用要通过jni或者nativeexecutable运行，就需要将要执行的代码编译成elf文件格式。在一些实施方式中，apk文件包括so文件格式的文件，其中so为shareobject的简称，so文件也是一种elf文件。其中，res文件为应用程序的资源文件，例如图像素材、布局文件等。其中，assets文件夹包括静态文件，比如说明文档或者字体文件。其中，签名文件可以是应用程序开发者对该应用程序进行签名的签名证书文件。签名文件可用于安全性校验，校验文件是否被篡改等。签名文件可存放于meta-inf文件夹中，meta-inf文件夹可包括安装包中每个文件哈希值的计算结果、安装包的签名文件等。然而，随着android应用程序的逐渐增多和发展，功能逐渐丰富，攻击者往往通过反编译来破解应用程序的apk，了解apk的功能，而由于目前许多android应用程序会涉及到隐私、信息、财产安全等安全性问题，因此为提高应用程序安全性，需防止apk被反编译。为此，发明人经过一系列研究发现，目前防止apk被反编译的方法包括对apk文件整体或其组成部分进行加固(reinforce)，加固后的apk先检测攻击者常用的反编译工具，如apktool，jadx，jeb，ida和jd-jui等，如果检测到这些工具，apk就退出，不释放原有的dex文件。但是，目前这些防护手段对于应用程序的安全防护仍显欠缺，攻击者可获取整个apk文件后绕过反编译检测。因此基于上述问题，本申请实施例提供了一种应用程序包处理方法、装置、系统、电子设备以及存储介质。下面将通过具体实施例进行详细说明。请参阅图2，图2示出了本申请实施例提供的一种应用程序包处理方法的流程示意图，可应用于上述第一终端。下面将针对图2所示的流程进行详细的阐述。该应用程序包处理方法可以包括以下步骤：步骤s110：获取应用程序标识对应的待保护文件和安装文件，安装文件作为应用程序标识对应的应用程序包。其中，根据应用程序标识可唯一确定该应用程序标识对应的应用程序，应用程序标识可以是应用程序的包名等，在此不作限定。一个应用程序若需正常被执行且实现相应功能，需要在需运行该应用程序的模拟器或设备上安装该应用程序的安装包。而一个应用程序的安装包可包括多个文件，部分文件可能涉及安全问题，因此如果安装包被攻击者反编译，则这部分文件可能会被攻击者获取，导致这部分文件对应的应用程序功能被破坏，从而对用户或设备带来安全威胁。但不是所有的文件都涉及安全问题或者涉及安全问题的程度不同。因而可将安装包内的文件根据安全性进行划分，分为待保护文件和安装文件。开发者基于第一终端开发时，可将安装文件单独作为应用程序标识对应的应用程序包，第一终端可获取安装文件，将安装文件作为应用程序的应用程序包。由于应用程序包与安装包的格式相同均为apk文件，而一般设备在安装应用程序时会获取apk文件进行解压安装等，因此通过将原来完整的apk文件分开，并仅将部分文件作为应用程序包，可隐藏另一部分文件即待保护文件，使得攻击者只能获取到应用程序包内的安装文件，应用程序标识对应的应用程序包即便被攻击者获取，也不能对应用程序的全部功能造成破坏，同时攻击者无法获取到完整的安装包，即完整的应用程序包，因而也就无法通过反编译了解应用程序的全部功能，从而可提高应用程序的安全性，降低完整的应用程序包被反编译的可能。另外，由于仅将安装文件作为应用程序标识对应的应用程序包，比原来完整的应用程序包即完整的apk文件的代码量小，还便于用户下载安装应用程序标识对应的应用程序。在一种实施方式中，可预先对各文件进行等级标注，每个文件对应一个安全等级。并可将安全等级高于指定安全等级的文件确定为待保护文件，将安全等级不高于指定安全等级的文件确定为安装文件。由此，应用程序标识对应的应用程序包只有安装文件，因此即便被攻击者获取到应用程序包，也仅可获取到安全等级低的安装文件，而无法获取到安全等级高的待保护文件，从而即便应用程序包被攻击者反编译，也不能对核心功能造成破坏，同时攻击者也无法获取到完整的安装包，也就无法通过反编译了解应用程序的核心功能。在另一种实施方式中，第一终端还可根据文件类型对原来完整的apk文件进行分类。例如，作为一种方式，由于在应用程序完整的apk文件中，包括可执行文件，可执行文件一般涉及功能实现，那为防止被攻击者反编译后破坏应用程序的功能，可将可执行文件作为待保护文件，将除可执行文件外的其他文件作为安装文件。由此，将可执行文件与其他文件分开，并在获取应用程序标识对应的应用程序包时，仅可获取到不涉及功能实现的安装文件，可提高对应用程序功能实现的相关代码的安全防护，从而提高应用程序安全性，降低被反编译使得应用程序功能遭到破坏的可能。在又一种实施方式中，第一终端还可先获取涉及功能实现的文件，再根据功能是否涉及用户隐私、信息、财产安全等安全性问题，对原来完整的apk文件进行分类，将功能涉及安全性问题的文件作为待保护文件，并将除待保护文件外的其他文件作为安装文件。由此，功能涉及安全性问题的文件得以与其他文件分开，并在获取应用程序标识对应的应用程序包时，仅可获取到不涉及安全性问题的安装文件，可提高对待保护文件的安全防护，从而提高应用程序安全性，降低被反编译使得涉及安全性问题的功能遭到破坏。具体的实施方式可见后述实施例，在此不再赘述。步骤s120：对待保护文件进行加密，获得加密后的待保护文件。第一终端对待保护文件进行加密，可获得加密后的待保护文件，从而增加待保护文件本身的安全性，使得待保护文件即便被攻击者获取到，攻击者还需要能解密，才可获得待保护文件，从而进一步提高待保护文件的安全性，进而提高应用程序的安全性。在一些实施方式中，可通过一对加解密算法对待保护文件进行加密，具体地，通过加密算法对待保护文件进行加密，获得加密后的待保护文件，在后续需解密时，可再基于与加密函数对应的解密函数对加密后的待保护文件进行解密，获得待保护文件。若攻击者无法对加密后的待保护文件，就难以获取到待保护文件，并解析其内容，导致应用程序功能遭到破坏，因而通过对待保护文件进行加密，可提高应用程序安全性。具体实施方式可见后述实施例，在此不再赘述。步骤s130：将加密后的待保护文件作为应用程序标识对应的安装更新包，将应用程序包和安装更新包分开存储。在一些实施方式中，第一终端可将加密后的待保护文件打包为安装更新包，文件格式为dex，将安装文件打包为应用程序包，文件格式为apk，将安装更新包和应用程序包分开存储。并由于用户安装应用程序时一般首先获取apk文件，即应用程序包，并在满足一定条件时，才获取加密后的待保护文件，因而可通过将安装更新包与应用程序包分开存储，可隐藏安装更新包，使得攻击者难以获取到安装更新包，也就难以获取到完整的apk文件，也就无法通过反编译了解完整的apk文件的功能。在一些实施方式中，可以将加密后的待保护文件作为安装更新包存储，使得在需要安装和运行应用程序标识对应的应用程序时，终端设备可先获取应用程序包，再获取安装更新包，使得应用程序包和安装更新包可合并成完整的apk文件，以使应用程序可正常运行，功能得以正常实现。而通过将待保护文件和安装文件分开存储，并安装文件作为应用程序标识对应的应用程序包，可隐藏待保护文件，降低待保护文件被攻击者获取、被反编译的可能性，从而可提高应用程序的安全性。在一种实施方式中，在需要安装和运行应用程序标识对应的应用程序时，第二终端可在获得待保护文件时，通过热更新的方式将待保护文件添加到安装文件，以形成应用程序标识对应的完整的apk文件。在一个示例中，安装文件内包含热更新代码，通过执行热更新代码可将待保护文件添加到安装文件内，形成完整的apk文件，由此，应用程序标识对应的应用程序就可正常运行，应用程序的功能得以实现。另外，在一些实施例中，应用程序包可存储于与应用市场关联的服务器，以供用户通过应用市场搜索、下载、安装该应用程序包对应的应用程序，而若待保护文件可以通过热更新方式被添加到安装文件，可以使得开发者可以无需将安装更新包上传应用市场，从而还可以提高开发和发布效率。在另一些实施例中，应用程序包本身也可存储于与应用市场不关联的服务器。具体实施方式可见后述实施例，在此不再赘述。本申请实施例提供的应用程序包处理方法，通过获取应用程序标识对应的待保护文件和安装文件，将安装文件作为应用程序标识对应的应用程序包，并对待保护文件进行加密，获得加密后的待保护文件，接着将加密后的待保护文件作为应用程序标识对应的安装更新包，将应用程序包和安装更新包分开存储。由此，本申请实施例可通过将原应用程序包包含的所有文件分为安装文件和待保护文件，仅将安装文件作为应用程序标识对应的应用程序包进行存储，对待保护文件加密后与安装文件分开存储，使得攻击者难以获取完整的应用程序包，提高对待保护文件的安全防护，降低待保护文件被反编译导致功能遭破坏的可能性，提高了应用程序的安全性。请参阅图3，图3示出了本申请另一实施例提供的一种应用程序包处理方法的流程示意图，可应用于上述第一终端，该应用程序包处理方法可以包括：步骤s210：获取应用程序标识对应的待保护文件和安装文件，安装文件作为应用程序标识对应的应用程序包。在一种实施方式中，根据功能的区别，可进一步将dex文件划分为普通功能的dex文件和核心功能的dex文件。在一种示例中，具体地，包含普通功能的dex文件可以是用于实现用户界面(userinterface，ui)展示、数据存储等普通功能的dex文件，核心功能的dex文件可以是用于实现核心业务功能的dex文件，核心业务包括涉及隐私、信息安全、财产安全等安全性问题的业务。在一个示例中，核心功能的插件dex文件可包括涉及支付功能的代码，再如实现本申请实施例所需的代码等，在此不做具体限定。在一些实施例中，安装文件可为宿主apk文件，待保护文件可为核心功能的插件dex文件。由此，将原来完整的apk文件划分为宿主apk文件和核心功能的插件dex文件(plugindex)，可通过后续操作将含有核心功能的插件dex文件进行加密后与宿主apk文件分开存储，使得攻击者难以获得完整的apk文件，可有效防止完整的apk文件被反编译。其中，宿主apk文件可以包括普通功能的dex文件以及运行plugindex功能必须的应用权限，前述应用权限用于在终端设备安装宿主apk文件后，可基于应用权限运行plugindex内的代码，使得plugindex功能可被正常使用。其中，包含有核心功能的插件dex文件(plugindex)，可通过将包含有核心功能的dex文件插件化得到，plugindex包含整个完整的apk需要重点防护的核心业务的实现代码。由此，在需安装和运行应用程序时，可获取plugindex添加到宿主apk文件上，即可得到完整的apk文件。可以理解的是，包含有核心功能的插件dex文件若被攻击者反编译获得，可能对应用程序的安全带来较大威胁，因而通过将该部分文件单独存储，而将不包含该部分文件的宿主apk文件单独作为应用程序标识对应的应用程序包，可隐藏该部分包含有核心功能的插件dex文件，从而可降低被攻击者获取的可能性，提高应用程序的安全性。在一些实施方式中，宿主apk文件还可以包括用于下载更新前进行网络连接的应用权限和代码，用于连接网络，下载plugindex并更新应用程序，使得安装有宿主apk文件的终端设备可通过下载plugindex，并进行热更新来获得完整的apk，使得应用程序标识对应的应用程序可在终端设备上正常运行，功能可被正常使用。在另一些实施例中，为进一步将宿主apk分割，减小apk代码量，使得apk的更新的成功率更高，还可将非核心功能的插件dex文件也作为待保护文件的一部分进行存储，使得待保护文件还可以包含非核心功能的插件dex文件，例如ui展示、数据存储等，具体在此不做限定。从而使得安装文件的代码量减小，也就减小了作为应用程序标识对应的应用程序包的文件大小。步骤s220：基于加密函数和指定密钥对待保护文件进行加密，获得加密后的待保护文件。在一些实施例中，可基于对称加密算法、非对称加密算法等加密算法对待保护文件进行加密，获得加密后的待保护文件。作为一种实施方式，可采用对称加密算法，即加密、解密均基于同一个密钥。作为另一种实施方式，还可采用非对称加密算法，此时需要两个密钥，一个为公开密钥(publickey)，即公钥，另一个为私有密钥(privatekey)，即私钥。可以理解的是，第一终端还可采用其他加密算法进行加密，并根据需要可采用安全等级更好的加密算法，具体采用何种加密算法，本实施例在此不作限定。其中，加密算法可包含加密函数与解密函数。在一些实施例中，指定密钥包括加密用的第一密钥和解密用的第二密钥，通过加密函数和第一密钥加密后得到的文件，可由对应的解密函数和第二密钥解密。若采用对称加密算法进行加密，则第一密钥和第二密钥相同，若采用非对称加密算法进行加密，第一密钥和第二密钥不同。在一种实施方式中，可采用对称加密算法对待保护文件进行加密。在一个示例中，可具体采用高级加密标准(advancedencryptionstandard，aes)算法的aes-512算法，以获得更快的加密速度。具体地，若基于aes加密函数和指定密钥对待保护文件进行加密，设加密函数为e，则密文c＝e(k，p)，其中，p为待保护文件，k为指定密钥，c为密文，则将待保护文件p和指定密钥k作为加密函数e的参数输入，加密函数e会输出密文c，即加密后的待保护文件。步骤s230：将指定密钥存储于加密后的待保护文件的指定位置，指定位置记录于安装文件。在一种实施方式中，若采用对称加密算法对待保护文件进行加密，由于对称加密算法的加密、解密所用的密钥相同，因而对加密后的待保护文件解密时，还需获得指定密钥。因此，可将指定密钥存储于指定位置，以降低被攻击者获取到指定密钥来解密的可能性，从而提高安全性。本实施例中，第一终端将指定密钥存储于加密后的待保护文件的指定位置，指定位置记录于安装文件，可使得在需要安装和运行应用程序时，终端设备可基于安装文件获得指定位置，以在加密后的待保护文件中获得指定密钥，用于解密得到待保护文件。由此，不仅通过对待保护文件进行加密提高存储安全性，防止被攻击者获取之外，还可进一步地，将指定密钥存储于加密后的待保护文件的指定位置，避免应用程序标识对应的应用程序包被反编译时，导致指定密钥的泄露，可进一步提高存储安全性，降低被攻击者获取到待保护文件的可能性，以提高应用程序的安全性。在一些可能的实施例中，第一终端还可将指定密钥存储于加密后的待保护文件外的其他位置，只需将指定位置记录于安装文件即可，使得基于安装文件，可获取到指定密钥存储的指定位置，并获取该指定密钥用于解密。例如，其他位置可以是服务器上的位置，还可以是本地的位置，在此不作限定。步骤s240：将加密后的待保护文件作为应用程序标识对应的安装更新包，将应用程序包和安装更新包分开存储。在一个实施例中，第一终端可将安装更新包存储于第一服务器，将应用程序包存储于第二服务器。在一种实施方式中，第二服务器可以是与应用市场关联的服务器，开发者开发好应用程序包后，将应用程序包都上传到该第二服务器，以供用户通过应用市场搜索、下载、安装该应用程序包对应的应用程序。在另一个实施例中，第一终端可将安装更新包、应用程序包分开存储于同一服务器，服务器根据终端设备发送的请求，分别发送对应的文件至终端设备。在一种实施方式中，根据应用程序标识对应的安装请求，可指示服务器返回应用程序标识对应的应用程序包，在终端设备执行应用程序包，安装该应用程序标识对应的应用程序，并启动时，可发送应用程序标识对应的启动请求至服务器，可指示服务器返回应用程序标识对应的安装更新包，以更新之前安装的应用程序，使得应用程序可完整具备应用程序标识所对应的文件代码，可正常运行应用程序的功能。在又一个实施例中，第一终端还可以将安装更新包存储于服务器，将应用程序包存储于本地。由此，即便攻击者可绕开反编译检测在本地获得应用程序包，也无法得到安装更新包，也就无法获得应用程序标识对应的完整的安装包，而且该应用程序标识对应的核心功能插件均存储于安装更新包，因此核心功能插件仍难以被攻击者获得，从而可降低被反编译而影响文件安全的可能，提高了应用程序的安全性。进一步地，在一些实施方式中，第一终端可基于超文本传输协议(https协议)将安装更新包发送至服务器，由此可防止终端设备和服务器之间的数据传输被监听，提高传输安全性，使得攻击者难以通过网络抓包获取待保护文件，提高待保护文件的安全性。在一些实施例中，将安装更新包存储后，可在获取安装更新包前，验证应用程序包的包名和签名，并在包名和签名均验证匹配后，才可获取安装更新包。使得用户如需获得加密后的待保护文件，至少要先知道应用程序包的包名、签名，在包名和签名均通过校验后，才可获得加密后的待保护文件。由此，可进一步降低被攻击者获取待保护文件进行反编译的可能性。在一些实施例中，为防止存储的安装更新包被替换，还可在安装更新包中设置完整性校验，以在获取安装更新包时，可通过完整性校验，获得安装更新包的文件是否被篡改的校验结果。具体地，在一个示例中，可对加密后的待保护文件计算第一哈希值，并将第一哈希值存储于本地，使得在用户下载安装更新包后，以加密后的待保护文件作为输入，通过哈希算法得到第二哈希值，将第一哈希值与第二哈希值进行校验匹配，若第一哈希值与第二哈希值不一致，可获得校验结果为加密后的待保护文件被篡改。由此，使得终端设备在下载安装更新包得到加密后的待保护文件时，可校验所存储的加密后的待保护文件的完整性，在文件被篡改时可不将被篡改文件与安装文件作合并或其他关联操作，以增强安全性。需要说明的是，本实施例中未详细描述的部分可以参考前述实施例，在此不再赘述。本实施例提供的应用程序包处理方法，在前述的基础上，在对待保护文件进行加密时，通过加密函数和指定密钥对待保护文件进行加密，获得加密后的待保护文件，将指定密钥存储于加密后的待保护文件的指定位置，指定位置记录于安装文件，可使得在需要安装和运行应用程序时，终端设备可基于安装文件获得指定位置，以在加密后的待保护文件中获得指定密钥，用于解密得到待保护文件。由此，不仅通过对待保护文件进行加密提高存储安全性，防止被攻击者获取之外，还可进一步地，将指定密钥存储于加密后的待保护文件的指定位置，避免应用程序标识对应的应用程序包被反编译时，导致指定密钥的泄露，可进一步提高存储安全性，降低被攻击者获取到待保护文件的可能性，以提高应用程序的安全性。另外，在一些实施例中，获得加密后的待保护文件之后，还可以更改加密后的待保护文件的文件类型，以隐藏待保护文件，使得攻击者难以获取该加密后的待保护文件，进一步降低攻击者获取到完整apk的可能性，从而进一步提高应用程序的安全性。具体地，请参阅图4，图4示出了本申请又一个实施例提供的应用程序包处理方法，于本实施例中，该方法可以包括：步骤s310：获取应用程序标识对应的待保护文件和安装文件，安装文件作为应用程序标识对应的应用程序包。步骤s320：基于加密函数和指定密钥对待保护文件进行加密，获得加密后的待保护文件。步骤s330：将指定密钥存储于加密后的待保护文件的指定位置，指定位置记录于安装文件。步骤s340：更改加密后的待保护文件的文件类型。其中，记更改前的加密后的待保护文件的文件类型为原文件类型，更改后的文件类型为目标文件类型。则本实施例中，原文件类型可为dex文件，目标文件类型与原文件类型不同，目标文件类型可包括但不限于图片、视频、文档、表格等文件，在此不做限定。由此，通过更改原文件类型为目标文件类型，可降低加密后的待保护文件被攻击者获取的可能性，提高文件安全性，进而提高应用程序的安全性。在一些实施方式中，可以通过更改加密后的待保护文件的文件名后缀，以更改加密后的待保护文件的文件类型。以下为表述方便，记加密后的待保护文件的文件名后缀为原文件名后缀，记更改后的文件名后缀为目标文件名后缀。作为一种方式，目标文件名后缀可以为图片文件的文件名后缀，如.jpg、.png等，以将加密后的待保护文件的文件类型更改为图片文件。作为另一种方式，目标文件名后缀还可为视频文件的文件名后缀，如.mp4、.avi等，以将加密后的待保护文件的文件类型更改为视频文件。由此，通过更改加密后的待保护文件的文件类型，可隐藏加密后的待保护文件，降低被攻击者获取加密后的待保护文件的可能性。需要说明的是，更改文件名后缀的方式存在多种，例如可以在原文件名后缀后直接加目标文件名后缀，还可以直接用目标文件名后缀替换原文件名后缀等，本实施例不对具体更改方式做限定。在另一些实施方式中，还可以通过给加密后的待保护文件添加目标文件类型的头部信息，以更改加密后的待保护文件的文件类型。其中，头部信息根据文件类型不同，可包括但不限于图片文件头、视频文件头等，在此不做限定。作为一种方式，第一终端可以在加密后的待保护文件的代码前添加图片文件头，以更改原文件类型为图片文件，在一个示例中，.jpg文件的图片文件头可为“ffd8ff”，将该图片文件头添加至加密后的待保护文件的代码前，可将原文件类型更改为jpg格式的图片文件；在另一个示例中，.png文件的图片文件头可为“89504e47”，将该图片文件头添加至加密后的待保护文件的代码前，可将原文件类型更改为png格式的图片文件。由此，在获取加密后的待保护文件时，可先检测头部信息，再从头部信息中获得索引位置，根据索引位置获取加密后的待保护文件。步骤s350：将加密后的待保护文件作为应用程序标识对应的安装更新包，将应用程序包和安装更新包分开存储。需要说明的是，本实施例中未详细描述的部分可以参考前述实施例，在此不再赘述。另外，在一些实施例中，第二终端在需安装和使用前述应用程序标识对应的应用程序时，可先获取应用程序标识对应的应用程序包，再获取应用程序标识对应的安装更新包，并通过一系列操作，得到应用程序标识对应的完整的apk，以正常运行应用程序标识对应的应用程序，从而在应用程序包和安装更新包由上述第一终端根据前述实施例提供的方法进行存储的基础上，可提高应用程序的安全性，降低待保护文件被反编译的可能。具体地，请参阅图5，图5示出了本申请再一个实施例提供的应用程序包处理方法，可应用于上述第二终端，该方法具体可以包括：步骤s410：基于应用程序标识对应的安装请求，获取应用程序标识对应的应用程序包，并根据应用程序包安装应用程序。其中，安装请求用于获取应用程序标识对应的应用程序包，第二终端基于应用程序标识对应的安装请求，可获取应用程序标识对应的应用程序包，并在获取到应用程序包时，可根据应用程序包安装应用程序。安装请求可由用户操作第二终端触发生成，也可由第二终端接收其他设备如其他终端设备或服务器的指令得到的，在此不做限定。在一些实施方式中，应用程序标识对应的应用程序包可存储于本地，也可存储于服务器。作为一种方式，若应用程序包存储于本地，第二终端可根据应用程序标识在本地查找对应的应用程序包；作为另一种方式，若应用程序包存储于服务器，第二终端可向服务器发送下载请求，下载请求包括应用程序标识，服务器接收到下载请求时，可向所述第二终端返回应用程序标识对应的应用程序包。步骤s420：在检测到应用程序首次启动时，获取应用程序标识对应的安装更新包。其中，应用程序包和安装更新包为上述第一终端根据上述实施例提供的方法而存储的。应用程序包可对应安装文件，安装更新包可对应加密后的待保护文件。在一些实施方式中，第二终端安装好应用程序，可自动启动应用程序，也可在检测到特定指令后，才启动应用程序。作为一种方式，应用程序包可包含安装后自启动的代码，第二终端安装好应用程序，可启动应用程序。作为另一种方式，第二终端可在检测到应用程序对应的启动指令时，启动应用程序。本实施例中，在检测到应用程序首次启动时，可获取应用程序标识对应的安装更新包。这部分实现代码可在开发时存储于应用程序包，则在第二终端根据应用程序包安装应用程序后，可检测启动程序的首次启动，在首次启动时，获取应用程序标识对应的更新包。步骤s430：对安装更新包进行解密，获得待保护文件。由于安装更新包对应上述实施例中的加密后的待保护文件，因而需对安装更新包进行解密，获得待保护文件，以将待保护文件添加到安装文件，得到应用程序标识对应的完整的应用程序包。在一些实施方式中，对安装更新包进行解密的方式，可由前述实施例中对待保护文件进行加密的方式确定，例如若加密时采用的是加密函数，在解密时可采用与加密函数对应的解密函数进行解密。另外，根据所采用加密算法的不同，还需要密钥进行加解密，还可能需要多个密钥进行加解密。作为一种方式，若采用对称加密算法对待保护文件进行加密，第二终端可基于解密函数和加密时所采用的第一密钥进行解密。具体实施方式可见后述实施例，在此不再赘述。作为另一种方式，若采用非对称算法对待保护文件进行加密，第二终端可基于解密函数和与第一密钥不同的第二密钥进行解密。步骤s440：基于待保护文件对应用程序进行更新。由于目前第二终端安装的应用程序还缺少待保护文件，无法实现待保护文件对应的功能，因而本实施例中，第二终端获得待保护文件后，可基于待保护文件对应用程序进行更新，使得应用程序标识对应的应用程序可在第二终端正常运行，并实现应用程序的功能。在一些实施方式中，第二终端可通过热更新技术，以不落地的方式更新应用程序，即更新安装文件，通过将待保护文件添加至安装文件，合并得到应用程序标识对应的完整的应用程序包，以在用户无感知的情况下完成应用程序的升级，提升用户体验。由此，在通过将完整的应用程序包分割为安装文件和待保护文件，并将安装文件单独打包为应用程序包，并分开存储安装文件和待保护文件，提高了安全性，并且也降低了最终分割后的应用程序包的代码量，使得热更新的成功率提高的同时，还可使得用户在下载安装时的感知情况基本与之前一致，也就是说，在用户无感知的情况下，不仅提高了应用程序安全性还降低了应用程序包的代码量，使得更新成功率也得以提高。在另一些实施方式中，还可通过其他方式进行更新，以得到包含待保护文件和安装文件的完整的应用程序包，本实施例在此并不对具体更新方式做限定。需要说明的是，本实施例中未详细描述的部分可以参考前述实施例，在此不再赘述。本实施例提供的应用程序包处理方法，通过基于应用程序标识对应的安装请求，获取应用程序标识对应的应用程序包，并根据应用程序包安装应用程序，然后在检测到应用程序首次启动时，获取应用程序标识对应的安装更新包，其中，应用程序包和安装更新包为第一终端根据前述实施例所述的方法而存储的，接着通过对安装更新包进行解密，获得可待保护文件，基于待保护文件对应用程序进行更新，可得到应用程序标识对应的完整的应用程序包，从而可使得应用程序标识对应的应用程序可在第二终端正常运行，并实现应用程序的功能。请参阅图6，图6示出了本申请还一个实施例提供的应用程序包处理方法，可应用于上述第二终端，该方法具体可以包括：步骤s510：基于应用程序标识对应的安装请求，获取应用程序标识对应的应用程序包，并根据应用程序包安装应用程序。步骤s520：在检测到应用程序首次启动时，获取应用程序标识对应的安装更新包。其中，应用程序包和安装更新包为上述第一终端根据上述实施例提供的方法而存储的。在一些实施例中，安装更新包可存储于服务器，第二终端在检测到应用程序首次启动时，可向服务器请求应用程序标识对应的安装更新包。在一种实施方式中，安装更新包可基于安全套接字层超文本传输安全协议(https协议)存储于服务器，由此，第二终端可基于https协议，向服务器请求应用程序标识对应的安装更新包，获取服务器返回的安装更新包。由此，基于https协议进行终端设备和服务器的通信，可降低通信被监听的可能，提高传输安全性。步骤s530：由应用程序包内获取到指定位置。其中，应用程序包记录有指定位置，指定位置存储有解密安装更新包所需的指定密钥。步骤s540：从安装更新包的指定位置，获取指定密钥。本实施例中，指定位置与安装更新包关联，第二终端可由应用程序包内获取到指定位置，并从安装更新包的指定位置，获取指定密钥。步骤s550：基于解密函数和指定密钥对安装更新包进行解密，获得待保护文件。其中，解密函数与前述实施例的加密函数对应，可用于对加密后的待保护文件进行解密。安装更新包对应加密后的待保护文件，因而可根据解密函数和指定密钥对安装更新包进行解密，获得待保护文件。例如，可将安装更新包和指定密钥作为解密函数的输入，解密函数输出解密后的文件即待保护文件。步骤s560：基于待保护文件对应用程序进行更新。需要说明的是，本实施例中未详细描述的部分可以参考前述实施例，在此不再赘述。请参阅图7，其示出了本申请实施例提供的一种应用程序包处理装置700的结构框图，该应用程序包处理装置700可应用于上述第一终端，该应用程序包处理装置700可以包括：文件获取模块710、文件加密模块720以及文件存储模块730。文件获取模块710，用于获取应用程序标识对应的待保护文件和安装文件，所述安装文件作为所述应用程序标识对应的应用程序包；文件加密模块720，用于对所述待保护文件进行加密，获得加密后的待保护文件；文件存储模块730，用于将所述加密后的待保护文件作为所述应用程序标识对应的安装更新包，将所述应用程序包和所述安装更新包分开存储。进一步地，所述文件加密模块720包括：文件加密子模块以及密钥存储子模块，其中：文件加密子模块，用于基于加密函数和指定密钥对所述待保护文件进行加密，获得加密后的待保护文件；密钥存储子模块，用于将所述指定密钥存储于所述加密后的待保护文件的指定位置，所述指定位置记录于所述安装文件。进一步地，获得加密后的待保护文件之后，所述应用程序包处理装置700还包括：类型更改模块，其中：类型更改模块，用于更改所述加密后的待保护文件的文件类型。进一步地，文件存储模块730包括：分开存储子模块，其中：分开存储子模块，用于将所述安装更新包存储于服务器，将所述应用程序包存储于本地。进一步地，所述安装文件为宿主apk文件，所述待保护文件为核心功能的插件dex文件。请参阅图8，其示出了本申请实施例提供的一种应用程序包处理装置800的结构框图，该应用程序包处理装置800可应用于上述第二终端，该应用程序包处理装置800可以包括：应用安装模块810、更新获取模块820、文件解密模块830以及应用更新模块840。应用安装模块810，用于基于应用程序标识对应的安装请求，获取所述应用程序标识对应的应用程序包，并根据所述应用程序包安装所述应用程序；更新获取模块820，用于在检测到所述应用程序首次启动时，获取所述应用程序标识对应的安装更新包，其中，所述应用程序包和所述安装更新包为第一终端根据前述应用于第一终端的方法实施例所述的方法而存储的；文件解密模块830，用于对所述安装更新包进行解密，获得待保护文件；应用更新模块840，用于基于所述待保护文件对所述应用程序进行更新。进一步地，所述应用程序包记录有指定位置，所述文件解密模块830包括：位置获取子模块、密钥获取子模块以及文件解密子模块，其中：位置获取子模块，用于由所述应用程序包内获取到所述指定位置；密钥获取子模块，用于从所述安装更新包的所述指定位置，获取指定密钥；文件解密子模块，用于基于解密函数和所述指定密钥对所述安装更新包进行解密，获得所述待保护文件。进一步地，所述更新获取模块820包括：更新请求子模块以及更新获取子模块，其中：更新请求子模块，用于基于超文本传输安全协议，向服务器请求所述应用程序标识对应的安装更新包；更新获取子模块，用于获取所述服务器返回的所述安装更新包。本申请实施例提供的应用程序包处理装置用于实现前述方法实施例中相应的应用程序包处理方法，并具有相应的方法实施例的有益效果，在此不再赘述。在本申请所提供的几个实施例中，模块相互之间的耦合可以是电性，机械或其它形式的耦合。另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。请参考图9，其示出了本申请实施例提供的一种电子设备的结构框图。该电子设备900可以是智能手机、平板电脑、笔记本电脑、个人计算机等能够运行应用程序的电子设备。本申请中的电子设备900可以包括一个或多个如下部件：处理器910、存储器920以及一个或多个应用程序，其中一个或多个应用程序可以被存储在存储器920中并被配置为由一个或多个处理器910执行，一个或多个程序配置用于执行如前述应用于第一终端的方法实施例所描述的方法。处理器910可以包括一个或者多个处理核。处理器910利用各种接口和线路连接整个电子设备900内的各个部分，通过运行或执行存储在存储器920内的指令、程序、代码集或指令集，以及调用存储在存储器920内的数据，执行电子设备900的各种功能和处理数据。可选地，处理器910可以采用数字信号处理(digitalsignalprocessing，dsp)、现场可编程门阵列(field－programmablegatearray，fpga)、可编程逻辑阵列(programmablelogicarray，pla)中的至少一种硬件形式来实现。处理器910可集成中央处理器(centralprocessingunit，cpu)、图像处理器(graphicsprocessingunit，gpu)和调制解调器等中的一种或几种的组合。其中，cpu主要处理操作系统、用户界面和应用程序等；gpu用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器910中，单独通过一块通信芯片进行实现。存储器920可以包括随机存储器(randomaccessmemory，ram)，也可以包括只读存储器(read-onlymemory)。存储器920可用于存储指令、程序、代码、代码集或指令集。存储器920可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等。存储数据区还可以存储电子设备900在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。请参考图10，其示出了本申请实施例提供的一种电子设备的结构框图。该电子设备1000可以是智能手机、平板电脑、电子书、笔记本电脑、个人计算机等能够运行应用程序的电子设备。本申请中的电子设备1000可以包括一个或多个如下部件：处理器1010、存储器1020以及一个或多个应用程序，其中一个或多个应用程序可以被存储在存储器1020中并被配置为由一个或多个处理器1010执行，一个或多个程序配置用于执行如前述应用于第一终端的方法实施例所描述的方法。处理器1010可以包括一个或者多个处理核。处理器1010利用各种接口和线路连接整个电子设备1000内的各个部分，通过运行或执行存储在存储器1020内的指令、程序、代码集或指令集，以及调用存储在存储器1020内的数据，执行电子设备1000的各种功能和处理数据。可选地，处理器1010可以采用数字信号处理(digitalsignalprocessing，dsp)、现场可编程门阵列(field－programmablegatearray，fpga)、可编程逻辑阵列(programmablelogicarray，pla)中的至少一种硬件形式来实现。处理器1010可集成中央处理器(centralprocessingunit，cpu)、图像处理器(graphicsprocessingunit，gpu)和调制解调器等中的一种或几种的组合。其中，cpu主要处理操作系统、用户界面和应用程序等；gpu用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器1010中，单独通过一块通信芯片进行实现。存储器1020可以包括随机存储器(randomaccessmemory，ram)，也可以包括只读存储器(read-onlymemory)。存储器1020可用于存储指令、程序、代码、代码集或指令集。存储器1020可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等。存储数据区还可以存储电子设备1000在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。请参考图11，其示出了本申请实施例提供的一种计算机可读取存储介质的结构框图。该计算机可读取存储介质1100中存储有程序代码，所述程序代码可被处理器调用执行上述应用于第一终端的方法实施例中所描述的方法。计算机可读取存储介质1100可以是诸如闪存、eeprom(电可擦除可编程只读存储器)、eprom、硬盘或者rom之类的电子存储器。可选地，计算机可读取存储介质1100包括非易失性计算机可读取存储介质(non-transitorycomputer-readablestoragemedium)。计算机可读取存储介质1100具有执行上述方法中的任何方法步骤的程序代码1110的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码1110可以例如以适当形式进行压缩。请参考图12，其示出了本申请实施例提供的一种计算机可读取存储介质的结构框图。该计算机可读取存储介质1200中存储有程序代码，所述程序代码可被处理器调用执行上述应用于第二终端的方法实施例中所描述的方法。计算机可读取存储介质1200可以是诸如闪存、eeprom(电可擦除可编程只读存储器)、eprom、硬盘或者rom之类的电子存储器。可选地，计算机可读取存储介质1200包括非易失性计算机可读取存储介质(non-transitorycomputer-readablestoragemedium)。计算机可读取存储介质1200具有执行上述方法中的任何方法步骤的程序代码1210的存储空间。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。程序代码1210可以例如以适当形式进行压缩。最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不驱使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。当前第1页12当前第1页12