一种应用程序权限管理的方法、装置、系统及移动终端的制作方法
【专利摘要】本发明提供了一种应用程序权限管理的方法、装置、系统及移动终端。其中，该方法包括接收第一应用程序通过服务方式对第二应用程序的自启动请求；获取应用程序授权权限列表；根据所述自启动请求中携带的所述第一应用程序的包标识和所述第二应用程序的包标识判断是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求，如果所述第一应用程序的包标识和所述第二应用程序的包标识与所述应用程序授权权限列表中存储的拦截策略一致，则拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。本发明能够尽量减少某些无用的自启动应用程序对终端资源的占用。
【专利说明】一种应用程序权限管理的方法、装置、系统及移动终端
【技术领域】
[0001]本发明涉及网络安全【技术领域】，具体而言，涉及一种应用程序权限管理的方法、装置、系统及移动终端。
【背景技术】
[0002]目前，终端内各软件自启动的方式主要包括三种:第一种是通过在系统中注册一些广播(Broadcast)，通过这些广播来调起指定应用程序的方式；第二种是通过服务(Service)来调起指定应用程序的方式；第三种是通过内容提供者(Content Provider)来调起指定应用程序的方式。
[0003]通过上述三种方式自启动的应用程序并非均为系统或其他应用程序运行所必须的条件，终端内某些应用程序的运行并不依赖于另外一些应用程序的运行，而且终端内的某些自启动应用程序也并非用户所期望启动的，因此，某些对其他应用程序以及对用户来说无用的应用程序的自启动不仅会占用多余的系统资源、降低系统的运行速度，而且还会耗费更多的电量。
[0004]针对上述问题，现有的禁止终端内应用程序自启动的方法是通过直接调用系统API中的PM disable函数来禁止Broadcast方式对指定应用程序的自启动。目前,调用该PM disable函数的方法无法禁止通过Service方式和Content Provider方式自启动的应用程序。
【发明内容】
[0005]有鉴于此，本发明要解决的一个技术问题是提供一种应用程序权限管理的方法，以尽量减少某些无用的自启动应用程序对终端资源的占用。
[0006]一种应用程序权限管理的方法，包括:
[0007]接收第一应用程序通过服务方式对第二应用程序的自启动请求；
[0008]获取应用程序授权权限列表；
[0009]根据所述自启动请求中携带的所述第一应用程序的包标识和所述第二应用程序的包标识判断是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求，如果所述第一应用程序的包标识和所述第二应用程序的包标识与所述应用程序授权权限列表中存储的拦截策略一致，则拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0010]根据本发明的方法的一个实施例，进一步地，所述获取应用程序授权权限列表之前，还包括:
[0011]从本地策略数据库中检索获得与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略，将获得的拦截策略存储在所述应用程序授权权限列表中。
[0012]根据本发明的方法的一个实施例，进一步地，所述将获得的拦截策略存储在所述应用程序授权权限列表中之前，还包括:
[0013]通过远程策略接口向云端服务器发送请求并获得反馈的与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略。
[0014]根据本发明的方法的一个实施例，进一步地，所述方法还包括:
[0015]判断所述第二应用程序是否为系统应用程序；
[0016]如为系统应用程序，并且在设定时间内所述第一应用程序对所述第二应用程序自启动的次数达到或超过设定门限值，则不拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0017]根据本发明的方法的一个实施例，进一步地，所述方法还包括:
[0018]如果在设定时间内所述第一应用程序对所述第二应用程序自启动的次数达到或超过设定门限值，则不拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0019]根据本发明的方法的一个实施例，进一步地，所述方法还包括:
[0020]在接收到所述第一应用程序通过内容提供者方式对所述第二应用程序的自启动请求后，记录所述自启动请求、内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识；
[0021]将所记录的所述自启动请求、所述内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识反馈给用户；
[0022]向用户界面弹窗告警，接收用户指令以获得处理策略。
[0023]根据本发明的方法的一个实施例，进一步地，所述拦截策略包括基于所述第一应用程序的包标识、所述第二应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是否拦截。
[0024]根据本发明的方法的一个实施例，进一步地，所述方法还包括:
[0025]获得拦截过程的通知栏条目的信息，所述通知栏条目的信息包括所述通知栏条目的显示视图和所述通知栏条目的操作行为响应；
[0026]展现所述通知栏条目的显示视图；
[0027]如果获取到用户对该通知栏条目的操作行为，根据所述通知栏条目的点击响应行为，对用户对所述通知栏条目的操作行为，以内存缓存或数据库缓存的方式，进行响应处理。
[0028]根据本发明的方法的一个实施例，进一步地，所述方法还包括:
[0029]获取移动终端中已安装应用程序的程序列表；
[0030]针对程序列表中的每个应用程序，在本地的省电数据库中查找是否存储有该应用程序的省电策略；
[0031]统计具有省电策略的各应用程序的耗电信息，并根据耗电信息对各应用程序进行排序；
[0032]当有耗电信息超过设定耗电级别的应用程序请求自启动时，触发拦截过程。
[0033]根据本发明的方法的一个实施例，进一步地，所述方法还包括:
[0034]获得所述第一应用程序对所述第二应用程序自启动的次数；
[0035]获得所述第二应用程序自启动的总次数；
[0036]根据所述第一应用程序对所述第二应用程序自启动的次数和所述第二应用程序自启动的总次数，获得比例值；
[0037]当有比例值达到或超过设定门限值的应用程序请求自启动时，触发拦截过程。
[0038]根据本发明的方法的一个实施例，进一步地，
[0039]所述第一应用程序与所述第二应用程序为相关的应用程序；或者
[0040]所述第一应用程序与所述第二应用程序为不相关的应用程序。
[0041]本发明要解决的另一个技术问题是提供一种应用程序权限管理的装置，以尽量减少某些无用的自启动应用程序对终端资源的占用。
[0042]一种应用程序权限管理的装置，包括:
[0043]自启动请求接收单元，用于接收第一应用程序通过服务方式对第二应用程序的自启动请求；
[0044]策略获取单元，用于获取应用程序授权权限列表；
[0045]拦截处理单元，用于根据所述自启动请求中携带的所述第一应用程序的包标识和所述第二应用程序的包标识判断是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求，如果所述第一应用程序的包标识和所述第二应用程序的包标识与所述应用程序授权权限列表中存储的拦截策略一致，则拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0046]根据本发明的方法的一个实施例，进一步地，所述策略获取单元，还用于
[0047]从本地策略数据库中检索获得与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略，将获得的拦截策略存储在所述应用程序授权权限列表中。
[0048]根据本发明的方法的一个实施例，进一步地，所述策略获取单元，还用于
[0049]通过远程策略接口向云端服务器发送请求并获得反馈的与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略。
[0050]根据本发明的方法的一个实施例，进一步地，所述装置还包括:
[0051]应用程序类型判断单元，用于判断所述第二应用程序是否为系统应用程序，如为系统应用程序，并且在设定时间内所述第一应用程序对所述第二应用程序自启动的次数达到或超过设定门限值，则不拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0052]根据本发明的方法的一个实施例，进一步地，所述方法还包括:
[0053]自启动次数判断单元，用于如果在设定时间内所述第一应用程序对所述第二应用程序自启动的次数达到或超过设定门限值，则不拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0054]根据本发明的方法的一个实施例，进一步地，所述装置还包括:
[0055]交互单元，被注册为系统服务，外壳应用程序通过其内建的交互接口与该交互单元通信，借助该交互单元向用户界面弹窗实现人机交互。
[0056]根据本发明的方法的一个实施例，进一步地，
[0057]所述装置还包括:
[0058]日志记录单元，用于在接收到所述第一应用程序通过内容提供者方式对所述第二应用程序的自启动请求后，记录所述自启动请求、内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识；
[0059]日志反馈单元，用于将所记录的所述自启动请求、所述内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识反馈给用户；
[0060]所述交互单元，用于向用户界面弹窗告警，接收用户指令以获得处理策略。
[0061]根据本发明的方法的一个实施例，进一步地，所述拦截策略包括基于所述第一应用程序的包标识、所述第二应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是否拦截。
[0062]根据本发明的方法的一个实施例，进一步地，所述装置还包括:
[0063]响应单元，用于获得拦截过程的通知栏条目的信息，所述通知栏条目的信息包括所述通知栏条目的显示视图和所述通知栏条目的操作行为响应，展现所述通知栏条目的显示视图，如果获取到用户对该通知栏条目的操作行为，根据所述通知栏条目的点击响应行为，对用户对所述通知栏条目的操作行为，以内存缓存或数据库缓存的方式，进行响应处理。
[0064]根据本发明的方法的一个实施例，进一步地，所述装置还包括:
[0065]耗电统计单元，用于获取移动终端中已安装应用程序的程序列表，针对程序列表中的每个应用程序，在本地的省电数据库中查找是否存储有该应用程序的省电策略，统计具有省电策略的各应用程序的耗电信息，并根据耗电信息对各应用程序进行排序，当有耗电信息超过设定耗电级别的应用程序请求自启动时，触发拦截过程。
[0066]根据本发明的方法的一个实施例，进一步地，所述装置还包括:
[0067]启动次数统计单元，用于获得所述第一应用程序对所述第二应用程序自启动的次数，获得所述第二应用程序自启动的总次数，根据所述第一应用程序对所述第二应用程序自启动的次数和所述第二应用程序自启动的总次数，获得比例值，当有比例值达到或超过设定门限值的应用程序请求自启动时，触发拦截过程。
[0068]根据本发明的方法的一个实施例，进一步地，
[0069]所述第一应用程序与所述第二应用程序为相关的应用程序；或者
[0070]所述第一应用程序与所述第二应用程序为不相关的应用程序。
[0071]本发明要解决的又一个技术问题是提供一种移动终端，以尽量减少某些无用的自启动应用程序对终端资源的占用。
[0072]—种移动终端，包括:广播接收机组件、服务组件以及前述实施例的应用程序权限管理的装置。
[0073]根据本发明的移动终端的一个实施例，进一步地，所述移动终端还包括内容提供者组件。
[0074]本发明要解决的又一个技术问题是提供一种应用程序权限管理的系统，以尽量减少某些无用的自启动应用程序对终端资源的占用。
[0075]一种应用程序权限管理的系统，包括云端服务器和前述实施例的移动终端。
[0076]本发明的应用程序权限管理的方法、装置、系统及移动终端，由于可以根据调用的应用程序的包标识即第一应用程序的包标识和被调用的应用程序的包标识即第二应用程序的包标识拦截掉对用户无用的和/或对其他应用程序的启动无任何帮助的应用程序，因此，不仅可以提高终端的运行速度、而且还可以为终端节省电量。
【专利附图】
【附图说明】
[0077]通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中:
[0078]图1是根据本发明一个实施例的应用程序权限管理的方法的流程示意图。
[0079]图2是根据本发明一个实施例的应用程序权限管理的装置的结构示意图。
[0080]图3是根据本发明一个实施例的移动终端的结构示意图。
[0081]图4是根据本发明另一实施例的移动终端的结构示意图。
[0082]图5是根据本发明一个实施例的应用程序权限管理的系统的结构示意图。
【具体实施方式】
[0083]下面参照附图对本发明进行更全面的描述，其中说明本发明的示例性实施例。下面将结合本发明实施例中的附图对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例都属于本发明保护的范围。
[0084]Android 系统有四大组件:Activity 组件、Service 组件、Broadcast Receiver 组件和Content Provider组件,这四大组件均可以被ActivityManagerService所管理。在应用程序被自启动时会通过ActivityManagerService执行。
[0085]本发明的方法所应用程序的环境包括可与远程服务器或云端通信的移动终端，该移动终端可以安装有Android操作系统，该系统处于未经ROOT授权或者已经获取ROOT权限的状态。
[0086]众所周知,Root权限是指Unix类操作系统(包括Linux、Android)的系统管理员权限，类似于Windows (视窗)系统中的Administrator (管理员)权限；Root权限可以访问和修改用户的移动设备中几乎所有的文件(Android系统文件及用户文件，不包括ROM)。但是，由于目前移动终端系统对于Root权限的管理是非常严格的，通常情况下多数应用程序或程序都不具备Root权限，因此对于某些需要具备Root权限的操作就无法执行，例如安装或卸载应用程序等操作；同时，此类操作调用进程每次执行相应操作时都需要向系统申请Root权限，但如果此时其他应用程序进程正在使用Root权限进行相关操作，则此调用进程的Root权限申请便无法成功；更甚者，如果用户在系统中设置了禁用Root权限的操作，则相关调用进程便无法进行相关操作。
[0087]图1是根据本发明一个实施例的应用程序权限管理的方法的流程示意图。
[0088]如图1所示，该实施例可以包括以下步骤:
[0089]102，接收第一应用程序通过服务方式对第二应用程序的自启动请求；
[0090]104，获取应用程序授权权限列表；
[0091]106，根据所述自启动请求中携带的所述第一应用程序的包标识和所述第二应用程序的包标识判断是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求，如果所述第一应用程序的包标识和所述第二应用程序的包标识与所述应用程序授权权限列表中存储的拦截策略一致，则拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0092]可选地，所述第一应用程序与所述第二应用程序为相关的应用程序。例如，第一应用程序与第二应用程序可以为淘宝与支付宝这两个阿里系的应用程序；或者，再例如，第一应用程序与第二应用程序可以为百度影音与百度搜索这两个百度系的应用程序；或者，再例如，第一应用程序与第二应用程序可以为360杀毒与360助手这两个360系的应用程序，等等，本实施例对此不进行特别限定。
[0093]可选地，所述第一应用程序与所述第二应用程序为不相关的应用程序。例如，第一应用程序与第二应用程序可以为阿里系的淘宝与百度系的百度影音这两个不同系的应用程序；或者，再例如，第一应用程序与第二应用程序可以为360系的手机助手与阿里系的支付宝这两个不同系的应用程序，等等，本实施例对此不进行特别限定。
[0094]通常，操作系统可以包括应用程序层(app层)和系统框架层(framework层)。本发明一种优选实现方式是，对app层和framework层进行改进，从而利用这两层的协同配合实现在智能终端上快速启动通信。具体的，可以在app层增加一个监听单元，用于监听framework层唤醒组件从而实现应用程序自启的操作，从而可以在应用程序自启之前，获取到负责应用程序自启的组件的相关信息，并分析该组件的类型和相关应用程序的包标识，根据所获得的拦截策略，确定是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0095]以Android系统为例,在启动一个应用程序之前,会首先在framework层分析出需要启动的组件名称，同时framework层会记录与该应用程序启动相关的信息，比如被启动的组件名称，该组件的类型(是Activity组件、Service组件、Broadcast Receiver组件还是Content Provider组件)等。通过注入和java hook,就能对framework层记录该信息的接口进行监听，并将该信息返回给app层的监听单元(例如，手机杀毒客户端)，再由该杀毒客户端决定是否允许该应用程序的启动行为。因此，实际上监听行为是app层通过监听framework层的接口调用实现的。因为这个接口本身就提供了被唤醒组件的相关信息，所以只需要对从framework层获取的数据进行少量解析即可得到。
[0096]具体地，可以采用中断机制实现对调取组件的接口进行监听。具体的，可采用hook (挂钩或钩子)机制实现对framework层中的用于调取组件的接口进行监听。本领域技术人员了解，hook机制允许应用程序截获处理操作系统的消息或特定事件。钩子实际上是一个处理消息的程序段，通过系统调用，把它挂入系统。每当特定的消息发出，在没有到达目的窗口前，钩子程序就先捕获该消息，亦即钩子函数先得到控制权。这时钩子函数即可以加工处理(改变)该消息，也可以不作处理而继续传递该消息，还可以强制结束消息的传递。在本发明实施例中，采用hook机制中断调取应用程序对应的组件的过程，实现在应用程序自启之前获取其组件信息。
[0097]下面对这四种组件类型作简单介绍。
[0098](I) Activity 组件
[0099]应用程序中，一个activity组件通常就是一个单独的屏幕，它上面可以显示一些控件也可以监听并处理用户的事件做出响应。
[0100](2) Broadcast Receiver 组件
[0101]应用程序可以使用Broadcast Receiver组件对外部事件进行过滤,从而只对感兴趣的外部事件如当电话呼入时，或者数据网络可用时，进行接收并做出响应。BroadcastReceiver组件没有用户界面。然而,它们可以启动一个Activity组件或Service组件来响应它们收到的信息，或者用状态栏管理器(Notificat1nManager)来通知用户。通知可以用很多种方式来吸引用户的注意力，如闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。
[0102](3) Service 组件
[0103]一个Service组件是一段长生命周期的没有用户界面的程序，可以用来开发如监控类程序。例如，一个正在从播放列表中播放歌曲的媒体播放器。举例来说，在一个媒体播放器的应用程序中，应该会有多个activity组件，让使用者可以选择歌曲并播放歌曲。然而，音乐重放这个功能并没有对应的activity组件，因为使用者当然会认为在导航到其它屏幕时音乐应该还在播放的。在这个例子中，媒体播放器这个activity组件会使用Context.startService O来启动一个service组件,从而可以在后台保持音乐的播放。同时，系统也将保持这个service组件一直执行,直到这个service组件运行结束。另外,还可以通过使用Context.bindService O方法，连接到一个service组件上(如果这个service组件还没有运行将启动它)。当连接到一个service组件之后,还可以service组件提供的接口与它进行通信。以媒体播放器这个例子来说，还可以进行暂停、重播等操作。
[0104](4) Content Provider 组件
[0105]Android系统平台提供了 Content Provider组件,使一个应用程序的指定数据集提供给其他应用程序。这些数据可以存储在文件系统中、在一个SQLite数据库、或以任何其他合理的方式，其他应用程序可以通过ContentResolver类从该内容提供者中获取或存入数据，只有需要在多个应用程序间共享数据时才需要内容提供者。例如，通信录数据被多个应用程序使用，且必须存储在一个内容提供者中。它的好处在于统一了数据的访问方式。
[0106]具体地，在104之前，还可以预先从本地策略数据库中检索获得与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略，将获得的拦截策略存储在所述应用程序授权权限列表中。
[0107]进一步地，在将获得的拦截策略存储在所述应用程序授权权限列表中之前，还可以进一步通过远程策略接口向云端服务器发送请求并获得反馈的与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略。这样，则可以将从本地策略数据库中所获得的拦截策略和从云端服务器所获得的拦截策略，一并存储在所述应用程序授权权限列表中。
[0108]所述拦截策略在设置的时候，针对每个组件可以遵循以下规则中的至少一项规则:
[0109]Activity组件是可视化组件，其引发的启动行为不能被拦截，因为这种行为大多由用户触发，并非严格意义上的应用程序的自启动；
[0110]Broadcast Receiver组件的唤醒是操作系统的行为，因此，对该组件所引发的自启动请求一般不进行拦截；以及
[0111]Content Provider组件所引发的自启动请求,可以将将权限交给用户，因此,每个用户可以根据自身需求设置个性化的过滤或拦截策略。
[0112]这样，通过对以上这些规则的应用，可以较准确的判定第一应用程序对第二应用程序的自启动请求，是否应该被拦截，同时又不对用户的正常使用造成困扰。
[0113]需要指出的是，在应用程序授权权限列表中可以针对Service组件设置将被拦截的第二应用程序的黑名单，即，如果该第二应用程序通过Service方式自启动，只要第一应用程序的包标识和第二应用程序的包标识存在于应用程序授权权限列表中，均被拦截。例如，某些第二应用程序仅禁止通过Service方式自启动，如果该第二应用程序通过Broadcast方式等其他方式自启动,贝U不禁止。
[0114]同样，某些应用程序仅禁止通过Service方式自启动，如果该应用程序通过Broadcast方式自启动，则不禁止。上述不同的设置方式可以应用程序于不同的应用程序场旦
-5^ O
[0115]此外，在预先设置的应用程序授权权限列表库中，某些应用程序对应有一应用程序授权权限列表，应用程序授权权限列表以应用程序标识(即，前述的包标识)为标记。在每一应用程序授权权限列表中，存储有用户预先为该应用程序授权的行为权限。如果该列表中没有对应于该应用程序的行为权限，则没有具体权限建议，但用户仍可对所有权限授权或禁止。
[0116]应用程序的行为权限在AndroidManifest.xml文件中的声明形式如下:
[0117]文件名:AndroidManifest.xml
[0118]〈uses-permiss1n android:name = “使用权限，，/>
[0119]可以使用Java中的可扩展标记语言(XML,Extensible Markup Language)文件解析器，解析AndroidManifest.xml文件中的权限描述部分，以获取应用程序申请的行为权限列表。当然，也可以使用其他XML解析器，或者，使用其他编程语言，例如，C/C++, python等编程语言开发XML解析器，对AndroidManifest.xml文件进行解析，以获得相应的应用程序所申请的行为权限列表。
[0120]其中，AndroidManifest.xml文件是安装包中较为重要的全局配置文件，其负责向系统注册Android系统的四大组件以及向系统申请权限等。在加壳安装包中，将其作为需要加入加壳安装包的重要内部文件进行考虑，以与原安装包完全一致的副本被包含到加壳安装包中。由于加壳安装包中的AndroidManifest.xml文件即为原安装包的同名文件，其包名相同，故加壳安装包在系统中安装运行宿主应用程序之后，以AndroidManifest.xml向系统注册各个组件和申请系统权限，以此便建立了各个组件的入口，使经反射调用的目标应用程序的各个组件均可以被ActivityManagerService调用，而不必为所述各个组件构造ActivityThread和提供相应的LoadedApk对象,省去运行上下文环境的程序实现环节。同理，反射调用所导致的PackageManagerService对各大组件是否合法注册的问题,也将因AndroidManifest.xml的注册而被克服。
[0121]具体地，在接收到Service第一应用程序对第二应用程序的自启动请求后，ActivityManagerService获悉该自启动请求来自Service,在执行对第二应用程序的调用之前，首先根据自启动请求中携带的第一应用程序的包标识和第二应用程序的包标识进行判断。例如，可以将接收到的第一应用程序的包标识和第二应用程序的包标识与预先存储的应用程序授权权限列表中的包标识进行比较，如果应用程序授权权限列表中存在与第一应用程序的包标识和第二应用程序的包标识相同的包标识,则ActiVityManagerService拦截通过Broadcast方式对应用程序的调用。
[0122]在该实施例中，由于可以根据调用的应用程序的包标识即第一应用程序的包标识和被调用的应用程序的包标识即第二应用程序的包标识拦截掉对用户无用的和/或对其他应用程序的启动无任何帮助的应用程序，因此，不仅可以提高终端的运行速度、而且还可以为终端节省电量。
[0123]在本发明方法的一实施例中，可以统计所述第一应用程序对所述第二应用程序自启动的次数，进而，则可以根据所获得的所述第一应用程序对所述第二应用程序自启动的次数，确定是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0124]进一步地，如果在设定时间内所述第一应用程序对所述第二应用程序自启动的次数达到或超过设定门限值，则不拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0125]这样可以防止陷入频繁地杀掉第二应用程序，然后第一应用程序掉起第二应用程序再频繁地自启动这个恶性循环，不仅耗费了大量的系统资源、浪费了电量，而且还降低了终端的运行速度。
[0126]在本发明方法的另一实施例中，可以调用AS的cleanUpRemovedTaskLocked函数，以获取当前所有的进程并且根据拦截策略遍历判断可疑进程的WD以及进程包列表中包含请求自启动的应用程序的包名的进程，将该进程加入可杀进程列表。
[0127]进一步地，由于应用程序至少包括系统应用程序和用户应用程序，针对系统应用程序，如果通过Service方式自启动时，可以按如下方式处理:
[0128]判断第二应用程序是否为系统应用程序；
[0129]如为系统应用程序，并且在设定时间内所述第一应用程序对所述第二应用程序自启动的次数达到或超过设定门限值，则不拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0130]这样可以防止陷入频繁地杀掉系统应用程序，然后系统应用程序再频繁地自启动这个恶性循环，不仅耗费了大量的系统资源、浪费了电量，而且还降低了终端的运行速度。
[0131]在实际应用程序中，一个应用程序的自启动方式并不仅限于上述的Service方式，还可以通过Content Provider方式实现应用程序的自启动。由于有大量的通过ContentProvider方式调用的应用程序,并且Content Provider的数目也非常多，因此,不便于预先在应用程序授权权限列表中设置好针对Content Provider方式的拦截策略。在此情况下，可以将通过Content Provider方式禁止应用程序自启动的权限交给用户，因此,每个用户可以根据自身需求设置个性化的过滤或拦截策略。
[0132]具体地，在接收到所述第一应用程序通过内容提供者方式对所述第二应用程序的自启动请求后，记录所述自启动请求、内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识，可以将这些记录信息存储到顽固自启日志中。
[0133]即，ActivityManagerService在接收到第一应用程序通过 Content Provider 方式对第二应用程序的调用请求后，首先判断该调用请求是通过何种方式发起的，如果是通过Content Provider方式发起的,则先对自启动请求的相关信息进行记录，以便于用户根据这些记录的信息确定相应的拦截策略。
[0134]进一步地,在ActivityManagerService记录相关信息的同时,可以通过向用户弹出界面的方式将所记录的所述自启动请求、所述内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识反馈给用户；并向用户界面弹窗告警。在用户接收到这些信息后，根据自身需求输入拦截策略，例如，对某些第一应用程序调起某些第二应用程序的自启动进行拦截、允许某些第一应用程序调起某些第二应用程序的自启动等。然后，则可以接收用户指令以获得处理策略，例如，对相应的自启动进行拦截或执行对第二应用程序的自启动。这样就可以把第一应用程序与第二应用程序这两个应用程序之间的调用关系给切断。其中，应用程序的常见自启动方式包括Bind Service方式或Content Provider方式。
[0135]例如，可以通过预先注入到系统服务进程中的拦截模块拦截到第二应用程序的危险操作信息后，向第二应用程序发送相应的询问信息；第二应用程序根据询问信息弹出相应的提示框，并接收用户输入的是否进行相应操作的确认信息后向拦截模块返回；拦截模块根据接收的确认信息，允许或阻断系统服务进程对第二应用程序的危险操作；这样能够做到对第二应用程序行为进行有效地拦截，拦截后，暂停相应的操作，并通知用户该操作，只有得到用户的确认信息后才执行相应的操作。
[0136]此外,如果用户允许某个第一应用程序通过Content Provider方式对某个第二应用程序进行自启动，也可以将该策略存储在应用程序授权权限列表中，一旦接收到该第一应用程序通过Content Provider方式对该第二应用程序的自启动请求，则不再记录且不向用户反馈该信息，而是直接对该第二应用程序进行自启动。
[0137]同样地,如果用户禁止某个第一应用程序通过Content Provider方式对某个第二应用程序进行自启动，也可以将该策略存储在应用程序授权权限列表中，一旦接收到该第一应用程序通过Content Provider方式对该第二应用程序的自启动，也不再记录且不向用户反馈该信息，而是直接杀掉对该第二应用程序自启动的进程。
[0138]换句话说,ActivityManagerService将记录那些用户未明确指示是否禁止或允许第一应用程序通过Content Provider方式调起自启动的第二应用程序,这样不仅可以提高处理效率，同时还可以提升用户的使用体验，避免频繁地向用户弹出确认窗口。
[0139]在上述实施例中，拦截策略可以包括但不限于基于第一应用程序的包标识和第二应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是否拦截。
[0140]进一步地，所述云端服务器为各应用程序设置的安全级别包括黑、灰和白三个级另O，分别对应禁止安装、由用户选择是否安装以及径行安装。
[0141]对于准备或者正在进行安装的应用程序而言，本发明可以通过将自身注册为默认安装器的形式，获取该应用程序的安装广播信息。继而，将这个新装应用程序作为目标应用程序，将其安装包或签名之类的特征信息通过远程规则库接口发送到云端服务器中，由云端服务器对其做出安全性判断。一种实施例中，云端服务器为应用程序的安全级别设定黑、灰、白三种级别，分别代表不同危险程度，并设定对应的处理规则。例如，黑应用程序禁止安装，灰应用程序由用户自行选择，白应用程序则可径行安装。当然，可以进一步简化为灰、白两种，或者简化为黑、白两种。本领域技术人员熟悉服务器的这种云端控制技术，将在后续进一步概要揭示。无论如何，本发明将从本机远程规则库接口中获得云端服务器有关这些应用程序的处理规则的反馈，利用反馈结果做出相应的后续处理。具体而言，当针对当前目标应用程序返回黑应用程序标识时，可以随即停止该目标应用程序的安装；当标识为白应用程序标识或灰应用程序标识时，则可放行安装。出于交互性的考虑，当完成远程判断后，本发明将向用户界面弹窗提醒用户有关判断结果，并显示相应的处理建议，询问用户是否确定对当前新装应用程序建构主动防御环境，用户从中确定对当前新装目标应用程序进行主动防御的标识后，即确定了该目标应用程序。
[0142]同理，用户确定该目标应用程序之后，本发明会将该目标应用程序的安装包存放至所述的指定目录中。另外，出于本发明后续将为该已确定的目标应用程序建构主动防御环境的考虑，本发明会立即停止该目标应用程序的安装，停止安装的操作既可以发生在用户确定该目标应用程序之前也可以发生在之后。
[0143]此外，可以将主防程序驻入到系统中的多个点，以协助实现上述禁止应用程序的自启动。
[0144]具体地，可以将未知应用程序安装包或签名之类的特征信息、或请求自启动应用程序的特征信息通过远程规则库接口发送到云端服务器中，由云端服务器对其做出安全性判断。
[0145]如前所述，由客户端通过远程规则库接口发送到云端服务器的特征信息，包括:Android安装包的包名，和/或，版本号，和/或，数字签名，和/或,Android组件receiver的特征，和/或，Android组件service的特征，和/或，Android组件activity的特征，和/或，可执行文件中的指令或字符串，和/或，Android安装包目录下各文件的MD5值(签名)。
[0146]实现了本发明的方法或装置的客户端，将指定的特征信息上传到云端服务器，在云端服务器预置的规则库中查找与指定的单个特征信息或其组合相匹配的特征记录；其中，云端服务器预置的规则库中包含特征记录及特征记录对应的安全级别，每条特征记录中包含单个特征信息或特征信息的组合；
[0147]云端服务器规则库中预置了数千条特征记录，其中，第一条特征记录中列出了某种病毒的Android安装包包名，第二条特征记录中列出了某个正常应用程序的Android安装包版本号及其数字签名的MD5值，第三条特征记录中列出了某个正常应用程序的Android安装包包名及其receiver特征,第四条特征记录中列出了某种木马的Android安装包包名、版本号及其ELF文件中的特定字符串，等等。
[0148]关于安全等级的标识，即黑，白(安全)或者灰(未知，可疑)三种标识，可以进一步的表不为:
[0149]安全:该应用程序是一个正常的应用程序，没有任何威胁用户手机安全的行为；
[0150]危险:该应用程序存在安全风险，有可能该应用程序本身就是恶意软件；也有可能该应用程序本来是正规公司发布的正常软件，但是因为存在安全漏洞，导致用户的隐私、手机安全受到威胁；
[0151]谨慎:该应用程序是一个正常的应用程序，但是存在一些问题，例如会让用户不小心被扣费，或者有不友好的广告遭到投诉等；当发现这类应用程序之后，会提示用户谨慎使用并告知该应用程序可能的行为，但是由用户自行决定是否清除该应用程序；
[0152]木马:该应用程序是病毒、木马或者其他恶意软件，此处为了简单统称为木马，但并不表示该应用程序仅仅是木马。
[0153]在本发明方法的一实施例中，还可以进一步获得拦截过程的通知栏条目的信息，所述通知栏条目的信息包括所述通知栏条目的显示视图和所述通知栏条目的操作行为响应。进而，则可以展现所述通知栏条目的显示视图。如果获取到用户对该通知栏条目的操作行为，则可以根据所述通知栏条目的点击响应行为，对用户对所述通知栏条目的操作行为，以内存缓存或数据库缓存的方式，进行响应处理。
[0154]具体地,在第二应用程序发送通知栏条目的时候,会构造一个Notificat1n实体类，用于表示一条即将显示的通知栏条目。Notificat1n实体类中会包含该通知栏条目的所有信息，比较重要的是，所述通知栏条目的显示视图和所述通知栏条目的操作行为响应。
[0155]所述通知栏条目的显示视图，具体可以是通过RemoteViews对象实现。其中，RemoteViews对象是一个可序列化的对象，可以将RemoteViews对象序列化为字节流存储在磁盘等物理文件中。当需要查看通知栏条目时,可以从磁盘等物理文件中读取出来所对应的字节流，然后，在反序列化为RemoteViews对象,在通过apply方法即可构造出View对象来，这样，就能够实现展现所述通知栏条目的显示视图的目的了。
[0156]需要说明的是，所述物理文件，可以以内存缓存的方式进行存储，具有快速响应的特点，移动终端重启之后会消失，或者还可以以数据库缓存的方式进行存储，具有持久化的特点，移动终端重启之后不会消失，可以重新加载到内存中，等等，本实施例对此不进行特别限定。
[0157]所述通知栏条目的操作行为响应，是指通知栏条目的操作行为如单击后的响应行为。响应行为，具体可以是通过PendingIntent来实现。而PendingIntent是一个不可序列化的，其是用android ActvityManagerService来维护的事件句柄。该事件句柄实际上对应了一个Intent对象,该Intent对象是一个可序列化的对象，可以将Intent对象序列化为字节流存储在磁盘等物理文件中。当需要对用户对所述通知栏条目的操作行为进行响应时，可以从磁盘等物理文件中读取出来所对应的字节流，然后，在反序列化为Intent对象。这样，通过Intent对象,可以代替PendingIntent来实现操作行为事件如单击事件。
[0158]需要说明的是，所述物理文件，可以以内存缓存的方式进行存储，具有快速响应的特点，移动终端重启之后会消失，或者还可以以数据库缓存的方式进行存储，具有持久化的特点，移动终端重启之后不会消失，可以重新加载到内存中，等等，本实施例对此不进行特别限定。
[0159]具体地，具体可以通过代码注入方式，检测到第二应用程序发送通知栏条目所采用的应用程序接口(Applicat1n Programming Interface,API)调用，进而,从中取出通知栏条目的对象参数。
[0160]在本发明方法的再一实施例中，还可以根据应用程序的包名设置省电策略；云端服务器根据设置有省电策略的程序生成省电数据库。云端服务器若接收到新增的程序及该应用程序的省电策略，则更新到省电数据库中。也就是说，省电数据库中对应记载有程序以及该应用程序的省电策略。
[0161]省电数据库中记载的省电策略可以包括:卸载、禁止自启；省电策略还可以包括:结束运行、保持现状或适合长期运行等。
[0162]例如，技术人员可以为健康类程序、或时钟天气类程序设置保持现状省电策略；而为账号同步等程序设置禁止自启省电策略。
[0163]较佳地，为了移动终端可以获取更有针对性的省电数据库，并减少获取的省电数据库所占用的空间，云端服务器为不同机型的移动终端分别定制省电数据库的一种具体方法包括:多个安装有监控软件的移动终端，若监控软件发现本移动终端中安装了不认识的程序，可以将该应用程序的程序信息与本移动终端的机型信息一并通过互联网等网络上传到云端的服务器；由专业的技术人员为云端服务器接收的程序设置省电策略，例如根据机型信息model设置省电策略；云端服务器针对每个机型信息，根据该机型信息名下设置有省电策略的程序，生成对应该机型信息的省电数据库。
[0164]云端服务器生成并维护省电数据库，移动终端可以从服务器下载省电数据库并存储于本地，用于向用户进行省电建议。
[0165]移动终端从服务器下载得到省电数据库的一种具体方法可以是，移动终端将本移动终端的机型信息通过网络向服务器上报；例如，2G内存的联通版华为荣耀3C智能手机，当判断出本手机连通网络后，从预存的系统信息中提取出本手机的型号U30-H10，作为机型信息通过网络向服务器上报。
[0166]服务器接收到移动终端上报的机型信息后，从与各机型信息所分别对应的省电数据库中，查找到与接收的机型信息相对应的省电数据库，并通过网络返回到上报机型信息的移动终端。
[0167]移动终端接收服务器返回的省电数据库进行存储。
[0168]本发明实施例的移动终端基于下载的省电数据库，依照下述流程进行省电建议，具体可以包括如下步骤:
[0169]步骤一，获取移动终端中已安装应用程序的程序列表。
[0170]具体地，移动终端从本移动终端的操作系统所记录的系统信息中，获取已安装的应用程序的程序列表。程序列表可以包括:应用程序的名称和安装路径；程序列表还可以包括:应用程序的所占空间大小、当前运行的进程和服务数量，以及累计运行时长等等。
[0171]步骤二，针对程序列表中的每个应用程序，在本地的省电数据库中查找是否存储有该应用程序的省电策略。
[0172]具体地，移动终端针对程序列表中的每个应用程序，判断是否可以在下载的省电数据库中查找到该应用程序:若是，则在省电数据库中查找出的该应用程序的省电策略；否则，不查找该应用程序的省电策略。
[0173]步骤三，统计具有省电策略的各应用程序的耗电信息，并根据耗电信息对各应用程序进行排序。
[0174]具体地，移动终端对于每个查找出省电策略的应用程序，检测该应用程序的耗电信息；根据检测得到的耗电信息，统计出该应用程序的单位时间耗电量；进而统计出每个查找出省电策略的应用程序的单位时间耗电量占比；根据统计出的单位时间耗电量占比对各应用程序进行排序。应用程序的耗电信息包括:该应用程序的唤醒次数和运行时间等。
[0175]较佳地，移动终端针对每个查找出省电策略的应用程序，可以根据该应用程序的单位时间耗电量占比，确定该应用程序的耗电级别；若判断出存在耗电级别超过设定级别的应用程序，则提示存在耗电程序，并显示耗电级别超过设定级别的程序的个数。
[0176]步骤四，当有耗电信息超过设定耗电级别的应用程序请求自启动时，触发拦截过程。
[0177]在本发明方法的再一实施例中，还可以统计所述第二应用程序自启动的次数，进而，则可以根据所统计的第二应用程序自启动的次数，依照下述流程进行省电建议，具体可以包括如下步骤:
[0178]步骤一，获得所述第一应用程序对所述第二应用程序自启动的次数；
[0179]步骤二，获得所述第二应用程序自启动的总次数；
[0180]步骤三，根据所述第一应用程序对所述第二应用程序自启动的次数和所述第二应用程序自启动的总次数，获得比例值；
[0181]步骤四，当有比例值达到或超过设定门限值的应用程序请求自启动时，触发拦截过程。
[0182]图2是根据本发明一个实施例的应用程序权限管理的装置的结构示意图。
[0183]如图2所示,该实施例中的装置20可以包括拦自启动请求接收单元202、策略获取单元204以及拦截处理单元206。其中，
[0184]自启动请求接收单元202，用于接收第一应用程序通过服务方式对第二应用程序的自启动请求；
[0185]策略获取单元204，用于获取应用程序授权权限列表；
[0186]拦截处理单元206，用于根据所述自启动请求中携带的所述第一应用程序的包标识和所述第二应用程序的包标识判断是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求，如果所述第一应用程序的包标识和所述第二应用程序的包标识与所述应用程序授权权限列表中存储的拦截策略一致，则拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0187]在该实施例中，由于可以根据被调用的第一应用程序的包标识和第二应用程序的包标识拦截掉对用户无用的和/或对其他应用程序的启动无任何帮助的应用程序，因此，不仅可以提高终端的运行速度、而且还可以为终端节省电量。
[0188]进一步地，在本发明装置的另一实施例中，所述策略获取单元204，还用于从本地策略数据库中检索获得与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略，将获得的拦截策略存储在所述应用程序授权权限列表中。
[0189]进一步地，所述策略获取单元204，还用于通过远程策略接口向云端服务器发送请求并获得反馈的与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略。
[0190]进一步地，在本发明装置的又一实施例中，该装置还可以包括:
[0191]应用程序类型判断单元，用于判断所述第二应用程序是否为系统应用程序，如为系统应用程序，并且在设定时间内所述第一应用程序对所述第二应用程序自启动的次数达到或超过设定门限值，则不拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0192]进一步地，在本发明装置的再一实施例中，该装置还可以包括:
[0193]自启动次数判断单元，用于如果在设定时间内所述第一应用程序对所述第二应用程序自启动的次数达到或超过设定门限值，则不拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
[0194]进一步地，在本发明装置的再一实施例中，该装置还可以包括:
[0195]交互单元，被注册为系统服务，外壳应用程序通过其内建的交互接口与该交互单元通信，借助该交互单元向用户界面弹窗实现人机交互。
[0196]进一步地，在本发明装置的再一实施例中，该装置还可以包括:
[0197]日志记录单元，用于在接收到所述第一应用程序通过内容提供者方式对所述第二应用程序的自启动请求后，记录所述自启动请求、内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识；
[0198]日志反馈单元，用于将所记录的所述自启动请求、所述内容提供者标识、所述第一应用程序的包标识以及所述第二应用程序的包标识反馈给用户；
[0199]交互单元，用于向用户界面弹窗告警，接收用户指令以获得处理策略。
[0200]此外，上述实施例中的拦截策略可以包括但不限于基于应用程序的包标识和云端服务器为各应用程序设置的安全级别确定是否拦截。
[0201]进一步地，所述云端服务器为各应用程序设置的安全级别包括黑、灰和白三个级另O，分别对应禁止、由用户选择以及直接执行。
[0202]在本发明装置的再一实施例中，该装置还可以包括:
[0203]响应单元，用于获得拦截过程的通知栏条目的信息，所述通知栏条目的信息包括所述通知栏条目的显示视图和所述通知栏条目的操作行为响应，展现所述通知栏条目的显示视图，如果获取到用户对该通知栏条目的操作行为，根据所述通知栏条目的点击响应行为，对用户对所述通知栏条目的操作行为，以内存缓存或数据库缓存的方式，进行响应处理。
[0204]在本发明装置的再一实施例中，该装置还可以包括:
[0205]耗电统计单元，用于获取移动终端中已安装应用程序的程序列表，针对程序列表中的每个应用程序，在本地的省电数据库中查找是否存储有该应用程序的省电策略，统计具有省电策略的各应用程序的耗电信息，并根据耗电信息对各应用程序进行排序，当有耗电信息超过设定耗电级别的应用程序请求自启动时，触发拦截过程。
[0206]在本发明装置的再一实施例中，该装置还可以包括:
[0207]启动次数统计单元，用于获得所述第一应用程序对所述第二应用程序自启动的次数，获得所述第二应用程序自启动的总次数，根据所述第一应用程序对所述第二应用程序自启动的次数和所述第二应用程序自启动的总次数，获得比例值，当有比例值达到或超过设定门限值的应用程序请求自启动时，触发拦截过程。
[0208]在本发明装置的再一实施例中，
[0209]所述第一应用程序与所述第二应用程序为相关的应用程序；或者
[0210]所述第一应用程序与所述第二应用程序为不相关的应用程序。
[0211]需要指出的是，上述应用程序权限管理的装置可以单独设置或设置在Activity组件内。
[0212]图3是根据本发明一个实施例的移动终端的结构示意图。
[0213]如图3所示，该实施例中的移动终端30可以包括:广播接收机组件302、服务组件304以及应用程序权限管理的装置306。其中，应用程序权限管理的装置306可以通过前述实施例实现。并且，广播接收机组件302和服务组件304分别与应用程序权限管理的装置306交互自启动信息。
[0214]图4是根据本发明另一实施例的移动终端的结构示意图。
[0215]如图4所示，与图3中的实施例相比，该实施例中的移动终端40还可以包括:内容提供者组件402。其中，内容提供者组件402与应用程序权限管理的装置306交互通过Content Provider方式发起的自启动信息。
[0216]图5是根据本发明一个实施例的应用程序权限管理的系统的结构示意图。
[0217]如图5所示，该实施例中的系统50可以包括云端服务器502和移动终端504，其中，移动终端504可以通过前述实施例实现。云端服务器502中存储了为各应用程序设置的安全级别，可以包括但不限于黑、灰和白三个级别，这三个级别分别对应禁止、由用户选择以及直接执行。
[0218]进一步地，云端服务器502还可以生产、存储并维护省电数据库。
[0219]在实际应用程序中，当同一家产品内部的各应用程序之间进行无用的相互调用时，例如，腾讯系或阿里系内部的产品之间互相调用时，可以利用本发明的方法禁止某些无用的应用程序的自启动，以节省终端的系统资源。同样，本发明也能够阻断对某些应用程序的流氓唤醒。
[0220]需要说明的是，本发明已经将HOOK框架做成了服务平台，以挂钩插件的方式为终端配置监控，因此，其加载仅需依赖于相应的配置文件，管理高效且易于实现，对技术人员而言，一些简单的函数调用仅需编写配置文件即可实现挂钩插件的配置，HOOK重入、并发性會泛1?。
[0221]采用外壳应用程序先后实现对程序行为的监控和目标应用程序的加载，继而借助监控对目标应用程序的事件行为建立监控，可以实现对Java函数、Native函数的挂钩。
[0222]本发明不仅适用于Dalvik模式，也适用于ART模式，功能表现上两者无异，使用者不需适应不同模式编写不同的代码，简化开发工作(小范围内测试Android版本号4.4.2、4.4.3、4.4.4) ο
[0223]经实测，有如下数据佐证本发明的实例的优越性:
[0224](I)本发明的开发实例，在16部手机上对107款主流应用程序软件(如QQ、微信，微博，手机卫士，支付类、多种团购app，各视频播放软件等)进行了稳定性深度测试，均能正常运行。
[0225](2)本发明的开发实例，测试涵盖手机Android操作系统版本号从2.3到4.4.3。机型包括neXUS4/5、7，三星，小米，华为，联想，索尼，HTC及部分山寨手机，均获得较为优异的表现。
[0226]可能以许多方式来实现本发明的方法和系统。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法和系统。用于方法的步骤的上述顺序仅是为了进行说明，本发明的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本发明实施例为记录在记录介质中的程序，这些程序包括用于实现根据本发明的方法的机器可读指令。因而，本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。
[0227]本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用程序，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。
【权利要求】
1.一种应用程序权限管理的方法，其特征在于，包括: 接收第一应用程序通过服务方式对第二应用程序的自启动请求； 获取应用程序授权权限列表； 根据所述自启动请求中携带的所述第一应用程序的包标识和所述第二应用程序的包标识判断是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求，如果所述第一应用程序的包标识和所述第二应用程序的包标识与所述应用程序授权权限列表中存储的拦截策略一致，则拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
2.根据权利要求1所述的应用程序权限管理的方法，其特征在于，所述获取应用程序授权权限列表之前，还包括: 从本地策略数据库中检索获得与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略，将获得的拦截策略存储在所述应用程序授权权限列表中。
3.根据权利要求2所述的应用程序权限管理的方法，其特征在于，所述将获得的拦截策略存储在所述应用程序授权权限列表中之前，还包括: 通过远程策略接口向云端服务器发送请求并获得反馈的与所述第一应用程序的包标识和所述第二应用程序的包标识对应的拦截策略。
4.根据权利要求1所述的应用程序权限管理的方法，其特征在于，所述方法还包括: 如果在设定时间内所述第一应用程序对所述第二应用程序自启动的次数达到或超过设定门限值，则不拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
5.根据权利要求1所述的应用程序权限管理的方法，其特征在于，所述方法还包括: 获得拦截过程的通知栏条目的信息，所述通知栏条目的信息包括所述通知栏条目的显示视图和所述通知栏条目的操作行为响应； 展现所述通知栏条目的显示视图； 如果获取到用户对该通知栏条目的操作行为，根据所述通知栏条目的点击响应行为，对用户对所述通知栏条目的操作行为，以内存缓存或数据库缓存的方式，进行响应处理。
6.根据权利要求1?5任一权利要求所述的应用程序权限管理的方法，其特征在于，所述方法还包括: 获得所述第一应用程序对所述第二应用程序自启动的次数； 获得所述第二应用程序自启动的总次数； 根据所述第一应用程序对所述第二应用程序自启动的次数和所述第二应用程序自启动的总次数，获得比例值； 当有比例值达到或超过设定门限值的应用程序请求自启动时，触发拦截过程。
7.根据权利要求1?5任一权利要求所述的应用程序权限管理的方法， 所述第一应用程序与所述第二应用程序为相关的应用程序；或者 所述第一应用程序与所述第二应用程序为不相关的应用程序。
8.一种应用程序权限管理的装置，其特征在于，包括: 自启动请求接收单元，用于接收第一应用程序通过服务方式对第二应用程序的自启动请求； 策略获取单元，用于获取应用程序授权权限列表； 拦截处理单元，用于根据所述自启动请求中携带的所述第一应用程序的包标识和所述第二应用程序的包标识判断是否拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求，如果所述第一应用程序的包标识和所述第二应用程序的包标识与所述应用程序授权权限列表中存储的拦截策略一致，则拦截所述第一应用程序通过服务方式对所述第二应用程序的自启动请求。
9.一种移动终端，其特征在于，包括广播接收机组件、服务组件以及权利要求8所述的应用程序权限管理的装置。
10.一种应用程序权限管理的系统，其特征在于，包括云端服务器和权利要求9所述的移动终端。
【文档编号】H04L29/08GK104462980SQ201410843695
【公开日】2015年3月25日 申请日期:2014年12月30日 优先权日:2014年12月30日
【发明者】刘新, 张越 申请人:北京奇虎科技有限公司, 奇智软件（北京）有限公司