CN111612450A - 应用程序支付渠道的检测方法、装置、终端设备及介质 - Google Patents

Abstract

本申请公开了一种应用程序支付渠道的检测方法、装置、终端设备及介质，该方法包括获取待检测应用程序的安装包文件；对所述安装包文件进行拆包，确定所述待检测应用程序对应的所有支付渠道，并显示所述支付渠道。由此，本申请实施例能够自动检测应用程序对应的全部支付渠道，使得用户可以提前知晓支付类型信息，从而选择最优的支付方式，同时还避免了应用程序的恶意扣费现象，保障用户财产安全。

Description

应用程序支付渠道的检测方法、装置、终端设备及介质

技术领域

本申请一般涉及通信技术领域，具体涉及一种应用程序支付渠道的检测方法、装置、终端设备及介质。

背景技术

互联网支付是一种网上交易形式，其是指交易双方为了交易商品或者业务通过手机、个人数字助理(Personal Digital Assistant，PDA)等终端设备实现货币资金转移的行为。互联网支付允许用户使用终端设备对所消费的商品或者业务进行账务支付，主要表现形式为网银、第三方支付和移动支付等。

目前，用户使用应用程序的过程中，只有通过该应用程序进行支付的时候才在终端设备上显示具体的支付渠道信息，比如支付宝支付、微信支付和QQ钱包支付等。

然而，在实现本发明的过程中，发明人发现相关技术中至少存在如下问题：由于终端设备会出现部分支付渠道处于隐藏状态的现象，即所显示的支付渠道信息不一定是应用程序对应的全部支付渠道，这就会造成用户选择的支付渠道不是最优的。并且，当用户不清楚应用程序是否存在其它支付渠道时，还可能会出现恶意扣费的现象，造成用户财产损失。

发明内容

鉴于相关技术中的上述缺陷或不足，期望提供一种应用程序支付渠道的检测方法、装置、终端设备及介质，能够自动检测应用程序对应的全部支付渠道，使得用户可以提前知晓支付类型信息，从而选择最优的支付方式，同时还能够避免应用程序的恶意扣费现象，保障用户财产安全。

第一方面，本申请提供一种应用程序支付渠道的检测方法，所述方法包括：

获取待检测应用程序的安装包文件；

对所述安装包文件进行拆包，确定所述待检测应用程序对应的所有支付渠道，并显示所述支付渠道。

第二方面，本申请提供一种应用程序支付渠道的检测装置，其特征在于，所述装置包括：

获取模块，配置用于获取待检测应用程序的安装包文件；

确定模块，配置用于对所述安装包文件进行拆包，确定所述待检测应用程序对应的所有支付渠道，并显示所述支付渠道。

第三方面，本申请提供一种终端设备，所述终端设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由所述处理器加载并执行以实现如第一方面所述的应用程序支付渠道的检测方法的步骤。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如第一方面所述的应用程序支付渠道的检测方法的步骤。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例提供了一种应用程序支付渠道的检测方法、装置、终端设备及介质，通过直接对待检测应用程序的安装包文件进行拆包和扫描分析，能够快速地确定出该待检测应用程序对应的所有支付渠道，并显示。由此，本申请实施例能够自动检测应用程序对应的全部支付渠道，使得用户可以提前知晓支付类型信息，从而选择最优的支付方式，同时还避免了应用程序的恶意扣费现象，保障用户财产安全。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为本申请实施例提供的一种应用程序支付渠道的检测方法的基本流程示意图；

图2为本申请实施例提供的一种应用程序支付渠道的检测方法的示例流程图；

图3为本申请实施例提供的另一种应用程序支付渠道的检测方法的示例流程图；

图4为本申请实施例提供的又一种应用程序支付渠道的检测方法的示例流程图；

图5为本申请实施例提供的再一种应用程序支付渠道的检测方法的示例流程图；

图6为本申请实施例提供的另一种应用程序支付渠道的检测方法的流程示意图；

图7为本申请实施例提供的一种应用程序支付渠道的检测装置的基本结构示意图；

图8为本申请实施例提供的另一种应用程序支付渠道的检测装置的结构示意图；

图9为本申请实施例提供的又一种应用程序支付渠道的检测装置的结构示意图；

图10为本申请实施例提供的一种移动设备的结构框图；

图11为本申请实施例提供的一种服务器的结构框图。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块。

本申请实施例涉及的技术术语如下：

AAPT(Android Asset Packaging Tool)：在软件开发工具包(SoftwareDevelopment Kit，SDK)的build-tools目录下，该工具可以查看、创建、更新ZIP格式的文档附件(比如zip、jar、apk)，也可以将资源文件编译成二进制文件。在使用AAPT之前需要在环境变量里面配置SDK-tools路径，或者是“路径+AAPT”的方式进入AAPT。

为了便于理解和说明，下面通过图1至图11详细的阐述本申请实施例提供的应用程序支付渠道的检测方法、装置、终端设备及介质。

请参考图1，其为本申请实施例提供的一种应用程序支付渠道的检测方法的基本流程示意图。应用程序支付渠道的检测方法应用于终端设备，而终端设备可以包括但不限于个人数字助理(Personal Digital Assistant，PDA)、平板电脑(Tablet Computer)、无线手持设备和手机等移动设备，还包括服务器等。该方法包括以下步骤：

S101，获取待检测应用程序的安装包文件。

需要说明的是，安装包文件根据本地存储路径或者云端下载地址得到。比如，安装包文件可以包括但不限于安卓系统(Android)的APK(Android Package)文件、塞班(Symbian)系统的SIS(Software Installation Script)文件以及苹果IOS系统的IPA(iPhone Application)文件。

S102，对安装包文件进行拆包，确定待检测应用程序对应的所有支付渠道，并显示支付渠道。

具体的，本申请实施例在利用反编译工具，解析安装包文件为多个子配置文件之后，基于预先构建的支付渠道字典，遍历子配置文件得到所有支付渠道。示例性地，比如支付渠道字典的形式为my array＝("银联""银行卡""充值卡""短信充值""AppStore充值""alipays""weixin""sms://""二维码支付")。在实际使用应用程序的过程中，可以不断增加和优化支付渠道，使得该支付渠道字典收录的关键字更加全面，进而提高检测的准确度。

以安装包文件是APK文件为例，比如通过反编译工具jadx对该APK文件进行拆包，得到多个.java后缀的子配置文件。之后，根据预先构建的支付渠道字典中的关键字，通过find命令逐一排查子配置文件。当检测到子配置文件中存在关键字时，比如关键字为myarray里"充值卡"和/或"alipays"的任意一种或者多种，则将所有关键字进行显示，也就是说该关键字即为支付渠道。

需要说明的是，本申请实施例对安装包文件进行拆包的方式包括本地拆包或者云端拆包中的任意一种。具体的，本地拆包是指在终端设备本机上进行拆包，比如终端设备A获取了待检测应用程序的安装包文件之后，在该终端设备A上解析安装包文件，这样设置的好处在于本地拆包不需要强制依赖网络，使用更加便捷和灵活；而云端拆包是指非终端设备本机进行拆包，比如终端设备A获取了待检测应用程序的安装包文件之后，该终端设备A将安装包文件传输至终端设备B，由终端设备B解析安装包文件，这样设置的好处在于云端拆包不需要占用终端设备A的计算资源，使得可以完成其它任务，运行更加流畅。

可选地，本申请实施例中当对安装包文件进行拆包的方式为本地拆包时，确定待检测应用程序对应所有支付渠道的扫描方式为本地扫描，也就是说预先构建的支付渠道字典存储于终端设备本机，该终端设备本机通过遍历子配置文件得到所有支付渠道，这样设置的好处在于拆包和扫描两个过程具有连贯性，不需要强制依赖网络，节省了传输文件所消耗的时间。而当对安装包文件进行拆包的方式为云端拆包时，确定待检测应用程序对应所有支付渠道的扫描方式为云端扫描，也就是说预先构建的支付渠道字典存储于其它终端设备中，比如服务器，这样设置的好处在于该支付渠道字典更新维护速度快，提高了检测的准确度，同时还能够避免占用终端设备本机的资源。同理，本申请实施例中还可以当对安装包文件进行拆包的方式为本地拆包时，确定待检测应用程序对应所有支付渠道的扫描方式为云端扫描，以及当对安装包文件进行拆包的方式为云端拆包时，确定待检测应用程序对应所有支付渠道的扫描方式为本地扫描，由此丰富了使用场景。

可选地，本申请实施例对安装包文件进行拆包之前，还检测安装包文件的文件签名，当预先记录的扫描结果表中存在文件签名时，直接读取文件签名对应的所有支付渠道。这样设置的好处在于，避免对同一应用程序做无用的重复检测，提高处理效率和扫描结果的复用性。

示例性地，在第一次对应用程序进行支付渠道的检测之后，将扫描结果和安装包文件的文件签名记录于扫描结果表中，用于以后快速检测相同文件签名的安装包文件的支付渠道。其中，文件签名比如为MD5(Message-Digest Algorithm 5)值，保证了同一应用程序只对应一个固定的码值，该码值不随使用者的不同而变化。在实际使用过程中，通过AAPT(Android Asset Packaging Tool)工具获取APK文件的包名、应用程序名称和应用程序版本号，进而使用md5sun命令得到APK文件的MD5值。

为便于更好地理解本申请实施例提供的应用程序支付渠道的检测方法，下面以安装包文件是APK文件为例，并结合实际应用场景进一步地说明。本领域技术人员可以理解，图2～6对应的应用场景并不构成对该应用程序支付渠道的检测方法的限定。

应用场景一、从应用商店下载应用程序，但并未安装到终端设备，此时终端设备比如为个人数字助理、平板电脑、无线手持设备或者手机等移动设备。如图2所示，其为本申请实施例提供的一种应用程序支付渠道的检测方法的示例流程图，包括如下步骤：

S201，获取待检测应用程序安装包文件的本地存储路径。

实际使用时，本申请实施例在终端设备上安装支付扫描工具APP来实现，以下简称该支付扫描工具为ScanPaymentTool。当然，该支付扫描工具APP对应的功能程序也可以嵌入终端设备的系统后台程序中，比如以安全中心插件的形式来实现相应检测功能。

比如，用户点击终端设备上的ScanPaymentTool，出现本地文件存储目录界面之后，选择待检测应用程序的安装包文件即可。

S202，检测是否属于APK文件，若是，则执行S203；若否，则执行S208。

比如，ScanPaymentTool检测安装包文件的后缀名是否为.apk来进行判断。

S203，获取APK文件的MD5值，并检测该MD5值在数据库中是否有记录，若否，则执行S207；若是，则执行S204。

比如，通过AAPT工具获取APK文件的包名、应用程序名称和应用程序版本号，进而使用md5sun命令得到APK文件的MD5值。

S204，对APK文件进行拆包。

需要说明的是，用户可以根据网络状态和使用需求进行云端拆包或者本地拆包的选择，丰富了多样化的使用场景。

S205，云端扫描。

在终端设备联网的情况下，ScanPaymentTool将经过拆包的待扫描APK文件上传至服务器，进而服务器把扫描结果回传至ScanPaymentTool，由该ScanPaymentTool在终端设备的界面上进行显示。此时，服务器上也安装有ScanPaymentTool。这样设置的好处在于，不需要占用终端设备的计算资源，使其运行更加流畅。

S206，本地扫描。

这样设置的好处在于，本地扫描不需要强制依赖网络，使用更加便捷和灵活。

S207，确定待检测应用程序对应的所有支付渠道。

比如，通过反编译工具jadx对APK文件进行拆包，得到多个.java后缀的子配置文件。之后，根据预先构建的支付渠道字典中的关键字，通过find命令逐一排查子配置文件。当检测到子配置文件中存在关键字时，比如关键字为my array里"充值卡"和/或"alipays"的任意一种或者多种，则将所有关键字进行记录，也就是说该关键字即为支付渠道。

S208，显示检测结果。

比如，当检测到安装包文件不属于APK文件时，显示“该安装包文件不属于APK文件”；或者，当确定了待检测应用程序对应的所有支付渠道时，则显示该所有支付渠道。

应用场景二、对已经安装到终端设备上的应用程序进行检测，此时终端设备比如为个人数字助理、平板电脑、无线手持设备或者手机等移动设备。如图3所示，其为本申请实施例提供的另一种应用程序支付渠道的检测方法的示例流程图，包括如下步骤：

S301，获取应用列表页面上选择的待检测应用程序的APK文件。

实际使用的过程中，当用户想扫描已经安装到终端设备上的应用程序时，通过终端设备上的ScanPaymentTool点击进入本地所装应用程序列表页面，该应用程序列表包括当前终端设备上所有安装应用程序的图标、APK文件的包名、应用程序名称和应用程序版本号等信息，进而点击待检测应用程序的图标或者应用程序名称，即可完成待检测应用程序的APK文件的选取。

同样地，ScanPaymentTool可以以独立应用程序的形式安装在终端设备上，也可以嵌入终端设备的系统后台程序中，比如以安全中心插件的形式来实现相应检测功能，本申请实施例对此不进行限定。

S302，获取APK文件的MD5值，并检测该MD5值在数据库中是否有记录，若否，则执行S303；若是，则执行S306。

比如，使用md5sun命令获取APK文件的MD5值。

S303，对APK文件进行拆包。

需要说明的是，用户可以根据网络状态和使用需求进行云端拆包或者本地拆包的选择，丰富了多样化的使用场景。

S304，云端扫描。

在终端设备联网的情况下，ScanPaymentTool将经过拆包的待扫描APK文件上传至服务器，进而服务器把扫描结果回传至ScanPaymentTool，由该ScanPaymentTool在终端设备的界面上进行显示。此时，服务器上也安装有ScanPaymentTool。这样设置的好处在于，不需要占用终端设备的计算资源，使其运行更加流畅。

S305，本地扫描。

这样设置的好处在于，本地扫描不需要强制依赖网络，使用更加便捷和灵活。

S306，确定待检测应用程序对应的所有支付渠道。

比如，通过反编译工具jadx对APK文件进行拆包，得到多个.java后缀的子配置文件。之后，根据预先构建的支付渠道字典中的关键字，通过find命令逐一排查子配置文件。当检测到子配置文件中存在关键字时，比如关键字为my array里"充值卡"和/或"alipays"的任意一种或者多种，则将所有关键字进行记录，也就是说该关键字即为支付渠道。

S307，显示扫描结果。

比如，当确定了待检测应用程序对应的所有支付渠道时，则显示该所有支付渠道。

应用场景三、对还未下载到终端设备上的应用程序进行检测，此时终端设备比如为个人数字助理、平板电脑、无线手持设备或者手机等移动设备。如图4所示，其为本申请实施例提供的又一种应用程序支付渠道的检测方法的示例流程图，包括如下步骤：

S401，获取待检测应用程序安装包文件的云端下载地址。

实际使用时，用户通过终端设备上的ScanPaymentTool点击进入应用程序页面，该应用程序页面包括应用程序图标、应用程序名称和应用程序版本号等信息。用户点击待检测应用程序的图标或者应用程序名称，即可得到待检测应用程序的安装包文件的云端下载地址。

同样地，ScanPaymentTool可以以独立应用程序的形式安装在终端设备上，也可以嵌入终端设备的系统后台程序中，比如以安全中心插件的形式来实现相应检测功能，本申请实施例对此不进行限定。

S402，检测云端下载地址是否有效，若有效，则执行S403；若无效，则执行S409。

这样设置的原因在于，低版本号的应用程序不再提供更新会导致存在漏洞，增加用户财产的损失风险。因此，本申请实施例通过检测应用程序的云端下载地址是否有效，一方面可以避免下载到低版本号的应用程序，进一步保障用户财产安全，另一方面还能够判断应用商店是否上线了待检测应用程序，有效减少搜索时间，提高处理效率。

S403，检测下载安装包文件是否为合法APK文件，若合法，则执行S404；若非法，则执行S408。

比如，ScanPaymentTool检测安装包文件的后缀名是否为.apk来进行判断。

S404，获取APK文件的MD5值，并检测该MD5值在数据库中是否有记录，若否，则执行S405；若是，则执行S408。

比如，使用md5sun命令得到APK文件的MD5值。

S405，对APK文件进行拆包。

需要说明的是，用户可以根据网络状态和使用需求进行云端拆包或者本地拆包的选择，丰富了多样化的使用场景。

S406，云端扫描。

在终端设备联网的情况下，ScanPaymentTool将经过拆包的待扫描APK文件的云端下载地址上传至服务器，该服务器根据云端下载地址下载待扫描的APK文件，并把扫描结果回传至ScanPaymentTool，由该ScanPaymentTool进行显示。此时，服务器上也安装有ScanPaymentTool。这样设置的好处在于，不需要占用终端设备的计算资源，使其运行更加流畅。

S407，本地扫描。

实际使用时，ScanPaymentTool根据云端下载地址下载待扫描的APK文件，并显示扫描结果。这样设置的好处在于，本地扫描不需要强制依赖网络，使用更加便捷和灵活。

S408，确定待检测应用程序对应的所有支付渠道。

比如，通过反编译工具jadx对APK文件进行拆包，得到多个.java后缀的子配置文件。之后，根据预先构建的支付渠道字典中的关键字，通过find命令逐一排查子配置文件。当检测到子配置文件中存在关键字时，比如关键字为my array里"充值卡"和/或"alipays"的任意一种或者多种，则将所有关键字进行记录，也就是说该关键字即为支付渠道。

S409，显示检测结果。

比如，当检测到云端下载地址无效时，显示“该云端下载地址无效”；或者，当检测到下载安装包文件为非法APK文件时，显示“该下载安装包文件为非法APK文件”；或者，当确定了待检测应用程序对应的所有支付渠道时，则显示该所有支付渠道。

应用场景四、开发应用程序的过程中，对该应用程序进行检测，此时终端设备比如为三个服务器，即服务器A、服务器B和服务器C，该服务器A、服务器B和服务器C的分工不同，例如服务器A和服务器B上都安装有ScanPaymentTool，能够执行应用程序的支付渠道检测，而服务器C执行数据库的功能。如图5所示，其为本申请实施例提供的再一种应用程序支付渠道的检测方法的示例流程图，包括如下步骤：

S501，根据接口访问指令，获取待检测应用程序安装包文件的云端下载地址。

实际使用时，用户通过服务器C访问服务器A，将待检测应用程序的安装包文件的云端下载地址进行上传。

S502，检测云端下载地址是否有效，若有效，则执行S503；若无效，则执行S509。

这样设置的好处在于，能够判断应用商店是否上线了待检测应用程序，有效减少搜索时间，提高处理效率。

S503，检测下载安装包文件是否为合法APK文件，若合法，则执行S504；若非法，则执行S508。

比如，服务器A上的ScanPaymentTool检测安装包文件的后缀名是否为.apk来进行判断。

S504，获取APK文件的MD5值，并检测该MD5值在数据库中是否有记录，若否，则执行S505；若是，则执行S508。

比如，服务器A上的ScanPaymentTool使用md5sun命令得到APK文件的MD5值。

S505，对APK文件进行拆包。

需要说明的是，服务器A可以根据网络连接状态进行云端拆包或者本地拆包的选择，使用更加便捷和灵活。

S506，云端扫描。

比如，在服务器A联网的情况下，服务器A上的ScanPaymentTool将经过拆包的待扫描APK文件的云端下载地址上传至服务器B，该服务器B根据云端下载地址下载待扫描APK文件，并把扫描结果回传至服务器A上的ScanPaymentTool，进而服务器A将该扫描结果返回服务器C进行显示。这样设置的好处在于，不需要占用服务器A的计算资源，使其可以进行其它任务，运行更加流畅。

S507，本地扫描。

实际使用时，ScanPaymentTool根据云端下载地址下载经过拆包的待扫描APK文件，并显示扫描结果。这样设置的好处在于，本地扫描不需要强制依赖网络，使用更加便捷和灵活。

S508，确定待检测应用程序对应的所有支付渠道。

比如，通过反编译工具jadx对APK文件进行拆包，得到多个.java后缀的子配置文件。之后，根据预先构建的支付渠道字典中的关键字，通过find命令逐一排查子配置文件。当检测到子配置文件中存在关键字时，比如关键字为my array里"充值卡"和/或"alipays"的任意一种或者多种，则将所有关键字进行记录，也就是说该关键字即为支付渠道。

S509，显示检测结果。

比如，当检测到云端下载地址无效时，显示“该云端下载地址无效”；或者，当检测到下载安装包文件为非法APK文件时，显示“该下载安装包文件为非法APK文件”；或者，当确定了待检测应用程序对应的所有支付渠道时，则显示该所有支付渠道。

综上，对图2～5的应用场景进行总结。如图6所示，其为本申请实施例提供的另一种应用程序支付渠道的检测方法的流程示意图，包括如下步骤：

S601，获取待检测应用程序的合法APK文件。

比如，支付扫描工具ScanPaymentTool通过检测安装包文件的后缀名是否为.apk来进行判断，其内置的支付渠道字典可以在实际使用的过程中不断更新，使得该支付渠道字典收录的关键字更加全面，进而提高检测的准确度。

S602，通过反编译工具对APK文件进行解析。

比如，ScanPaymentTool通过反编译工具jadx对该APK文件进行拆包，得到多个.java后缀的子配置文件。

S603，遍历APK文件中是否存在支付渠道字典中的关键字，若不存在，则执行S604；若存在，则执行S605。

比如，ScanPaymentTool根据预先构建的支付渠道字典中的关键字，通过find命令逐一排查子配置文件。当检测到子配置文件中存在关键字时，比如关键字为my array里"充值卡"和/或"alipays"的任意一种或者多种，则将所有关键字进行记录，也就是说该关键字即为支付渠道。

S604，不记录支付渠道。

此时表明，待检测应用程序没有包含支付渠道，用户可以放心使用该应用程序，无需担心出现恶意扣费的现象。

S605，记录支付渠道。

S6051，获取APK文件的文件签名。

比如，通过AAPT工具获取APK文件的包名、应用程序名称和应用程序版本号，进而使用md5sun命令得到APK文件的MD5值。

S6052，获取扫描结果。

S606，将文件签名和扫描结果保存于数据库中。

需要说明的是，在第一次对应用程序进行支付渠道的检测之后，将APK文件的文件签名和扫描结果记录于数据库的扫描结果表中，用于以后快速检测相同文件签名的APK文件的支付渠道。其中，文件签名比如为MD5值，保证了同一应用程序只对应一个固定的码值，该码值不随使用者的不同而变化。

S6061，服务器端扫描结果返回。

S6062，接收服务器端结果显示。

对于应用场景四而言，服务器A将扫描结果返回服务器C进行显示。此时，服务器A为服务器端，服务器C为接收服务器端。

S6063，本地扫描结果显示。

对于应用场景一至四中的本地扫描而言，终端设备上的ScanPaymentTool检测到应用程序的支付渠道之后，将扫描结果在该终端设备上进行显示。

S6064，云端扫描结果返回。

S6065，云端扫描结果显示。

对于应用场景一至四中的云端扫描而言，服务器将扫描结果回传至终端设备上的ScanPaymentTool，由该ScanPaymentTool进行显示。

本申请实施例提供的应用程序支付渠道的检测方法，通过直接对待检测应用程序的安装包文件进行拆包和扫描分析，能够快速地确定出该待检测应用程序对应的所有支付渠道，并显示。由此，本申请实施例能够自动检测应用程序对应的全部支付渠道，使得用户可以提前知晓支付类型信息，从而选择最优的支付方式，同时还避免了应用程序的恶意扣费现象，保障用户财产安全。

基于前述实施例，本申请实施例提供一种应用程序支付渠道的检测装置，该装置可以应用于图1～6对应的实施例提供的应用程序支付渠道的检测方法中。参照图7所示，该应用程序支付渠道的检测装置700包括：

获取模块701，配置用于获取待检测应用程序的安装包文件；

确定模块702，配置用于对安装包文件进行拆包，确定待检测应用程序对应的所有支付渠道，并显示支付渠道。

可选地，安装包文件根据本地存储路径或者云端下载地址得到。

可选地，在本申请的其它实施例中，如图8所示，确定模块702包括：

解析单元7021，配置用于利用反编译工具，解析安装包文件为多个子配置文件；

确定单元7022，配置用于基于预先构建的支付渠道字典，遍历子配置文件得到所有支付渠道。

可选地，对安装包文件进行拆包的方式包括本地拆包或者云端拆包中的任意一种。

可选地，当对安装包文件进行拆包的方式为云端拆包时，确定待检测应用程序对应所有支付渠道的扫描方式为云端扫描。

可选地，在本申请的其它实施例中，如图9所示，确定模块702还包括：

检测单元7023，配置用于检测安装包文件的文件签名；

读取单元7024，配置用于当预先记录的扫描结果表中存在文件签名时，直接读取文件签名对应的所有支付渠道。

需要说明的是，本实施例中与其它实施例中相同步骤和相同内容的说明，可以参照其它实施例中的描述，此处不再赘述。

本申请实施例提供的应用程序支付渠道的检测装置，通过直接对待检测应用程序的安装包文件进行拆包和扫描分析，能够快速地确定出该待检测应用程序对应的所有支付渠道，并显示。由此，本申请实施例能够自动检测应用程序对应的全部支付渠道，使得用户可以提前知晓支付类型信息，从而选择最优的支付方式，同时还避免了应用程序的恶意扣费现象，保障用户财产安全。

基于前述实施例，请参考图10，其为本申请实施例提供的一种移动设备的结构框图。该移动设备101包括处理器1011和存储器1012，其中处理器1011可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器1011可以采用数字信号处理(DigitalSignal Processing，DSP)、现场可编程门阵列(Field Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable Logic Array，PLA)中的至少一种硬件形式来实现。

处理器1011也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称为中央处理器(Central Processing Unit，CPU)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。

另外，处理器1011可以集成有图像处理器(Graphics Processing Unit，GPU)，GPU用于对显示屏所需要显示的内容进行渲染和绘制。在一些实施例中，处理器1011还可以包括人工智能(Artificial Intelligence，AI)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器1012可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器1012还可以包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1012中的非暂态的计算机可读存储介质用于存储至少一个程序，该至少一个程序用于被处理器1011所执行，以实现本申请方法实施例中提供的应用程序支付渠道的检测方法。

在一些实施例中，移动设备101还可以包括外围设备接口1013和至少一个外围设备。处理器1011、存储器1012和外围设备接口1013之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口1013相连。

具体地，外围设备包括但不限于射频电路1014、触摸显示屏1015和电源1016。外围设备接口1013可以被用于将输入/输出(Input/Output，I/O)相关的至少一个外围设备连接到处理器1011和存储器1012。在一些实施例中，处理器1011、存储器1012和外围设备接口1013被集成在同一芯片或电路板上；在一些其他实施例中，处理器1011、存储器1012和外围设备接口1013中的任意一个或两个可以在单独的芯片或电路板上实现，本申请实施例对此不进行限定。

射频电路1014用于接收和发射射频(Radio Frequency，RF)信号，也称电磁信号。射频电路1014通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1014将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1014包括天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等。射频电路1014可以通过至少一种无线通信协议来与其它设备进行通信。该无线通信协议包括但不限于城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或无线保真(Wireless Fidelity，WiFi)网络。在一些实施例中，射频电路1014还可以包括近距离无线通信(Near Field Communication，NFC)有关的电路。

显示屏1015用于显示用户界面(User Interface，UI)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏1015是触摸显示屏时，显示屏1015还具有采集在显示屏1015的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器1011进行处理。此时，显示屏1015还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1015可以为一个，设置在移动设备101的前面板；在另一些实施例中，显示屏1015可以为至少两个，分别设置在移动设备101的不同表面或呈折叠设计；在又一些实施例中，显示屏1015可以是柔性显示屏，设置在移动设备101的弯曲表面上或折叠面上。甚至，显示屏1015还可以设置成非矩形的不规则图形，也即异形屏。显示屏1015可以采用液晶显示屏(Liquid Crystal Display，LCD)、有机发光二极管(OrganicLight-Emitting Diode，OLED)等材质制备。

本领域技术人员可以理解，图10中示出的结构并不构成对移动设备101的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

基于前述实施例，本申请实施例提供一种服务器的结构框图。请参照图11所示，该服务器102可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(Central Processing Units，CPU)1021(例如，一个或一个以上处理器)和存储器1022，一个或一个以上存储应用程序1023或数据1024的存储介质1025(例如一个或一个以上海量存储设备)。其中，存储器1022和存储介质1025可以是短暂存储或持久存储。存储在存储介质1025的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对计算机系统中的一系列指令进行操作。更进一步地，中央处理器1021可以设置为与存储介质1025通信，在服务器102上执行存储介质1025中的一系列指令操作。

服务器102还可以包括一个或一个以上电源1026，一个或一个以上有线或无线网络接口1027，一个或一个以上输入输出接口1028，和/或，一个或一个以上操作系统1029，例如Windows Server TM，Mac OS XTM，Unix TM,Linux TM，FreeBSDTM等等。

作为另一方面，本申请实施例提供一种计算机可读存储介质，用于存储程序代码，该程序代码用于执行前述各个实施例应用程序支付渠道的检测方法中的任意一种实施方式。

作为再一方面，本申请实施例提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得计算机执行前述各个实施例应用程序支付渠道的检测方法中的任意一种实施方式。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。而集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。

基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例应用程序支付渠道的检测方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (11)

1.一种应用程序支付渠道的检测方法，其特征在于，所述方法包括：

获取待检测应用程序的安装包文件；

对所述安装包文件进行拆包，确定所述待检测应用程序对应的所有支付渠道，并显示所述支付渠道。

2.根据权利要求1所述的应用程序支付渠道的检测方法，其特征在于，所述安装包文件根据本地存储路径或者云端下载地址得到。

3.根据权利要求1所述的应用程序支付渠道的检测方法，其特征在于，所述对所述安装包文件进行拆包，确定所述待检测应用程序对应的所有支付渠道，包括：

利用反编译工具，解析所述安装包文件为多个子配置文件；

基于预先构建的支付渠道字典，遍历所述子配置文件得到所有支付渠道。

4.根据权利要求1所述的应用程序支付渠道的检测方法，其特征在于，所述对所述安装包文件进行拆包的方式包括本地拆包或者云端拆包中的任意一种。

5.根据权利要求4所述的应用程序支付渠道的检测方法，其特征在于，当对所述安装包文件进行拆包的方式为所述云端拆包时，确定所述待检测应用程序对应所有支付渠道的扫描方式为云端扫描。

6.根据权利要求1至5中任意一项所述的应用程序支付渠道的检测方法，其特征在于，所述对所述安装包文件进行拆包之前，还包括：

检测所述安装包文件的文件签名；

当预先记录的扫描结果表中存在所述文件签名时，直接读取所述文件签名对应的所有支付渠道。

7.一种应用程序支付渠道的检测装置，其特征在于，所述装置包括：

获取模块，配置用于获取待检测应用程序的安装包文件；

确定模块，配置用于对所述安装包文件进行拆包，确定所述待检测应用程序对应的所有支付渠道，并显示所述支付渠道。

8.根据权利要求7所述的应用程序支付渠道的检测装置，其特征在于，所述确定模块包括：

解析单元，配置用于利用反编译工具，解析所述安装包文件为多个子配置文件；

确定单元，配置用于基于预先构建的支付渠道字典，遍历所述子配置文件得到所有支付渠道。

9.根据权利要求7至8中任意一项所述的应用程序支付渠道的检测装置，其特征在于，所述确定模块还包括：

检测单元，配置用于检测所述安装包文件的文件签名；

读取单元，配置用于当预先记录的扫描结果表中存在所述文件签名时，直接读取所述文件签名对应的所有支付渠道。

10.一种终端设备，其特征在于，所述终端设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由所述处理器加载并执行以实现如权利要求1至6中任意一项所述的应用程序支付渠道的检测方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1至6中任意一项所述的应用程序支付渠道的检测方法的步骤。

Images