控制应用程序自启的方法及装置制造方法

控制应用程序自启的方法及装置制造方法
【专利摘要】本发明公开了一种控制应用程序自启的方法及装置，其中的方法包括：应用程序层通过监听模块，对框架层中用于调取所述应用程序对应的组件的接口进行监听；所述应用程序层通过监听所述接口，获取到所述应用程序对应的组件信息；所述应用程序层利用所述组件信息，在预置的自启规则中进行匹配，如果匹配成功，则确定所述应用程序自启，并通知所述框架层控制所述应用程序的自启行为。本发明将拦截范围扩展到全部组件上，并通过分析这些组件的行为总结出一些规则，降低误拦截。
【专利说明】控制应用程序自启的方法及装置

【技术领域】
[0001] 本发明涉及终端安全【技术领域】，具体涉及一种控制应用程序自启的方法及装置。

【背景技术】
[0002] 安卓（Android)系统是一个是基于组件的系统，这些组件包括broadcast (广播 组件）、provider (提供者组件）、service (服务组件）和activity (活动组件）。每一个 Android软件都是由这些组件拼装而成，通过配置这些组件的功能和行为，就能实现软件被 用户或者系统中其他组件唤醒。在很多情况下，这种唤醒行为并不是由用户主动触发，这种 行为被称做应用程序自启或软件自启。Android的软件自启行为不仅严重的降低了系统续 航时间，还大大降低的系统的流畅度。
[0003] 目前，很多安全厂商都已经在产品中加入了禁止Android软件自启的功能，但 实现方法上存在很大缺陷。以360手机卫士为例，该安全软件通过禁用第三方软件的 broadcast组件来防止自启，这种禁自启方式存在以下缺点：1.无法有效识别软件自启。现 在很多软件（手机QQ，淘宝，助手类软件等）已经能够通过service组件来实现后台自启， 而仅仅只把broadcast组件作为监控点，已经无法全面监测软件的自启行为，另外这种实 现方式无法将软件自启和用户主动唤醒做区分，极大降低用户体验。2.这种拦截软件自启 的方式存在一定的风险。禁用组件的防自启方式是一种非常危险的行为，一旦组件被禁用， 即使用户手动唤醒包含该组件的软件也无法取消这种禁用状态，如果用户卸载了 360手机 卫士，那么被禁止自启的程序将进入永久性的功能缺失状态。


【发明内容】

[0004] 鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上 述问题的控制应用程序自启的方法及装置。
[0005] 依据本发明的一个方面，提供一种控制应用程序自启的方法，包括：应用程序层通 过监听模块，对框架层中用于调取所述应用程序对应的组件的接口进行监听；所述应用程 序层通过监听所述接口，获取到所述应用程序对应的组件信息；所述应用程序层利用所述 组件信息，在预置的自启规则中进行匹配，如果匹配成功，则确定所述应用程序自启，并通 知所述框架层控制所述应用程序的自启行为。
[0006] 优选的，所述在预置的自启规则中进行匹配包括：通过所述应用程序对应的组件 类型和/或所述应用程序的运行状态，确定所述应用程序是否自启。
[0007] 优选的，如果根据所述组件信息确定所述组件类型是广播组件，则进一步判断所 述应用程序是否已经处于运行状态，如果是，则确定所述应用程序并非自启，不禁止所述应 用程序的启动行为，否则，确定所述应用程序是自启，并通知所述框架层控制所述应用程序 的自启行为。
[0008] 优选的，所述通知所述框架层控制所述应用程序的自启行为包括：通过注入框架 层的系统服务进程实现动态广播过滤，当所述应用程序未被唤醒时，丢弃所有需要该广播 组件处理的广播，实现预防自启；当所述应用程序被用户唤醒后，启动所述应用程序。
[0009] 优选的，如果根据所述组件信息确定所述组件类型是服务组件，则进一步判断所 述应用程序是否已经处于运行状态，如果是，则确定所述应用程序并非自启，不禁止所述应 用程序的启动行为，否则，确定所述应用程序是自启，并通知所述框架层停止所述应用程序 的自启行为。
[0010] 优选的，还包括：向用户发送提示消息，提示用户已经停止了所述应用程序的自启 行为；当用户设置允许所述应用程序自启时，所述应用程序层通知所述框架层不再禁止所 述应用程序的自启行为。
[0011] 优选的，如果根据所述组件信息确定所述组件类型是活动组件或提供者组件，则 确定所述应用程序并非自启，不禁止所述应用程序的启动行为。
[0012] 优选的，所述应用程序层的监听模块采用hook机制中断所述框架层中的所述接 口调取所述应用程序对应的组件的过程，从而实现对所述接口的监听。
[0013] 依据本发明的另一个方面，提供一种控制应用程序自启的装置，包括：监听单元， 用于通过应用程序层通过监听模块，对框架层中用于调取所述应用程序对应的组件的接口 进行监听；组件信息获取单元，用于通过监听所述接口，获取到所述应用程序对应的组件信 息；自启控制单元，用于在所述应用程序层利用所述组件信息，在预置的自启规则中进行匹 配，如果匹配成功，则确定所述应用程序自启，并通知所述框架层控制所述应用程序的自启 行为。
[0014] 优选的，所述自启控制单元具体用于：通过所述应用程序对应的组件类型和/或 所述应用程序的运行状态，确定所述应用程序是否自启。
[0015] 优选的，所述自启控制单元具体用于：如果根据所述组件信息确定所述组件类型 是广播组件，则进一步判断所述应用程序是否已经处于运行状态，如果是，则确定所述应用 程序并非自启，不禁止所述应用程序的启动行为，否则，确定所述应用程序是自启，并通知 所述框架层控制所述应用程序的自启行为。
[0016] 优选的，所述自启控制单元具体用于：通过注入框架层的系统服务进程实现动态 广播过滤，当所述应用程序未被唤醒时，丢弃所有需要该广播组件处理的广播，实现预防自 启；当所述应用程序被用户唤醒后，启动所述应用程序。
[0017] 优选的，所述自启控制单元具体用于：如果根据所述组件信息确定所述组件类型 是服务组件，则进一步判断所述应用程序是否已经处于运行状态，如果是，则确定所述应用 程序并非自启，不禁止所述应用程序的启动行为，否则，确定所述应用程序是自启，并通知 所述框架层停止所述应用程序的自启行为。
[0018] 优选的，还包括：提示单元，向用户发送提示消息，提示用户已经停止了所述应用 程序的自启行为；所述自启控制单元还用于，当用户设置允许所述应用程序自启时，通过所 述应用程序层通知所述框架层不再禁止所述应用程序的自启行为。
[0019] 优选的，所述自启控制单元具体用于：如果根据所述组件信息确定所述组件类型 是活动组件或提供者组件，则确定所述应用程序并非自启，不禁止所述应用程序的启动行 为。
[0020] 优选的，所述应用程序层的监听模块采用hook机制中断所述框架层中的所述接 口调取所述应用程序对应的组件的过程，从而实现对所述接口的监听。
[0021] 如之前对现有技术的分析，传统禁止应用程序自启的方法只是针对应用程序 的broadcast组件，但其实能够引发应用程序自启的组件还包含activity、service和 provider。为了达到更好的拦截效果，本发明将拦截范围扩展到全部组件上，并通过分析这 些组件的行为总结出一些规则，降低误拦截。具体的，应用程序层通过监听框架层负责调取 应用程序对应的组件的接口，获取到应用程序对应的组件信息；并利用所述组件信息，在预 置的自启规则中进行匹配，从而确定应用程序是否自启，并根据组件类型最终决定是否禁 止该自启行为。
[0022] 上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段， 而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够 更明显易懂，以下特举本发明的【具体实施方式】。

【专利附图】

【附图说明】
[0023] 通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通 技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明 的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
[0024] 图1示出了根据本发明一个实施例的控制应用程序自启的方法流程图；以及
[0025] 图2示出了根据本发明一个实施例的控制应用程序自启的方法实施例示意图。

【具体实施方式】
[0026] 下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开 的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例 所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围 完整的传达给本领域的技术人员。
[0027] 为了更为有效的解决Android的应用程序自启问题，本发明提出一种智能化的控 制应用程序自启的方案。
[0028] 本领域技术人员理解，操作系统包括应用程序层（app层）和系统框架层 (framework层）。本发明一种优选实现方式是，对app层和framework层进行改进，从而利 用这两层的协同配合实现在智能终端上快速启动通信。具体的，可以在app层增加一个监 听模块，用于监听framework层唤醒组件从而实现应用程序自启的操作，从而可以在应用 程序自启之前，获取到负责应用程序自启的组件的相关信息，并分析该组件的类型，根据预 先设置的自启规则，确定是否禁止该应用程序自启行为。
[0029] 图1是本发明实施例提供的一种控制应用程序自启的方法流程图。该方法包括步 骤 S101 - S103。
[0030] S101 :app层通过监听模块，对framework层中用于调取应用程序对应的组件的接 口进行监听。
[0031] 以android系统为例，在启动一个应用程序之前，会首先在framework层分析出需 要启动的组件名称，同时framework层会记录与该应用程序启动相关的信息，比如被启动 的组件名称，该组件的类型（是broadcast、activity、service还是provider)等。通过注 入和java hook,就能对framework层记录该信息的接口进行监听，并将该信息返回给app 层的监听模块（例如，手机杀毒客户端），再由该杀毒客户端决定是否允许该应用程序的启 动行为。因此，实际上监听行为是app层通过监听framework层的接口调用实现的。因为 这个接口本身就提供了被唤醒组件的相关信息，所以只需要对从framework层获取的数据 进行少量解析即可得到。
[0032] 参见图2,为本发明实施例的控制应用程序自启的方法实施例示意图。App层的 监听模块对framework层中用于调取应用程序对应的组件的接口进行监听，并将监听到 的数据与预置的自启规则进行匹配，然后根据匹配结果返回给framework层，从而使得 framework层控制应用程序的自启。
[0033] 可采用中断机制实现对调取组件的接口进行监听。具体的，可采用h〇〇k(挂钩或 钩子）机制实现对framework层中的用于调取组件的接口进行监听。本领域技术人员了 解，hook机制允许应用程序截获处理操作系统的消息或特定事件。钩子实际上是一个处理 消息的程序段，通过系统调用，把它挂入系统。每当特定的消息发出，在没有到达目的窗口 前，钩子程序就先捕获该消息，亦即钩子函数先得到控制权。这时钩子函数即可以加工处理 (改变）该消息，也可以不作处理而继续传递该消息，还可以强制结束消息的传递。在本发 明实施例中，采用hook机制中断调取应用程序对应的组件的过程，实现在应用程序自启之 前获取其组件信息。
[0034] S102 :app层通过监听该接口，获取到应用程序对应的组件信息。
[0035] 以android系统为例，四大基本组件分别是activity (活动组件）、broadcast (广 播组件）、service (服务组件）和provider (提供者组件）。
[0036] 下面对这四种组件类型作简单介绍。
[0037] (1) activity 组件
[0038] 应用程序中，一个activity通常就是一个单独的屏幕，它上面可以显示一些控件 也可以监听并处理用户的事件做出响应。
[0039] (2) broadcast 组件
[0040] 应用程序可以使用broadcast对外部事件进行过滤，从而只对感兴趣的外部事件 (如当电话呼入时，或者数据网络可用时）进行接收并做出响应。broadcast没有用户界面。 然而，它们可以启动一个activity或service来响应它们收到的信息，或者用状态栏管理 器（NotificationManager)来通知用户。通知可以用很多种方式来吸引用户的注意力- 闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它 并获取消息。
[0041] (3) service 组件
[0042] 一个Service是一段长生命周期的没有用户界面的程序，可以用来开发如监控类 程序。例如，一个正在从播放列表中播放歌曲的媒体播放器。在一个媒体播放器的应用程 序中,应该会有多个activity，让使用者可以选择歌曲并播放歌曲。然而，音乐重放这个功 能并没有对应的activity，因为使用者当然会认为在导航到其它屏幕时音乐应该还在播放 的。在这个例子中，媒体播放器这个activity会使用Context. startServiceO来启动一 个service,从而可以在后台保持音乐的播放。同时，系统也将保持这个service -直执行， 直到这个service运行结束。另外，还可以通过使用Context. bindServiceO方法，连接到 一个service上（如果这个service还没有运行将启动它）。当连接到一个service之后， 还可以service提供的接口与它进行通讯。以媒体播放器这个例子来说，还可以进行暂停、 重播等操作。
[0043] (4) provider 组件
[0044] android平台提供了 Content Provider (内容提供者），使一个应用程序的指定数 据集提供给其他应用程序。这些数据可以存储在文件系统中、在一个SQLite数据库、或以 任何其他合理的方式，其他应用程序可以通过ContentResolver类从该内容提供者中获取 或存入数据，只有需要在多个应用程序间共享数据时才需要内容提供者。例如，通讯录数 据被多个应用程序使用，且必须存储在一个内容提供者中。它的好处在于统一了数据的访 问方式。
[0045] S103 :app层利用获取到的组件信息，在预置的自启规则中进行匹配，如果匹配成 功，则确定应用程序自启，并通知framework层控制该应用程序的自启行为。
[0046] 步骤S103包括两个关键点，一是需要判断应用程序是否自启，再是如何控制应用 程序的自启行为。
[0047] 首先，根据组件类型判断应用程序是否自启。
[0048] 如之前对现有技术的分析，传统禁止应用程序自启的方法只是针对应用程序 的broadcast组件，但其实能够引发应用程序自启的组件还包含activity、service和 provider。为了达到更好的拦截效果，本发明将拦截范围扩展到全部组件上，并通过分析这 些组件的行为总结出一些规则，降低误拦截。
[0049] 如前描述的，通过注入和java hook等手段，能够实时监听各个软件的启动行为， 并能够分析出导致该软件被唤醒的组件。
[0050] 在判定是否为软件的自启行为时，会遵循以下规则：
[0051] (1) activity 组件
[0052] activity组件是可视化组件，其引发的启动行为不能被拦截，因为这种行为多由 用户触发，并非软件自启。
[0053] (2) broadcast 组件
[0054] 分两种情况处理。如果包含该broadcast组件的软件已经处于运行状态（例如， 杀毒客户端启动成功后，会监听手机中每个应用程序的运行状态，当一个组件被启动时，就 可以遍历这个运行状态列表，判别包含该组件的应用程序是否处于运行状态。具体的实现 方法就是注入每一个应用程序，在该程序中设置一个监听器），则认为当前的启动行为并非 自启，不需要被拦截，这种情况一般发生在多进程Android软件中。反之，则认为是自启。
[0055] (3) service 组件
[0056] 判别方式与broadcast组件类似。但是service组件的重要性一般要高于 broadcast组件，不恰当的拦截极有可能导致某些软件运行异常，为了避免这种情况，当 service组件引发的自启行为被拦截时，可进一步给予提示，引导用户完成预期的操作。例 如，预期的操作一般有以下几种场景：比如当用户在手机淘宝上进行支付时，即使用户禁止 了支付宝自启，此时他也希望支付宝能够被唤醒；另外一种场景是360手机卫士和360手 机助手，当这个两个应用程序共存时，手机卫士会不断通过service组件唤醒手机助手，如 果用户本身就禁止了手机助手的自启功能，那么这时候用户很有可能不希望手机助手被启 动。根据具体的使用场景，用户会对禁自启的效果产生不同的预期。
[0057] (4) provider 组件
[0058] 对provider组件引发的启动行为一般不拦截。
[0059] 通过对以上这些规则的应用，可以较准确的判定应用程序是否存在自启行为，同 时又不对用户的正常使用造成困扰。
[0060] 在确定了应用程序是否自启之后，采取安全的拦截方式。
[0061] 传统的拦截方法可能导致应用程序功能缺失，为了避免这种情况，本发明提出一 套新的拦截方案。
[0062] (1)对于broadcast组件，不再禁用该组件，而是通过注入Android系统的关键进 程system_server (系统服务）进程实现动态广播过滤（动态的广播过滤就是：能够动态的 配置哪些应用在未启动状态下能够接收广播，哪些不能接受广播），当软件未被唤醒时，所 有需要该broadcast组件处理的广播都会被直接丢弃掉，实现预防自启；而当软件被用户 唤醒后，这种过滤行为就会被自动停止，不会对软件的正常运行造成任何影响，更加安全。
[0063] (2)对于service组件，如果发现是自启行为则通知Android系统停止该软件的 运行并给予用户相应的提示，用户可以随时根据当前的使用需求决定某个软件是否需要 被禁止自启。其中，"通知Android系统停止该软件的运行"是指：app层以接口方式通知 framework层；注入system_server进程后，会在该进程中添加一个新的服务，手机杀毒客 户端可以与该服务进行通信。因为该服务运行在systenuserver进程中，具有杀死任何进 程的权限，所以手机杀毒客户端只需要调用该服务的接口即可停止某款软件的运行。为了 安全起见，该接口并不直接停止软件运行，而是通过调用framework层的接口来完成。
[0064] 通过上述多种途径相结合的拦截方式，可以安全有效的禁止软件自启。
[0065] 下面以一个具体例子，对本发明提供的控制应用程序自启的方法进行描述。
[0066] 以在QQ软件上实施本发明方案为例，流程如下：
[0067] 1.用户在app层的手机杀毒客户端中禁止QQ软件自启动，QQ软件停止运行；
[0068] 2.在广播过滤列表中添加 QQ，此时所有发给QQ软件的广播会被直接丢弃；
[0069] 3.当某款QQ游戏软件需要通过QQ进行授权时，就会尝试通过service方式唤醒 QQ ；
[0070] 4. framework层监听到QQ尝试启动，启动该软件的组件是com. tencent. qq/com. tencent. qq. service,组件的类型是service, framework层将该消息发送给手机杀毒客户 端；
[0071] 5.手机杀毒客户端发现QQ软件已经被禁自启动，就会通过驻留在system_server 中的一个服务停止QQ软件的启动行为；为了不给用户造成困惑，会在屏幕上提醒"360手机 杀毒客户端已经禁止QQ启动〃；
[0072] 6.用户发现禁止QQ启动后，QQ游戏无法正常运行，就会手动开启QQ软件（从启 动器中打开，从启动器中打开任何软件，杀毒客户端都是不拦截的）或者在手机杀毒客户 端中取消禁止QQ自启动；
[0073] 7.用户再次打开QQ游戏，QQ游戏再次向QQ申请授权，启动组件仍然是com. tencent. qq/com. tencent. qq. service,组件的类型是 service, framework 层将该消息发 送给手机杀毒客户端；
[0074] 8.手机杀毒客户端发现QQ已经启动或者已经被停止禁自启，则直接放行，并停止 过滤发给该软件的广播。
[0075] 与上述方法相对应，本发明还提供一种控制应用程序自启的装置。该装置可以通 过硬件、软件或软硬件结合方式实现。该装置可以是指终端内部的功能模块，也可以是指终 端本身，只要终端包括实现该装置的功能即可。其中，终端的操作系统包括框架层和应用程 序层。该装置包括：
[0076] 监听单元，用于通过应用程序层通过监听模块，对框架层中用于调取所述应用程 序对应的组件的接口进行监听；
[0077] 组件信息获取单元，用于通过监听所述接口，获取到所述应用程序对应的组件信 息；
[0078] 自启控制单元，用于在所述应用程序层利用所述组件信息，在预置的自启规则中 进行匹配，如果匹配成功，则确定所述应用程序自启，并通知所述框架层控制所述应用程序 的自启行为。
[0079] 优选的，所述自启控制单元具体用于：通过所述应用程序对应的组件类型和/或 所述应用程序的运行状态，确定所述应用程序是否自启。
[0080] 优选的，所述自启控制单元具体用于：如果根据所述组件信息确定所述组件类型 是广播组件，则进一步判断所述应用程序是否已经处于运行状态，如果是，则确定所述应用 程序并非自启，不禁止所述应用程序的启动行为，否则，确定所述应用程序是自启，并通知 所述框架层控制所述应用程序的自启行为。
[0081] 优选的，所述自启控制单元具体用于：通过注入框架层的系统服务进程实现动态 广播过滤，当所述应用程序未被唤醒时，丢弃所有需要该广播组件处理的广播，实现预防自 启；当所述应用程序被用户唤醒后，启动所述应用程序。
[0082] 优选的，所述自启控制单元具体用于：如果根据所述组件信息确定所述组件类型 是服务组件，则进一步判断所述应用程序是否已经处于运行状态，如果是，则确定所述应用 程序并非自启，不禁止所述应用程序的启动行为，否则，确定所述应用程序是自启，并通知 所述框架层停止所述应用程序的自启行为。
[0083] 优选的，该装置还包括：提示单元，向用户发送提示消息，提示用户已经停止了所 述应用程序的自启行为；所述自启控制单元还用于，当用户设置允许所述应用程序自启时， 通过所述应用程序层通知所述框架层不再禁止所述应用程序的自启行为。
[0084] 优选的，所述自启控制单元具体用于：如果根据所述组件信息确定所述组件类型 是活动组件或提供者组件，则确定所述应用程序并非自启，不禁止所述应用程序的启动行 为。
[0085] 优选的，所述应用程序层的监听模块采用hook机制中断所述框架层中的所述接 口调取所述应用程序对应的组件的过程，从而实现对所述接口的监听。
[0086] 在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。 各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求 的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种 编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发 明的最佳实施方式。
[0087] 在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施 例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构 和技术，以便不模糊对本说明书的理解。
[0088] 类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在 上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施 例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保 护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面 的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此， 遵循【具体实施方式】的权利要求书由此明确地并入该【具体实施方式】，其中每个权利要求本身 都作为本发明的单独实施例。
[0089] 本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地 改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单 元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或 子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任 何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开 的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴 随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代 特征来代替。
[0090] 此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例 中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的 范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任 意之一都可以以任意的组合方式来使用。
[0091] 本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行 的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用 微处理器或者数字信号处理器（DSP)来实现根据本发明实施例的控制应用程序自启的装 置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述 的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这 样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的 形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他 形式提供。
[0092] 应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领 域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中， 不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词"包含"不排除存在 未列在权利要求中的元件或步骤。位于元件之前的单词"一"或"一个"不排除存在多个这 样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来 实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件 项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为 名称。
[0093] 本发明提供以下方案：
[0094] A1、一种控制应用程序自启的方法，包括：
[0095] 应用程序层通过监听模块，对框架层中用于调取所述应用程序对应的组件的接口 进行监听；
[0096] 所述应用程序层通过监听所述接口，获取到所述应用程序对应的组件信息；
[0097] 所述应用程序层利用所述组件信息，在预置的自启规则中进行匹配，如果匹配成 功，则确定所述应用程序自启，并通知所述框架层控制所述应用程序的自启行为。
[0098] A2、如A1所述的方法，所述在预置的自启规则中进行匹配包括：通过所述应用程 序对应的组件类型和/或所述应用程序的运行状态，确定所述应用程序是否自启。
[0099] A3、如A2所述的方法，如果根据所述组件信息确定所述组件类型是广播组件，则 进一步判断所述应用程序是否已经处于运行状态，如果是，则确定所述应用程序并非自启， 不禁止所述应用程序的启动行为，否则，确定所述应用程序是自启，并通知所述框架层控制 所述应用程序的自启行为。
[0100] A4、如A3所述的方法，所述通知所述框架层控制所述应用程序的自启行为包括：
[0101] 通过注入框架层的系统服务进程实现动态广播过滤，当所述应用程序未被唤醒 时，丢弃所有需要该广播组件处理的广播，实现预防自启；当所述应用程序被用户唤醒后， 启动所述应用程序。
[0102] A5、如A2所述的方法，如果根据所述组件信息确定所述组件类型是服务组件，则 进一步判断所述应用程序是否已经处于运行状态，如果是，则确定所述应用程序并非自启， 不禁止所述应用程序的启动行为，否则，确定所述应用程序是自启，并通知所述框架层停止 所述应用程序的自启行为。
[0103] A6、如A5所述的方法，还包括：
[0104] 向用户发送提示消息，提示用户已经停止了所述应用程序的自启行为；
[0105] 当用户设置允许所述应用程序自启时，所述应用程序层通知所述框架层不再禁止 所述应用程序的自启行为。
[0106] A7、如A2所述的方法，如果根据所述组件信息确定所述组件类型是活动组件或提 供者组件，则确定所述应用程序并非自启，不禁止所述应用程序的启动行为。
[0107] A8、如A1至A7任一项所述的方法，所述应用程序层的监听模块采用hook机制中 断所述框架层中的所述接口调取所述应用程序对应的组件的过程，从而实现对所述接口的 监听。
[0108] B9、一种控制应用程序自启的装置，包括：
[0109] 监听单元，用于通过应用程序层通过监听模块，对框架层中用于调取所述应用程 序对应的组件的接口进行监听；
[0110] 组件信息获取单元，用于通过监听所述接口，获取到所述应用程序对应的组件信 息；
[0111]自启控制单元，用于在所述应用程序层利用所述组件信息，在预置的自启规则中 进行匹配，如果匹配成功，则确定所述应用程序自启，并通知所述框架层控制所述应用程序 的自启行为。
[0112] B10、如B9所述的装置，所述自启控制单元具体用于：通过所述应用程序对应的组 件类型和/或所述应用程序的运行状态，确定所述应用程序是否自启。
[0113] B11、如B10所述的装置，所述自启控制单元具体用于：如果根据所述组件信息确 定所述组件类型是广播组件，则进一步判断所述应用程序是否已经处于运行状态，如果是， 则确定所述应用程序并非自启，不禁止所述应用程序的启动行为，否则，确定所述应用程序 是自启，并通知所述框架层控制所述应用程序的自启行为。
[0114] B12、如B11所述的装置，所述自启控制单元具体用于：通过注入框架层的系统服 务进程实现动态广播过滤，当所述应用程序未被唤醒时，丢弃所有需要该广播组件处理的 广播，实现预防自启；当所述应用程序被用户唤醒后，启动所述应用程序。
[0115] B13、如B10所述的装置，所述自启控制单元具体用于：如果根据所述组件信息确 定所述组件类型是服务组件，则进一步判断所述应用程序是否已经处于运行状态，如果是， 则确定所述应用程序并非自启，不禁止所述应用程序的启动行为，否则，确定所述应用程序 是自启，并通知所述框架层停止所述应用程序的自启行为。
[0116] B14、如B13所述的装置，还包括：提示单元，向用户发送提示消息，提示用户已经 停止了所述应用程序的自启行为；所述自启控制单元还用于，当用户设置允许所述应用程 序自启时，通过所述应用程序层通知所述框架层不再禁止所述应用程序的自启行为。
[0117] B15、如B14所述的装置，所述自启控制单元具体用于：如果根据所述组件信息确 定所述组件类型是活动组件或提供者组件，则确定所述应用程序并非自启，不禁止所述应 用程序的启动行为。
[0118] B16、如B9至B16任一项所述的装置，所述应用程序层的监听模块采用hook机制 中断所述框架层中的所述接口调取所述应用程序对应的组件的过程，从而实现对所述接口 的监听。
【权利要求】
1. 一种控制应用程序自启的方法，其特征在于，包括： 应用程序层通过监听模块，对框架层中用于调取所述应用程序对应的组件的接口进行 监听； 所述应用程序层通过监听所述接口，获取到所述应用程序对应的组件信息； 所述应用程序层利用所述组件信息，在预置的自启规则中进行匹配，如果匹配成功，则 确定所述应用程序自启，并通知所述框架层控制所述应用程序的自启行为。
2. 如权利要求1所述的方法，其特征在于，所述在预置的自启规则中进行匹配包括：通 过所述应用程序对应的组件类型和/或所述应用程序的运行状态，确定所述应用程序是否 自启。
3. 如权利要求2所述的方法，其特征在于，如果根据所述组件信息确定所述组件类型 是广播组件，则进一步判断所述应用程序是否已经处于运行状态，如果是，则确定所述应用 程序并非自启，不禁止所述应用程序的启动行为，否则，确定所述应用程序是自启，并通知 所述框架层控制所述应用程序的自启行为。
4. 如权利要求3所述的方法，其特征在于，所述通知所述框架层控制所述应用程序的 自启行为包括： 通过注入框架层的系统服务进程实现动态广播过滤，当所述应用程序未被唤醒时，丢 弃所有需要该广播组件处理的广播，实现预防自启；当所述应用程序被用户唤醒后，启动所 述应用程序。
5. 如权利要求2所述的方法，其特征在于，如果根据所述组件信息确定所述组件类型 是服务组件，则进一步判断所述应用程序是否已经处于运行状态，如果是，则确定所述应用 程序并非自启，不禁止所述应用程序的启动行为，否则，确定所述应用程序是自启，并通知 所述框架层停止所述应用程序的自启行为。
6. 如权利要求5所述的方法，其特征在于，还包括： 向用户发送提示消息，提示用户已经停止了所述应用程序的自启行为； 当用户设置允许所述应用程序自启时，所述应用程序层通知所述框架层不再禁止所述 应用程序的自启行为。
7. 如权利要求2所述的方法，其特征在于，如果根据所述组件信息确定所述组件类型 是活动组件或提供者组件，则确定所述应用程序并非自启，不禁止所述应用程序的启动行 为。
8. 如权利要求1至7任一项所述的方法，其特征在于，所述应用程序层的监听模块采用 hook机制中断所述框架层中的所述接口调取所述应用程序对应的组件的过程，从而实现对 所述接口的监听。
9. 一种控制应用程序自启的装置，其特征在于，包括： 监听单元，用于通过应用程序层通过监听模块，对框架层中用于调取所述应用程序对 应的组件的接口进行监听； 组件信息获取单元，用于通过监听所述接口，获取到所述应用程序对应的组件信息； 自启控制单元，用于在所述应用程序层利用所述组件信息，在预置的自启规则中进行 匹配，如果匹配成功，则确定所述应用程序自启，并通知所述框架层控制所述应用程序的自 启行为。
10.如权利要求9所述的装置，其特征在于，所述自启控制单元具体用于：通过所述应 用程序对应的组件类型和/或所述应用程序的运行状态，确定所述应用程序是否自启。
【文档编号】G06F9/445GK104123162SQ201410367202
【公开日】2014年10月29日 申请日期:2014年7月29日 优先权日:2014年7月29日
【发明者】唐淳, 张越 申请人:北京奇虎科技有限公司, 奇智软件（北京）有限公司