CN108829405B - 渠道包的生成方法及装置、存储介质、电子装置 - Google Patents

Abstract

本发明提供了一种渠道包的生成方法及装置、存储介质、电子装置，其中，该方法包括：获取第一应用安装包APK，以及获取第二APK，其中，第一APK包含渠道软件开发工具包SDK功能，第二APK用于提供目标应用的对外接口；对第一APK和第二APK进行反编译；合并反编译后的第一APK和第二APK，生成目标应用的渠道包。通过本发明，解决了相关技术中在开发应用接入多个渠道的SDK而导致效率低下的技术问题。

Description

渠道包的生成方法及装置、存储介质、电子装置

技术领域

本发明涉及通信领域，具体而言，涉及一种渠道包的生成方法及装置、存储介质、电子装置。

背景技术

终端操作系统(如Android)的渠道众多，国外主要是google play和amazon，而国内渠道就有上百家。其中包括应用宝、360手机助手、百度手机助手、小米应用商店、华为应用商店等。

游戏开发人员一般比较专注于游戏场景以及逻辑方面的开发，不是很熟悉平台(IOS、Android)开发APP的相关技术，为了能够介入各个平台，开发者只能开发接入各个渠道的接口，非常耗时且不高效。

相关技术中的方案一般有两种：游戏开发者直接去获取渠道的SDK开发包，然后按照渠道的文档接入相应的功能，例如登录支付等功能；由部分开发人员，统一接入各个渠道SDK，然后统一不同渠道的接口，并且提供封装后的SDK给游戏开发人员进行接入。

相关技术中的两种方案都有对应的缺点，第一种方案需要游戏开发者自己维护不同渠道SDK，如果渠道SDK升级，游戏开发人员又需要重新对渠道SDK进行升级，这是一个比较繁琐的工作；第二种方案，虽然已经统一接口，屏蔽掉不同渠道的接口差异性，游戏不用关心渠道具体的实现以及渠道不同版本之前的差异，但是游戏还是接触封装后的SDK，还是要维护不同版本SDK，并且还需要对每个渠道进行编译打包APK，如果游戏工程比较大，编译一个渠道包耗时是非常多的。

针对相关技术中存在的上述问题，目前尚未发现有效的解决方案。

发明内容

本发明实施例提供了一种渠道包的生成方法及装置、存储介质、电子装置。

根据本发明的一个实施例，提供了一种渠道包的生成方法，包括：获取第一应用安装包APK，以及获取第二APK，其中，所述第一APK包含渠道软件开发工具包SDK功能，所述第二APK用于提供目标应用的对外接口；对所述第一APK和所述第二APK进行反编译；合并反编译后的所述第一APK和所述第二APK，生成所述目标应用的渠道包。

根据本发明的另一个实施例，提供了一种渠道包的生成装置，包括：获取模块，用于获取第一应用安装包APK，以及获取第二APK，其中，所述第一APK包含渠道软件开发工具包SDK功能，所述第二APK用于提供目标应用的对外接口；反编译模块，用于对所述第一APK和所述第二APK进行反编译；生成模块，用于合并反编译后的所述第一APK和所述第二APK，生成所述目标应用的渠道包。

根据本发明的又一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本发明的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

通过本发明，基于第一APK和第二APK生成目标应用的渠道包，可以屏蔽渠道所有东西，对于目标应用是完全透明的，开发者不用关心渠道接口，以及每个版本升级的内容，也不用单独对每个渠道进行编译打包，解决了相关技术中在开发应用接入多个渠道的SDK而导致效率低下的技术问题，开发者可以专注于应用开发，脱离和渠道的沟通具体实现、维护不同渠道不同版本的各种混乱状态。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的渠道包的生成方法的流程图；

图2是本发明实施例的效果流程图；

图3是本发明实施例封装渠道SDK的效果示意图；

图4是本发明实施母包SDK的工程结构图；

图5是本发明实施游戏接入母包SDK的示意图；

图6是本发明实施的APK打包示意图；

图7是本发明实施的APK的文件结构示意图；

图8是本实施例res资源目录打包成arsc文件的示意图；

图9是本发明实施例的arsc文件结构示意图；

图10是本发明实施例的Dex文件总体结构示意图；

图11是本发明实施例的APK二进制反编译文件结构图；

图12是本发明实施例的合并示意图；

图13是根据本发明实施例的渠道包的生成装置的结构框图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

在实施例应用在应用开发的环境，在应用开发中，存在以下术语：

APK，是应用安装包(如Android Package)的缩写，即Android安装包(APK)，在Android手机安装后，即可以运行该程序。

SDK，是Software Development Kit的缩写，即软件开发工具包。开发工程师可以从目标系统开发者那里获取到对应的开发包，然后即可接入对应的平台功能。SDK还经常包括示例代码、支持性的开发文档等。

Aapt，即Android Asset Packaging Tool，在android官方SDK的build-tools目录下，可以把开发工程下面的资源编译打包进APK。

Dex，文件是手机上类似Windows上的EXE文件，dex文件是可以直接在Dalvik虚拟机中加载运行的文件。点击android手机上面的应用程序图标，都会运行在一个Dalvik虚拟机实例，并且运行dex文件。

Arsc，包含Android APK的包名、版本号、版本名称、资源索引的文件等。

渠道，Android应用分发商或应用平台，一般渠道都有自己的用户体系以及相应的支付方式，如果产品要上架该渠道，一般需要接入该渠道的登录以及支付功能。例如国外的渠道，一般就是google play和amazon，国内的渠道就非常多，据不完全统计，最少200家，如果一个游戏产品需要上架所有渠道，就单单接入渠道SDK就是一个非常庞大和耗时的工作。

在本公开其中之一种实施例中提供了一种渠道包的生成方法，图1是根据本发明实施例的渠道包的生成方法的流程图，如图1所示，该流程包括如下步骤：

步骤S102，获取第一应用安装包APK，以及获取第二APK，其中，第一APK包含渠道软件开发工具包SDK功能，第二APK用于提供目标应用的对外接口；

步骤S104，对第一APK和第二APK进行反编译；

步骤S106，合并反编译后的第一APK和第二APK，生成目标应用的渠道包。

通过上述步骤，基于第一APK和第二APK生成目标应用的渠道包，可以屏蔽渠道所有东西，对于目标应用是完全透明的，开发者不用关心渠道接口，以及每个版本升级的内容，也不用单独对每个渠道进行编译打包，解决了相关技术中在开发应用接入多个渠道的SDK而导致效率低下的技术问题，开发者可以专注于应用开发，脱离和渠道的沟通具体实现、维护不同渠道不同版本的各种混乱状态。

可选地，上述步骤的执行主体可以为应用软件(如游戏)的开发平台，服务器，终端等，但不限于此。本实施例中的目标应用可以是各种应用软件，如游戏，即时通讯，理财，视频各种需要在应用商店下载的软件，本实施例以游戏为例进行说明。

图2是本发明实施例的效果流程图，包括：

游戏接入母包SDK得到游戏母包APK，即游戏只需要接入一个SDK。这个母包SDK只是提供一些对外接口给游戏调用，并没有真正的功能，这也是母包SDK和封装后的渠道SDK不一样的地方，封装的渠道SDK包含渠道本身的逻辑功能。母包SDK只是为了让游戏接入对应的功能接口，并且完成编译，输出包含SDK功能接口的游戏APK。

使用和母包一样的通用接口封装渠道SDK，然后打包成一个APK，仅包含渠道SDK资源、逻辑以及对外的封装接口。游戏开发人员不用关心渠道具体的实现以及该APK具体的封装。

游戏提供母包APK，然后使用本发明，按照APK的格式以及APK里面文件的文件结构解开游戏母包APK以及渠道APK，然后把解开后的两部分文件进行合并，然后重新按照APK文件的构造打包回来，即可以输出真正的渠道包。

可选地，获取第一APK包括：统一封装一个或多个渠道的SDK接口；打包一个或多个渠道的SDK接口，生成第一APK。

图3是本发明实施例封装渠道SDK的效果示意图，图3显示其中一个渠道封装时候的工程目录结构，libs目录是渠道本身提供的jar，res目录是渠道本身提供的资源，Android Manifest文件是渠道本身的清单配置，会罗列渠道的登录、支付、用户中心等配置信息，src目录是封装渠道的相关接口，包括登录支付等；然后对外提供给游戏开发者，每个渠道对外提供给游戏开发的接口都是一样，这样才能简化游戏接入的成本，保证游戏只需要接入一个母包SDK(接口名字和封装的渠道一致)，最终打包后能真正执行到对应渠道的功能。

根据上面的Android工程目录结构，进行编译打包，输出封装渠道的APK，供后面打该游戏渠道包(可以上架到渠道应用市场的APK)做合并准备。

可选地，获取第二APK包括：获取预设的母包SDK，其中，母包SDK用于提供目标应用的调用接口；在母包SDK中接入渠道要求的功能接口，生成第二APK。

图4是本发明实施母包SDK的工程结构图，母包SDK是一个特殊的特殊虚拟的渠道SDK，让游戏接入对应的渠道接口并且顺利编译通过，然后游戏打包的母包APK就会包含渠道要求的相关功能接口，例如登录支付等。其他真正的渠道(360、百度等渠道)都会使用对应的工程，输出对应封装后的渠道APK，然后和游戏母包APK做合并。而母包SDK本身不会输出APK，会直接提供给游戏接入引用、编译，然后输出游戏母包APK。

图5是本发明实施游戏接入母包SDK的示意图，本实施例是一个统一的打渠道包方案，并没有每个游戏的项目源代码，但是需要每个游戏接入渠道要求的功能接口后，输出一个游戏母包APK(即第二APK)。在打包渠道包时候，会把母包SDK的所有东西删除，然后替换成渠道SDK本身的代码和资源，即可得到真正的游戏渠道包。游戏开发工程引用母包SDK后，可以输出一个游戏母包APK。

图6是本发明实施的APK打包示意图，包括封装渠道APK(第一APK)和游戏母包APK(第二APK)。包括：

通过aapt打包res资源文件，生成R.java、resources.arsc和res文件(二进制&非二进制如res/raw和pic保持原样)

处理.aidl文件，生成对应的Java接口文件，某些渠道没有该类型文件，Googleplay渠道就有这种类型的文件。

通过Java Compiler编译R.java、src目录里面的Java接口文件、Java源文件，生成.class文件。

通过dex命令，将.class文件和第三方库中的.class文件处理生成classes.dex。

通过apkbuilder工具，将aapt生成的resources.arsc和res文件、assets文件和classes.dex一起打包生成APK。

通过Jarsigner工具，对上面的APK进行debug或release签名。对于我们封装的渠道APK，可以不用处理该步骤，因为我们封装渠道APK并不用真正安装运行，只需要后面和游戏母包做合并。但是该发明后面完成了游戏母包APK和渠道APK合并操作后，必须进行签名，否则是无法安装到手机上面的。

通过zipalign工具，将签名后的APK进行对齐处理，使得APK中的资源文件偏离文件起始位置4个字节，从而可以通过mmap()直接访问，从而减少RAM占用。该发明后面完成了游戏母包APK和渠道APK合并操作，以及进行签名后，也要进行对齐处理。

图7是本发明实施的APK的文件结构示意图，在把游戏母包APK和封装渠道APK做二进制解包和合并，因此需要先了解APK内部的文件结构。按照APK内部文件的文件结构，把它们解析出对应的文本，然后互相合并，文件合并完成后，然后又使用Android打包工具打包回来一个真正的游戏渠道包(即目标应用的渠道包)。

上面是一个APK文件所包含的基础文件，APK本身就是一个压缩文件，解压即可看到对应的目录结构。上面封装的渠道APK和游戏母包APK也是相同的目录结构。

resources.arsc是资源索引表，通过它可以找到资源的值，路径等。该发明会把该二进制文件，按照本身的文件结构解析出对应的文件，以及资源索引id等文本，然后把渠道APK资源和游戏母包APK做合并。图8是本实施例res资源目录打包成arsc文件的示意图。

assets、res目录都是资源目录，两者区别主要是：

assets目录下面可以建立任意层次的子目录；而res目录只能存储在相应的子目录，必须按照Android官方的目录结构；

引用资源的方式不同；

res目录中的资源子目录除了raw外，其他资源目录中的资源文件都会被编译，并且按照arsc文件的结构进行存储。

AndroidManifest.xml，是Android应用程序的配置文件，是一个用来描述Android应用整体配置的设定文件。

META-INF目录：保存应用的签名信息，签名信息可以验证APK文件的完整性。

classes.dex，是编译开发工程java代码后，生成的Dalvik字节码。

lib，这里存放应用程序依赖的native库文件，一般是用C/C++编写，这里的lib库可能包含4中不同类型，根据CPU型号的不同，大体可以分为ARM，ARM-v7a，MIPS，X86，分别对应着ARM架构，ARM-V7架构，MIPS架构和X86架构。

本实施例输入两个APK，也是有两个arsc文件，需要按照arsc的文件结构，解析出对应的文本，然后进行合并。

图9是本发明实施例的arsc的文件结构示意图，其中，资源索引表的头部信息主要包括Resources.arsc文件的大小和资源包数量。默认情况下都只有一个就是应用的包名所在的资源包。全局字符串资源池，包含了所有的在资源包里面所定义的资源项的值字符串。该部分数据结构包含字符串的个数、字符串样式的个数、字符串偏移数组和字符串样式偏移数组。package数据块，这个数据块记录编译包的元数据，数据结构主要包括包id，包名、类型字符串资源池相对头部的偏移以及资源项名称字符串相对头部的偏移等，其中包的ID,等于Package Id,一般用户包的值Package Id为0X7F,系统资源包的Package Id为0X01，后面解析arsc文件生成的public.xml需要用到。里面还分别对应类型字符串资源池和资源项名称字符串资源池。这两个字符串资源池结构和上面的资源项的值字符串资源池结构相同。类型规范数据块：用来描述资源项的配置差异性。通过这个差异性描述，我们就可以知道每一个资源项的配置状况。知道了一个资源项的配置状况之后，Android资源管理框架在检测到设备的配置信息发生变化之后，就可以知道是否需要重新加载该资源项。类型规范数据块是按照类型来组织的，也就是说，每一种类型都对应有一个类型规范数据块。资源的类型有animator、anim、color、drawable、layout、menu、raw、string和xml等。类型资源项数据块用来描述资源项的具体信息,这样我们就可以知道每一个资源项的名称、值和配置等信息。类型资源项数据同样是按照类型和配置来组织的,也就是说,一个具有n个配置的类型一共对应有n个类型资源项数据块。数据结果包括对应类型索引以及资源数据索引等。

图10是本发明实施例的Dex文件总体结构示意图，header,除了描述.dex文件的文件信息外，还有文件里其它各个区域的索引。各个的定义字段以及长度如表1的字段：

表1

字段名称	偏移值	长度	说明
				magic	0x0	8	魔数字段，值为″dex\n035\0″
checksum	0x8	4	校验码
				signature	0xc	20	sha-1签名
file_size	0x20	4	dex文件总长度
				header_size	0x24	4	文件头长度，009版本＝0x5c 035版本＝0x70
endian_tag	0x28	4	标示字节顺序的常量
				link_size	0x2c	4	链接段的大小，如果为0就是静态链接
link_off	0x30	4	链接段的开始位置
				map_off	0x34	4	map数据基址
string_ids_size	0x38	4	字符串列表中字符串个数
				string_ids_off	0x3c	4	字符串列表基址
type_ids_size	0x40	4	类列表里的类型个数
				type_ids_off	0x44	4	类列表基址
proto_ids_size	0x48	4	原型列表里面的原型个数
				proto_ids_off	0x4c	4	原型列表基址
field_ids_size	0x50	4	字段个数
				field_ids_off	0x54	4	字段列表基址
method_ids_size	0x58	4	方法个数
				method_ids_off	0x5c	4	方法列表基址
class_defs_size	0x60	4	类定义标中类的个数
				class_defs_off	0x64	4	类定义列表基址
data_size	0x68	4	数据段的大小，必须4k对齐
				data_off	0x6c	4	数据段基址

string_ids，存放string区段的实际偏移量，单位字节。他可以帮助编译器和虚拟机直接跳到这个区段，而不必从前读到后，一直读取到该位置。type_ids，proto_ids,field_ids,method_ids的大小(size)和偏移量(offset)和string_ids的作用一样。

每个字符串都对应一个DexStringId数据结构，大小为4B,同时虚拟机可以通过头文件中的string_ids_size知道当前dex文件中字符串的总数，也就是string_ids区域中DexStringId数据结构的总数，所以虚拟机可以通过简单的乘法运算即可实现对字符串资源的索引，也可以根据kDexTypeStringIdItem获取字字符串。

class_defs区域里存放着class definitions,class的定义。记录了指定类的各类信息，包括接口，超类，类数据偏移量等。数据结构如表2所示：

表2

data，数据区，保存着各个类的数据，对应第4点中class_defs的各个偏移地址的数据。包含的内容如表3所示：

表3

annotation items
	COde item
annotation directory
	interfaces
parameters
	strings
debug items
	annotation sets
static values
	class data

可选的，对第一APK和第二APK进行反编译包括：将第一APK的二进制文件反编译出第一解封装文件，以及将第二APK中的二进制文件反编译出第二解封装文件。

图11是本发明实施例的APK二进制反编译文件结构图，把封装后的渠道包APK和游戏母包APK进行反编译，得到的文件结构如图11所示，assets文件夹就是APK本身解压后的assets目录

original存放原来APK的签名等信息，在本发明中该目录并没有什么作用。本发明最后得到的APK是需要重新签名和对齐的。

res目录就是按照上面arsc文件数据结构把APK中的resources.arsc文件解析出来的数据。

smali目录就是按照上面dex文件数据结构把APK中的classes.dex文件解析出来的数据。

AndroidManifest.xml是把原来APK中的AndroidManifest.xml文件解析出来。

apktool.yml文件存储的是原来APK的一些额外数据，包括版本号、版本名称等数据。由于本实施例在进行反编译时，使用了apktool来实现，因此产生“apktool.yml”文件，需要说明的是，在对第一APK和第二APK进行反编译时，并不仅限于参考使用apktool来实现，其他的反编译工具也可以。

可选的，合并反编译后的第一APK和第二APK包括：合并第一解封装文件和第二解封装文件，其中，在第一解封装文件录和第二解封装文件存在重复文件时，在第二解封装文件中保留重复文件，同时在第一解封装文件中删除重复文件。合并第一解封装文件和第二解封装文件包括：合并第一解封装文件和第二解封装文件中的以下至少之一：assets目录、original目录、res目录、smali目录、lib目录、AndroidManifest.xml文件、apktool.yml文件。

图12是本发明实施例的合并示意图，由于APK反编译后的目录格式基本一致，所以只需要把对应目录的文件进行拷贝，或者合并，或者丢弃即可；对于有两个目录文件中相同的地方，都是保留游戏母包APK里面的文件或者节点，丢弃渠道APK里面的文件或者节点。合并项目包括：

assets目录合并

assets目录里面的所有文件都没有什么规则，游戏母包APK的assets目录里面一般是游戏的UI资源，脚本等文件。渠道APK的assets目录里面一般是渠道的一些配置信息。两个目录在该发明实践过程中不会有同名的文件，直接把两个目录进行物理拷贝即可。

original目录

该目录在合并后会删除掉，实践过程中不用做合并操作。

res目录合并

res目录里面包含drawable(图片)、layout(布局)、values(常量配置)等子目录。

drawable子目录都是png格式的图片，合并过程中如果有同名的文件，会丢弃渠道apk里面该目录的文件，保留游戏母包APK的同名文件，然后做同名文件报警处理。

layout和res子目录都是xml格式的文本，layou目录合并过程如果有同名文件，也是丢弃渠道APK里面的该文件，保留游戏母包APK里面的该文件，并做报警处理。

res子目录里面的xml文件，如果有同名文件，不会丢弃，而是把两份xml文件文本进行合成一份xml文件，按照xml格式，不同xml节点合并，相同xml节点丢弃渠道APK的，保留游戏母包APK反编译目录里面的。其中对于res/values/public.xml文件，该文件是APK图片资源、常量资源的索引表，每个索引必须唯一对应一个资源。因此需要在把public.xml合成一份文件的基础上，重新计算对应的id值，在游戏母包APK对应类型的id值上面，把渠道APK对应类型的id值按顺序都加1，达到每个资源id值都是唯一的。

smali目录

smali目录是JAVA代码生成dex反编译后得到的，如果游戏母包APK和渠道APK使用相同的JAVA包名和类名文件，就会丢弃渠道APK里面的该文件，保留游戏母包APK里面的该文件，然后进行报警处理。否则就进行文件拷贝操作。

lib目录合并

lib目录不一定会存在，和游戏本身或者渠道本身的功能实现有关。lib存放的是不同架构(arm、x86)的so文件，如果有同名文件就会丢弃渠道APK反编译目录里面的该文件，保留游戏母包APK反编译目录里面的该文件，然后进行报警处理；否则就进行文件拷贝操作。

AndroidManifest.xml文件合并

需要把这两份xml文件文本进行合成一份xml文件，按照xml格式，不同xml节点合并，相同xml节点丢弃渠道APK反编译目录的，保留游戏母包APK反编译目录里面的。两份文件相同的xml节点一般都是声明了相同的手机权限。

apktool.yml文件合并

该文件一般不需要做合并，直接使用游戏母包APK反编译目录里面的那一份，但是如果渠道APK反编译目录里面的apktool.yml有unknownFiles节点内容，即需要把该unknownFiles节点内容拷贝到游戏母包APK反编译目录的apktool.yml文件的unknownFiles节点下面。

可选的，本实施例的方案还包括输出渠道包，把合并好的渠道包(游戏母包APK+渠道APK)目录编译回去，得到最终可以上架到渠道应用商店的APK。使用aapt编译资源；接着把smali目录中的smali文件编译成dex文件；最后把dex、arsc等文件压缩合并成一个渠道包APK，然后使用jarsigner进行签名，使用zipalign进行对齐，得到最终的渠道包，用于上架渠道方的应用商店，供用户下载安装。

可选的，在生成目标应用的渠道包之后，还包括：获取目标应用的功能逻辑；将功能逻辑接入对外接口，并生成目标应用的APK。功能逻辑可以是游戏的策略，界面等。

根据本发明提供的渠道包打包方法与装置，游戏只需要提供一个游戏母包APK，然后使用二进制方法把游戏母包APK和渠道APK进行合并即可打出对应的渠道包。完全屏蔽了渠道所有东西，对于游戏来说是完全透明的，渠道接口是怎么样，每个版本升级了什么内容完全不用关心，也不用单独对每个渠道进行编译打包，从此专注于游戏开发，脱离和渠道的沟通具体实现、维护不同渠道不同版本的各种混乱状态。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例的方法。

本公开其中之一种实施例还提供了一种渠道包的生成装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图13是根据本发明实施例的渠道包的生成装置的结构框图，如图13所示，该装置包括：

获取模块130，用于获取第一应用安装包APK，以及获取第二APK，其中，第一APK包含渠道软件开发工具包SDK功能，第二APK用于提供目标应用的对外接口；

反编译模块132，用于对第一APK和第二APK进行反编译；

生成模块134，用于合并反编译后的第一APK和第二APK，生成目标应用的渠道包。

可选的，获取第一APK时，获取模块包括：封装单元，用于统一封装一个或多个渠道的SDK接口；打包单元，用于打包一个或多个渠道的SDK接口，生成第一APK。

可选的，获取第二APK时，获取模块包括：获取单元，用于获取预设的母包SDK，其中，母包SDK用于提供目标应用的调用接口；生成单元，用于在母包SDK中接入渠道要求的功能接口，生成第二APK。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

本公开其中之一种实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：

S1，获取第一应用安装包APK，以及获取第二APK，其中，第一APK包含渠道软件开发工具包SDK功能，第二APK用于提供目标应用的对外接口；

S2，对第一APK和第二APK进行反编译；

S3，合并反编译后的第一APK和第二APK，生成目标应用的渠道包。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，获取第一应用安装包APK，以及获取第二APK，其中，第一APK包含渠道软件开发工具包SDK功能，第二APK用于提供目标应用的对外接口；

S2，对第一APK和第二APK进行反编译；

S3，合并反编译后的第一APK和第二APK，生成目标应用的渠道包。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (6)

1.一种渠道包的生成方法，其特征在于，包括：

统一封装一个或多个渠道的SDK接口；

打包所述一个或多个渠道的SDK接口，生成第一APK，其中，所述第一APK包含渠道软件开发工具包SDK功能；

获取预设的母包SDK，其中，所述母包SDK用于只提供调用接口，没有真正的功能；

在所述母包SDK中接入渠道要求的功能接口，生成第二APK，其中，所述第二APK用于提供目标应用的对外接口；

将所述第一APK的二进制文件反编译出第一解封装文件，以及将所述第二APK中的二进制文件反编译出第二解封装文件；

合并反编译后的所述第一APK和所述第二APK，生成所述目标应用的渠道包；

其中，在生成所述目标应用的渠道包之后，所述方法还包括：

获取所述目标应用的功能逻辑；

将所述功能逻辑接入所述对外接口，并生成所述目标应用的APK。

2.根据权利要求1所述的方法，其特征在于，合并反编译后的所述第一APK和所述第二APK包括：

合并所述第一解封装文件和所述第二解封装文件，其中，在所述第一解封装文件录和所述第二解封装文件存在重复文件时，在所述第二解封装文件中保留所述重复文件，同时在所述第一解封装文件中删除所述重复文件。

3.根据权利要求2所述的方法，其特征在于，合并所述第一解封装文件和所述第二解封装文件包括：

合并所述第一解封装文件和所述第二解封装文件中的以下至少之一：assets目录、original目录、res目录、smali目录、lib目录、AndroidManifest.xml文件、apktool.yml文件。

4.一种渠道包的生成装置，其特征在于，包括：

封装单元，用于统一封装一个或多个渠道的SDK接口；

打包单元，用于打包所述一个或多个渠道的SDK接口，生成第一APK，其中，所述第一APK包含渠道软件开发工具包SDK功能；

获取单元，用于获取预设的母包SDK，其中，所述母包SDK用于只提供调用接口，没有真正的功能；

生成单元，用于在所述母包SDK中接入渠道要求的功能接口，生成第二APK，其中，所述第二APK用于提供目标应用的对外接口；

反编译模块，用于将所述第一APK的二进制文件反编译出第一解封装文件，以及将所述第二APK中的二进制文件反编译出第二解封装文件；

生成模块，用于合并反编译后的所述第一APK和所述第二APK，生成所述目标应用的渠道包；

其中，所述装置还包括：

在生成所述目标应用的渠道包之后，获取所述目标应用的功能逻辑；

将所述功能逻辑接入所述对外接口，并生成所述目标应用的APK。

5.一种存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至3任一项中所述的方法。

6.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至3任一项中所述的方法。

Images