CN110297776A - 检测报告生成、接收方法、装置、设备及存储介质 - Google Patents

Abstract

本申请实施例公开了一种检测报告生成、接收方法、装置、设备及存储介质。所述方法包括：获取应用程序的安装包；解析应用程序的安装包，获得应用程序的待检测信息；利用检测规则对待检测信息进行安装失败风险检测，确定待检测信息的检测结果；检测规则是根据至少两种不同终端对应用程序的历史安装包进行安装时的安装失败案例所得到的；根据待检测信息的检测结果，生成应用程序的检测报告。本申请实施例检测周期较短，从服务器获得安装包到确定检测结果一般只需要花费10秒左右的时间，得到检测结果的效率较高。

Description

检测报告生成、接收方法、装置、设备及存储介质

技术领域

本申请实施例涉及计算机技术领域，特别涉及一种检测报告生成、接收方法、装置、设备及存储介质。

背景技术

为了保证应用程序能够正常安装，在进入市场前，研究人员需要对应用程序的安装失败风险进行检测。

在相关技术中，研究人员需要通过将应用程序的安装包安装到不同型号类型的移动终端上，来动态检测是否存在安装失败问题，例如，是否存在应用程序安装后不能够正常运行或应用程序安装过程不可以取消或安装空间不足时没有相应提示等等问题，最终得到检测结果。

然而，上述相关技术中检测周期较长，得到检测结果的效率较低。

发明内容

本申请实施例提供了一种检测报告生成、接收方法、装置、设备及存储介质，可用于解决相关技术中检测周期较长，得到检测结果的效率较低的问题。技术方案如下：

一方面，本申请实施例提供一种检测报告生成方法，所述方法包括：

获取应用程序的安装包；

解析所述应用程序的安装包，获得所述应用程序的待检测信息；

利用检测规则对所述待检测信息进行安装失败风险检测，确定所述待检测信息的检测结果；所述检测规则是根据至少两种不同终端对所述应用程序的历史安装包进行安装时的安装失败案例所得到的；

根据所述待检测信息的检测结果，生成所述应用程序的检测报告。

另一方面，本申请实施例提供一种检测报告接收方法，所述方法包括：

显示安装失败风险检测网页，所述安装失败风险检测网页中包括上传控件；

通过所述上传控件，向服务器发送应用程序的安装包；

接收和显示所述应用程序的检测报告，所述检测报告是所述服务器利用检测规则对所述应用程序的安装包进行安装失败风险检测生成的，所述检测规则是根据至少两种不同终端对所述应用程序的历史安装包进行安装时的安装失败案例所得到的。

另一方面，本申请实施例提供一种检测报告生成装置，所述装置包括：

安装包获取模块，用于获取应用程序的安装包；

信息获取模块，用于解析所述应用程序的安装包，获得所述应用程序的待检测信息；

结果确定模块，用于利用检测规则对所述待检测信息进行安装失败风险检测，确定所述待检测信息的检测结果；所述检测规则是根据至少两种不同终端对所述应用程序的历史安装包进行安装时的安装失败案例所得到的；

报告生成模块，用于根据所述待检测信息的检测结果，生成所述应用程序的检测报告。

又一方面，本申请实施例提供一种检测报告接收装置，所述装置包括：

网页显示模块，用于显示安装失败风险检测网页，所述安装失败风险检测网页中包括上传控件；

安装包发送模块，用于通过所述上传控件，向服务器发送应用程序的安装包；

报告接收模块，用于接收和显示所述应用程序的检测报告，所述检测报告是所述服务器利用检测规则对所述应用程序的安装包进行安装失败风险检测生成的，所述检测规则是根据至少两种不同终端对所述应用程序的历史安装包进行安装时的安装失败案例所得到的。

又一方面，本申请实施例提供一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上述方面所述的检测报告生成方法或检测报告接收方法。可选地，所述计算机设备为终端或服务器。

又一方面，本申请实施例提供一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如上述方面所述的检测报告生成方法或检测报告接收方法。

又一方面，本申请实施例提供一种计算机程序产品，当该计算机程序产品被执行时，其用于执行上述方面所述的检测报告生成方法或检测报告接收方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

对于需要检测是否存在安装失败风险的应用程序，通过将该应用程序的安装包发送给服务器，服务器解析该应用程序的安装包，获得待检测信息，并利用检测规则对待检测信息进行安装失败风险检测，确定检测结果。检测规则是根据至少两种不同终端对应用程序的历史安装包进行安装时的安装失败案例所得到的，检测规则准确。通过静态检测应用程序是否存在安装失败风险，检测周期较短，从服务器获得安装包到确定检测结果一般只需要花费10秒左右的时间，得到检测结果的效率较高。

附图说明

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

图1是本申请一个实施例提供的实施环境的示意图；

图2是本申请一个实施例提供的检测报告生成方法的流程图；

图3是本申请一个实施例提供的检测报告接收方法的流程图；

图4是本申请一个实施例提供的检测报告生成平台的逻辑架构图；

图5是本申请一个实施例提供的检测报告生成装置的框图；

图6是本申请另一个实施例提供的检测报告生成装置的框图；

图7是本申请一个实施例提供的检测报告接收装置的框图；

图8是本申请一个实施例提供的计算机设备的结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

请参考图1，其示出了本申请一个实施例提供的实施环境的示意图。该实施环境可以包括：终端10和服务器20。

在本申请实施例中，终端10是用于向服务器20发送应用程序的安装包和接收检测报告的设备。终端10可以是PC(Personal Computer，个人计算机)、平板电脑、多媒体播放设备、可穿戴设备、手机等。可选地，终端10具备显示屏。

在本申请实施例中，服务器20是用于接收终端10发送的应用程序的安装包，并对该应用程序是否存在安装失败风险进行检测的设备。

终端10和服务器20之间可以通过有线网络或者无线网络的方式建立通信连接。

请参考图2，其示出了本申请一个实施例提供的检测报告生成方法的流程图。该方法的执行主体可以是图1中的服务器。该方法可以包括以下几个步骤：

步骤201，获取应用程序的安装包。

应用程序可以是任意一个应用程序。应用程序可以是系统应用程序，也可以是第三方应用程序。在本申请实施例中，对待检测到应用程序的种类不作限定，如其可以是社交类应用程序、即时通信应用程序、视频播放应用程序等等。

应用程序可以是基于Android(安卓)操作系统开发的应用程序，该Android操作系统可以是Android原生的操作系统，也可以是其它一些基于Android操作系统开发的定制化操作系统。此时，应用程序的安装包可以是apk(AndroidPackage，安卓安装包)。

应用程序也可以是基于IOS操作系统开发的应用程序，该IOS操作系统是由Apple公司开发的移动操作系统。此时，应用程序的安装包可以是ipa(iphoneApplication，Apple程序应用文件)。

服务器可以主动获取应用程序的安装包，例如从应用商店(提供各类型应用程序下载的平台)中获取应用程序的安装包进行检测；或者，服务器可以接收终端发送的应用程序的安装包进行检测。

步骤202，解析应用程序的安装包，获得应用程序的待检测信息。

在本申请实施例中，待检测信息用于检测应用程序的安装失败风险。待检测信息有多种，示例性地，待检测信息包括但不限于以下至少一种：应用程序的包名、应用程序的版本号、应用程序的安装位置、应用程序的签名方案、应用清单等信息。待检测信息可以结合相关安装失败案例以及系统源码(系统源码中包括对各种安装异常进行处理的代码实现)确定。例如，应用程序的安装位置就是根据相关安装失败案例确定的，应用程序的包名、应用程序的版本号、应用程序的签名方案、应用清单等信息是根据系统源码确定的。

步骤203，利用检测规则对待检测信息进行安装失败风险检测，确定待检测信息的检测结果。检测规则是根据至少两种不同终端对应用程序的历史安装包进行安装时的安装失败案例所得到的。

影响应用程序安装失败的因素较多，任意一个因素检测不通过，都会导致应用程序存在安装失败风险。因此，应用程序安装失败风险检测需要遍历检测所有的影响因素。影响应用程序安装失败的待检测信息可以是一个也可以是多个。

示例性地，当待检测信息为多种时，利用第i种待检测信息对应的检测规则进行安装失败风险检测，确定第i种待检测信息的检测结果，i为正整数。

在本申请实施例中，待检测信息包括：安装包内的二进制文件、应用程序的应用签名、安装包内的函数方法总数、安装包内的属性列表中的至少一种。

示例性地，第i种待检测信息包括安装包内的二进制文件。

利用第i种待检测信息对应的检测规则进行安装失败风险检测，包括如下步骤中的至少一种：检测二进制文件中的安装位置是否为外置内存卡。当二进制文件中的安装位置对应的参数值是1时，代表将应用程序安装在终端内存中；当二进制文件中的安装位置对应的参数值是0时，代表优先将应用程序安装在终端内存中，当终端内存不够时，再安装到外置内存卡上。当二进制文件中的安装位置对应的参数值是2时，代表将应用程序安装到外置内存卡上。检测二进制文件的结构是否符合二进制格式。检测二进制文件中的应用包名对应的参数值是否符合官方命名要求。检测二进制文件中的版本号是否低于第一版本号；第一版本号为最新版本应用程序的版本号。检测二进制文件中的目标接口版本号是否低于第二版本号，第二版本号是最新版本应用程序的目标接口版本号。

示例性地，第i种待检测信息包括应用程序的应用签名。

利用第i种待检测信息对应的检测规则进行安装失败风险检测，包括如下步骤中的至少一种：检测应用签名的签名方案是否缺失；检测签名方案对应的参数值是否为第一阈值；可选地，第一阈值为V2(Full APK Signature)。检测应用签名所使用的签名算法是否过期；检测应用签名对应的哈希值与历史版本对应的哈希值是否一致。

示例性地，第i种待检测信息包括安装包内的函数方法总数。

利用第i种待检测信息对应的检测规则进行安装失败风险检测，包括：检测函数方法总数是否大于第二阈值。可选地，第二阈值为65536。在Android操作系统中，编译后的函数方法存放在一个dex文件(可执行文件)中，在安装应用程序的时候，dex文件会被DexOpt程序odex化。dexopt会把dex文件里的函数方法对应的id保存到一个链表中，而这个链表的长度是用short(短整型)类型保存的，因此函数方法的总数不能大于2¹⁶＝65536。当函数方法总数大于65536时，检测结果为存在安装失败风险。

示例性地，待检测信息为安装包内的二进制文件、应用程序的应用签名、安装包内的函数方法总数适用于Android操作系统，上述安装包为apk。

二进制文件中的安装位置对应的参数可以用android：installLocation表示。若android：installLocation值为2，则不满足检测规则，应用程序没有安装到目标位置，检测结果为存在安装失败风险。当其值为2时，表示应用程序被优先安装到外置内存卡中，在部分未安装外置内存卡的终端中会安装失败。

二进制文件可以用AndroidManifest.xml文件表示。若安装包内不存在AndroidManifest.xml文件，则不满足检测规则，检测结果为存在安装失败风险；若AndroidManifest.xml文件不符合文件节点配置要求，则不满足检测规则，检测结果为存在安装失败风险。

二进制文件中的应用包名对应的参数可以用package值表示。若package值不符合Android官方命名要求，则不满足检测规则，检测结果为存在安装失败风险。

二进制文件中的版本号可以用versionCode表示。若versionCode低于最新版本号，则不满足检测规则，检测结果为存在安装失败风险。

二进制文件中的目标接口版本号可以用targetSdkVersion表示。若targetSdkVersion值低于最新版本应用程序的目标接口版本号的值，则不满足检测规则，检测结果为存在安装失败风险。

应用程序的签名方案可以通过apksigner(apk签名工具)获取。若应用签名的签名方案缺失或签名方案对应的参数值为V2，或者应用签名所使用的签名算法过期，则不满足检测规则，检测结果为存在安装失败风险。应用签名的签名方案缺失在终端上会安装失败，签名方案或签名算法异常，会在部分终端上安装失败。

若应用签名对应的哈希(hash)值与历史版本对应的哈希值的不一致，则不满足检测规则，检测结果为存在安装失败风险。

若安装包内的单个dex文件中的函数方法总数大于65536，则不满足检测规则，检测结果为存在安装失败风险。

示例性地，第i种待检测信息包括安装包内的属性列表；

利用第i种待检测信息对应的检测规则进行安装失败风险检测，包括如下步骤中的至少一种：检测属性列表中的最低系统版本号对应的参数值是否为第三阈值；可选地，第三阈值为最低系统版本号。检测属性列表中的环境配置参数对应的值是否为第四阈值；可选地，第四阈值为false(错误)。检测属性列表中的环境配置参数是否配置；检测属性列表中的支持设备类型对应的参数值是否为第五阈值；可选地，第五阈值为2。检测属性列表中的设备兼容性对应的参数值是否配置为目标特性。目标特性包括以下任意一种：真机具有64位处理器(arm64)、具有低层次的渲染应用程序编程接口(metal)、具有2D和3D图形应用程序接口3.0(opengles-3)、具有实现AR(Augumented Reality，增强现实)技术的工具(arkit)、具有实现nfc(near field communication，近距离无线通讯)技术的功能(nfc)。如果属性列表中的设备兼容性对应的参数值为上述特性，在部分不支持该特性的终端上会安装失败，检测结果为存在安装失败风险。

示例性地，待检测信息为安装包内的属性列表时适用于IOS操作系统，上述安装包为ipa。

属性列表可以通过ipa内的info.plist文件获得。属性列表中的最低系统版本号对应的参数可以用MinimumOSVersion表示，若MinimumOSVersion参数值为第四阈值，则不满足检测规则，检测结果为存在安装失败风险。低于该第四阈值的系统无法安装应用程序。环境配置参数可以用LSRequiresiphoneOS表示，若LSRequiresiphoneOS参数值为“False”或没有配置该参数，则不满足检测规则，检测结果为存在安装失败风险，应用程序无法在IOS系统上安装。支持设备类型对应的参数可以用UIDeviceFamily表示，若UIDeviceFamily值为2，则不满足检测规则，检测结果为存在安装失败风险，应用程序无法在终端上安装。设备兼容性对应的参数可以用UIRequiredDeviceCapabilities表示，若UIRequiredDeviceCapabilities值配置为arm64、metal、opengles-3、arkit、nfc特性，则不满足检测规则，检测结果为存在安装失败风险，应用程序在部分不支持该特性的终端会安装失败。

本申请实施例仅示出了一部分待检测信息和待检测对应的检测规则，但并不对此构成限定。

可选地，服务器爬取下载应用市场上的安装包；解析应用市场上的安装包，获取应用市场上的安装包的待检测信息；当应用市场上的安装包的待检测信息中存在与主流配置信息不一致的异常信息时，将应用市场上的安装包安装到至少两种不同终端上；其中，主流配置信息是指应用程序中常用的配置信息；若存在安装失败，提取异常信息对应的检测规则，更新检测规则。常用的配置信息是指应用程序配置的该配置信息在应用市场上的应用程序的配置占比大于预设阈值。例如，预设阈值可以是60％。

服务器会对应用市场上的应用程序的安装包自动进行大量爬取下载，并解析应用市场上的安装包，获取应用市场上的安装包的待检测信息；当应用市场上的安装包的待检测信息中存在与主流配置信息不一致的异常信息时，将该安装包安装到至少两种不同终端上，如果存在安装失败，则分析该异常信息对应的检测规则，更新已有的检测规则，对已有的检测规则进行补充和完善。

服务器可以不断积累待检测信息和待检测信息的检测结果，并不断迭代更新待检测信息。服务器还可以基于收集的待检测信息大数据，统计出当前市场或头部应用(下载量较多的应用程序)的主流配置信息占比，以供开发团队参考借鉴，规避风险。例如，当前应用市场上，app配置的最低支持系统版本，有60％配置的是Android4.4系统，10％配置的是Android5.0系统等等。

可选地，根据操作系统源码中的目标代码，提取检测规则；其中，目标代码用于检测安装是否失败。操作系统源码中包括关于检测应用程序安装是否失败的代码实现，对上述代码进行分析，可以提取出检测规则。操作系统源码会根据检测条件检测安装包中是否存在异常参数使得应用程序安装失败，本申请可以从上述检测条件中提取出检测规则。应用程序在终端上进行安装时，系统源码会拷贝安装包到指定目录，并对安装包进行解压，获得安装包中的二进制文件；然后解析安装包中的二进制文件，获得签名、应用包名、版本等信息；系统源码会依次读取这些信息，检测应用程序是否能安装。当这些信息存在异常时，应用程序安装失败。因此本申请实施例可以先对系统源码中关于检测应用程序安装的代码进行分析，提取出检测规则。本申请实施例先利用检测规则对待检测信息进行安装失败检测，找到可能导致应用程序安装失败的因素，在动态安装前对它进行修复；从而当应用程序在终端上进行安装时，系统源码对这些信息检测时，不存在异常，应用程序能正常安装。

步骤204，根据待检测信息的检测结果，生成应用程序的检测报告。

在本申请实施例中，检测报告中包括待检测信息和待检测信息的检测结果的对应关系。

示例性地，服务器生成应用程序的检测报告之后，存储应用程序的检测报告和应用程序的对应关系。服务器保存各应用程序的历史检测报告，方便后期对比分析及回溯历史结果。

检测报告中会列举待检测信息以及待检测信息的检测结果。若应用程序存在安装失败风险，则检测报告中还会详细说明存在安装失败风险的原因和修复建议。对于配置类问题，检测报告中还会说明相应的大数据配置占比，以供应用程序的开发人员参考。

示例性地，服务器还会向终端发送检测报告。例如，服务器会以邮件的形式向用户发送检测报告。

需要说明的是，本申请实施例提供的技术方案，对待检测信息和待检测信息对应的检测规则做出相应调整，可以适用于对应用程序的兼容适配问题进行检测，或者对应用程序崩溃问题的静态检测。

综上所述，本申请实施例提供的技术方案中，对于需要检测是否存在安装失败风险的应用程序，通过将该应用程序的安装包发送给服务器，服务器解析该应用程序的安装包，获得待检测信息，并利用检测规则对待检测信息进行安装失败风险检测，确定检测结果。检测规则是根据至少两种不同终端对应用程序的历史安装包进行安装时的安装失败案例所得到的，检测规则准确。通过静态检测应用程序是否存在安装失败风险，检测周期较短，从服务器获得安装包到确定检测结果一般只需要花费10秒左右的时间，得到检测结果的效率较高。

在基于图2实施例提供的一个可选实施例中，可以通过如下步骤获得应用程序的待检测信息：

第一、通过解压缩工具对应用程序的安装包进行处理，获得解压后的待检测文件；

应用程序安装失败，通常与该应用程序的各类配置错误有关，要进行安装失败风险检测，首先就需要精准获取该应用程序的详细配置信息及其它必要信息。

安装包文件本质上是一个压缩文件，融合了代码、资源、配置文件等信息。解压缩工具可以是python的zip模块，通过python的zip模块对应用程序的安装包进行处理，获得解压后的待检测文件。

示例性地，还可以将安装包文件对应的后缀名改为压缩包格式，例如，zip格式，获得解压后的待检测文件。

第二、通过解析工具对解压后的待检测文件进行处理，获得待检测信息。

解析工具可以是aapt(android asset packaging tool，安卓资源打包工具)，通过aapt可以获得安装包中的资源信息等；解析工具还可以是开源代码，例如，arm-linux-androideabi-strings，通过arm-linux-androideabi-strings开源代码解析so动态库，可以获得应用程序的版本信息等。

解压后的待检测文件可能是编译后的二进制文件，不是明文可读文本，需要通过解密工具对解压后的待检测文件进行处理，获得待检测信息。

解密工具是用于将二进制文件还原为明文可读文本的工具。通过解密工具可以将待检测文件从二进制文件变为明文可读文本，从而获得明文可读文本中的待检测信息。

解密工具可以通过如下方式获得：

1、获取二进制文件和明文可读文本之间的映射关系；

二进制文件和明文可读文本之间是存在一定的映射关系的，例如，明文可读文本中的同一类型的信息在编译后的二进制文件中的位置是固定的。

典型的二进制文件为AndroidManifest.xml文件，开发人员可以自己编译一个已知AndroidManifest.xml内容的apk文件，然后解析获得相应二进制文件，利用工具010editor(十六进制编辑器)分析二进制文件结构，确定明文信息编译成二进制后，各类型信息的存储位置，再把二进制信息还原成可读文本信息，并和原来可读的文件进行对比，优化映射关系。

2、根据上述映射关系，生成解密工具。

根据优化后的映射关系，代码编程实现二进制文件的明文还原。

综上所述，本申请实施例提供的技术方案中，通过多种方式获得应用程序的待检测信息，灵活性高。

请参考图3，其示出了本申请一个实施例提供的检测报告接收方法的流程图。该方法的执行主体可以是图1中的终端。该方法可以包括以下几个步骤：

步骤301，显示安装失败风险检测网页，安装失败风险检测网页中包括上传控件。

用户可以登录安装失败风险检测网页，安装失败风险检测网页中包括上传控件。

步骤302，通过上传控件，向服务器发送应用程序的安装包。

用户可以点击上传控件，触发终端向服务器发送应用程序的安装包。

步骤303，接收和显示应用程序的检测报告，检测报告是上述实施例中的服务器利用检测规则对应用程序的安装包进行安装失败风险检测生成的。

在本申请实施例中，检测规则是根据至少两种不同终端对应用程序的历史安装包进行安装时的安装失败案例所得到的。

示例性地，应用程序的检测报告以邮件的形式在终端上显示。

综上所述，本申请实施例提供的技术方案中，通过向服务器发送应用程序的安装包，即可获得应用程序的检测报告，操作简便。

请参考图4，其示出了本申请一个实施例提供的检测报告生成平台的逻辑架构图。该检测报告生成平台包括web前端、数据库服务器和web服务器。检测报告生成平台生成检测报告的流程可以包括如下几个步骤：

1、web前端上传应用程序的安装包；

web前端向web服务器发送应用程序的安装包。

2、web服务器接收该应用程序的安装包；

3、web服务器返回上传中状态；

4、web前端显示上传中；

5、web服务器接收完成；

6、web前端显示检测中；

将web服务器的处理进度显示在web前端中，可以方便用户通过web前端了解处理进度，用户体验感好。

7、web服务器开始解析安装包；

8、web服务器获取待检测信息，并将待检测信息发送给数据库服务器；

待检测信息可以包括安装包的基础信息，例如应用程序的包名、应用程序的版本等信息；待检测信息还可以包括安装包的深度信息，例如，应用程序的签名、dex方法数等信息。

9、web服务器从数据库服务器中获取检测规则；

检测规则存储在数据库服务器中可以方便后续读取、更新、查找等。将检测规则存储在数据库服务器中，当web服务器需要使用时才从数据库服务器中获取检测规则，一定程度上可以减轻web服务器的存储压力。

10、web服务器遍历执行检测规则；

11、web服务器记录每个待检测信息对应的检测结果，并将检测结果发送给数据库服务器；

数据库服务器接收并存储检测结果。

12、web服务器根据检测结果，生成检测报告，并将检测报告发送给数据库服务器；

13、数据库服务器向web前端以邮件的形式发送检测报告，并返回页面结果；

检测报告中会列举待检测信息以及待检测信息的检测结果。若应用程序存在安装失败风险，则检测报告中还会详细说明存在安装失败风险的原因和修复建议。对于配置类问题，检测报告中还会说明相应的大数据配置占比，以供应用程序的开发人员参考。

14、用户可以在web前端查看检测报告。

综上所述，本申请实施例提供的技术方案中，提供了一种检测报告生成平台，对应用程序的安装失败风险提供了一站式检测服务。用户只需要将应用程序的安装包上传到检测报告生成平台，即可获得检测报告，效率高，成本低，不需要使用终端进行实际安装测试，10秒左右即可输出检测结果，而且检测内容丰富完整，对于存在的问题，详细说明问题原因、影响评估、修复建议、及其它app的大数据统计。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

请参考图5，其示出了本申请一个实施例提供的检测报告生成装置的框图。该装置具有实现上述方法示例的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。该装置500可以包括：安装包获取模块510、信息获取模块520、结果确定模块530和报告生成模块540。

所述安装包获取模块510，用于获取应用程序的安装包。

所述信息获取模块520，用于解析所述应用程序的安装包，获得所述应用程序的待检测信息。

所述结果确定模块530，用于利用检测规则对所述待检测信息进行安装失败风险检测，确定所述待检测信息的检测结果；所述检测规则是根据至少两种不同终端对所述应用程序的历史安装包进行安装时的安装失败案例所得到的。

所述报告生成模块540，用于根据所述待检测信息的检测结果，生成所述应用程序的检测报告。

综上所述，本申请实施例提供的技术方案中，对于需要检测是否存在安装失败风险的应用程序，通过将该应用程序的安装包发送给服务器，服务器解析该应用程序的安装包，获得待检测信息，并利用检测规则对待检测信息进行安装失败风险检测，确定检测结果。检测规则是根据至少两种不同终端对应用程序的历史安装包进行安装时的安装失败案例所得到的，检测规则准确。通过静态检测应用程序是否存在安装失败风险，检测周期较短，从服务器获得安装包到确定检测结果一般只需要花费10秒左右的时间，得到检测结果的效率较高。

在示意性实施例中，所述结果确定模块530，用于：

当所述待检测信息为多种时，利用第i种所述待检测信息对应的检测规则进行安装失败风险检测，确定所述第i种待检测信息的检测结果，i为正整数；

其中，所述待检测信息包括：所述安装包内的二进制文件、所述应用程序的应用签名、所述安装包内的函数方法总数、所述安装包内的属性列表中的至少一种。

在示意性实施例中，所述第i种待检测信息包括所述安装包内的二进制文件；

所述结果确定模块530，用于：

检测所述二进制文件中的安装位置是否为外置内存卡；

检测所述二进制文件的结构是否符合二进制格式；

检测所述二进制文件中的应用包名对应的参数值是否符合官方命名要求；

检测所述二进制文件中的版本号是否低于第一版本号；

检测所述二进制文件中的目标接口版本号是否低于第二版本号。

在示意性实施例中，所述第i种待检测信息包括所述应用程序的应用签名；

所述结果确定模块530，用于：

检测所述应用签名的签名方案是否缺失；

检测所述签名方案对应的参数值是否为第一阈值；

检测所述应用签名所使用的签名算法是否过期；

检测所述应用签名对应的哈希值与历史版本对应的哈希值是否一致。

在示意性实施例中，所述第i种待检测信息包括所述安装包内的函数方法总数；

所述结果确定模块530，用于：

检测所述函数方法总数是否大于第二阈值。

在示意性实施例中，所述第i种待检测信息包括所述安装包内的属性列表；

所述结果确定模块530，用于：

检测所述属性列表中的最低系统版本号对应的参数值是否为第三阈值；

检测所述属性列表中的环境配置参数对应的值是否为第四阈值；

检测所述属性列表中的所述环境配置参数是否配置；

检测所述属性列表中的支持设备类型对应的参数值是否为第五阈值；

检测所述属性列表中的设备兼容性对应的参数值是否配置为目标特性。

在示意性实施例中，如图6所示，所述装置500，还包括：安装包爬取模块550、安装包安装模块560和规则更新模块570。

所述安装包爬取模块550，用于爬取下载应用市场上的安装包。

所述信息获取模块520，还用于解析所述应用市场上的安装包，获取所述应用市场上的安装包的待检测信息。

所述安装包安装模块560，用于当所述应用市场上的安装包的待检测信息中存在与主流配置信息不一致的异常信息时，将所述应用市场上的安装包安装到所述至少两种不同终端上；其中，所述主流配置信息是指应用程序中常用的配置信息。

所述规则更新模块570，用于若存在安装失败，提取所述异常信息对应的检测规则，更新所述检测规则。

在示意性实施例中，所述装置500，还包括：规则提取模块580。

所述规则提取模块580，用于根据操作系统源码中的目标代码，提取所述检测规则；其中，所述目标代码用于检测安装是否失败。

在示意性实施例中，所述装置500，还包括：解压处理模块590和解密处理模块591。

所述解压处理模块590，用于通过解压缩工具对所述应用程序的安装包进行处理，获得解压后的待检测文件。

所述解密处理模块591，用于通过解密工具将所述待检测文件从二进制文件变为明文可读文本，获得所述明文可读文本中的所述待检测信息。

请参考图7，其示出了本申请一个实施例提供的检测报告接收装置的框图。该装置具有实现上述方法示例的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。该装置700可以包括：网页显示模块710、安装包发送模块720和报告接收模块730。

所述网页显示模块710，用于显示安装失败风险检测网页，所述安装失败风险检测网页中包括上传控件。

所述安装包发送模块720，用于通过所述上传控件，向服务器发送应用程序的安装包。

所述报告接收模块730，用于接收和显示所述应用程序的检测报告，所述检测报告是所述服务器利用检测规则对所述应用程序的安装包进行安装失败风险检测生成的，所述检测规则是根据至少两种不同终端对所述应用程序的历史安装包进行安装时的安装失败案例所得到的。

综上所述，本申请实施例提供的技术方案中，对于需要检测是否存在安装失败风险的应用程序，通过将该应用程序的安装包发送给服务器，服务器解析该应用程序的安装包，获得待检测信息，并利用检测规则对待检测信息进行安装失败风险检测，确定检测结果。检测规则是根据至少两种不同终端对应用程序的历史安装包进行安装时的安装失败案例所得到的，检测规则准确。通过静态检测应用程序是否存在安装失败风险，检测周期较短，从服务器获得安装包到确定检测结果一般只需要花费10秒左右的时间，得到检测结果的效率较高。

需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内容结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

请参考图8，其示出了本申请一个实施例提供的计算机设备800的结构框图。该计算机设备800可用于实施上述实施例中提供的检测报告生成方法或检测报告接收方法。具体来讲：

所述计算机设备800包括中央处理单元(CPU)801、包括随机存取存储器(RAM)802和只读存储器(ROM)803的系统存储器804，以及连接系统存储器804和中央处理单元801的系统总线805。所述计算机设备800还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(I/O系统)806，和用于存储操作系统813、应用程序814和其他程序模块815的大容量存储设备807。

所述基本输入/输出系统806包括有用于显示信息的显示器808和用于用户输入信息的诸如鼠标、键盘之类的输入设备809。其中所述显示器808和输入设备809都通过连接到系统总线805的输入输出控制器810连接到中央处理单元801。所述基本输入/输出系统806还可以包括输入输出控制器810以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器810还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备807通过连接到系统总线805的大容量存储控制器(未示出)连接到中央处理单元801。所述大容量存储设备807及其相关联的计算机可读介质为计算机设备800提供非易失性存储。也就是说，所述大容量存储设备807可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。

不失一般性，所述计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、EPROM、EEPROM、闪存或其他固态存储其技术，CD-ROM、DVD或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器804和大容量存储设备807可以统称为存储器。

根据本申请的各种实施例，所述计算机设备800还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即计算机设备800可以通过连接在所述系统总线805上的网络接口单元811连接到网络812，或者说，也可以使用网络接口单元811来连接到其他类型的网络或远程计算机系统(未示出)。

所述存储器还包括一个或者一个以上的程序，所述一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行。上述一个或者一个以上程序包含用于实现上述检测报告生成方法或检测报告接收方法。

在示例性实施例中，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集。所述至少一条指令、至少一段程序、代码集或指令集经配置以由一个或者一个以上处理器执行，以实现上述检测报告生成方法或检测报告接收方法。

在示例性实施例中，还提供了一种服务器，所述服务器包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集。所述至少一条指令、至少一段程序、代码集或指令集经配置以由一个或者一个以上处理器执行，以实现上述检测报告生成方法。

在示例性实施例中，还提供了一种终端，所述终端包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集。所述至少一条指令、至少一段程序、代码集或指令集经配置以由一个或者一个以上处理器执行，以实现上述检测报告接收方法。

在示例性实施例中，还提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或所述指令集在被终端的处理器执行时实现上述检测报告生成方法或检测报告接收方法。

可选地，上述计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品，当该计算机程序产品被执行时，其用于实现上述检测报告生成方法或检测报告接收方法。

应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。另外，本文中描述的步骤编号，仅示例性示出了步骤间的一种可能的执行先后顺序，在一些其它实施例中，上述步骤也可以不按照编号顺序来执行，如两个不同编号的步骤同时执行，或者两个不同编号的步骤按照与图示相反的顺序执行，本申请实施例对此不作限定。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的示例性实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (14)

1.一种检测报告生成方法，其特征在于，所述方法包括：

获取应用程序的安装包；

解析所述应用程序的安装包，获得所述应用程序的待检测信息；

利用检测规则对所述待检测信息进行安装失败风险检测，确定所述待检测信息的检测结果；所述检测规则是根据至少两种不同终端对所述应用程序的历史安装包进行安装时的安装失败案例所得到的；

根据所述待检测信息的检测结果，生成所述应用程序的检测报告。

2.根据权利要求1所述的方法，其特征在于，所述利用检测规则对所述待检测信息进行安装失败风险检测，确定所述待检测信息的检测结果，包括：

当所述待检测信息为多种时，利用第i种所述待检测信息对应的检测规则进行安装失败风险检测，确定所述第i种待检测信息的检测结果，i为正整数；

其中，所述待检测信息包括：所述安装包内的二进制文件、所述应用程序的应用签名、所述安装包内的函数方法总数、所述安装包内的属性列表中的至少一种。

3.根据权利要求2所述的方法，其特征在于，所述第i种待检测信息包括所述安装包内的二进制文件；

所述利用第i种所述待检测信息对应的检测规则进行安装失败风险检测，包括如下步骤中的至少一种：

检测所述二进制文件中的安装位置是否为外置内存卡；

检测所述二进制文件的结构是否符合二进制格式；

检测所述二进制文件中的应用包名对应的参数值是否符合官方命名要求；

检测所述二进制文件中的版本号是否低于第一版本号；

检测所述二进制文件中的目标接口版本号是否低于第二版本号。

4.根据权利要求2所述的方法，其特征在于，所述第i种待检测信息包括所述应用程序的应用签名；

所述利用第i种所述待检测信息对应的检测规则进行安装失败风险检测，包括如下步骤中的至少一种：

检测所述应用签名的签名方案是否缺失；

检测所述签名方案对应的参数值是否为第一阈值；

检测所述应用签名所使用的签名算法是否过期；

检测所述应用签名对应的哈希值与历史版本对应的哈希值是否一致。

5.根据权利要求2所述的方法，其特征在于，所述第i种待检测信息包括所述安装包内的函数方法总数；

所述利用第i种所述待检测信息对应的检测规则进行安装失败风险检测，包括：

检测所述函数方法总数是否大于第二阈值。

6.根据权利要求2所述的方法，其特征在于，所述第i种待检测信息包括所述安装包内的属性列表；

所述利用第i种所述待检测信息对应的检测规则进行安装失败风险检测，包括如下步骤中的至少一种：

检测所述属性列表中的最低系统版本号对应的参数值是否为第三阈值；

检测所述属性列表中的环境配置参数对应的值是否为第四阈值；

检测所述属性列表中的所述环境配置参数是否配置；

检测所述属性列表中的支持设备类型对应的参数值是否为第五阈值；

检测所述属性列表中的设备兼容性对应的参数值是否配置为目标特性。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：

爬取下载应用市场上的安装包；

解析所述应用市场上的安装包，获取所述应用市场上的安装包的待检测信息；

当所述应用市场上的安装包的待检测信息中存在与主流配置信息不一致的异常信息时，将所述应用市场上的安装包安装到所述至少两种不同终端上；其中，所述主流配置信息是指应用程序中常用的配置信息；

若存在安装失败，提取所述异常信息对应的检测规则，更新所述检测规则。

8.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：

根据操作系统源码中的目标代码，提取所述检测规则；其中，所述目标代码用于检测安装是否失败。

9.根据权利要求1所述的方法，其特征在于，所述解析所述应用程序的安装包，获得所述应用程序的待检测信息，包括：

通过解压缩工具对所述应用程序的安装包进行处理，获得解压后的待检测文件；

通过解密工具将所述待检测文件从二进制文件变为明文可读文本，获得所述明文可读文本中的所述待检测信息。

10.一种检测报告接收方法，其特征在于，所述方法包括：

显示安装失败风险检测网页，所述安装失败风险检测网页中包括上传控件；

通过所述上传控件，向服务器发送应用程序的安装包；

接收和显示所述应用程序的检测报告，所述检测报告是所述服务器利用检测规则对所述应用程序的安装包进行安装失败风险检测生成的，所述检测规则是根据至少两种不同终端对所述应用程序的历史安装包进行安装时的安装失败案例所得到的。

11.一种检测报告生成装置，其特征在于，所述装置包括：

安装包获取模块，用于获取应用程序的安装包；

信息获取模块，用于解析所述应用程序的安装包，获得所述应用程序的待检测信息；

结果确定模块，用于利用检测规则对所述待检测信息进行安装失败风险检测，确定所述待检测信息的检测结果；所述检测规则是根据至少两种不同终端对所述应用程序的历史安装包进行安装时的安装失败案例所得到的；

报告生成模块，用于根据所述待检测信息的检测结果，生成所述应用程序的检测报告。

12.一种检测报告接收装置，其特征在于，所述装置包括：

网页显示模块，用于显示安装失败风险检测网页，所述安装失败风险检测网页中包括上传控件；

安装包发送模块，用于通过所述上传控件，向服务器发送应用程序的安装包；

报告接收模块，用于接收和显示所述应用程序的检测报告，所述检测报告是所述服务器利用检测规则对所述应用程序的安装包进行安装失败风险检测生成的，所述检测规则是根据至少两种不同终端对所述应用程序的历史安装包进行安装时的安装失败案例所得到的。

13.一种计算机设备，其特征在于，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至9任一项所述的检测报告生成方法，或实现如权利要求10所述的检测报告接收方法。

14.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如权利要求1至9任一项所述的检测报告生成方法，或实现如权利要求10所述的检测报告接收方法。