CN104363264A - 移动终端软件的多渠道sdk接入系统及方法 - Google Patents

Abstract

本发明提供了一种移动终端软件多渠道SDK接入系统，所述系统包括中央控制台、通用SDK、CP接口模块、第三方SDK、渠道接口模块、渠道参数配置及文件打包模块和文件管理模块，其中通用SDK用于存储对于不同的多个渠道通用的SDK；CP接口模块为至少一个CP提供接入到系统的接口，用于CP下载或上传文件或进行配置；第三方SDK用于存储由不同的渠道商提供的各自的SDK；渠道接口模块为至少一个渠道商提供接入到系统的接口，用于获取不同渠道的SDK并将通过渠道参数配置及文件打包模块生成的文件上传至各个渠道；渠道参数配置及文件打包模块，用于接收CP提供的配置，并根据CP的配置和第三方SDK，将CP上传的基于通用SDK开发的程序进行配置与打包，以便接入到不同渠道中。

Description

移动终端软件的多渠道SDK接入系统及方法

技术领域

本发明涉及一种SDK接入系统，特别涉及一种移动终端软件多渠道SDK接入的系统及方法。

背景技术

SDK，即软件开发工具包(Software Development Kit)是指被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。在移动终端领域，内容开发者可以基于渠道商提供的SDK来开发相应的移动终端程序，并上传到渠道商进行推广和分发。

通常，内容开发者开发完一个基于移动操作系统(例如Android系统)的移动终端应用(例如以APK文件格式的应用程序形式)后，由于内容开发者个人的推广能力有限，因此需要接入到不同的渠道商进行推广。渠道商通常会与内容开发者合作，以便在APK源文件中嵌入用户账户系统、付费系统、广告系统等功能，从而实现渠道商与内容开发者的收益共享。为了实现上述嵌入功能，渠道商会发布自己的SDK库供内容开发者下载使用。内容开发者需要将自己的APK文件根据渠道商的SDK库进行修改，以便符合渠道商的定制化要求。

然而，内容开发者为了更好地推广自己的应用，通常会接入不同的渠道。而每个渠道都会发布自己独特的SDK库给开发者进行修改。因此，当开发者面对当前成百上千的渠道的SDK，开发者需要花费大量的人力物力将APK应用接入到不同的渠道的SDK，且接入到不同的渠道的SDK后会带来后续的维护问题。但是为了将APK应用更广泛的推送给用户，开发者不得不接入少则几个多则数十个的渠道的SDK。纷繁的渠道SDK接入过程耗时耗力，不仅会给内容开发者增加很多没有必要的成本，更可能延误APK应用的最佳上线时间，进而带来一定的损失。

因此，如何帮助开发者降低接入到不同渠道的SDK的工作量和维护量是当前亟需解决的问题。

发明内容

本发明的目的在于提供一种用于多渠道SDK接入系统，所述系统包括中央控制台、通用SDK、CP接口模块、第三方SDK、渠道接口模块、渠道参数配置及文件打包模块和文件管理模块，其中，所述中央控制台，用于调度和控制其他各个模块；所述通用SDK，用于存储对于不同的多个渠道通用的SDK，其封装了与所有渠道提供的第三方SDK同样的客户端接口与服务端接口；所述CP接口模块，为至少一个CP提供接入到所述系统的接口，用于CP下载或上传文件或对文件进行配置；所述第三方SDK，用于存储由不同的渠道商提供的各自的SDK；所述渠道接口模块，为至少一个渠道商提供接入到所述系统的接口，用于获取不同渠道的SDK，并将通过所述渠道参数配置及文件打包模块生成的文件上传至所述各个相应的渠道；所述渠道参数配置及文件打包模块，用于接收CP提供的配置，并根据CP的配置和第三方SDK，将CP上传的基于通用SDK开发的程序进行配置与打包，以便能够接入到不同渠道中；所述文件管理模块，用于存储和管理在系统运行中产生和传输的各类文件。

根据本发明的多渠道SDK接入系统可以帮助开发者降低接入到不同渠道的SDK的工作量和维护量，在一个平台上即可以实现多渠道的开发和管理。

应当理解，前述大体的描述和后续详尽的描述均为示例性说明和解释，并不应当用作对本发明所要求保护内容的限制。

附图说明

参考随附的附图，本发明更多的目的、功能和优点将通过本发明实施方式的如下描述得以阐明，其中：

图1示意性示出根据本发明实施方式的多渠道SDK接入系统的架构图；

图2示意性示出根据本发明实施方式的渠道参数配置及SDK打包流程图；

图3示意性示出根据本发明实施方式的检查更新功能的流程图；

图4示意性示出根据本发明实施方式的CP端、通用SDK服务器和第三方SDK服务器之间的交互流程图；

图5(a)示意性示出根据本发明实施方式的用户登录验证交互流程图；

图5(b)示意性示出根据本发明实施方式的用户充值交互流程图。

具体实施方式

通过参考示范性实施例，本发明的目的和功能以及用于实现这些目的和功能的方法将得以阐明。然而，本发明并不受限于以下所公开的示范性实施例；可以通过不同形式来对其加以实现。说明书的实质仅仅是帮助相关领域技术人员综合理解本发明的具体细节。

在下文中，将参考附图描述本发明的实施例。在附图中，相同的附图标记代表相同或类似的部件，或者相同或类似的步骤。

系统概述

图1示意性示出根据本发明实施方式的一种移动终端软件多渠道SDK接入系统的系统架构图。如本文所使用的，术语“模块”是指用于提供特定功能的计算机程序逻辑和/或数据。模块可以在硬件中实现，也可以在固件和/或软件中实现。为了明确和突出本发明的要点，例如网络接口、安全机制、负载均衡器等一些常规部件在图1中未示出。

此外，尽管实施例在这里描述了基于安卓(Android)系统的APK文件的SDK移动终端软件开发工具包，本领域普通技术人员将会认识到，本发明所描述的系统和架构功能可以适用于其它任何类型的软件开发平台和软件开发工具包。

根据本发明的移动终端软件多渠道SDK接入系统100分别通过网络与至少一个内容提供方(CP)，例如CP_1、CP_2、……、CP_m进行交互，并通过网络与至少一个渠道商，例如第一渠道商、第二渠道商、……、第n渠道商进行交互。该网络是在多渠道SDK接入系统100、内容提供方和渠道商之间的通信通路。内容提供方提供包含特定内容的软件产品，所述软件产品需通过根据本发明的多渠道SDK接入系统100接入到渠道商进行分发或发行。所述特定内容包括但不限于游戏、应用软件、工具软件、教育软件等。

在一个实施例中，该网络是因特网。然而，该网络可以是任何通信路径，诸如局域网(LAN)，城域网(MAN)，广域网(WAN)，移动有线或无线网络、专用网络，或虚拟专用网络。

在一个实施例中，网络使用标准通信技术和/或协议。在网络上使用的协议的例子包括：传输控制协议/因特网协议(TCP/IP)，超文本传输协议(HTTP)，文件传输协议(FTP)等。通过网络交换的数据可利用的技术和/或格式包括超文本标记语言(HTML)，可扩展标记语言(XML)等。

在一些实施例中，除了上述技术和/或格式，数据也可以被通过网络使用定制和/或专用、和/或加密的数据通信技术通过网络进行传输。

本发明的系统100包括中央控制台101、通用SDK 102、CP接口模块103、第三方SDK 104、渠道接口模块105、渠道参数配置及文件打包模块106、文件管理模块107、CP统计与管理模块108和检查更新模块109。

中央控制台101，是用于调度和控制其他各个模块的中央控制端，优选地呈现方式为web界面。中央控制台101中包含了其他各个功能模块的入口。

通用SDK 102，用于存储为本发明的系统100提供对于不同的多个渠道通用的SDK。通用SDK 102封装了与所有渠道商提供的第三方SDK 104同样的客户端接口与服务端接口，以可下载的软件开发工具包的形式存在。CP通过CP接口模块103从系统100中下载该通用SDK102，对其开发的APK或Android工程文件进行调试、验证，并最终利用通用SDK 102接入到第三方SDK 104。这里的工程文件即在Android程序开发过程中中间版本的文件。

CP接口模块103，为至少一个CP提供接入到系统100的接口，用于CP下载或上传文件或对文件进行配置。CP通过CP接口模块103下载通用SDK 102，且CP将其开发的APK或Android工程文件接入到通用SDK 102，接入进行调试和验证直至正确接入，并形成基于通用SDK 102的APK或Android工程文件，最后将基于通用SDK 102的APK或Android工程文件通过CP接口模块103上传到本发明的系统100。

第三方SDK 104，用于存储由不同的渠道商提供的各自的软件开发工具包。第三方SDK 104集成了一定功能渠道专用的SDK，例如用户登录、充值通道、社区功能、社交分享、数据后台统计等功能。不同渠道的第三方SDK 104通过配置均封装到通用SDK 102中。

对于第三方SDK 104的特定功能，CP必须将其植入到自己的APK或Android工程文件中，只有这样渠道商才会允许CP将其产品发布到渠道商的平台上并最终实现上线。

渠道接口模块105，为至少一个渠道商提供接入到系统100的接口，用于获取不同渠道的SDK，并将通过渠道参数配置与文件打包模块106处理后并打包生成的供用户下载使用的APK上传至相应的各个不同渠道。

渠道参数配置与文件打包模块106，用于接收CP提供的配置，并根据CP的配置和第三方SDK的要求，将基于通用SDK 102的APK程序或Android工程文件进行配置与打包，以接入到不同渠道中。CP在上传了其基于通用SDK开发的APK或Android工程文件后，通过本系统的CP接口模块103进行相关参数的配置(例如填写不同渠道的私钥)，然后将这些参数与工程文件在渠道参数配置与文件打包模块106中进行打包，并最终分别生成应用于不同渠道的各自的APK文件。打包生成APK文件后还需进行相关测试，测试通过后通过渠道接口模块105提交给不同的渠道，渠道检查通过后即可正式上线进行分发。具体的渠道参数配置与打包算法在后文参照图2进行描述。

文件管理模块107，用于存储和管理在系统100运行中产生和传输的各类文件，包括但不限于以上所述的不同版本的通用SDK文件、第三方SDK文件、CP开发的APK或Android工程文件以及打包生成的APK文件等。

CP统计和管理模块108，用于CP统计接入到各个渠道的程序产品运营情况，以及管理自己不同版本的产品在不同渠道上的运行情况。

根据本发明的一个实施例，系统100还可以包括检查更新模块109，用于为CP提供不同APK的版本管理功能，检查CP上传的用于接入渠道的APK文件版本的更新情况。在CP根据通用SDK制作适用于各个渠道的APK文件过程中，可能会经常更新版本(例如修改bug，增加新功能等)上传至系统100。当终端用户通过渠道商下载了APK文件并在终端安装后，检查更新模块109用来每次终端用户允许该程序时是否CP已经提供了更新的版本。当判断出有更新的版本后，检查更新模块109还为终端用户提供增量更新的功能。增量更新功能可以让用户使用较小的网络流量上传或下载比较大的文件。具体的检查更新实现算法在后文参照图3进行描述。

根据本发明的一个实施例，检查更新模块109为每个上传至渠道商的APK文件版本生成唯一的标识符，以在不同版本之间进行区分。

图2示意性示出根据本发明实施方式的渠道参数配置与文件打包模块106进行渠道参数配置及SDK打包的流程图。如图2所示，以一个渠道为例，具体步骤如下：

步骤210，获取CP提供的基于通用SDK开发的APK文件，将该APK文件进行解包，生成CP临时文件；

根据本发明的一个实施例，CP可以通过CP接口模块将基于通用SDK开发的APK文件进行上传，存储在文件管理模块中。

步骤220，获取CP所选择的要发布的渠道，以及对所述APK文件应用于该渠道的配置信息；

根据本发明的一个实施例，所述配置信息包括但不限于涉及渠道支付的配置信息、Debug模式配置、横屏配置、更新配置、用户帐号设置等。

步骤230，获取该渠道的SDK文件，基于该SDK文件生成渠道SDK开发工程文件，然后将该工程文件生成渠道APK包；

根据本发明的一个实施例，获取该渠道的SDK文件可以通过第三方SDK 104中获取，或通过渠道接口模块105直接从渠道商获取。

步骤240，对所述渠道APK包进行解包，生成系统SDK临时文件；

步骤250，将步骤220获取的配置信息添加到步骤240生成的SDK临时文件中；

根据本发明的一个实施例，配置信息的添加可以是将配置信息替换SDK临时文件中的原有配置信息，也可以添加SDK临时文件中原来没有的信息条目。

步骤260，将更新了配置信息的系统SDK临时文件和步骤210中生成的CP临时文件合并，生成对应于该渠道的渠道APK临时文件；

步骤270，将该渠道APK临时文件进行打包，生成渠道APK包；

步骤280，对该渠道APK包进行签名，生成签名的渠道APK包。签名后的渠道APK包即可以直接上传至相应的渠道商进行发布。

根据本发明的一个实施例，签名的规则可以在步骤220中的配置信息中获取。

本领域技术人员可以理解的是，上述步骤210和220的组合以及步骤230和240的组合的执行顺序可以任意交换，例如可以同时进行，也可以按顺序依次进行，只要在步骤250执行之前生成了相应的文件和配置信息即可。

图2仅示意性地示出了针对一个渠道的渠道参数配置与打包的流程，当CP同时配置了多个渠道时，图2的方法流程可以针对各个渠道同步进行。

图3示意性示出根据本发明实施方式的检查更新模块109对文件版本进行检查更新功能的流程图，具体步骤如下：

步骤310，获取终端用户发来的APK文件版本标识符(ChecksumA)。根据本发明的一个实施例，终端用户通过渠道商获取的APK文件带有通过检查更新模块109为该APK文件添加的版本标识符，该版本标识符用来唯一地标识该APK文件的版本。

步骤320，将所获取的APK文件版本标识符与系统100中已有的最新APK文件版本标识符(ChecksumB)进行比较，若相同，则终端用户安装的已经是最新版本，本方法结束；若不同，则进入步骤330；

步骤330，判断是否接收到终端用户发来的同意更新的请求，若收到，则进入步骤340，否则，本方法结束；

步骤340，生成所获取的APK文件版本与最新APK文件版本之间的差值文件Patch，为所述差值文件添加唯一的标识(ChecksumPatch)；

步骤350，获取所述差值文件的地址，发送给终端用户，同时将最新APK文件版本标识符(ChecksumB)发送给终端用户。

步骤360，终端用户访问该差值文件的地址，客户端启动下载程序，下载该差值文件并安装，然后记录收到的最新APK文件版本标识符(ChecksumB)。差值文件下载完成以后，与客户端中原有的版本APK合成最新的版本APK文件，客户端启动应用安装程序，提示安装完毕。之后，将收到的最新APK文件版本标识符(ChecksumB)记录在该安装的版本中，作为该版本的标识符。

通过上述增量更新的功能，可以让用户使用较小的网络流量上传或下载比较大的文件，提高用户的体验，同时便于CP更好地管理上传至系统的多个版本。

交互方式

图4示出了CP端401、多渠道SDK接入系统402(即图1中的系统100)和渠道商403之间的交互流程图。图4仅示意性地示出了一个CP端401和一个渠道商403通过多渠道SDK接入系统402之间进行的交互。可以理解的是，该交互方法适用于多个CP和多个渠道商之间进行交互。

如图4所示，交互流程的具体步骤如下：

多渠道SDK接入系统402获取不同渠道的第三方SDK 104(步骤405)并存储在多渠道SDK接入系统402中。CP端401向服务器端402发送请求通用SDK(步骤410)，服务器端402呈现出通用SDK102(步骤415)并供CP端401下载使用(步骤420)。

CP端401将其开发的APK接入到下载的通用SDK 102，接入后进行调试和验证直至正确接入，并形成基于通用SDK 102的APK，最后上传基于通用SDK 102的APK到多渠道SDK接入系统402(步骤425)。

CP端选择渠道并进行参数配置，完成后将渠道和配置的参数发送到通用多渠道SDK接入系统402(步骤430)。多渠道SDK接入系统402会根据CP端选择的渠道和配置的参数将CP端开发的APK打包成渠道APK(步骤435)。可选地，CP可以下载打包的渠道APK(步骤440)并进行相关测试(步骤445)。如果测试发现需要修改APK文件，则返回步骤425，重复步骤425-步骤440，重新进行打包。在测试完成之后，CP发出上传至渠道的指令(步骤450)，多渠道SDK接入系统402接到指令后将测试后的APK上传至相应的渠道(步骤455)。

当CP通过上述方法利用本发明的系统100完成了APK文件上传至不同的渠道后，终端用户就可以从各个渠道下载相应的APK文件，在终端设备(例如智能手机、平板电脑)上安装并使用。根据本发明的系统还可以进一步对后续终端用户的使用进行管理和统计，以方便CP更好地实现一个平台多渠道的APK管理。管理和统计的数据还可以通过CP统计和管理模块108提供给CP。

图5(a)和图5(b)分别示出了终端用户在使用根据本发明的多渠道SDK接入系统100生成的程序时与系统100进行交互的两个示例。其中图5(a)示出了终端用户登录验证的交互流程图，图5(b)示出了终端用户付费验证的交互流程图。CP通过根据本发明的多渠道SDK接入系统100生成的程序(例如APK文件)，经不同的渠道分发后，终端用户可以下载相应的程序。下载后终端用户运行相应的程序进行一系列的操作，如游戏类程序则进行游戏、工具类程序则使用相关功能、社交类程序则进行聊天等活动。

在图5(a)和图5(b)中，终端用户与系统00之间交互流程的节点包括终端用户客户端501、通用SDK客户端502、渠道SDK客户端503、渠道SDK服务器505、终端程序服务器504和多渠道SDK接入系统402。其中，终端用户客户端501是终端用户通过客户端终端设备下载、安装并使用的经过了本发明的多渠道SDK接入系统100生成的程序(例如APK文件)，客户端终端设备例如智能手机、平板电脑、电脑等带有计算功能的智能终端。通用SDK客户端502是在CP利用本发明的多渠道SDK接入系统100进行接入时，以通用SDK形式嵌入到最终程序，即嵌入到终端用户客户端501中的客户端。渠道SDK客户端503是用于使终端用户接入到第三方渠道的接口。优选地，呈现为在终端用户的客户端终端设备的用户交互界面形式，当用户登录时，通过渠道SDK客户端503呈现的界面，可以为终端用户提供输入用户名、密码以及附加信息等的功能。渠道SDK客户端503再将信息发送到渠道SDK服务器505端进行登陆鉴权和授权操作。终端程序服务器504是为终端用户客户端501程序提供一系列服务的服务器，例如游戏服务器、社交论坛服务器等。

图5(a)示出了用户登录验证的交互流程图。如图5(a)所示，在登录到终端程序服务器之前，首先进行渠道登录验证，即登录到分发该终端程序的渠道服务器。用户启动终端用户客户端501的程序，例如游戏或工具类软件，终端用户客户端501发出调用登录的请求到通用SDK客户端502(步骤506)，进而通过通用SDK客户端502转发请求到渠道SDK客户端503，请求调用渠道登录(步骤508)；接着，通过终端用户客户端501随请求发送过来的渠道登录信息(例如用户名和密码、渠道标识等信息)请求登录渠道SDK的服务器505(步骤510)。在步骤512，渠道SDK服务器505进行验证，以验证终端用户的客户端501是否是合法通过渠道服务器下载的终端程序，以及验证客户端用户的信息。当渠道验证成功后，返回给渠道SDK客户端503登录成功的提示(步骤514)，并将用户UID标识返回至通用SDK客户端502(步骤516)；通用SDK客户端502再将用户UID标识和渠道标识返回终端用户客户端501(步骤518)，完成了渠道SDK服务器的登录验证过程。

接着利用渠道SDK服务器登录成功获取的信息(用户UID，渠道标识等)，进行终端程序服务器的登录验证。终端用户客户端501利用用户UID标识和渠道标识请求登录终端程序服务器504，获取用户的信息(步骤520)；进而验证登录到多渠道SDK接入系统100(步骤522)。在步骤524，多渠道SDK接入系统100进行验证。当验证通过后，由多渠道SDK接入系统100将用户信息发送至渠道SDK服务器505进行验证(步骤526)。在步骤528，由渠道SDK服务器505进行用户身份的验证。若验证成功，则通知多渠道SDK接入系统100正在操作的用户为有效的用户(步骤530)；接着，多渠道SDK接入系统100再通知终端程序服务器504正在操作的用户为有效的用户(步骤532)，从而返回给终端用户客户端501用户成功登录的信息(步骤534)，完成登录验证。

通过上述终端用户、渠道SDK服务器、终端程序服务器和多渠道SDK接入系统之间的交互验证，可以确保用户信息的准确与安全，使终端用户通过不同渠道下载的程序都可以正确的验证和使用，保障了渠道商和CP的利益。

图5(b)示出了用户充值的交互流程图。如图5(b)所示，在用户运行终端程序的过程中进行充值操作时(例如游戏的付费充值，或使用软件工具的付费充值)，需要本发明的多渠道SDK接入系统、渠道SDK服务器和终端程序服务器协同操作，以确保用户充值的安全性和可靠性。用户登陆终端用户客户端501后即可发起充值操作，具体地，用户的充值请求首先是向通用SDK客户端502发起调用充值请求(步骤550)。通用SDK客户端502向多渠道SDK接入系统100发起请求，创建带有回调信息的订单，提交给多渠道SDK接入系统100(步骤552)。回调信息可以基于特定的事件或条件发生时做出响应，例如充值的结果通知。多渠道SDK接入系统402创建了带有回调信息的订单后，返回订单ID和其他相关信息至通用SDK客户端502(步骤554)。接着，通过SDK客户端502利用返回的订单ID想渠道SDK客户端503发起充值的请求，请求支付订单ID(步骤556)，进而渠道SDK客户端将该充值请求发送到渠道SDK服务器505(步骤558)，由渠道SDK服务器505验证充值是否成功，如果充值成功，则将充值成功的提示返回到通用SDK客户端502(步骤560)，进而通用SDK客户端502再将充值成功的提示返回到终端用户客户端501(步骤562)。

根据本发明的一个实施例，由于用户的充值行为通常需要在渠道SDK服务器端和终端程序的服务器端进行分成，即由渠道商和CP共同分成充值，因此，还需要将用户充值的信息提供给终端程序服务器504。如图5(b)所示，在渠道SDK服务器505验证充值成功后，还将充值成功的结果通知给多渠道SDK接入系统100(步骤564)。优选地，该通知可以以异步通信的方式发送。多渠道SDK接入系统402接收到充值结果的消息后，再将带有回调信息的充值结果通知发送给终端程序服务器504(步骤566)，最后通过终端程序服务器504将充值结果的通知返回给终端用户客户端501(步骤568)，从而完成用户充值。

根据本发明的多渠道SDK接入系统100也可以与为不同渠道提供更多的功能，通过渠道提供给第三方SDK的API，则可直接获取通用SDK接入渠道SDK的相关应用的配置，过程中可能需要CP提供其在渠道上的用户标示符(通常是用户名或用户ID)。CP需要通过本发明的系统100接入到渠道的oAuth认证系统，登录并获取其在渠道上的配置信息。

此外，本发明的系统100还可以具有推荐引擎，基于统计模块的大数据分析向CP推荐不同的渠道或者向渠道推荐CP的双向推荐模式。CP推荐渠道，根据cp在棱镜后台填写的APK相关信息，以及CP统计和管理模块108基于大数据对CP的应用分析结果，结合CP统计和管理模块108基于大数据对渠道的数据特性的分析结果，通过一套算法，系统自动向CP推荐渠道。渠道推荐CP，本发明的系统100的后台提供CP可选择向部分或全部渠道开放推荐其应用的功能。本发明的系统100根据CP开发的结果，以及对应用和渠道的分析结果，通过一套算法，自动向渠道推荐CP的应用。

本发明的系统100还可将根据用户的需求和产业链的需求与第三方服务公司进行深度整合，给用户提供以下相关服务：云服务(包括云数据、云存储)、应用加固、应用统计、应用测试、应用推送、广告SDK、游戏引擎插件、支付SDK等。

所述附图仅为示意性的并且未按比例画出。虽然已经结合优选实施例对本发明进行了描述，但应当理解本发明的保护范围并不局限于这里所描述的实施例。

结合这里披露的本发明的说明和实践，本发明的其他实施例对于本领域技术人员都是易于想到和理解的。说明和实施例仅被认为是示例性的，本发明的真正范围和主旨均由权利要求所限定。

Claims (10)

1.一种用于移动终端软件的多渠道SDK接入系统，所述系统包括中央控制台、通用SDK、CP接口模块、第三方SDK、渠道接口模块、渠道参数配置及文件打包模块和文件管理模块，其中，

所述中央控制台，用于调度和控制其他各个模块；

所述通用SDK，用于存储对于不同的多个渠道通用的SDK，其封装了与所有渠道提供的第三方SDK同样的客户端接口与服务端接口；

所述CP接口模块，为至少一个CP提供接入到所述系统的接口，用于CP下载或上传文件或对文件进行配置；

所述第三方SDK，用于存储由不同的渠道商提供的各自的SDK；

所述渠道接口模块，为至少一个渠道商提供接入到所述系统的接口，用于获取不同渠道的SDK，并将通过所述渠道参数配置及文件打包模块生成的文件上传至所述各个相应的渠道；

所述渠道参数配置及文件打包模块，用于接收CP提供的配置，并根据CP的配置和第三方SDK，将CP上传的基于通用SDK开发的程序进行配置与打包，以便能够接入到不同渠道中；

所述文件管理模块，用于存储和管理在系统运行中产生和传输的各类文件。

2.根据权利要求1所述的系统，还包括CP统计与管理模块，用于CP统计接入到各个渠道的程序产品运营情况，以及管理不同版本的产品在不同渠道上的运行情况。

3.根据权利要求1所述的系统，还包括检查更新模块，用于为CP提供不同APK的版本管理功能，并检查CP上传的用于接入渠道的APK文件版本的更新情况。

4.根据权利要求1所述的系统，其中所述中央控制台的呈现方式为web界面。

5.根据权利要求1所述的系统，其中所述渠道参数配置及文件打包模块通过下列步骤进行打包：

步骤a，获取CP提供的基于通用SDK开发的APK文件，将该APK文件进行解包，生成CP临时文件；

步骤b，获取CP所选择的要发布的渠道，以及对所述APK文件应用于该渠道的配置信息；

步骤c，获取该渠道的SDK文件，基于该SDK文件生成渠道SDK开发工程文件，将该工程文件生成渠道APK包；

步骤d，对所述渠道APK包进行解包，生成系统SDK临时文件；

步骤e，将步骤b获取的配置信息添加到步骤240生成的SDK临时文件中；

步骤f，将更新了配置信息的系统SDK临时文件和步骤a中生成的CP临时文件合并，生成对应于该渠道的渠道APK临时文件；

步骤g，将该渠道APK临时文件进行打包，生成渠道APK包；

步骤h，对该渠道APK包进行签名，生成签名的渠道APK包。

6.根据权利要求1所述的系统，其中所述配置信息选自涉及渠道支付的配置信息、Debug模式配置、横屏配置、更新配置、用户帐号设置。

7.根据权利要求5所述的系统，其中所述步骤a和b、所述步骤c和d互换或同时进行。

8.根据权利要求3所述的系统，其中所述检查更新模块为每个上传至渠道商的文件版本生成唯一的标识符。

9.根据权利要求3所述的系统，其中所述检查更新模块进行的更新为增量更新。

10.根据权利要求1所述的系统，其中所述系统还包括推荐引擎，基于所述CP统计与管理模块的大数据分析向CP推荐不同的渠道或者向渠道推荐CP。