CN106874088B - 一种应用程序自启动的处理方法、装置及移动终端 - Google Patents

Abstract

本发明公开了一种应用程序自启动的处理方法、装置及移动终端，涉及应用处理技术领域，主要目的在于能够从底层彻底有效的管理已经自启动的应用程序。所述方法包括：接收应用程序的自启动请求，获取应用程序对应的自启动模式，当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略，根据所述应用处理策略对所述应用程序的自启动请求进行处理。本发明适用于应用程序自启动的处理。

Description

一种应用程序自启动的处理方法、装置及移动终端

技术领域

本发明涉及应用处理技术领域，特别是涉及一种应用程序自启动的处理方法、装置及移动终端。

背景技术

随着智能终端的不断发展，用户在智能终端中安装的应用程序也不断增多，通常情况下，很多应用程序开发者为了方便用户使用会在安装平台开机时自启动应用程序。目前，终端内各个应用程序自启动的方式为通过在系统中注册静态广播接收器BroadcastReceiver，通过广播接收器来调用指定应用程序，或者通过系统中其他组件来调用指定应用程序，例如，可以通过内容提供者ContentProvider组件来提供的应用程序接口来调用同一家族内的其他应用程序，还可以通过后台服务Service来调用指定系统功能的应用程序。

应说明的是，通过上述方式自启动的应用程序有时并非系统或其他应用程序运行时所必须的条件，或者终端内某些应用程序的启动并非用户所期望启动的，因此，对于某些应用程序以及用户来说无用的应用程序，自启动过多会占用终端过多的资源，降低系统运行速度。

针对上述问题，现有的禁止应用程序自启动的实现方式为：当应用程序接收到广播接收器或者系统中其他组件的调用后，判断该应用程序是否允许自启动，如果允许则不进行处理，如果不允许则将已经启动的应用程序的应用进程结束。然而，现有的禁止应用程序自启动的技术是在系统应用层实现的，如果广播接收器监听的广播过多，就会频繁的触发应用程序自启动，通过将已经自启动的应用程序结束无法从底层彻底拦截应用程序，对于已经成功自启动的应用程序如果没有及时结束进程，还可能带来隐私以及安全方面的风险。

发明内容

有鉴于此，本发明提供一种应用程序自启动的处理方法、装置及移动终端，能够从底层彻底有效的管理已经自启动的应用程序。

依据本发明一个方面，提供了一种应用程序自启动的处理方法，包括：

接收应用程序的自启动请求，获取应用程序对应的自启动模式；

当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略；

根据所述应用处理策略对所述应用程序的自启动请求进行处理。

依据本发明一个方面，提供了一种应用程序自启动的处理装置，包括：

获取单元，用于接收应用程序的自启动请求，获取应用程序对应的自启动模式；

配置单元，用于当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略；

处理单元，用于根据所述应用处理策略对所述应用程序的自启动请求进行处理。

依据本发明一个方面，提供了一种移动终端，包括处理器和存储器：

所述存储器用于存储执行上述应用程序自启动的处理方法的程序；

所述处理器被配置为用于执行所述存储器中存储的程序。

借由上述技术方案，本发明实施例提供的技术方案至少具有下列优点：

本发明提供的一种应用程序自启动的处理方法、装置及移动终端，与现有的禁止应用程序自启动的技术是在系统应用层实现的，无法从底层彻底拦截应用程序相比，本发明通过获取所述应用程序对应的自启动模式，然后当应用程序对应的自启动模式为鉴权启动模式时，配置与服务启动程序相应的应用处理策略，在不影响用户正常使用的基础上，对于用户允许自启动的应用程序可以启动，对于用户不允许自启动的应用程序，根据应用处理策略对应用程序的自启动请求进行处理，能够从底层有效的处理应用程序的自启动，对应用程序进行有效的拦截，从而降低了在应用程序自启动处理不及时给用户带来的隐私以及安全方面的风险。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种应用程序自启动的处理方法流程示意图；

图2示出了本发明实施例提供的另一种应用程序自启动的处理方法流程示意图；

图3示出了本发明实施例提供的另一种应用程序自启动的处理方法流程示意图

图4示出了本发明实施例提供的一种应用程序自启动的处理装置结构示意图；

图5示出了本发明实施例提供的另一种应用程序自启动的处理装置结构示意图；

图6示出了本发明实施例提供的另一种应用程序自启动的处理装置结构示意图；

图7示出了本发明实施例提供的一种移动终端的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明实施例提供了一种应用程序自启动的处理方法，如图1所示，所述方法包括：

101、接收应用程序的自启动请求，获取所述应用程序对应的自启动模式。

其中，所述应用程序的自启动请求为当安卓手机程序后台接收到某些事件，如网络连接变化、开屏解锁、开机启动等事件而触发的自动启动行为，即使清理了内存，软件进程当时被杀掉了，但是如果遇到如解锁、锁屏等触发事件，应用程序就会向系统发送自动的启动后台进程的自启动请求。

在安卓系统中，触发应用程序自启动的方式有很多种，例如，用户通过手机屏幕中点击应用程序图标的场景，或者应用之间进行数据共享的场景，或者执行系统本地服务的场景，不同的应用场景对应不同的应用程序自启动模式，因此当接收到应用程序的自启动请求时，有必要根据不同触发应用程序的应用场景获取应用程序对应的自启动模式，例如，用户通过手机屏幕中点击应用程序图标的场景对应的自启动模式为界面启动模式，应用之间进行数据共享的场景对应的启动模式为接口启动模式，执行系统本地服务的场景对应的自启动模式为服务启动模式。

需要说明的是，上述的界面启动模式为用户操作而展示的可视化用户界面，比如，通过界面展示一个菜单项列表供用户选择，或者显示一些包含说明的照片等，本发明实施例不做限定。

对于某些影响到系统运行的核心进程默认是在界面不显示的，系统默认配置好自启动的能力，例如有些系统进程无需自启动，就不在界面进行显示，以免用户手动开启影响功耗和性能，而有些需要自启动能力的系统进程，也默认不在界面进行显示，以免影响系统的正常运行；对于某些非系统核心进程，如部分系统应用程序以及第三份应用程序，通常情况需要用户手动参与设置自启动情况，例如，对于微信应用程序、QQ等需要实时接收消息的应用程序，默认设置自启动功能，对于游戏等占用较大内存和功耗的应用程序通常设置禁止自启动功能。

然而，在实际进行设置应用程序自启动的过程中，某些应用程序虽然被设置禁止自启动功能，而当终端中家族应用过多，就会频繁的后台自启动，造成了功能和性能方面的影响，如果不及时结束进程可能带来隐私等安全方面的风险。

102、当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略。

这里的接口启动模式可以通过安卓系统中的AccountManager功能来实现，应用程序通过AccountManager获得验证标识auth-token，从而决定是否打开登陆、创建用户的Activity，或者从之前的请求中返回已经存储好的验证标识auth-token。当AccountManager查找合适的AccountAuthenticator组件后，与其通信，并且根据账号类型执行所有动作。所以AccountManager为不同类型的账户提供了统一验证管理的方法，处理有效的账户详细信息并且实现排序。例如Google、Facebook各自有验证方法。

对于本发明实施例，根据应用程序对应的自启动模式配置与应用程序相应的应用处理策略，当应用程序对应的启动模式为鉴权启动模式时，通过配置与鉴权启动模式对应的应用处理策略来控制应用程序的启动和禁止，自动配置好默认值，无需用户手动参与设置，也能够保证系统的正常运行。

需要说明的是，应用处理策略为在安卓系统在接收到广播消息后调用应用程序之前判断是否调用各应用程序的策略，具体可以通过在启动流程中增加处理模块，其主要代码在AmInjector.java文件中，首先通过调用服务接口判断应用程序是否有自启权限，如果是则不进行拦截，否则获取广播启动模式的消息传递机制，进一步判断消息传递机制是否符合预设匹配条件，这里的预设匹配条件分别为行为匹配条件、类匹配条件以及行为前缀匹配条件，如果符合则不进行拦截，否则判断应用程序是否为系统应用程序，如果是则不进行拦截，否则判断应用程序是否处于运行状态，如果是则说明应用程序当前已经被后台开启，不进行拦截，否则判断应用程序的调用者以及应用程序的包名是否一致，如果一致则不进行拦截，否则判断应用程序是否为核心应用程序，如果是则不进行拦截，否则禁止启动应用程序。

103、根据所述应用处理策略对所述应用程序的自启动请求进行处理。

本步骤中，根据应用处理策略对通过鉴权启动模式启动的应用程序进行处理，这里通过鉴权启动模式启动的应用程序在启动应用程序之前，会根据应用处理策略对该应用程序进行判断，如对于某些用户不期望自启动的应用程序，可以通过在底层进行设置禁止启动，对于某些系统运行所必须的应用程序，如桌面、电话等系统应用程序，可以通过在底层进行设置可以进行启动，本法实施例通过配置的应用处理策略对通过广播启动模式启动的应用程序进行处理，对于用户不允许启动的应用程序能进行有效的拦截。

本发明提供的一种应用程序自启动的处理方法，与现有的禁止应用程序自启动的技术是在系统应用层实现的，无法从底层彻底拦截应用程序相比，本发明通过获取所述应用程序对应的自启动模式，然后当应用程序对应的自启动模式为鉴权启动模式时，配置与鉴权启动模式相应的应用处理策略，在不影响用户正常使用的基础上，对于用户允许自启动的应用程序可以启动，对于用户不允许自启动的应用程序，根据应用处理策略对应用程序的自启动请求进行处理，能够从底层有效的处理应用程序的自启动，对应用程序进行有效的拦截，从而降低了在应用程序自启动处理不及时给用户带来的隐私以及安全方面的风险。

本发明实施例提供了另一种应用程序自启动的处理方法，如图2所示，所述方法包括：

201、接收应用程序的自启动请求，判断所述应用程序的启动方式是否为界面启动方式，若是则执行202a，若否则执行202b。

通常情况应用程序的自启动可以为分开机启动与后台启动，开机启动是伴随终端开机时候就自动开启，用户可以通过自启动选项进行设置，后台启动是通过终端环节变化启动程序的行为，例如当用户打开微博应用程序时会触发其他应用程序的启动。

其中，界面启动方式为通过Activity组件启动应用程序，每个界面都是一个Activity组件，通过Activity组件提供的可视化界面可以实现与用户的交互，例如，用户通过界面的提示信息可以选择是否授权应用程序，通过点击界面提供的图片能够实现图片的旋转等动作。

202a、若所述应用程序的启动方式是界面启动模式，根据用户操作的行为数据启动所述应用程序。

由于界面启动方式的应用程序为按照与用户交互产生的操作数据进行启动的方式，因此，若所述应用程序的启动方式是界面启动模式，则说明该启动方式符合用户意愿，不必进行启动拦截，进一步根据用户操作的行为数据启动应用程序，如用户选择授权的行为数据或者用户点击照片的行为数据，本发明实施例中不做限定。

相应的，与步骤202a对应的有步骤202b、若所述应用程序的启动方式不是界面启动方式，通过在framework层调用检测函数来获取所述应用程序对应的自启动模式。

需要说明的是，若应用程序的启动方式不是界面启动方式，则说明并非是用户操作启动的应用程序，而是通过后台启动的应用程序，为了不影响用户的正常操作，本发明实施例通过在framework层调用检测函数来获取应用程序对应的自启动模式，从而基于不同的自启动模式判断是否允许该应用程序的自启动。

其中，framework层为安卓系统开发人员提供服务和交互接口，通过调用framework层的检测函数能够获取应用程序的自启动模式，目前常用改的启动模式有广播Broadcast Receiver启动模式、服务Srvice启动模式、接口Content Provider启动模式等，本发明实施例对应用程序的自启动模式不进行限定。

203b、当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略。

对于本发明实施例，当应用程序对应的自启动模式为鉴权启动模式时，根据应用程序对应的自启动模式配置与应用程序相应的应用处理策略可以包括：首先通过调用服务接口判断应用程序是否有自启权限，如调用应用程序安装包的包名，即ApsManagerService服务的接口isInBlackList来判断应程序是否具有自启权限，具体可以用于通过调用接口识别应用程序的标识信息来判断应用程序是否具有自启权限，这里的标识信息可以为应用程序的pid和应用程序的uid，如果是则不进行拦截，否则获取广播启动模式的消息传递机制，进一步判断消息传递机制是否符合预设匹配条件，这里的预设匹配条件分别为行为匹配条件、类名全匹配条件以及行为前缀匹配条件，如果符合则不进行拦截，否则判断应用程序是否为系统应用程序，如果是则不进行拦截，否则判断应用程序是否处于运行状态，如果是则说明应用程序当前已经被后台开启，不进行拦截，否则判断应用程序的调用者以及应用程序的包名是否一致，如果一致则不进行拦截，否则判断应用程序是否为核心应用程序，如果是则不进行拦截，否则禁止启动应用程序。

需要说明的是，鉴权启动模式在添加账号时触发应用程序自启动。具体拦截逻辑代码在AccountManagerService.java文件的函数addAccountAsUs er、addAccount、checkoutBlocking中getContentProviderImpl函数中实现，具体流程如图3所示。

204b、根据所述应用处理策略对所述应用程序的自启动请求进行处理。

本发明实施例当应用程序对应的启动模式为鉴权启动模式时，通过配置与鉴权启动模式对应的应用处理策略，保证了一些非核心进程无需用户手动参与设置便可启动或者禁止，例如对应用户经常使用的应用程序设置为启动，用户不经常那个使用或者占用系统内存过大的应用程序设置为禁止启动，提高了应用程序自启动的灵活性。

205b、按照预设时间间隔统计所述应用程序自启动的处理记录，将所述处理记录存放至缓存文件中。

其中，应用程序自启动的处理记录可以包括但不局限于应用程序自启动情况，具体包括启动的次数，通过不同启动模式实现自启动的次数，以及被其他应用程序唤醒启动的次数，还可以详细的记录被哪些应用程序唤醒启动，以及唤醒启动的次数、时间等。

需要说明的是，本发明实施例对上述预设时间间隔不进行限定，优选为1天，通常情况以天为单位来展示应用程序每天的处理记录，如每天唤醒应用程序的情况以及每天被其他应用程序唤醒的情况。

相应的，本发明实施例中的处理记录还可以包括但不局限于应用程序拦截情况，具体包括拦截的次数，通过不同启动模式实现拦截的次数，以及被其他应用程序唤醒拦截的次数，还可以详细的记录被哪些应用程序唤醒拦截，以及唤醒拦截的次数、时间等。

本发明实施例通过按照预设时间间隔统计应用程序自启动的处理记录，将所述处理记录存放至缓存文件中，从而使得应用程序的启动情况以及家族应用程序的关系一目了然，以便用户可以根据自己的实际需求来决定是否更改应用程序的启动情况。

206b、当所述缓存文件中的处理记录大于预设阈值时，将所述处理记录更新至预置数据库中。

由于缓存文件在系统运行过程中会占用系统内存，本发明实施例在缓存文件中的处理记录过多的时候为处理记录设置一个预设预置，例如，当缓存文件中的处理记录大于20条时，则将处理记录进行更新，本发明实施例对该预设预置的大小在此不进行限定，可根据系统实际运行情况进行设置，为了不影响系统运行速率，进一步可以将处理记录更新配置中心的数据库中的表格里，保证了系统运行的稳定性。

本发明提供的另一种应用程序自启动的处理方法，对于安装在手机中的应用程序，当应用程序对应的启动模式为鉴权启动模式时，通过配置与鉴权启动模式对应的应用处理策略，能够从底层有效的管理应用自启动；通过统计应用程序的处理记录，以便在不影响用户正常使用的基础上，使得用户能够根据处理记录来设置应用程序自启动，从而提高应用程序自启动处理方式的灵活性。

进一步地，作为图1所述方法的具体实现，本发明实施例提供了一种应用程序自启动的处理装置，如图4所示，所述装置包括：获取单元31、配置单元32、处理单元33。

获取单元31，可以用于当接收到应用程序的自启动请求时，获取所述应用程序对应的自启动模式；获取单元31为一种应用程序自启动的处理装置中用于获取应用程序自启动的主要功能模块，具体可以根据应用程序不同的触发模式进行获取。

配置单元32，可以用于当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略；配置单元32为一种应用程序自启动的处理装置用于为鉴权启动模式的应用程序配置对应的应用处理策略的主要功能模块。

处理单元33，可以用于根据所述应用处理策略对所述应用程序的自启动请求进行处理，处理单元33为一种应用程序自启动的处理装置中用于设置应用程序开启或者拦截的主要功能模块，对于用户不期望启动的应用程序设置为拦截启动，对于用户经常使用的应用程序设置为自启动。

本发明提供的一种应用程序自启动的处理装置，与现有的禁止应用程序自启动的技术是在系统应用层实现的，无法从底层彻底拦截应用程序相比，本发明通过获取所述应用程序对应的自启动模式，然后当应用程序对应的自启动模式为鉴权启动模式时，配置与鉴权启动模式相应的应用处理策略，在不影响用户正常使用的基础上，对于用户允许自启动的应用程序可以启动，对于用户不允许自启动的应用程序，根据应用处理策略对应用程序的自启动请求进行处理，能够从底层有效的处理应用程序的自启动，对应用程序进行有效的拦截，从而降低了在应用程序自启动处理不及时给用户带来的隐私以及安全方面的风险。

进一步地，作为图2所述方法的具体实现，本发明实施例提供了另一种应用程序自启动的处理装置，如图5所示，所述装置包括：判断单元41、获取单元42、配置单元43、处理单元44、统计单元45、更新单元46。

获取单元42，可以用于接收应用程序的自启动请求，获取所述应用程序对应的自启动模式；获取单元42为一种应用程序自启动的处理装置中用于获取应用程序自启动的主要功能模块，具体可以根据应用程序不同的触发模式进行获取；

配置单元43，可以用于当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略；配置单元43为一种应用程序自启动的处理装置用于为鉴权启动模式的应用程序配置对应的应用处理策略的主要功能模块；

处理单元44，可以用于根据所述应用处理策略对所述应用程序进行处理，处理单元44为一种应用程序自启动的处理装置中用于设置应用程序开启或者拦截的主要功能模块，对于用户不期望启动的应用程序设置为拦截启动，对于用户经常使用的应用程序设置为自启动。

进一步地，为了方便用户可以根据自己的实际需求来决定是否更改应用程序的启动情况，所述装置还包括：

判断单元41，可以用于判断所述应用程序的启动方式是否为界面启动方式，判断单元41为一种应用程序自启动的处理装置中用于判断应用程序是否通过用户界面的方式启动的主要功能模块，其中，界面启动方式为通过Activity组件启动应用程序；

所述判断单元41，具体可以用于若所述应用程序的启动方式是界面启动方式，则根据用户操作的行为数据启动所述应用程序，其中，用户操作的行为数据可以包括但不局限于用户选择授权的行为数据或者用户点击照片的行为数据；

所述判断单元41，具体还可以用于若所述应用程序的启动方式不是界面启动方式，获取所述应用程序对应的自启动模式。

具体地，为了获取不同应用程序的自启动模式，所述获取单元42具体可以用于通过在framework层调用检测函数来获取所述应用程序对应的自启动模式。

当所述应用程序对应的自启动模式为鉴权启动模式时，如图6所示，所述配置单元43包括：

第一判断模块431，可以用于通过调用服务接口判断所述应用程序是否有自启权限；

所述第一判断模块431，具体可以用于若通过调用服务接口判断所述应用程序有自启权限，则启动所述应用程序；

获取模块432，可以用于若通过调用服务接口判断所述应用程序没有自启权限，获取广播启动模式的消息传递机制；

第二判断模块433，可以用于判断所述消息传递机制是否符合预设匹配条件；

所述第二判断模块433，具体可以用于若所述消息传递机制符合预设匹配条件，则启动所述应用程序；

第三判断模块434，可以用于若所述消息传递机制不符合预设匹配条件，判断所述应用程序是否为系统应用；

所述第三判断模块434，具体可以用于若所述应用程序是系统应用，则启动所述应用程序；

第四判断模块435，可以用于若所述应用程序不是系统应用，判断所述应用程序是否处于运行状态；

所述第四判断模块435，具体可以用于若所述应用程序处于运行状态，则启动所述应用程序；

第五判断模块436，可以用于若所述应用程序不是处于运行状态，判断所述应用程序的调用者以及所述应用程序的包名是否一致；

所述第五判断模块436，具体可以用于若所述应用程序的调用者以及所述应用程序的包名一致，则启动所述应用程序；

第六判断模块437，可以用于若所述应用程序的调用者以及所述应用程序的包名不一致，判断所述应用程序是否为核心应用；

所述第六判断模块437，具体可以用于若所述应用程序是核心应用，则启动所述应用程序；

所述第六判断模块437，具体还可以用于若所述应用程序不是核心应用，禁止启动所述应用程序。

进一步地，所述第一判断模块431，具体可以用于通过调用接口识别所述应用程序的标识信息来判断所述应用程序是否具有自启权限，这里的标识信息可以为应用程序的pid和应用程序的uid。

进一步地，为了方便用户可以根据自己的实际需求来决定是否更改应用程序的启动情况，所述装置还包括：

统计单元45，用于按照预设时间间隔统计所述应用程序自启动的处理记录，将所述处理记录存放至缓存文件中，统计单元45为一种应用程序自启动的处理装置中用于记录应用程序自启动处理记录的主要功能模块，其中，应用程序自启动的处理记录可以包括但不局限于应用程序自启动情况，具体包括启动的次数，通过不同启动模式实现自启动的次数，以及被其他应用程序唤醒启动的次数，还可以详细的记录被哪些应用程序唤醒启动，以及唤醒启动的次数、时间等。

进一步地，由于缓存文件在系统运行过程中会占用系统内存，为了不影响系统运行速率，所述装置还包括：

更新单元46，可以用于当所述缓存文件中的处理记录大于预设阈值时，将所述处理记录更新至预置数据库中，更新单元46为一种应用程序自启动的处理装置中用于更新应用程序自启动处理记录的主要功能模块。

本发明提供的另一种应用程序自启动的处理装置，对于安装在手机中的应用程序，当应用程序对应的启动模式为鉴权启动模式时，通过配置与鉴权启动模式对应的应用处理策略，能够从底层有效的管理应用自启动；通过统计应用程序的处理记录，以便在不影响用户正常使用的基础上，使得用户能够根据处理记录来设置应用程序自启动，从而提高应用程序自启动处理方式的灵活性。

本发明实施例提供了一种移动终端，如图7所示，包括一个或多个处理器(processor)51、通信接口(Communications Interface)52、存储器(memory)53和总线54，其中，处理器51、通信接口52、存储器53通过总线54完成相互间的通信。通信接口52可以用于获取模块、扩展模块与访问模块之间的信息传输。处理器51可以调用存储器53中的逻辑指令，使得所述装置能够执行上述任意实施例中的图像显示方法。

此外，上述的存储器53中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本发明提供的一种移动终端，与现有的禁止应用程序自启动的技术是在系统应用层实现的，无法从底层彻底拦截应用程序相比，本发明通过获取所述应用程序对应的自启动模式，然后当应用程序对应的自启动模式为鉴权启动模式时，配置与服务启动程序相应的应用处理策略，在不影响用户正常使用的基础上，对于用户允许自启动的应用程序可以启动，对于用户不允许自启动的应用程序，根据应用处理策略对应用程序的自启动请求进行处理，能够从底层有效的处理应用程序的自启动，对应用程序进行有效的拦截，从而降低了在应用程序自启动处理不及时给用户带来的隐私以及安全方面的风险。

本发明公开了A1、一种应用程序自启动的处理方法，包括：

接收应用程序的自启动请求，获取应用程序对应的自启动模式；

当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略；

根据所述应用处理策略对所述应用程序的自启动请求进行处理。

A2、如A1所述的方法，所述配置与所述鉴权启动模式对应的应用处理策略包括：

通过调用服务接口判断所述应用程序是否有自启权限；

若是，则启动所述应用程序，否则，获取广播启动模式的消息传递机制；

判断所述消息传递机制是否符合预设匹配条件；

若是，则启动所述应用程序，否则，判断所述应用程序是否为系统应用；

若是，则启动所述应用程序，否则，判断所述应用程序是否处于运行状态；

若是，则启动所述应用程序，否则，判断所述应用程序的调用者以及所述应用程序的包名是否一致；

若是，则启动所述应用程序，判断所述应用程序是否为核心应用；

若是，则启动所述应用程序，否则，禁止启动所述应用程序。

A3、如A2所述的方法，所述通过调用服务接口判断所述应用程序是否有自启权限包括：

通过调用接口识别所述应用程序的标识信息来判断所述应用程序是否具有自启权限。

A4、如A2所述的方法，所述预设匹配条件包括行为匹配条件、类名全匹配条件以及行为前缀匹配条件。

A5、如A1-A4中任一项所述的方法，所述获取应用程序对应的自启动模式包括：

通过在framework层调用检测函数来获取所述应用程序对应的自启动模式。

A6、如A5所述的方法，在所述通过在framework层调用检测函数来获取所述应用程序对应的自启动模式之前，所述方法还包括：

判断所述应用程序的启动方式是否为界面启动方式；

若是，则根据用户操作的行为数据启动所述应用程序，否则获取所述应用程序对应的自启动模式。

A7、如A6所述的方法，所述方法还包括：

按照预设时间间隔统计所述应用程序自启动的处理记录，将所述处理记录存放至缓存文件中。

A8、如A7所述的方法，所述方法还包括：

当所述缓存文件中的处理记录大于预设阈值时，将所述处理记录更新至预置数据库中。

B9、一种应用程序自启动的处理装置，包括：

获取单元，用于接收应用程序的自启动请求，获取应用程序对应的自启动模式；

配置单元，用于当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略；

处理单元，用于根据所述应用处理策略对所述应用程序的自启动请求进行处理。

B10、如B9所述的装置，所述配置单元包括：

第一判断模块，用于通过调用服务接口判断所述应用程序是否有自启权限；

所述第一判断模块，具体用于若通过调用服务接口判断所述应用程序有自启权限，则启动所述应用程序；

获取模块，用于若通过调用服务接口判断所述应用程序没有自启权限，获取广播启动模式的消息传递机制；

第二判断模块，用于判断所述消息传递机制是否符合预设匹配条件；

所述第二判断模块，具体用于若所述消息传递机制符合预设匹配条件，则启动所述应用程序；

第三判断模块，用于若所述消息传递机制不符合预设匹配条件，判断所述应用程序是否为系统应用；

所述第三判断模块，具体用于若所述应用程序是系统应用，则启动所述应用程序；

第四判断模块，用于若所述应用程序不是系统应用，判断所述应用程序是否处于运行状态；

所述第四判断模块，具体用于若所述应用程序处于运行状态，则启动所述应用程序；

第五判断模块，用于若所述应用程序不是处于运行状态，判断所述应用程序的调用者以及所述应用程序的包名是否一致；

所述第五判断模块，具体用于若所述应用程序的调用者以及所述应用程序的包名一致，则启动所述应用程序；

第六判断模块，用于若所述应用程序的调用者以及所述应用程序的包名不一致，判断所述应用程序是否为核心应用；

所述第六判断模块，具体用于若所述应用程序是核心应用，则启动所述应用程序；

所述第六判断模块，具体还用于若所述应用程序不是核心应用，禁止启动所述应用程序。

B11、如B10所述的装置，

所述第一判断模块，具体用于通过调用接口识别所述应用程序的标识信息来判断所述应用程序是否具有自启权限。

B12、如B10所述的装置，所述预设匹配条件包括行为匹配条件、类名全匹配条件以及行为前缀匹配条件。

B13、如B9-B12中任一项所述的装置，

所述获取单元，具体用于通过在framework层调用检测函数来获取所述应用程序对应的自启动模式。

B14、如B13所述的装置，所述装置还包括：

判断单元，用于判断所述应用程序的启动方式是否为界面启动方式；

所述判断单元，具体用于若所述应用程序的启动方式是界面启动方式，则根据用户操作的行为数据启动所述应用程序；

所述判断单元，具体还用于若所述应用程序的启动方式不是界面启动方式，获取所述应用程序对应的自启动模式。

B15、如B14所述的装置，所述装置还包括：

统计单元，用于按照预设时间间隔统计所述应用程序自启动的处理记录，将所述处理记录存放至缓存文件中。

B16、如B15所述的装置，所述装置还包括：

更新单元，用于当所述缓存文件中的处理记录大于预设阈值时，将所述处理记录更新至预置数据库中。

C17、一种移动终端，包括处理器和存储器：

所述存储器用于存储执行A1至A8中任一项所述方法的程序；

所述处理器被配置为用于执行所述存储器中存储的程序。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

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

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的定位系统性能的优化方法及装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (15)

1.一种应用程序自启动的处理方法，其特征在于，包括：

接收应用程序的自启动请求，获取应用程序对应的自启动模式；

当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略；

根据所述应用处理策略对所述应用程序的自启动请求进行处理；

其中，所述配置与所述鉴权启动模式对应的应用处理策略包括：

通过调用服务接口判断所述应用程序是否有自启权限；

若是，则启动所述应用程序，否则，获取广播启动模式的消息传递机制；

判断所述消息传递机制是否符合预设匹配条件；

若判断出所述消息传递机制符合预设匹配条件，则启动所述应用程序，否则，判断所述应用程序是否为系统应用；

若判断出所述应用程序是系统应用，则启动所述应用程序，否则，判断所述应用程序是否处于运行状态；

若判断出所述应用程序处于运行状态，则启动所述应用程序，否则，判断所述应用程序的调用者以及所述应用程序的包名是否一致；

若判断出所述应用程序的调用者以及所述应用程序的包名一致，则启动所述应用程序，否则，判断所述应用程序是否为核心应用；

若判断出所述应用程序为核心应用，则启动所述应用程序，否则，禁止启动所述应用程序。

2.根据权利要求1所述的方法，其特征在于，所述通过调用服务接口判断所述应用程序是否有自启权限包括：

通过调用接口识别所述应用程序的标识信息来判断所述应用程序是否具有自启权限。

3.根据权利要求1所述的方法，其特征在于，所述预设匹配条件包括行为匹配条件、类名全匹配条件以及行为前缀匹配条件。

4.根据权利要求1-3中任一项所述的方法，其特征在于，所述获取应用程序对应的自启动模式包括：

通过在framework层调用检测函数来获取所述应用程序对应的自启动模式。

5.根据权利要求4所述的方法，其特征在于，在所述通过在framework层调用检测函数来获取所述应用程序对应的自启动模式之前，所述方法还包括：

判断所述应用程序的启动方式是否为界面启动方式；

若是，则根据用户操作的行为数据启动所述应用程序，否则获取所述应用程序对应的自启动模式。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

按照预设时间间隔统计所述应用程序自启动的处理记录，将所述处理记录存放至缓存文件中。

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

当所述缓存文件中的处理记录大于预设阈值时，将所述处理记录更新至预置数据库中。

8.一种应用程序自启动的处理装置，其特征在于，包括：

获取单元，用于接收应用程序的自启动请求，获取应用程序对应的自启动模式；

配置单元，用于当应用程序对应的自启动模式为鉴权启动模式时，配置与所述鉴权启动模式对应的应用处理策略；

处理单元，用于根据所述应用处理策略对所述应用程序的自启动请求进行处理；

其中，所述配置单元包括：

第一判断模块，用于通过调用服务接口判断所述应用程序是否有自启权限；

所述第一判断模块，具体用于若通过调用服务接口判断所述应用程序有自启权限，则启动所述应用程序；

获取模块，用于若通过调用服务接口判断所述应用程序没有自启权限，获取广播启动模式的消息传递机制；

第二判断模块，用于判断所述获取模块获取的所述消息传递机制是否符合预设匹配条件；

所述第二判断模块，具体用于若判断出所述消息传递机制符合预设匹配条件，则启动所述应用程序；

第三判断模块，用于若所述第二判断模块判断出所述消息传递机制不符合预设匹配条件，判断所述应用程序是否为系统应用；

所述第三判断模块，具体用于判断出若所述应用程序是系统应用，则启动所述应用程序；

第四判断模块，用于若所述第三判断模块判断出所述应用程序不是系统应用，判断所述应用程序是否处于运行状态；

所述第四判断模块，具体用于若判断出所述应用程序处于运行状态，则启动所述应用程序；

第五判断模块，用于若所述第四判断模块判断出所述应用程序不是处于运行状态，判断所述应用程序的调用者以及所述应用程序的包名是否一致；

所述第五判断模块，具体用于若判断出所述应用程序的调用者以及所述应用程序的包名一致，则启动所述应用程序；

第六判断模块，用于若所述第五判断模块判断出所述应用程序的调用者以及所述应用程序的包名不一致，判断所述应用程序是否为核心应用；

所述第六判断模块，具体用于若判断出所述应用程序是核心应用，则启动所述应用程序；

所述第六判断模块，具体还用于若判断出所述应用程序不是核心应用，禁止启动所述应用程序。

9.根据权利要求8所述的装置，其特征在于，

所述第一判断模块，具体用于通过调用接口识别所述应用程序的标识信息来判断所述应用程序是否具有自启权限。

10.根据权利要求8所述的装置，其特征在于，所述预设匹配条件包括行为匹配条件、类名全匹配条件以及行为前缀匹配条件。

11.根据权利要求8-10中任一项所述的装置，其特征在于，

所述获取单元，具体用于通过在framework层调用检测函数来获取所述应用程序对应的自启动模式。

12.根据权利要求11所述的装置，其特征在于，所述装置还包括：

判断单元，用于判断所述应用程序的启动方式是否为界面启动方式；

所述判断单元，具体用于若所述应用程序的启动方式是界面启动方式，则根据用户操作的行为数据启动所述应用程序；

所述判断单元，具体还用于若所述应用程序的启动方式不是界面启动方式，获取所述应用程序对应的自启动模式。

13.根据权利要求12所述的装置，其特征在于，所述装置还包括：

统计单元，用于按照预设时间间隔统计所述应用程序自启动的处理记录，将所述处理记录存放至缓存文件中。

14.根据权利要求13所述的装置，其特征在于，所述装置还包括：

更新单元，用于当所述缓存文件中的处理记录大于预设阈值时，将所述处理记录更新至预置数据库中。

15.一种移动终端，其特征在于，包括处理器和存储器：

所述存储器用于存储执行权利要求1至8中任一项所述方法的程序；

所述处理器被配置为用于执行所述存储器中存储的程序。