具体实施方式

正如背景技术中所述，对于应用市场类应用来说，统计同一应用通过不同渠道的下载转化量具有重要的意义。

目前针对渠道信息的上报主要两种方式：

其一是：首页以及详情页提供在Android Manifest中写入了不同渠道标识的安装包，用户在不同入口或者模块下载的安装包的渠道标识不同，应用启动完成后读取指定文件中的渠道标识进行数据上报。

该方法主要弊端包括：由于写入了不同的渠道标识必然导致两个游戏安装包的MD5值不同，因此在客户端下载逻辑中，该安装包即使是同一个游戏但是由于文件MD5值不同只能按照两个不同的游戏来处理，此时给用户造成很大的困惑，进而影响用户体验；另外就是该方法需要针对APK(Android application package，Android应用程序包)进行二次打包，导致实施起来较为繁琐。

其二是：利用Android APK安装包本质上是一个zip压缩包的特性，在运营后台上传安装包的过程中将渠道标识写入zip包的comment区域(注释区域)中，只要能正确修改该区域，我们就可以在不破坏安装包、不二次打包的情况下给APK写入自己想要的数据，然后在APK安装完成后SDK(Software Development Kit，软件开发工具包)读取该信息完成数据上报。该方法的主要弊端一个是不同渠道信息的包需要不同的下载路径来标识，在同一个应用中用户体验很差，另一个是目前在打包编译APK的过程中如果开发者开启了V2签名机制，在该区域写入信息会导致APK无法正确被安装。

为了解决上述两种方式存在的各种弊端，本申请实施例综合考虑了Android跨进程通信各个方式的优点与弊端，提供了一种跨进程传递渠道数据的思路以及利用Android跨进程通信方式将渠道标识上报真正实现。

通过解决“数据在应用市场端如何存储以及绑定，然后渠道数据怎么在应用分发端和应用端传输以及最后应用内怎么获取该信息完成上报”的技术问题，提出了一种渠道标识的上报方法，所述渠道标识的上报方法在获取到当前安装包对应的渠道信息后，将所述渠道信息存储到本地文件和/或本地数据库中，当所述当前安装包对应的应用启动后，从所述本地文件或本地数据库中获取所述渠道信息并上报，实现了针对不同渠道下载的当前安装包的渠道信息的上报，且该方法针对不同的权限设计了不同的渠道信息存储方式以及应用启动后获取方式，提高了渠道信息的获取以及上报成功的概率，且该方法无需修改应用的安装包，也无需在安装包的注释区域写入渠道信息，避免了在安装包中写入渠道标识或者在安装包的注释区域写入渠道标识等方式存在的统计不准确以及渠道标识设计复杂的问题。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供了一种渠道标识的上报方法，如图1所示，包括：

S101：获取当前安装包对应的渠道信息。

S102：将所述渠道信息存储到本地文件和/或本地数据库中。

S103：在所述当前安装包对应的应用启动后，从所述本地文件或本地数据库中获取所述渠道信息。

S104：将获取到的所述渠道信息上报。

在本实施例中，所述渠道标识的上报方法在获取到当前安装包对应的渠道信息后，将所述渠道信息存储到本地文件和/或本地数据库中，当所述当前安装包对应的应用启动后，从所述本地文件或本地数据库中获取所述渠道信息并上报，实现了针对不同渠道下载的当前安装包的渠道信息的上报，且该方法针对不同的权限设计了不同的渠道信息存储方式以及应用启动后获取方式，提高了渠道信息的获取以及上报成功的概率，且该方法无需修改应用的安装包，也无需在安装包的注释区域写入渠道信息，避免了在安装包中写入渠道标识或者在安装包的注释区域写入渠道标识等方式存在的统计不准确以及渠道标识设计复杂的问题。

下面针对所述渠道标识的上报方法的各个步骤的具体可行执行方式进行说明。

可选的，在本申请的一个实施例中，如图2所示，所述获取当前安装包对应的渠道信息包括：

S1011：获取当前安装包的渠道字段以及安装包名称。

所述当前安装包的渠道字段主要用于标识所述当前安装包的下载入口或下载模块，即用于标识用户触发当前安装包下载时的渠道信息。

可选的，在本申请的另一个实施例中，如图3所示，所述将所述渠道信息存储到本地文件和/或本地数据库中包括：

S1021：判断所述当前安装包对应的软件开发工具包是否具有内存读取权限，如果是，则使用所述安装包名称作为预设文件的文件名将所述渠道字段序列化到预设目录中，并编写内容提供者，将所述渠道字段通过所述内容提供者提供暴露的接口；

如果否，则编写内容提供者，将所述渠道字段通过所述内容提供者提供暴露的接口。

在本实施例中，针对用户赋予的不同权限，设计了两种不同的渠道信息存储方式，保证了存储数据的准确性。

相应的，在本申请的又一个实施例中，如图4所示，所述从所述本地文件或本地数据库中获取所述渠道信息包括：

S1031：启动所述当前安装包对应的软件开发工具包的上报线程，以使所述上报线程在当所述当前安装包对应的应用具有内存读取权限时，以所述安装包名称作为文件名检索序列化好的文件，读取与所述安装包名称匹配的预设文件中存储的渠道字段，在当所述当前安装包对应的应用不具有内存读取权限时，使用内容提供者通过暴露的接口从本地数据库中获取所述渠道字段。

当所述当前安装包的渠道信息的存储方式有多种时，针对不同的情况，获取渠道信息的方式也相应地分为多种，保证了数据准确性以及渠道信息上报的准确性。

在本申请的一个具体实施例中，提供了一种具体地所述渠道信息上报方法的流程，包括：

S201：运营人员配置各个模块数据的时候增加一个渠道标识数据通过数据接口下发到客户端；

S202：客户端处理用户点击下载逻辑时获取服务端接口下发的渠道字段，并且获取当前下载应用的包名；

S203：客户端获取数据后判断SD卡读写权限，如果具有权限，使用包名作为文件名将渠道信息序列化到指定SD卡目录当中；

S204：序列化完成后，继续将渠道数据和包名存储到Android设备的本地数据库中；

S205：编写内容提供者，将渠道数据使用该方式暴露出去；

S206：应用安装完成并启动后，启动SDK内部数据上报线程，该线程会判断当前应用是否具有SD卡读写权限，如果具有权限则去约定目录使用包名作为文件名检索序列化好的文件，如果文件名匹配则读取数据；

S207：如果S206没有权限或者未成功反序列化渠道标识，则使用内容提供者(Content Provider)通过接口去本地数据库中获取；

S208：如果步骤S206或S207中获取到了渠道数据则进行数据上报。

下面对本申请实施例提供的渠道标识的上报系统进行描述，下文描述的渠道标识的上报系统可与上文描述的渠道标识的上报方法相互对应参照。

相应的，本申请实施例还提供了一种渠道标识的上报系统，如图5所示，包括：

信息获取模块100，用于获取当前安装包对应的渠道信息；

渠道存储模块200，用于将所述渠道信息存储到本地文件和/或本地数据库中；

渠道读取模块300，用于在所述当前安装包对应的应用启动后，从所述本地文件或本地数据库中获取所述渠道信息；

渠道上报模块400，用于将获取到的所述渠道信息上报。

可选的，所述信息获取模块具体用于，获取当前安装包的渠道字段以及安装包名称。

可选的，所述渠道存储模块具体用于，判断所述当前安装包对应的软件开发工具包是否具有内存读取权限，如果是，则使用所述安装包名称作为预设文件的文件名将所述渠道字段序列化到预设目录中，并编写内容提供者，将所述渠道字段通过所述内容提供者提供暴露的接口；

如果否，则编写内容提供者，将所述渠道字段通过所述内容提供者提供暴露的接口。

可选的，所述渠道读取模块具体用于，启动所述当前安装包对应的软件开发工具包的上报线程，以使所述上报线程在当所述当前安装包对应的应用具有内存读取权限时，以所述安装包名称作为文件名检索序列化好的文件，读取与所述安装包名称匹配的预设文件中存储的渠道字段，在当所述当前安装包对应的应用不具有内存读取权限时，使用内容提供者通过暴露的接口从本地数据库中获取所述渠道字段。

描述于本公开实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块的名称在某种情况下并不构成对该单元本身的限定，例如，信息获取模块还可以被描述为“获取当前安装包对应的渠道信息的模块”。

相应的，本申请实施例还提供了一种渠道标识的上报系统，包括：存储器和处理器；其中，

所述存储器中存储有程序代码，所述处理器用于调用所述程序代码，所述程序代码被调用时执行以下步骤：

获取当前安装包对应的渠道信息；

将所述渠道信息存储到本地文件和/或本地数据库中；

在所述当前安装包对应的应用启动后，从所述本地文件或本地数据库中获取所述渠道信息；

将获取到的所述渠道信息上报。

相应的，本申请实施例还提供了一种存储介质，所述存储介质上存储有程序代码，所述程序代码被执行时实现上述任一实施例所述的渠道标识的上报方法。

在本公开的上下文中，存储介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。存储介质可以是机器可读信号介质或机器可读储存介质。存储介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

需要说明的是，本公开上述的存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。存储介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述存储介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

本说明书中各实施例中记载的特征可以相互替换或者组合，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。