一种应用程序权限管理的方法和装置

1.一种应用程序权限管理的方法，其特征在于，包括：
接收通过广播或服务或内容提供者方式对应用程序的自启动请求；
在接收到通过广播或服务方式对应用程序的自启动请求后，从本地策略数据库中检索获得与应用程序的包标识对应的拦截策略，通过远程策略接口向云端服务器发送请求并获得反馈的与应用程序的包标识对应的拦截策略，将获得的拦截策略存储在应用程序授权权限列表中；
根据所述自启动请求中携带的所述应用程序的包标识判断是否拦截通过广播或服务方式对所述应用程序的自启动请求，如果所述应用程序的包标识与应用程序授权权限列表中存储的拦截策略一致，则拦截通过广播或服务方式对所述应用程序的自启动请求；
在接收到通过内容提供者方式对应用程序的自启动请求后，记录所述自启动请求、内容提供者标识以及应用程序的包标识；
将所记录的自启动请求、内容提供者标识以及应用程序的包标识反馈给用户；
向用户界面弹窗告警，接收用户指令以获得处理策略。
2.根据权利要求1所述的应用程序权限管理的方法，其特征在于，所述方法还包括：
判断所述应用程序是否为系统应用程序；
如为系统应用程序，并且在设定时间内所述应用程序自启动的次数达到或超过设定门限值，则不拦截对所述应用程序的自启动请求。
3.根据权利要求1所述的应用程序权限管理的方法，其特征在于，所述拦截策略包括基于应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是否拦截。
4.根据权利要求3所述的应用程序权限管理的方法，其特征在于，云端服务器为各应用程序设置的安全级别包括黑、灰和白三个级别，分别对应禁止自启、有用户选择是否自启和直接自启。
5.根据权利要求1所述的应用程序权限管理的方法，其特征在于，所述方法还包括：
获取移动终端中已安装程序的程序列表；
针对程序列表中的每个程序，在本地的省电数据库中查找是否存储有该程序的省电策略；
统计具有省电策略的各程序的耗电信息，并根据耗电信息对各程序进行排序；
当有耗电量超过设定耗电级别的应用程序请求自启动时，触发拦截过程。
6.一种应用程序权限管理的装置，其特征在于，包括：
自启动请求接收单元，用于接收通过广播或服务或内容提供者方式对应用程序的自启动请求；
策略获取单元，用于在接收到通过广播或服务方式对应用程序的自启动请求后，从本地策略数据库中检索获得与应用程序的包标识对应的拦截策略，通过远程策略接口向云端服务器发送请求并获得反馈的与应用程序的包标识对应的拦截策略，将获得的拦截策略存储在应用程序授权权限列表中；
拦截处理单元，用于根据所述自启动请求中携带的所述应用程序的包标识判断是否拦截通过广播或服务方式对所述应用程序的自启动请求，如果所述应用程序的包标识与应用程序授权权限列表中存储的拦截策略一致，则拦截通过广播或服务方式对所述应用程序的自启动请求；
日志记录单元，用于在接收到通过内容提供者方式对应用程序的自启动请求后，记录所述自启动请求、内容提供者标识以及应用程序的包标识；
日志反馈单元，用于将所记录的自启动请求、内容提供者标识以及应用程序的包标识反馈给用户；
交互单元，用于向用户界面弹窗告警，接收用户指令以获得处理策略。
7.根据权利要求6所述的应用程序权限管理的装置，其特征在于，所述交互单元，被注册为系统服务，外壳应用通过其内建的交互接口与该交互单元通信，借助该交互单元向用户界面弹窗实现人机交互。
8.根据权利要求6所述的应用程序权限管理的装置，其特征在于，所述装置还包括：
应用类型判断单元，用于判断所述应用程序是否为系统应用程序，如为系统应用程序，并且在设定时间内所述应用程序自启动的次数达到或超过设定门限值，则不拦截对所述应用程序的自启动请求。
9.根据权利要求6所述的应用程序权限管理的装置，其特征在于，所述拦截策略包括基于应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是否拦截。
10.根据权利要求9所述的应用程序权限管理的装置，其特征在于，云端服务器为各应用程序设置的安全级别包括黑、灰和白三个级别，分别对应禁止自启、有用户选择是否自启和直接自启。
11.根据权利要求6所述的应用程序权限管理的装置，其特征在于，所述装置还包括：
耗电统计单元，用于获取移动终端中已安装程序的程序列表，针对程序列表中的每个程序，在本地的省电数据库中查找是否存储有该程序的省电策略，统计具有省电策略的各程序的耗电信息，并根据耗电信息对各程序进行排序，当有耗电量超过设定耗电级别的应用程序请求自启动时，触发拦截过程。
12.一种移动终端，其特征在于，包括广播接收机组件、服务组件、内容提供者组件以及权利要求7至11中任一项所述的应用程序权限管理的装置。
13.一种应用程序权限管理的系统，其特征在于，包括云端服务器和权利要求12所述的移动终端。

一种应用程序权限管理的方法和装置\n技术领域\n[0001] 本发明涉及网络安全技术领域，具体而言，涉及一种应用程序权限管理的方法、装置、系统及移动终端。\n背景技术\n[0002] 目前，终端内各软件自启动的方式主要包括三种：第一种是通过在系统中注册一些广播(Broadcast)，通过这些广播来调起指定应用程序的方式；第二种是通过服务(Service)来调起指定应用程序的方式；第三种是通过内容提供者(Content Provider)来调起指定应用程序的方式。\n[0003] 通过上述三种方式自启动的应用程序并非均为系统或其他应用程序运行所必须的条件，终端内某些应用程序的运行并不依赖于另外一些应用程序的运行，而且终端内的某些自启动应用程序也并非用户所期望启动的，因此，某些对其他应用程序以及对用户来说无用的应用程序的自启动不仅会占用多余的系统资源、降低系统的运行速度，而且还会耗费更多的电量。\n[0004] 针对上述问题，现有的禁止终端内应用程序自启动的方法是通过直接调用系统API中的PM disable函数来禁止广播方式对指定应用程序的自启动。目前，调用该PM disable函数的方法无法禁止通过Service和Content Provider方式自启动的应用程序。\n发明内容\n[0005] 有鉴于此，本发明要解决的一个技术问题是提供一种应用程序权限管理的方法，以尽量减少某些无用的自启动应用程序对终端资源的占用。\n[0006] 一种应用程序权限管理的方法，包括：\n[0007] 接收通过广播或服务方式对应用程序的自启动请求；\n[0008] 从本地策略数据库中检索获得与应用程序的包标识对应的拦截策略，通过远程策略接口向云端服务器发送请求并获得反馈的与应用程序的包标识对应的拦截策略，将获得的拦截策略存储在应用程序授权权限列表中；\n[0009] 根据所述自启动请求中携带的所述应用程序的包标识判断是否拦截通过广播或服务方式对所述应用程序的自启动请求，如果所述应用程序的包标识与应用程序授权权限列表中存储的拦截策略一致，则拦截通过广播或服务方式对所述应用程序的自启动请求。\n[0010] 根据本发明的方法的一个实施例，进一步地，所述方法还包括：\n[0011] 判断所述应用程序是否为系统应用程序；\n[0012] 如为系统应用程序，并且在设定时间内所述应用程序自启动的次数达到或超过设定门限值，则不拦截对所述应用程序的自启动请求。\n[0013] 根据本发明的方法的一个实施例，进一步地，所述方法还包括：\n[0014] 在接收到通过内容提供者方式对应用程序的自启动请求后，记录所述自启动请求、内容提供者标识以及应用程序的包标识；\n[0015] 将所记录的自启动请求、内容提供者标识以及应用程序的包标识反馈给用户；\n[0016] 向用户界面弹窗告警，接收用户指令以获得处理策略。\n[0017] 根据本发明的方法的一个实施例，进一步地，所述拦截策略包括基于应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是否拦截。\n[0018] 根据本发明的方法的一个实施例，进一步地，云端服务器为各应用程序设置的安全级别包括黑、灰和白三个级别，分别对应禁止、由用户选择以及直接执行。\n[0019] 根据本发明的方法的一个实施例，进一步地，所述方法还包括：\n[0020] 获取移动终端中已安装程序的程序列表；\n[0021] 针对程序列表中的每个程序，在本地的省电数据库中查找是否存储有该程序的省电策略；\n[0022] 统计具有省电策略的各程序的耗电信息，并根据耗电信息对各程序进行排序；\n[0023] 当有耗电量超过设定耗电级别的应用程序请求自启动时，触发拦截过程。\n[0024] 本发明要解决的另一个技术问题是提供一种应用程序权限管理的装置，以尽量减少某些无用的自启动应用程序对终端资源的占用。\n[0025] 一种应用程序权限管理的装置，包括：\n[0026] 自启动请求接收单元，用于接收通过广播或服务方式对应用程序的自启动请求；\n[0027] 策略获取单元，用于从本地策略数据库中检索获得与应用程序的包标识对应的拦截策略，通过远程策略接口向云端服务器发送请求并获得反馈的与应用程序的包标识对应的拦截策略，将获得的拦截策略存储在应用程序授权权限列表中；\n[0028] 拦截处理单元，用于根据所述自启动请求中携带的所述应用程序的包标识判断是否拦截通过广播或服务方式对所述应用程序的自启动请求，如果所述应用程序的包标识与应用程序授权权限列表中存储的拦截策略一致，则拦截通过广播或服务方式对所述应用程序的自启动请求。\n[0029] 根据本发明的装置的一个实施例，进一步地，所述装置还包括：\n[0030] 交互单元，被注册为系统服务，外壳应用通过其内建的交互接口与该交互单元通信，借助该交互单元向用户界面弹窗实现人机交互。\n[0031] 根据本发明的装置的一个实施例，进一步地，所述装置还包括：\n[0032] 应用类型判断单元，用于判断所述应用程序是否为系统应用程序，如为系统应用程序，并且在设定时间内所述应用程序自启动的次数达到或超过设定门限值，则不拦截对所述应用程序的自启动请求。\n[0033] 根据本发明的装置的一个实施例，进一步地，\n[0034] 所述装置还包括：\n[0035] 日志记录单元，用于在接收到通过内容提供者方式对应用程序的自启动请求后，记录所述自启动请求、内容提供者标识以及应用程序的包标识；\n[0036] 日志反馈单元，用于将所记录的自启动请求、内容提供者标识以及应用程序的包标识反馈给用户；\n[0037] 所述交互单元用于向用户界面弹窗告警，接收用户指令以获得处理策略。\n[0038] 根据本发明的装置的一个实施例，进一步地，所述拦截策略包括基于应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是否拦截。\n[0039] 根据本发明的装置的一个实施例，进一步地，云端服务器为各应用程序设置的安全级别包括黑、灰和白三个级别，分别对应禁止、由用户选择以及直接执行。\n[0040] 根据本发明的装置的一个实施例，进一步地，所述装置还包括：\n[0041] 耗电统计单元，用于获取移动终端中已安装程序的程序列表，针对程序列表中的每个程序，在本地的省电数据库中查找是否存储有该程序的省电策略，统计具有省电策略的各程序的耗电信息，并根据耗电信息对各程序进行排序，当有耗电量超过设定耗电级别的应用程序请求自启动时，触发拦截过程。\n[0042] 本发明要解决的又一个技术问题是提供一种移动终端，以尽量减少某些无用的自启动应用程序对终端资源的占用。\n[0043] 一种移动终端，包括：广播接收机组件、服务组件以及前述实施例的应用程序权限管理的装置。\n[0044] 根据本发明的移动终端的一个实施例，进一步地，所述移动终端还包括内容提供者组件。\n[0045] 本发明要解决的又一个技术问题是提供一种应用程序权限管理的系统，以尽量减少某些无用的自启动应用程序对终端资源的占用。\n[0046] 一种应用程序权限管理的系统，包括云端服务器和前述实施例的移动终端。\n[0047] 本发明的应用程序权限管理的方法、装置、系统及移动终端，由于可以根据被调用的应用程序的包标识拦截掉对用户无用的和/或对其他应用程序的启动无任何帮助的应用程序，因此，不仅可以提高终端的运行速度、而且还可以为终端节省电量。\n附图说明\n[0048] 通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：\n[0049] 图1是根据本发明一个实施例的应用程序权限管理的方法的流程示意图。\n[0050] 图2是根据本发明一个实施例的应用程序权限管理的装置的结构示意图。\n[0051] 图3是根据本发明一个实施例的移动终端的结构示意图。\n[0052] 图4是根据本发明另一实施例的移动终端的结构示意图。\n[0053] 图5是根据本发明一个实施例的应用程序权限管理的系统的结构示意图。\n具体实施方式\n[0054] 下面参照附图对本发明进行更全面的描述，其中说明本发明的示例性实施例。下面将结合本发明实施例中的附图对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例都属于本发明保护的范围。\n[0055] Android系统有四大组件：Activity、Service、Broadcast Receiver和Content Provider，这四大组件均可以被ActivityManagerService所管理。在应用程序被自启动时会通过ActivityManagerService执行。\n[0056] 本发明的方法所应用的环境包括可与远程服务器或云端通信的移动终端，该移动终端可以安装有Android操作系统，该系统处于未经ROOT授权或者已经获取ROOT权限的状态。\n[0057] 众所周知，Root权限是指Unix类操作系统(包括Linux、Android)的系统管理员权限，类似于Windows(视窗)系统中的Administrator(管理员)权限；Root权限可以访问和修改用户的移动设备中几乎所有的文件(Android系统文件及用户文件，不包括ROM)。但是，由于目前移动终端系统对于Root权限的管理是非常严格的，通常情况下多数应用或程序都不具备Root权限，因此对于某些需要具备Root权限的操作就无法执行，例如安装或卸载应用等操作；同时，此类操作调用进程每次执行相应操作时都需要向系统申请Root权限，但如果此时其他应用进程正在使用Root权限进行相关操作，则此调用进程的Root权限申请便无法成功；更甚者，如果用户在系统中设置了禁用Root权限的操作，则相关调用进程便无法进行相关操作。\n[0058] 图1是根据本发明一个实施例的应用程序权限管理的方法的流程示意图。\n[0059] 如图1所示，该实施例可以包括以下步骤：\n[0060] 步骤102，接收通过广播或服务方式对应用程序的自启动请求；\n[0061] 步骤104，从本地策略数据库中检索获得与应用程序的包标识对应的拦截策略，通过远程策略接口向云端服务器发送请求并获得反馈的与应用程序的包标识对应的拦截策略，将获得的拦截策略存储在应用程序授权权限列表中；\n[0062] 步骤106，根据自启动请求中携带的应用程序的包标识判断是否拦截通过广播或服务方式对应用程序的自启动请求，如果应用程序的包标识与应用程序授权权限列表中存储的拦截策略一致，则拦截通过广播或服务方式对应用程序的自启动请求，进而禁止了应用程序的自启动。\n[0063] 具体地，在接收到Broadcast  Receiver对应用程序的自启动请求后，ActivityManagerService获悉该自启动请求来自Broadcast Receiver，在执行对应用程序的调用之前，首先根据自启动请求中携带的应用程序的包标识进行判断。例如，可以将接收到的应用程序的包标识与预先存储的应用程序授权权限列表中的包标识进行比较，如果应用程 序授权 权限 列表中 存在与 应 用程序的 包标 识相同的 包标 识 ，则ActivityManagerService拦截通过Broadcast方式对应用程序的调用。\n[0064] 同理，在接收到Service对应用程序的自启动请求后，ActivityManagerService获悉该自启动请求来自Service，在执行对应用程序的调用之前，也先根据自启动请求中携带的应用程序的包标识进行判断。\n[0065] 需要指出的是，在应用程序授权权限列表中可以不区分组件地设置将被拦截的应用程序的黑名单，即，只要应用程序的包标识存在于应用程序授权权限列表中，无论是通过Broadcast方式还是通过Service方式调用均被拦截，这是一种最严格的禁止自启动的方式。此外，还可以按组件类型进行设置，例如，某些应用程序仅禁止通过Broadcast方式自启动，如果该应用程序通过Service方式自启动，则不禁止。同样，某些应用程序仅禁止通过Service方式自启动，如果该应用程序通过Broadcast方式自启动，则不禁止。上述不同的设置方式可以应用于不同的应用场景。\n[0066] 此外，在预先设置的应用程序授权权限列表库中，某些应用程序对应有一应用程序授权权限列表，应用程序授权权限列表以应用程序标识(即，前述的包标识)为标记。在每一应用程序授权权限列表中，存储有用户预先为该应用程序授权的行为权限。如果该列表中没有对应于该应用程序的行为权限，则没有具体权限建议，但用户仍可对所有权限授权或禁止。\n[0067] 应用程序的行为权限在AndroidManifest.xml文件中的声明形式如下：\n[0068] 文件名：AndroidManifest.xml\n[0069] \n[0070] 可以使用Java中的可扩展标记语言(XML，Extensible Markup Language)文件解析器，解析AndroidManifest.xml文件中的权限描述部分，以获取应用程序申请的行为权限列表。当然，也可以使用其他XML解析器，或者，使用其他编程语言，例如，C/C++、python等编程语言开发XML解析器，对AndroidManifest.xml文件进行解析，以获得相应的应用程序所申请的行为权限列表。\n[0071] 其中，AndroidManifest.xml文件是安装包中较为重要的全局配置文件，其负责向系统注册Android系统的四大组件以及向系统申请权限等。在加壳安装包中，将其作为需要加入加壳安装包的重要内部文件进行考虑，以与原安装包完全一致的副本被包含到加壳安装包中。由于加壳安装包中的AndroidManifest.xml文件即为原安装包的同名文件，其包名相同，故加壳安装包在系统中安装运行宿主应用程序之后，以AndroidManifest.xml向系统注册各个组件和申请系统权限，以此便建立了各个组件的入口，使经反射调用的目标应用程序的各个组件均可以被ActivityManagerService调用，而不必为所述各个组件构造ActivityThread和提供相应的LoadedApk对象，省去运行上下文环境的程序实现环节。同理，反射调用所导致的PackageManagerService对各大组件是否合法注册的问题，也将因AndroidManifest.xml的注册而被克服。\n[0072] 在该实施例中，由于可以根据被调用的应用程序的包标识拦截掉对用户无用的和/或对其他应用程序的启动无任何帮助的应用程序，因此，不仅可以提高终端的运行速度、而且还可以为终端节省电量。\n[0073] 在一个实例中，可以调用AS的cleanUpRemovedTaskLocked函数，以获取当前所有的进程并且根据拦截策略遍历判断可疑进程的UID以及进程包列表中包含请求自启动的应用程序的包名的进程，将该进程加入可杀进程列表。\n[0074] 进一步地，由于应用程序至少包括系统应用程序和用户应用程序，针对系统应用程序，如果通过Broadcast方式或Service方式自启动时，可以按如下方式处理：\n[0075] 判断应用程序是否为系统应用程序；\n[0076] 如为系统应用程序，并且在设定时间内应用程序自启动的次数达到或超过设定门限值，则不拦截对应用程序的自启动请求。\n[0077] 这样可以防止陷入频繁地杀掉系统应用程序，然后系统应用程序再频繁地自启动这个恶性循环，不仅耗费了大量的系统资源、浪费了电量，而且还降低了终端的运行速度。\n[0078] 在实际应用中，应用程序的自启动方式并不仅限于上述的Broadcast方式和Service方式，还可以通过Content Provider方式实现应用程序的自启动。由于有大量的通过Content Provider方式调用的应用程序，并且Content Provider的数目也非常多，因此，不便于预先在应用程序授权权限列表中设置好针对Content Provider方式的拦截策略。在此情况下，可以将通过Content Provider方式禁止应用程序自启动的权限交给用户，因此，每个用户可以根据自身需求设置个性化的过滤或拦截策略。\n[0079] 具体地，在接收到通过内容提供者方式对应用程序的自启动请求后，记录自启动请求、内容提供者标识以及应用程序的包标识，可以将这些记录信息存储到顽固自启日志中。\n[0080] 即，ActivityManagerService在接收到Content Provider对应用程序的调用请求后，首先判断该调用请求是通过何种方式发起的，如果是通过Content Provider方式发起的，则先对自启动请求的相关信息进行记录，以便于用户根据这些记录的信息确定相应的拦截策略。\n[0081] 进一步地，在ActivityManagerService记录相关信息的同时，可以通过向用户弹出界面的方式将所记录的自启动请求、内容提供者标识以及应用程序的包标识反馈给用户；\n[0082] 向用户界面弹窗告警，在用户接收到这些信息后，根据自身需求输入拦截策略，例如，对某些应用程序的自启动进行拦截、允许某些应用程序的自启动等；\n[0083] 接收用户指令以获得处理策略，例如，对相应的自启动进行拦截或执行对应用程序的自启动。这样就可以把两个应用程序之间的调用关系给切断。其中，应用程序的常见自启动方式包括Bind Service方式或Content Provider方式。\n[0084] 例如，可以通过预先注入到系统服务进程中的拦截模块拦截到应用程序的危险操作信息后，向应用程序发送相应的询问信息；应用程序根据询问信息弹出相应的提示框，并接收用户输入的是否进行相应操作的确认信息后向拦截模块返回；拦截模块根据接收的确认信息，允许或阻断系统服务进程对应用程序的危险操作；这样能够做到对应用程序行为进行有效地拦截，拦截后，暂停相应的操作，并通知用户该操作，只有得到用户的确认信息后才执行相应的操作。\n[0085] 此外，如果用户允许通过Content Provider方式对某个应用程序进行自启动，也可以将该策略存储在应用程序授权权限列表中，一旦接收到通过Content Provider方式对该应用程序的自启动请求，则不再记录且不向用户反馈该信息，而是直接对该应用程序进行自启动。\n[0086] 同样地，如果用户禁止通过Content Provider方式对某个应用程序进行自启动，也可以将该策略存储在应用程序授权权限列表中，一旦接收到通过Content Provider方式对该应用程序的自启动，也不再记录且不向用户反馈该信息，而是直接杀掉对该应用程序自启动的进程。\n[0087] 换句话说，ActivityManagerService将记录那些用户未明确指示是否禁止或允许通过Content Provider方式自启动的应用程序，这样不仅可以提高处理效率，同时还可以提升用户的使用体验，避免频繁地向用户弹出确认窗口。\n[0088] 在上述实施例中，拦截策略可以包括但不限于基于应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是否拦截。\n[0089] 进一步地，云端服务器为各应用程序设置的安全级别包括黑、灰和白三个级别，分别对应禁止安装、由用户选择是否安装以及径行安装。\n[0090] 对于准备或者正在进行安装的应用程序而言，本发明可以通过将自身注册为默认安装器的形式，获取该应用程序的安装广播信息。继而，将这个新装应用程序作为目标应用，将其安装包或签名之类的特征信息通过远程规则库接口发送到云端服务器中，由云端服务器对其做出安全性判断。一种实施例中，云端服务器为应用程序的安全级别设定黑、灰、白三种级别，分别代表不同危险程度，并设定对应的处理规则。例如，黑应用禁止安装，灰应用由用户自行选择，白应用则可径行安装。当然，可以进一步简化为灰、白两种，或者简化为黑、白两种。本领域技术人员熟悉服务器的这种云端控制技术，将在后续进一步概要揭示。无论如何，本发明将从本机远程规则库接口中获得云端服务器有关这些应用的处理规则的反馈，利用反馈结果做出相应的后续处理。具体而言，当针对当前目标应用返回黑应用标识时，可以随即停止该目标应用的安装；当标识为白应用或灰应用时，则可放行安装。出于交互性的考虑，当完成远程判断后，本发明将向用户界面弹窗提醒用户有关判断结果，并显示相应的处理建议，询问用户是否确定对当前新装应用建构主动防御环境，用户从中确定对当前新装目标应用进行主动防御的标识后，即确定了该目标应用。\n[0091] 同理，用户确定该目标应用之后，本发明会将该目标应用的安装包存放至所述的指定目录中。另外，出于本发明后续将为该已确定的目标应用建构主动防御环境的考虑，本发明会立即停止该目标应用的安装，停止安装的操作既可以发生在用户确定该目标应用之前也可以发生在之后。\n[0092] 此外，可以将主防程序驻入到系统中的多个点，以协助实现上述禁止应用程序的自启动。\n[0093] 具体地，可以将未知应用程序安装包或签名之类的特征信息、或请求自启动应用程序的特征信息通过远程规则库接口发送到云端服务器中，由云端服务器对其做出安全性判断。\n[0094] 如前所述，由客户端通过远程规则库接口发送到云端服务器的特征信息，包括：\nAndroid安装包的包名，和/或，版本号，和/或，数字签名，和/或，Android组件receiver的特征，和/或，Android组件service的特征，和/或，Android组件activity的特征，和/或，可执行文件中的指令或字符串，和/或，Android安装包目录下各文件的MD5值(签名)。\n[0095] 实现了本发明的方法或装置的客户端，将指定的特征信息上传到云端服务器，在云端服务器预置的规则库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，云端服务器预置的规则库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；\n[0096] 云端服务器规则库中预置了数千条特征记录，其中，第一条特征记录中列出了某种病毒的Android安装包包名，第二条特征记录中列出了某个正常应用的Android安装包版本号及其数字签名的MD5值，第三条特征记录中列出了某个正常应用的Android安装包包名及其receiver特征，第四条特征记录中列出了某种木马的Android安装包包名、版本号及其ELF文件中的特定字符串，等等。\n[0097] 关于安全等级的标识，即黑，白(安全)或者灰(未知，可疑)三种标识，可以进一步的表示为：\n[0098] 安全：该应用是一个正常的应用，没有任何威胁用户手机安全的行为；\n[0099] 危险：该应用存在安全风险，有可能该应用本身就是恶意软件；也有可能该应用本来是正规公司发布的正常软件，但是因为存在安全漏洞，导致用户的隐私、手机安全受到威胁；\n[0100] 谨慎：该应用是一个正常的应用，但是存在一些问题，例如会让用户不小心被扣费，或者有不友好的广告遭到投诉等；当发现这类应用之后，会提示用户谨慎使用并告知该应用可能的行为，但是由用户自行决定是否清除该应用；\n[0101] 木马：该应用是病毒、木马或者其他恶意软件，此处为了简单统称为木马，但并不表示该应用仅仅是木马。\n[0102] 在本发明方法的另一实施例中，还可以根据应用程序的包名设置省电策略；云端服务器根据设置有省电策略的程序生成省电数据库。云端服务器若接收到新增的程序及该程序的省电策略，则更新到省电数据库中。也就是说，省电数据库中对应记载有程序以及该程序的省电策略。\n[0103] 省电数据库中记载的省电策略可以包括：卸载、禁止自启；省电策略还可以包括：\n结束运行、保持现状或适合长期运行等。\n[0104] 例如，技术人员可以为健康类程序、或时钟天气类程序设置保持现状省电策略；而为账号同步等程序设置禁止自启省电策略。\n[0105] 较佳地，为了移动终端可以获取更有针对性的省电数据库，并减少获取的省电数据库所占用的空间，云端服务器为不同机型的移动终端分别定制省电数据库的一种具体方法包括：多个安装有监控软件的移动终端，若监控软件发现本移动终端中安装了不认识的程序，可以将该程序的程序信息与本移动终端的机型信息一并通过互联网等网络上传到云端的服务器；由专业的技术人员为云端服务器接收的程序设置省电策略，例如根据机型信息model设置省电策略；云端服务器针对每个机型信息，根据该机型信息名下设置有省电策略的程序，生成对应该机型信息的省电数据库。\n[0106] 云端服务器生成并维护省电数据库，移动终端可以从服务器下载省电数据库并存储于本地，用于向用户进行省电建议。\n[0107] 移动终端从服务器下载得到省电数据库的一种具体方法可以是，移动终端将本移动终端的机型信息通过网络向服务器上报；例如，2G内存的联通版华为荣耀3C智能手机，当判断出本手机连通网络后，从预存的系统信息中提取出本手机的型号U30-H10，作为机型信息通过网络向服务器上报。\n[0108] 服务器接收到移动终端上报的机型信息后，从与各机型信息所分别对应的省电数据库中，查找到与接收的机型信息相对应的省电数据库，并通过网络返回到上报机型信息的移动终端。\n[0109] 移动终端接收服务器返回的省电数据库进行存储。\n[0110] 本发明实施例的移动终端基于下载的省电数据库，依照下述流程进行省电建议，具体可以包括如下步骤：\n[0111] 步骤一，获取移动终端中已安装程序的程序列表。\n[0112] 具体地，移动终端从本移动终端的操作系统所记录的系统信息中，获取已安装的程序的程序列表。程序列表可以包括：程序的名称和安装路径；程序列表还可以包括：程序的所占空间大小、当前运行的进程和服务数量，以及累计运行时长等等。\n[0113] 步骤二，针对程序列表中的每个程序，在本地的省电数据库中查找是否存储有该程序的省电策略。\n[0114] 具体地，移动终端针对程序列表中的每个程序，判断是否可以在下载的省电数据库中查找到该程序：若是，则在省电数据库中查找出的该程序的省电策略；否则，不查找该程序的省电策略。\n[0115] 步骤三，统计具有省电策略的各程序的耗电信息，并根据耗电信息对各程序进行排序。\n[0116] 具体地，移动终端对于每个查找出省电策略的程序，检测该程序的耗电信息；根据检测得到的耗电信息，统计出该程序的单位时间耗电量；进而统计出每个查找出省电策略的程序的单位时间耗电量占比；根据统计出的单位时间耗电量占比对各程序进行排序。程序的耗电信息包括：该程序的唤醒次数和运行时间等。\n[0117] 较佳地，移动终端针对每个查找出省电策略的程序，可以根据该程序的单位时间耗电量占比，确定该程序的耗电级别；若判断出存在耗电级别超过设定级别的程序，则提示存在耗电程序，并显示耗电级别超过设定级别的程序的个数。\n[0118] 当有耗电量超过设定级别的程序请求自启动时，可以对这类程序进行拦截，以节省终端的耗电量。\n[0119] 图2是根据本发明一个实施例的应用程序权限管理的装置的结构示意图。\n[0120] 如图2所示，该实施例中的装置20可以包括拦自启动请求接收单元202、策略获取单元204以及拦截处理单元206。其中，\n[0121] 自启动请求接收单元202，用于接收通过广播或服务方式对应用程序的自启动请求；\n[0122] 策略获取单元204，用于从本地策略数据库中检索获得与应用程序的包标识对应的拦截策略，通过远程策略接口向云端服务器发送请求并获得反馈的与应用程序的包标识对应的拦截策略，将获得的拦截策略存储在应用程序授权权限列表中；\n[0123] 拦截处理单元206，用于根据自启动请求中携带的应用程序的包标识判断是否拦截通过广播或服务方式对应用程序的自启动请求，如果应用程序的包标识与应用程序授权权限列表中存储的拦截策略一致，则拦截通过广播或服务方式对应用程序的自启动请求。\n[0124] 在该实施例中，由于可以根据被调用的应用程序的包标识拦截掉对用户无用的和/或对其他应用程序的启动无任何帮助的应用程序，因此，不仅可以提高终端的运行速度、而且还可以为终端节省电量。\n[0125] 进一步地，在本发明装置的另一实施例中，该装置还可以包括：\n[0126] 交互单元，被注册为系统服务，外壳应用通过其内建的交互接口与该交互单元通信，借助该交互单元向用户界面弹窗实现人机交互。\n[0127] 进一步地，在本发明装置的又一实施例中，该装置还可以包括：\n[0128] 应用类型判断单元，用于判断应用程序是否为系统应用程序，如为系统应用程序，并且在设定时间内应用程序自启动的次数达到或超过设定门限值，则不拦截对应用程序的自启动请求。\n[0129] 进一步地，在本发明装置的又一实施例中，该装置还可以包括：\n[0130] 日志记录单元，用于在接收到通过内容提供者方式对应用程序的自启动请求后，记录自启动请求、内容提供者标识以及应用程序的包标识；\n[0131] 日志反馈单元，用于将所记录的自启动请求、内容提供者标识以及应用程序的包标识反馈给用户；\n[0132] 交互单元具体地用于向用户界面弹窗告警，接收用户指令以获得处理策略。\n[0133] 此外，上述实施例中的拦截策略可以包括但不限于基于应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是否拦截。\n[0134] 进一步地，云端服务器为各应用程序设置的安全级别包括黑、灰和白三个级别，分别对应禁止、由用户选择以及直接执行。\n[0135] 在本发明装置的再一实施例中，该装置还可以包括：\n[0136] 耗电统计单元，用于获取移动终端中已安装程序的程序列表，针对程序列表中的每个程序，在本地的省电数据库中查找是否存储有该程序的省电策略，统计具有省电策略的各程序的耗电信息，并根据耗电信息对各程序进行排序，当有耗电量超过设定耗电级别的应用程序请求自启动时，触发拦截过程。\n[0137] 需要指出的是，上述应用程序权限管理的装置可以单独设置或设置在Activity组件内。\n[0138] 图3是根据本发明一个实施例的移动终端的结构示意图。\n[0139] 如图3所示，该实施例中的移动终端30可以包括：广播接收机组件302、服务组件\n304以及应用程序权限管理的装置306。其中，应用程序权限管理的装置306可以通过前述实施例实现。并且，广播接收机组件302和服务组件304分别与应用程序权限管理的装置306交互自启动信息。\n[0140] 图4是根据本发明另一实施例的移动终端的结构示意图。\n[0141] 如图4所示，与图3中的实施例相比，该实施例中的移动终端40还可以包括：内容提供者组件402。其中，内容提供者组件402与应用程序权限管理的装置306交互通过Content Provider方式发起的自启动信息。\n[0142] 图5是根据本发明一个实施例的应用程序权限管理的系统的结构示意图。\n[0143] 如图5所示，该实施例中的系统50可以包括云端服务器502和移动终端504，其中，移动终端504可以通过前述实施例实现。云端服务器502中存储了为各应用程序设置的安全级别，可以包括但不限于黑、灰和白三个级别，这三个级别分别对应禁止、由用户选择以及直接执行。\n[0144] 进一步地，云端服务器502还可以生产、存储并维护省电数据库。\n[0145] 在实际应用中，当同一家产品内部的各应用程序之间进行无用的相互调用时，例如，腾讯系或阿里系内部的产品之间互相调用时，可以利用本发明的方法禁止某些无用的应用程序的自启动，以节省终端的系统资源。同样，本发明也能够阻断对某些应用程序的流氓唤醒。\n[0146] 需要说明的是，本发明已经将HOOK框架做成了服务平台，以挂钩插件的方式为终端配置监控，因此，其加载仅需依赖于相应的配置文件，管理高效且易于实现，对技术人员而言，一些简单的函数调用仅需编写配置文件即可实现挂钩插件的配置，HOOK重入、并发性能高。\n[0147] 采用外壳应用先后实现对程序行为的监控和目标应用的加载，继而借助监控对目标应用的事件行为建立监控，可以实现对Java函数、Native函数的挂钩。\n[0148] 本发明不仅适用于Dalvik模式，也适用于ART模式，功能表现上两者无异，使用者不需适应不同模式编写不同的代码，简化开发工作(小范围内测试Android版本号4.4.2、\n4.4.3、4.4.4)。\n[0149] 经实测，有如下数据佐证本发明的实例的优越性：\n[0150] (1)本发明的开发实例，在16部手机上对107款主流应用软件(如QQ、微信，微博，手机卫士，支付类、多种团购app，各视频播放软件等)进行了稳定性深度测试，均能正常运行。\n[0151] (2)本发明的开发实例，测试涵盖手机Android操作系统版本号从2.3到4.4.3。机型包括nexus4/5、7，三星，小米，华为，联想，索尼，HTC及部分山寨手机，均获得较为优异的表现。\n[0152] 可能以许多方式来实现本发明的方法和系统。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法和系统。用于方法的步骤的上述顺序仅是为了进行说明，本发明的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本发明实施例为记录在记录介质中的程序，这些程序包括用于实现根据本发明的方法的机器可读指令。因而，本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。\n[0153] 本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。