CN111078223B - 一种应用程序的打包方法及装置 - Google Patents

Abstract

本申请实施例提供了一种应用程序的打包方法及装置，涉及互联网技术领域，包括：对应用程序进行编译，确定应用程序的安装包。针对每一个渠道，获取渠道的属性信息，然后根据渠道的属性信息修改安装包中二进制格式的***文件，之后再对修改后的应用程序的安装包进行签名，确定渠道对应的渠道包。由于对应用程序编译生成安装包后，根据渠道数量复制应用程序的安装包，然后基于安装包生成渠道包，而不需要在生成每一个渠道的渠道包时，重新编译应用程序，从而提高了应用程序的打包效率。其次，根据渠道的属性信息直接修改安装包中二进制格式的***文件，而不需要采用二次编译的方法修改***文件，减少了打包工作量，从而提高了打包效率。

Description

一种应用程序的打包方法及装置

技术领域

本申请实施例涉及互联网技术领域，尤其涉及一种应用程序的打包方法及装置。

背景技术

目前，应用程序可以在各种各样的应用市场中进行发布，用户从应用市场中下载应用程序并安装使用，应用市场我们也称之为渠道。现今，由于各个渠道的属性不同，因此对应用程序的安装包的要求也不相同。为了满足不同渠道的要求，在针对各渠道打包时，将编译后的安装包反编译后，再对安装包进行修改，之后再进行编译，这种二次编译的方法增加了打包工作量，从而影响多渠道打包的效率。

发明内容

由于现有技术中，针对各渠道打包时，采用二次编译的方法修改安装包，增加了打包工作量，从而影响多渠道打包效率的问题，本申请实施例提供了一种应用程序的打包方法及装置。

第一方面，本申请实施例提供了一种应用程序的打包方法，包括：

对应用程序进行编译，确定所述应用程序的安装包；

针对每一个渠道，获取所述渠道的属性信息；

根据所述渠道的属性信息修改所述安装包中二进制格式的***文件；

对修改后的所述应用程序的安装包进行签名，确定所述渠道对应的渠道包。由于对应用程序编译生成安装包后，根据渠道数量复制应用程序的安装包，然后基于安装包生成渠道包，而不需要在生成每一个渠道的渠道包时，重新编译应用程序，从而提高了应用程序的打包效率。其次，根据渠道的属性信息修改安装包中二进制格式的***文件，而不需要采用二次编译的方法修改***文件，减少了打包工作量，从而提高了打包效率，再者，修改安装包后对安装包进行签名，修改后的***文件受签名保护，提高了安装包的安全性。

第二方面，本申请实施例提供了一种应用程序的打包装置，包括：

编译模块，用于对应用程序进行编译，确定所述应用程序的安装包；

获取模块，用于针对每一个渠道，获取所述渠道的属性信息；

处理模块，用于根据所述渠道的属性信息修改所述安装包中二进制格式的***文件；

签名模块，用于对修改后的所述应用程序的安装包进行签名，确定所述渠道对应的渠道包。

第三方面，本申请实施例提供了一种计算机设备，包括至少一个处理器以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器第一方面所述方法的步骤。

第四方面，本申请实施例提供了一种计算机可读介质，其存储有可由计算机设备执行的计算机程序，当所述程序在计算机设备上运行时，使得所述计算机设备执行第一方面所述方法的步骤。

本申请实施例中，由于将应用程序编译后根据渠道数量复制应用程序的安装包，然后以安装包为基础生成渠道包，而不需要在生成每一个渠道的渠道包时，重新编译应用程序，从而提高了应用程序的打包效率。其次，在将渠道号添加至应用程序的安装包时，直接将渠道号写入二进制格式的***文件中，避免了二次编译，从而减少了打包工作量，提高了打包效率。之后，对应用程序的安装包进行重新签名，使得渠道号受签名保护，从而提高了应用程序的安全性。另外，根据渠道的特定需求修改安装包中的资源文件，然后对修改后的安装包进行签名，确定渠道对应的渠道包，使得渠道包能满足渠道的特定要求，提高用户体验。

附图说明

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

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

图2为本申请实施例提供的一种应用市场的界面图；

图3为本申请实施例提供的一种应用市场的界面图；

图4a为本申请实施例提供的一种应用程序的打包方法的流程示意图；

图4b为本申请实施例提供的一种修改***文件的方法的流程示意图；

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

图6为本申请实施例提供的一种应用程序的打包装置的结构示意图；

图7为本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及有益效果更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

为了方便理解，下面对本申请实施例中涉及的名词进行解释。

Android：Google公司开发的一种手机操作***。

APK：安装包(AndroidPackage，简称APK)，把Android sdk编译的工程打包成一个安装程序文件，格式为apk，是Android应用程序的安装包。

渠道包：用户可以从多个应用市场下载应用程序，故应用程序对于很多分发渠道，从各个渠道下载的应用程序的安装包也称之为各个渠道对应的渠道包。为了统计每一个渠道中应用程序的下载、安装、使用等情况，需要每一个渠道的渠道包有一个特定的标志符加以区分，这个标志符就叫做渠道号。

在具体实践过程中，本申请的发明人发现，现有技术中采用安卓打包工具对应用程序进行打包时，由于各个渠道的属性不同，因此对应用程序的安装包的要求也不相同。为了满足不同渠道的要求，需要对安装包进行修改，现有技术在针对各渠道打包时，将编译后的安装包反编译后，对安装包进行修改，之后再进行编译，这种二次编译的方法增加了打包工作量，从而影响多渠道打包的效率。

为此，本申请的发明人考虑到，对应用程序进行编译，确定应用程序的安装包，针对每一个渠道，获取渠道的属性信息，然后根据渠道的属性信息修改安装包中二进制格式的***文件。由于根据渠道的属性信息直接修改安装包中二进制格式的***文件，而不需要采用二次编译的方法修改***文件，从而减少了打包的工作量，提高了打包效率。

其次，现有技术中采用安卓打包工具对应用程序进行打包时，生成的标准安装包中各个文件的属性是统一的，比如，采用安卓标准工具打包的各个渠道的安装包中图标的分辨率是统一的，但是一些渠道的为了适应移动设备的分辨率，要求应用程序图标的分辨率高于安卓标准的分辨率。而采用安卓标准工具对这些渠道打包应用程序，应用程序图标的分辨率为安卓标准的分辨率。这样将导致渠道对应的应用市场界面中显示的应用程序图标模糊。用户从这些渠道中下载的渠道包安装后，也可能出现应用程序图标模糊的问题，从而影响用户体验。安卓标准工具也可以在编译之前针对每个渠道修改资源文件，然后再编译打包生成对应的渠道包，但是一个应用程序对应的多个渠道，且编译应用程序的时间较长，如果生成每一个渠道包时，都需要编译应用程序，将导致打包速度很慢。

为此，本申请的发明人考虑到，对应用程序进行编译，确定应用程序的安装包，然后根据渠道的属性信息确定渠道的资源文件，采用渠道的资源文件替换应用程序的安装包中对应的资源文件，其中属性信息可以包括该渠道对渠道包的一些特定要求。最后对修改后的应用程序的安装包进行签名，确定渠道对应的渠道包。由于本申请中，将应用程序一次编译后根据渠道数量的数量复制应用程序的安装包，而不需要在生成每一个渠道的渠道包时，重新编译应用程序，从而提高了应用程序的打包效率。其次，根据渠道的属性信息替换安装包中的资源文件，然后对安装包进行签名，确定渠道对应的渠道包，使得每一个渠道包能满足渠道的特定要求，提高用户使用从渠道下载的应用程序的体验。

另外，为了便于统计应用程序在各渠道的下载、安装以及使用情况，应用程序安装包都包含与渠道对应的渠道号。现有技术中，将应用程序针对多渠道进行打包时，先将应用程序进行编译并签名得到应用程序的安装包，然后在不破坏签名的前提下，将渠道号添加至安装包中，得到渠道对应的渠道包。而采用该方法添加的渠道号不受签名保护，渠道号容易被非法篡改，从而影响应用程序的安全性。为此，本申请的发明人考虑到，对应用程序进行编译，确定应用程序的安装包，然后根据渠道的数量复制应用程序的安装包。针对每一个渠道，将渠道的渠道号写入安装包中二进制格式的***文件中，然后对修改后的应用程序的安装包进行签名，确定渠道对应的渠道包。由于在对应用程序进行编译确定安装包后，将安装包进行复制，然后针对每一个渠道，将渠道号添加至安装包中，从而避免了重复编译应用程序，提高了打包效率。其次，在将渠道号添加至应用程序的安装包之后，对应用程序的安装包进行签名，渠道号受签名保护，从而提高了应用程序的安全性。

本申请实施例中的应用程序的打包方法可以应用于如图1所示的应用场景，在该应用场景中包括多渠道打包服务器101、渠道服务器102以及用户终端103。

多渠道打包服务器101包括应用程序的打包装置，是一台服务器或若干台服务器组成的服务器集群或云计算中心，多渠道打包服务器101通过无线网络与一个或多个渠道服务器102连接，多渠道打包服务器101针对每个渠道打包应用程序，生成渠道包，然后将渠道包分发至对应的渠道服务器102。渠道服务器102是一台服务器或若干台服务器组成的服务器集群或云计算中心。用户终端103是具备网络通信能力的电子设备，该电子设备可以是智能手机、平板电脑或便携式个人计算机等等，用户终端103通过无线网络与渠道服务器102连接。

对于需要在多个渠道上发布的应用程序来说，首先编译该应用程序，生成安装包。多渠道打包服务器101预先保存各个渠道的属性信息，其中渠道的属性信息至少包括渠道号、渠道对资源文件的要求。在针对每一个渠道进行打包时，复制编译生成的安装包。多渠道打包服务器101获取该渠道的属性信息，然后将渠道号添加至安装包中，根据渠道对资源文件的要求替换安装包中的资源文件，再对安装包进行签名，生成渠道包。多渠道打包服务器101将渠道包发送至渠道服务器102，然后由渠道服务器102发布至应用市场中。用户在需要下载应用程序时，点击用户终端103中应用市场网页或者APP，具体如图2所示。然后点击需要下载的应用程序后的“进入”图标，进入下载界面，具体如图3所示，点击下载按钮即可下载该应用程序。

基于图1所示的应用场景图，本申请实施例提供了一种应用程序的打包方法的流程，该方法的流程可以由应用程序的打包装置执行，如图4a所示，包括以下步骤：

步骤S401，对应用程序进行编译，确定应用程序的安装包。

具体地，对应用程序进行编译时，根据不同的操作***采用不同编译工具，比如针对Android操作***，采用Android打包工具执行标准的Android编译流程，生成Android标准的安装包(AndroidPackage，简称APK)文件。

具体实施中，Android编译流程包括：打包资源文件，生成R.java文件。处理aidl文件，生成相应java文件。编译所有java文件，生成相应class文件。打包class文件和jar包，生成classes.dex文件。打包assets和res资源，生成资源压缩包。组合classes.dex和res.zip，生成未签名的APK，生成有签名的APK。对签名包进行zipalign优化。

需要说明的是，在本申请实施例中。编译应用程序生成安装包时，可以对安装包进行签名，也可以不对安装包进行签名。

步骤S402，针对每一个渠道，获取渠道的属性信息。

渠道是指应用程序的分发渠道，也可以指应用程序的应用市场。应用市场可以是各个手机厂商对应的应用市场，比如华为应用市场、VIVO应用市场、魅族应用市场等等，也可以是通用的应用市场，比如应用宝、手机管家等等。

属性信息包括渠道号、渠道对资源文件的特定要求、应用程序标识等，不同的渠道对资源文件的特定要求可能不同，比如，渠道A要求应用程序图标的分辨率大于安卓标准中应用程序图标的分辨率。渠道B要求应用程序图标的字体大于安卓标准中应用程序图标的字体等。

应用程序的打包装置可以预先保存各个渠道的属性信息，当某个渠道的属性信息更新时，应用程序的打包装置也可以更新保存的各个渠道的属性信息。

步骤S403，根据渠道的属性信息修改安装包中二进制格式的***文件。

当针对每一个渠道对应用程序进行打包时，可以先复制已经编译生成的应用程序的安装包，而不需要每次重新编译应用程序生成安装包，然后根据渠道的属性信息直接修改安装包中二进制格式的***文件，以使安装包与渠道匹配。

步骤S404，对修改后的应用程序的安装包进行签名，确定渠道对应的渠道包。

在一种可能的实施方式中，在对应用程序进行编译，生成安装包时，没有对安装包进行签名。根据渠道的属性信息修改应用程序的安装包后，对修改后的应用程序的安装包进行签名，确定渠道对应的渠道包。

在另一种可能的实施方式中，在对应用程序进行编译，生成安装包时，对安装包进行签名。根据渠道的属性信息修改应用程序的安装包后，先删除已有签名，然后再对修改后的应用程序的安装包进行签名，确定渠道对应的渠道包。

由于对应用程序编译生成安装包后，根据渠道数量复制应用程序的安装包，然后基于安装包生成渠道包，而不需要在生成每一个渠道的渠道包时，重新编译应用程序，从而提高了应用程序的打包效率。其次，根据渠道的属性信息修改安装包中二进制格式的***文件，而不需要采用二次编译的方法修改***文件，减少了打包工作量，从而提高了打包效率。再者，修改安装包后对安装包进行签名，修改后的***文件受签名保护，提高了安装包的安全性。

具体实施中，Android应用程序的安装包的签名方式支持V1签名和V2签名。V1签名是对jar进行签名，在V1中只对未压缩的文件内容进行了验证，所以在APK签名之后可以进行很多修改，比如文件可以移动，甚至可以重新压缩。

V2签名是对整个APK签名，V2签名验证了归档中的所有字节，而不是单独的ZIP条目。由于在修改应用程序的安装包后，可以采用多种签名方式对安装包进行签名确定渠道包，故可以满足各渠道对渠道包版本的需求，提高渠道包的适用性。

可选地，在上述步骤S403中，根据渠道的属性信息修改安装包中二进制格式的***文件，如图4b所示，具体包括以下步骤：

S4031，将渠道的属性信息写入二进制格式的***文件的字符串常量池中，并记录渠道的属性信息在字符串常量池中的位置信息。

S4032，通过解析***文件确定***文件中的属性标签。

属性标签可以指meta-data标签。

S4033，将属性标签的属性值修改为渠道的属性信息在字符串常量池中的位置信息。

示例性地，设定渠道的属性信息为渠道号，***文件为AndroidManifest.xml文件，AndroidManifest.xml文件为二进制格式的清单文件。首先使用二进制编辑器查看AndroidManifest.xml文件的布局，确定字符串常量池StringPool，在StringPool的最后***渠道号，并记录渠道号在StringPool中的位置。然后解析AndroidManifest.xml文件，确定预先设置的用于写入渠道号的meta-data标签，之后再将meta-data标签的属性值修改为渠道号在StringPool中的位置。由于AndroidManifest.xml文件是安装包中的清单文件，用于记录安装包的属性参数，故在安装应用程序时，将读取AndroidManifest.xml文件中的属性参数并保存。将渠道号写入AndroidManifest.xml文件中后，应用程序在安装时也会读取渠道号并保存。后续应用程序每次启动时，通过安卓***接口即可获得渠道号，而无需再解析AndroidManifest.xml文件，从而一方面使得读取渠道号简单方便，另一方面使得读取渠道号的速度非常快。应用程序获取渠道号后上报，给统计各渠道中应程序的使用情况带来便利。将渠道的渠道号添加至应用程序的安装包的***文件中后，对修改后的应用程序的安装包进行签名，确定渠道包，故该渠道包的渠道号受签名保护，不能被随意篡改，提高了渠道包的安全性。

可选地，在上述步骤S404对修改后的所述应用程序的安装包进行签名，确定渠道对应的渠道包之前，可以先根据渠道的属性信息确定渠道的资源文件，然后采用渠道的资源文件替换应用程序的安装包中对应的资源文件。

示例性地，渠道A要求应用程序图标的分辨率大于安卓标准中应用程序图标的分辨率，在针对渠道A进行打包时，可以将安装包内应用程序图标的图片替换成满足分辨率条件的图标图片。

示例性地，渠道B要求应用程序的图标字体大于安卓标准中应用程序的图标字体。在针对渠道B进行打包时，可以将安装包内应用程序的图标字体修改成渠道B要求的字体。

示例性的，商务合作中渠道C有特殊推广要求，其应用程序启动画面(闪屏)中带有“由XX应用市场首发”字样。因此渠道C中应用程序的闪屏图片不同于其他渠道，在针对渠道C进行打包时，将应用程序的安装包内闪屏图片替换为指定图。

示例性的，某些应用市场对应用程序运行时要求严格。如GooglePlay渠道不允许动态下载可执行文件，因此需要将so文件(一种可执行的二进制代码格式)加进APK中。而国内渠道中为了降低安装包APK的体积，会故意的不把so文件打进安装包中。因此针对GooglePlay渠道进行打包时，将so文件加进APK中，从而避免后续下载，即动态下载代码。

示例性的，在特定国家和地区，由于文化、法律的差异，一些在中国大陆地区可以使用的文字、图片、语音等资源，在特定国家和地区无法使用。在针对特定国家和地区的渠道打包时，可以将安装包内对应的资源文件删除掉。

由于根据渠道的特定需求修改安装包中的资源文件，然后对修改后的安装包进行签名，确定渠道对应的渠道包，使得渠道包能满足渠道的特定要求，提高用户体验。

需要说明的是，将渠道的渠道号添加至安装包的***文件中这个步骤可以是在根据渠道的属性信息替换安装包中的资源文件之前，也可以是在根据渠道的属性信息替换安装包中的资源文件之后，对此本申请实施例不做具体限定。

可选地，在上述步骤S404确定渠道对应的渠道包之后，通过安装并运行渠道对应的渠道包，对渠道对应的渠道包进行校验。

具体地，应用程序的打包装置在本地安装并运行渠道包，根据安装情况校验渠道包的签名是否合理。在运行渠道包的过程中，读取渠道号，然后将渠道号与添加的渠道号进行比较，校验渠道号是否添加正确。在安装和运行过程，校验安装包中代码的对齐(zip-align)。由于在生成渠道包之后，自动校验渠道包的签名、渠道号和zip-align，当检验通过后，才将渠道包分发至对应的渠道，从而提高了渠道包的可靠性。

可选地，为了提高多渠道打包的效率，应用程序的打包装置采用多线程对多个渠道进行打包，具体实施中，线程数可以根据中央处理器(Central Processing Unit，简称CPU)核数确定。由于采用多线程进行渠道打包，故可以同时生成多个渠道对应的渠道包，然后将渠道包发布至对应的渠道，从而提高了多渠道打包的效率。

为了更好的解释本申请实施例，下面结合具体的实施场景描述本申请实施例提供的一种应用程序的打包方法，设定应用程序为企鹅FM、应用程序的安装包为Android应用程序的安装包，企鹅FM的渠道包括渠道1和渠道2，渠道1对应的渠道号为AB，渠道1的属性信息为企鹅FM图标的分辨率为第一阈值。渠道2对应的渠道号为CD，如图5所示，该方法包括以下步骤：

步骤S501，采用Android打包工具对企鹅FM进行编译，确定企鹅FM的安装包。

步骤S502，对企鹅FM的安装包进行复制确定两个相同的安装包。

步骤S503，针对其中一个安装包，将渠道号AB添加至AndroidManifest.xml文件中。

下面介绍将渠道号AB写入AndroidManifest.xml的过程：

APK中的AndroidManifest.xml文件不是普通的文本文件，而是结构化的二进制格式，该二进制格式会把所有字符串放到StringPool，即字符串常量池中。在往该文件中添加渠道号AB时，首先把渠道号AB写到StringPool，然后找到渠道号对应的meta-data标签，并将其值改为渠道号AB在StringPool中的位置。

为了实现将渠道号AB写到StringPool，首先需要修改StringPool header(字符串常量池头部)，设定对应的stringCount(字符串数量)变量，以及stringStart(字符串开始位移)，在StringOffsets中增加一条新的记录，指向新增的渠道号AB的偏移位，在StringPool的最后，把渠道号AB***进去，并记下渠道号AB在StringPool中的位置(index)。

为了实现将meta-data标签改为写到StringPool中的渠道号AB，首先需要解析xml文件，并找到渠道号对应的meta-data标签位置，然后将meta-data标签位置的属性值修改为新***的渠道号AB在StringPool中的位置。

步骤S504，将安装包中图像资源文件中企鹅FM图标替换为分辨率为第一阈值的企鹅FM图标。

步骤S505，删除安装包中原有的签名，对安装包重新签名，确定渠道1的渠道包a。

步骤S506，对渠道包a中的签名、渠道号以及zip-align进行校验。

步骤S507，将渠道包a发布在渠道1中。

步骤S508，针对另一个安装包，将渠道号CD添加至AndroidManifest.xml文件中。

将渠道号CD添加至AndroidManifest.xml文件中的过程与前述将渠道号AB写入AndroidManifest.xml的过程相同，此处不再赘述。

步骤S509，删除安装包中原有的签名，对安装包重新签名，确定渠道2的渠道包b。

步骤S5010，对渠道包b中的签名、渠道号以及zip-align进行校验。

步骤S511，将渠道包b发布在渠道2中。

本申请实施例中，由于将应用程序编译后根据渠道数量复制应用程序的安装包，然后以安装包为基础生成渠道包，而不需要在生成每一个渠道的渠道包时，重新编译应用程序，从而提高了应用程序的打包效率。其次，在将渠道号添加至应用程序的安装包时，直接将渠道号写入二进制格式的***文件中，避免了二次编译，从而减少了打包工作量，提高了打包效率。之后，对应用程序的安装包进行重新签名，使得渠道号受签名保护，从而提高了应用程序的安全性。另外，根据渠道的特定需求修改安装包中的资源文件，然后对修改后的安装包进行签名，确定渠道对应的渠道包，使得渠道包能满足渠道的特定要求，提高用户体验。

为了验证本申请实施中应用程序的打包方案的技术效果，本申请的发明人将本申请中的打包方案与现有技术中的打包方案进行比较，具体如表1所示：

表1.

在表1中，Gralde flavor为Android标准的打包工具，Gralde flavor在针对每一个渠道进行打包时，先将渠道号写入对应的文件中，渠道存在特定的需求时，根据渠道需求修改资源文件，然后再对修改后的应用程序进行编译，生成的安装包，之后在对安装包进行签名，确定渠道包。由于Gralde flavor在针对每一个渠道生成渠道包时，都需要编译应用程序，因此打包速度很慢。如表1所示，本申请支持根据已有APK生成渠道包，不需要重复编译，通过测试得出打包速度为生成一个渠道包平均需要559ms，而Gralde flavor不支持根据已有APK生成渠道包，每次生成渠道包度需要编译，通过测试得出打包速度为生成一个渠道包平均10min，本申请的打包方案的打包速度比Gralde flavor快很多。其次，Graldeflavor在生成渠道包后，只对渠道包的签名进行校验，而本申请生成渠道包后，会对渠道包的渠道号、zip-align、签名都进行校验，从而提高渠道包的可靠性。

在表1中，Walle为针对Android的V2签名设计的打包工具，具体过程为：先对应用程序进行编译，生成APK，然后采用V2签名对安装包进行签名。接着对采用V2签名生成的APK中的ID-value进行扩展，提供自定义ID－value(渠道信息)，并保存在APK中。APK在安装过程中进行的签名校验，会忽略添加的自定义ID-value，从而使APK能正常安装。由于Walle是针对V2签名设计的打包工具，因此不支持采用V1签名对安装包进行签名，而本申请中，将渠道号添加至安装包和/或自定义修改安装包时，可以采用V1签名对安装包进行签名，也可以采用V2签名对安装包进行签名，从而提高渠道包的适用性和兼容性。其次，Walle是在不破坏签名的前提下，将渠道号添加至安装包，因此渠道号也就不会受签名保护，从而导致渠道号容易被篡改，影响渠道包的安全性。而本申请中，将渠道号添加至安装包和/或自定义修改安装包后，对修改后的安装包进行签名，生成渠道包，所以渠道号受签名保护，提高了渠道包的安全性。另外，Walle在生成渠道包后，只对渠道包的渠道号进行校验，而本申请生成渠道包后，会对渠道包的渠道号、zip-align、签名都进行校验，从而提高渠道包的可靠性。再者，在渠道存在一些特定需求时，Walle不支持根据渠道需求自定义修改APK，而本申请中，支持根据渠道需求自定义修改安装包APK，从而满足各个渠道的需求，提高用户体验。

在表1中，packer-ng-plugin为针对Android的V1签名设计的打包工具，具体过程为：先对应用程序进行编译，生成APK，然后采用V1签名对安装包进行签名。接着将渠道的渠道号写入APK文件的注释中，生成渠道包。由于packer-ng-plugin是针对V1签名设计的打包工具，因此不支持采用V2签名对安装包进行签名，而本申请中，将渠道号添加至安装包和/或自定义修改安装包时，可以采用V1签名对安装包进行签名，也可以采用V2签名对安装包进行签名，从而提高渠道包的适用性和兼容性。其次，packer-ng-plugin是在不破坏签名的前提下，将渠道号添加至APK，因此渠道号也就不会受签名保护，从而导致渠道号容易被篡改，影响渠道包的安全性。而本申请中，将渠道号添加至安装包和/或自定义修改安装包后，对修改后的安装包进行签名，生成渠道包，所以渠道号受签名保护，提高了渠道包的安全性。另外，packer-ng-plugin在生成渠道包后，不会对渠道包进行校验，而本申请生成渠道包后，会对渠道包的渠道号、zip-align、签名都进行校验，从而提高渠道包的可靠性。再者，在渠道存在一些特定需求时，packer-ng-plugin不支持根据渠道需求自定义修改APK，而本申请中，支持根据渠道需求自定义修改安装包APK，从而满足各个渠道的需求，提高用户体验。

进一步地，用户终端从各个渠道下载的渠道包都携带了渠道号，用户终端在运行应用程序时，应用程序将向统计中心反馈渠道号，从而便于统计中心统计应用程序在各个渠道中下载并安装使用的情况。

基于相同的技术构思，本申请实施例提供了一种应用程序的打包装置，如图6所示，该装置600包括：下载模块601、获取模块602、处理模块603、签名模块605。

编译模块601，用于对应用程序进行编译，确定所述应用程序的安装包；

获取模块602，用于针对每一个渠道，获取所述渠道的属性信息；

处理模块603，用于根据所述渠道的属性信息修改所述安装包中二进制格式的***文件；

签名模块604，用于对修改后的所述应用程序的安装包进行签名，确定所述渠道对应的渠道包。

可选地，还包括替换模块605；

所述替换模块605具体用于：

对修改后的所述应用程序的安装包进行签名，确定所述渠道对应的渠道包之前，根据所述渠道的属性信息确定所述渠道的资源文件；

采用所述渠道的资源文件替换所述应用程序的安装包中对应的资源文件。

可选地，还包括校验模块606；

所述校验模块606具体用于：

对修改后的所述应用程序的安装包进行签名，确定所述渠道对应的渠道包之后，通过安装并运行所述渠道对应的渠道包，对所述渠道对应的渠道包进行校验。

可选地，处理模块603具体用于：

将所述渠道的属性信息写入二进制格式的***文件的字符串常量池中，并记录所述渠道的属性信息在所述字符串常量池中的位置信息；

通过解析所述***文件确定所述***文件中的属性标签；

将所述属性标签的属性值修改为所述渠道的属性信息在所述字符串常量池中的位置信息。

可选地，渠道的属性信息包括渠道号，所述***文件为AndroidManifest.xml文件。

基于相同的技术构思，本申请实施例提供了一种计算机设备，如图7所示，包括至少一个处理器701，以及与至少一个处理器连接的存储器702，本申请实施例中不限定处理器701与存储器702之间的具体连接介质，图7中处理器701和存储器702之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。

在本申请实施例中，存储器702存储有可被至少一个处理器701执行的指令，至少一个处理器701通过执行存储器702存储的指令，可以执行前述的应用程序的打包方法中所包括的步骤。

其中，处理器701是计算机设备的控制中心，可以利用各种接口和线路连接计算机设备的各个部分，通过运行或执行存储在存储器702内的指令以及调用存储在存储器702内的数据，从而实现多渠道打包。可选的，处理器701可包括一个或多个处理单元，处理器701可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作***、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器701中。在一些实施例中，处理器701和存储器702可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器701可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器702作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器702可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器702是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器702还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

基于同一发明构思，本申请实施例还提供了一种计算机可读介质，其存储有可由计算机设备执行的计算机程序，当所述程序在计算机设备上运行时，使得所述计算机设备执行打包应用程序的方法的步骤。

本领域内的技术人员应明白，本发明的实施例可提供为方法、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种应用程序的打包方法，其特征在于，包括：

对应用程序进行编译，确定所述应用程序的安装包；

针对每一个渠道，获取所述渠道的属性信息；

根据所述渠道的属性信息修改所述安装包中二进制格式的***文件；

对修改后的所述应用程序的安装包进行签名，确定所述渠道对应的渠道包；

通过安装并运行所述渠道对应的渠道包，对所述渠道对应的渠道包进行校验，校验内容包括：渠道包的签名、渠道号和代码对齐；在校验通过后将所述渠道包分发至对应的渠道。

2.如权利要求1所述的方法，其特征在于，所述对修改后的所述应用程序的安装包进行签名，确定所述渠道对应的渠道包之前，还包括：

根据所述渠道的属性信息确定所述渠道的资源文件；

采用所述渠道的资源文件替换所述应用程序的安装包中对应的资源文件。

3.如权利要求1或2所述的方法，其特征在于，所述根据所述渠道的属性信息修改所述安装包中二进制格式的***文件，包括：

将所述渠道的属性信息写入二进制格式的***文件的字符串常量池中，并记录所述渠道的属性信息在所述字符串常量池中的位置信息；

通过解析所述***文件确定所述***文件中的属性标签；

将所述属性标签的属性值修改为所述渠道的属性信息在所述字符串常量池中的位置信息。

4.如权利要求3所述的方法，其特征在于，所述渠道的属性信息包括渠道号，所述***文件为AndroidManifest.xml文件。

5.一种应用程序的打包装置，其特征在于，包括：

编译模块，用于对应用程序进行编译，确定所述应用程序的安装包；

获取模块，用于针对每一个渠道，获取所述渠道的属性信息；

处理模块，用于根据所述渠道的属性信息修改所述安装包中二进制格式的***文件；

签名模块，用于对修改后的所述应用程序的安装包进行签名，确定所述渠道对应的渠道包；通过安装并运行所述渠道对应的渠道包，对所述渠道对应的渠道包进行校验，校验内容包括：渠道包的签名、渠道号和代码对齐；在校验通过后将所述渠道包分发至对应的渠道。

6.如权利要求5所述的装置，其特征在于，还包括替换模块；

所述替换模块具体用于：

对修改后的所述应用程序的安装包进行签名，确定所述渠道对应的渠道包之前，根据所述渠道的属性信息确定所述渠道的资源文件；

采用所述渠道的资源文件替换所述应用程序的安装包中对应的资源文件。

7.如权利要求5或6所述的装置，其特征在于，所述处理模块具体用于：

将所述渠道的属性信息写入二进制格式的***文件的字符串常量池中，并记录所述渠道的属性信息在所述字符串常量池中的位置信息；

通过解析所述***文件确定所述***文件中的属性标签；

将所述属性标签的属性值修改为所述渠道的属性信息在所述字符串常量池中的位置信息。

8.如权利要求7所述的装置，其特征在于，所述渠道的属性信息包括渠道号，所述***文件为AndroidManifest.xml文件。

9.一种计算机设备，其特征在于，包括至少一个处理器以及至少一个存储器，其中，所述存储器存储有计算机程序，当所述程序被所述处理器执行时，使得所述处理器执行权利要求1～4任一权利要求所述方法的步骤。

10.一种计算机可读介质，其特征在于，其存储有可由计算机设备执行的计算机程序，当所述程序在计算机设备上运行时，使得所述计算机设备执行权利要求1～4任一所述方法的步骤。

Images