CN104375869A - 自启动应用控制方法及装置 - Google Patents

Abstract

本发明涉及智能设备的自启动应用控制技术，具体而言，本发明公开一种自启动控制方法，包括如下步骤：从已安装应用的配置文件中获取其广播组件；监控该应用运行时的事件行为，以确定其是否运行组件调用指令；在该应用未运行组件调用指令时，其广播组件被设置为不可用状态；当该应用运行所述组件调用指令时，将其广播组件设置为可用状态。相应的，本发明还公开一种用于执行该方法的自启动控制装置。本发明能够深度禁止目标应用的开机自启动功能，可以加快移动终端的开机速度，节省手机电量和流量，并且确保目标应用的正常使用。

Description

自启动应用控制方法及装置

技术领域

本发明涉及智能设备的自启动应用控制自启动应用控制技术，尤其涉及一种自启动应用控制方法及装置。

背景技术

出于商业利益的需要，移动终端设备上的各种功能的应用，均喜欢抢占操作系统的运行入口，通过将自身注册为接收开机广播信息，使自身在系统完成开机启动时即被加载。由此，应用便能实现开机自动运行，常驻内存。常驻内存的应用太多，自然会影响设备的运行效率，导致启动变慢，耗电增加，流量偷跑，运行效率低等。如果应用挟带不法目的甚至恶意目的，进一步还可能收集用户信息，甚至在获得Root权限的前提下，还能实现一些类似木马、病毒的侵害效果。因此，对操作系统上的自启动应用控制是实现系统安全所必须关注的。

以Android为例，其广播机制的应用，既可以采用静态注册的方式，也可以采用动态注册的方式来实现。静态注册在开机自启目的中较为常用。具体而言，每个应用可以在其Androidmanifest.xml配置文件中用<Receiver>标识向系统注册广播接收器，通过在程序中实现的一个例如继承自BroacastReceiver的MyReceiver类，重写其onReceiver方法，在安装后实现通过广播机制来达到自启动的目的。该应用一旦安装并完成广播接收器的注册，当系统完成开机启动之后，其发送的开机广播消息及其它相关消息均能被该应用的广播接收器所接收，该广播接收器过滤到自己关注的开机广播之后，便可按照其预设的指令完成一系列的动作执行，达到启动自身进程的效果。

为了解决开机自启的问题，现有技术的一些安全软件，直接禁止系统发送开机完成的广播消息，由此，所有应用均不能收到开机完成的广播，理论上切断了消息源头，能达到禁止应用开机自启的目的。然而，事实上，不少恶意软件不仅利用开机完成的广播消息，还能利用其它相关消息来识别当前是否处于开机状态，例如，可以通过系统发送的SD卡加载完成的广播消息来触发，继而实现开机自启的目的。另一方面，有一些非常重要或者经用户授意的应用，如果接收不到开机广播，便不能正常自启。因此，这种方式不仅治标不治本，无法根本性地解决开机自启的问题，而且，可能矫枉过正，导致一些应用无法正常使用。

发明内容

本发明的目的在于解决如何根本性地防止应用自启的问题，而提供一种自启动应用控制方法及其相应的自启动应用控制装置。

本发明的另一目的在于提供一节具有节能效果的移动终端。

为实现本发明的目的，本发明采取如下技术方案：

本发明的一种自启动应用控制方法，包括以下步骤：

从已安装应用的配置文件中获取其广播组件；

监控该应用运行时的事件行为，以确定其是否运行组件调用指令；

在该应用未运行组件调用指令时，其广播组件被设置为不可用状态；

当该应用运行所述组件调用指令时，将其广播组件设置为可用状态。

具体的，从已安装应用的配置文件中获取其所述广播组件的步骤包括如下子步骤：

从系统安装包备份目录中获取已安装应用的安装包；

解析该安装包以获取其中的配置文件；

解析该配置文件，通过获取其中的广播组件的组件名称而实现其广播组件的获取。

较佳的，采用指令反编译该安装包以解析并获得所述的配置文件，该配置文件特指Androidmanifest.xml文件。

具体的，采用钩子函数的方式实现对所述应用的运行进程的事件行为的监控。

较佳的，所述钩子函数所挂钩的组件调用指令为可用于激活Android组件的调用指令。

具体的，该组件调用指令特指以可用于传递消息的Intent对象为传递参数的startActivity或startService函数。

可选地，所述广播组件，包括已安装应用的配置文件中所包含的所有广播组件或其中部分特定的广播组件。

具体的，应用未运行组件调用指令，表现在时间上，是指包括：该应用处于未启动的时间段、虽启动但未进入运行该组件调用指令的入口点的进程生命期、虽进入运行该组件调用指令的入口点但未执行该组件调用指令的生命期、完成该组件调用指令的调用执行后的后续生命期。

具体的，应用运行所述组件调用指令，表现在时间上，是指该应用的进程已经进入运行该组件调用指令的入口点但并未执行该组件调用指令。

具体的，采用setComponentEnabledSetting函数，以所获得的广播组件的组件名称为参数，设置所述广播组件的状态。

较佳的，每次完成所述组件调用指令的执行后，或者当该应用的进程结束其生命周期后，重新将所述的其广播组件设置为不可用状态。

进一步，所述广播组件中被设置为不可用状态的依据，来源于预设的外部数据表，依照该数据表的相应配置而决定将相应的广播组件设置为不可用状态。

本发明提供的一种自启动应用控制装置，包括：

获取单元，用于从已安装应用的配置文件中获取其广播组件；

监控单元，用于监控该应用运行时的事件行为，以确定其是否运行组件调用指令；

执行单元，用于在该应用未运行组件调用指令时，保持广播组件被设置为不可用状态；而当该应用运行所述组件调用指令时，将其广播组件设置为可用状态。

进一步的，所述获取单元包括：

枚举模块，用于从系统安装包备份目录中获取已安装应用的安装包；

反向模块，用于解析该安装包以获取其中的配置文件；

获取模块，用于解析该配置文件，通过获取其中的广播组件的组件名称而实现其广播组件的获取。

具体的，所述配置文件特指Androidmanifest.xml文件。

具体的，该组件调用指令特指以可用于传递消息的Intent对象为传递参数的startActivity或startService函数。

可选地，所述广播组件，包括已安装应用的配置文件中所包含的所有广播组件或其中部分特定的广播组件。

进一步，所述执行单元，采用setComponentEnabledSetting函数，以所获得的广播组件的组件名称为参数，设置所述广播组件的状态。

较佳的，所述执行单元，在每次完成所述组件调用指令的执行后，或者当该应用的进程结束其生命周期后，重新将所述的其广播组件设置为不可用状态。

较佳的，该装置还包括预设的外部数据表，该数据表预存有若干应用所包含的广播组件及其预设的是否禁用的状态标识，执行单元依据该数据表的相应配置而决定将相应的广播组件设置为不可用状态。

本发明提供的移动终端，其配置有本发明前述的自启动应用控制装置，藉由该装置的运行降低该移动终端的能耗和/或流量。

相较于现有技术，本发明至少具有如下优点：

1、本发明具有根本性禁止自启的效果：本发明首先通过已安装应用的安装包来获得其中的配置文件，从配置文件中获得在其中注册的广播组件，然后利用所获得的广播组件的特征信息，主要是其组件名称，后续即可以此为基础，实现对该应用的广播组件的状态控制。这种方式显然是治本的解决方案，从应用程序的源头上对广播组件的广播消息接受能力进行掌握，可以从根本上阻止应用的顽固的开机自启动行为，从技术上大大改善禁止自启动的成功率。

2、本发明具有智能化管控自启动的效果：具体而言，在默认状态下，本发明将目标应用的广播组件的状态设置为不可用，其广播消息接收功能全部被关闭，但是，本发明仍在后台监控该应用的运行进程所发生的事件行为，当该应用需要运行组件调用指令(例如startActivity,startService等)时，可先于该组件调用指令的执行，而将所述的广播组件的状态设置为可用，从而开启其广播消息接收功能。因此，本发明尽管是通过控制广播组件的可用状态来实现开机自启控制，但并不影响应用自身的正常运行，具有人性化的特点。

3、本发明实现了广泛性禁止自启的效果：由于本发明是通过直接控制应用的广播组件的可用状态而实现该应用的广播消息的接收能力控制的效果，因而，可以推知，不仅针对开机自启，即使该应用企图通过后台自启，或者通过借助系统的时间改变广播消息来实现的自启等，这种企图必然都会因为相应的广播组件已经被关闭而无法实现。

4、本发明具有节省电量和流量的效果：电池续航能力一直是本领域的短板，而自启动应用便是消耗资源的大户，通过在移动终端上配置本发明的装置，可以大幅度降低该移动终端的电量消耗，还可避免这些自启动应用偷跑流量，因而，具有节能节流的效果。

由以上的分析可知，本发明解决了长期以来无法根本性解决的应用自启动的技术难题，实现了智能化深度禁止应用自启动的功能。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是本发明的自启动应用控制方法的流程原理图；

图2是本发明的自启动应用控制方法的步骤S11的更具体的流程原理图；

图3是本发明的自启动应用控制装置的原理框图；

图4是本发明的自启动应用控制装置中获取单元的原理框图；

图5是本发明的自启动应用控制方法/装置通过通知栏提示用户有关自启动应用的信息的效果示意图；

图6是本发明的自启动应用控制方法/装置通过悬浮窗提示用户有关自启动应用的信息的效果示意图；

图7是本发明的依照自启动应用控制方法/装置所实现的终端桌面软件的用于实现自启动应用控制配置的加劲加载页面的效果示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“终端”、“终端设备”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；PCS(Personal Communications Service，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；PDA(PersonalDigital Assistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或GPS(Global PositioningSystem，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“终端”、“终端设备”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是PDA、MID(Mobile Internet Device，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

本技术领域技术人员可以理解，这里所使用的服务器、云端、远端网络设备等概念，具有等同效果，其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云。在此，云由基于云计算(Cloud Computing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。本发明的实施例中，远端网络设备、终端设备与WNS服务器之间可通过任何通信方式实现通信，包括但不限于，基于3GPP、LTE、WIMAX的移动通信、基于TCP/IP、UDP协议的计算机网络通信以及基于蓝牙、红外传输标准的近距无线传输方式。

本领域技术人员应当理解，本发明所称的“应用”、“应用程序”、“应用软件”以及类似表述的概念，是业内技术人员所公知的相同概念，是指由一系列计算机指令及相关数据资源有机构造的适于电子运行的计算机软件。除非特别指定，这种命名本身不受编程语言种类、级别，也不受其赖以运行的操作系统或平台所限制。理所当然地，此类概念也不受任何形式的终端所限制。

本发明以下即将描述的一种自启动应用控制方法和装置所实施的应用场景，是安装在移动终端上的基于Android操作系统的运行环境。

为了说明本发明的实施，本发明试图结合计算机程序的静态和动态两个方面进行描述，所谓静态方面，是指程序安装包、文件、数据库等存储于媒介的存储对象；所谓动态方面，是指被调入内存中执行的动态对象，包括但不局限于进程、线程、所用到的数据等。鉴于计算机软件技术的这些特点，不应将本发明所述及的各个方法、步骤、子步骤、装置、单元、模块等，孤立地理解为仅静态或仅动态的方面，本领域技术人员对此应当知晓。故而，本领域技术人员应当能够依据本发明有关静态的表述而将其对应到动态的进程活动，或者依据本发明有关动态的进程活动对应到其静态的表现形式，建立起静态与动态两方面的必然性关联，以此为基础来理解本发明。

本领域技术人员应当可以预见，由于本发明所揭示的技术涉及到对Android系统级别资源的调用，因而，在实施本发明前需要为以本发明实例化的应用程序的运行获取Root权限。

众所周知，Root权限是指Unix类操作系统(包括Linux、Android)的系统管理员权限，类似于Windows(视窗)系统中的Administrator(管理员)权限；Root权限可以访问和修改用户的移动设备中几乎所有的文件(Android系统文件及用户文件，不包括ROM)。但是，由于目前移动终端系统对于Root权限的管理是非常严格的，通常情况下多数应用或程序都不具备Root权限，因此对于某些需要具备Root权限的操作就无法执行，例如安装或卸载应用等操作；同时，此类操作调用进程每次执行相应操作时都需要向系统申请Root权限，但如果此时其他应用进程正在使用Root权限进行相关操作，则此调用进程的Root权限申请便无法成功；更甚者，如果用户在系统中设置了禁用Root权限的操作，则相关调用进程便无法进行相关操作。

基于此，本发明提出只需要向系统发送一次Root权限获取请求，具体可通过调用系统内置的SU(Super User，超级用户)命令获取Root权限，或者通过获取具有Root权限的shell获取Root权限并在shell中启动进程，然后在获取所述系统的Root权限授权后，即可使后续其他调用进程需执行相关操作时无需重复申请Root权限；具体Root权限获取过程可参照现有技术的Root权限调用函数，本发明在此不再赘述。

可以看出，Root权限的获取方式，从权限作用的生命周期来看，包括永久Root权限和临时Root权限，顾名思义，永久Root权限情况下，应用程序一经Root授权，以后可不必再进行Root提权操作；而临时Root权限情况下，权限作用的生命周期只是操作系统的一次从开机到关机的过程，下次开机依然需要进行Root。本发明的实现不受这种分类限制。

当然，本领域关于Root提权的技术实施方式多种多样，因而，请注意，本发明的方法和装置的实施，虽有赖于已获Root权限，但并不受限于获取Root授权的具体实施方式。

基于上述的先导性的说明，可以知晓，本发明所要揭示的自启动应用控制方法及其装置，是实现本发明的相对应的两个方面，并非相互孤立的两个方案。

请参阅图1，其揭示了本发明的自启动应用控制方法的实现原理，该方法包括如下步骤：

S11：从已安装应用的配置文件中获取其广播组件。

众所周知的，Android系统中，第三方应用的安装会涉及对如下目录做如下操作：data/app，第三方应用安装目录，安装时先把Apk文件复制到此目录；data/dalvik-cache，将Apk解压后的代码文件(.dex文件)安装到该目录下；data/data，用于建立并存放应用程序所需的数据。基于上述原理可知，第三方应用的Apk文件即为其安装包，在data/app中可以找到该安装包。因此，对于已安装的目标应用而言，可以从data/app中复制相应的apk文件到指定目录中，然后卸载该目标应用。同理，如果是系统自带的应用程序，会在system/app目录中保存其相应的Apk文件。因此，通过data/app和system/app两个安装包存放目录，可以获取所有应用的安装包。

本领域技术人员也必知晓由Android系统规范的Apk文件的构造。在一个Apk文件中，包括有包含该应用的源代码的Classes.dex文件，还包括有对整个应用进行配置的配置文件Androidmanifest.xml，主要是用于配置Android系统的四大组件，以及期望获得系统资源的权限声明等。当一个应用中包含有广播组件时，会采用静态注册的方式，在该配置文件中添加代码如下例所示：

由此，配置文件中便建立了广播组件，其组件名称为.systemReceiver。同一应用可能设置有多个广播组件，以分别处理不同的广播消息，因此，可以在同一配置文件中配置相应多个广播组件，实现这些广播组件的静态注册。可以预见，通过对Apk文件做反向工程，便可获得其中的Androidmanifest.xml，进一步解析Androidmanifest.xml文件，便可以获得其中所注册的多个广播组件。以下结合图2，分三个子步骤介绍一个用于揭示如何实现广播组件的获取的实例：

S111、从系统安装包备份目录中获取已安装应用的安装包：

结合前述，所谓获取已安装应用的安装包，是指由本方法实现的进程从data/app或者system/app中查找到需要实施自启动应用控制的应用的相应的Apk文件。

S112、解析该安装包以获取其中的配置文件：

本领域技术人员常用的用于解析安装包的工具是Apktool，利用该工具可以实现对Apk文件做反向工程。因此，本方法实现的进程可以通过调用Apktool指令，解压并反编译相应安装包(Apk文件)，反编译后，将在临时目录中产生.smali文件和Androidmanifest.xml文件以及其它资源文件等。Androidmanifest.xml文件由此便可以被本方法实现的进程进一步解析。

S113、解析该配置文件，通过获取其中的广播组件的组件名称而实现广播组件的获取：

进一步，由本方法实现的进程分析Androidmanifest.xml文件，可以快速地定位到各个<Receiver>标签，并获取相应的广播组件的组件名称，也便获取了所有的广播组件。当然，如果强化本方法实现的进程的功能，本领域技术人员完全可以进一步通过语义判断，而将广播组件的获取深度具体到其功能层面，如果仅仅需要针对某些广播消息而禁用相应的广播组件，则可以仅获取在语义上与该广播消息相关的部分特定广播组件(组件名称)即可。

通过上述的技术实现，可以获得已安装应用的广播组件，便可供后续进行广播消息功能控制之用，从而实现自启动应用控制的目的。

S12、监控该应用运行时的事件行为，以确定其是否运行组件调用指令：

本发明的基本思想，是在默认状态下禁用目标应用的广播接收功能，而在其受用户触发启动的生命周期中，特别是在其自身可能需要进行广播消息操作时，为其开放广播接收功能。因此，为了实现广播消息接收控制的功能，特别是为了确保实现应用运行时的正常功能，本发明通过一个常驻后台的服务进程，通过监控该应用运行时产生的事件行为，来实现本步骤确定该应用是否运行组件调用指令的目的。

对应用程序进行事件行为监控，一般采用钩子函数实现，也即公知的Hook API技术。本发明所述的服务进程常驻内存，在目标应用被用户运行之后，便可监控该应用的调用指令。根据Android的原理，Intent被用来表达组件想要传递的意图，通过Intent可以传递广播消息。构造一个Intent对象之后，通过组件调用指令例如startActivity、startService，以及sendBroadcast等，以该Intent为这些组件调用指令的传递参数，便可通过这些组件调用指令激活Intent所指向的组件，也便实现了广播消息的传递。因此，startActivity、startService、sendBroadcast或类似函数，均可能与广播消息相关，进一步，也可以推广告凡是以Intent来实现参数传递的函数均可纳入本发明的监控范围，以此为依据来实现事件行为的监控，由此便可以理解本发明如何利用钩子函数的思维。具体而言，本发明通过钩子函数挂钩startActivity和/或startService和/或sendBroadcast，甚至可以按需挂钩其它可能与广播相关的函数，由此实现本步骤所要达到的监控目的。

需要注意的是，当钩子函数监控到组件调用指令运行时，基于Hook技术原理，将先于该组件调用指令执行钩子函数。可以理解，钩子函数监控到组件调用指令，是指监控到目标应用进程中该组件调用指令(函数)的入口点，这时组件调用指令虽有运行的特征，但未有执行该组件调用指令内部功能的事实发生。而钩子函数即在该入口点处挂钩，通过地址指针的修改而使目标应用进程转向执行钩子函数本身，当完成钩子函数的执行后，再由钩子函数转向该组件调用指令的入口点去执行该组件调用指令。因此，在钩子函数内部，便可实现本发明所要实现的智能化控制目标应用的广播接收功能的目的。

S13、在该应用未运行组件调用指令时，其广播组件被设置为不可用状态：

本发明实现对目标应用进行广播组件的禁用，需要从以下两种情况来考虑：

一、目标应用非运行情况下的广播组件禁用：

目标应用非运行的情况，例如，在首次利用本发明所实现的程序启动时，枚举移动终端的所有第三方应用，又或者，用户指定针对的某个具体应用，自动对这些应用进行广播组件禁用；又如，一旦某个新应用安装完毕，由安装完成广播消息触发，由以本发明所实现的程序自动对这一已安装应用进行广播组件禁用；再如，如果未在运行过程中组件调用指令执行完毕之后随即禁用应用的广播组件，而需要在应用结束运行之后，统一对其进行广播组件禁用。诸如此类，均是未伴随目标应用进程的即时执行实况而发生的广播组件禁用操作。这类操作也可以由前述的由本发明构造的服务进程来实现，也可以由独立的服务进程来实现。

特别地，如果每次禁用应用的广播组件均需对安装包做反向工程，将增大内存消耗，因此，本发明的一个实施例中，增设一外部数据表，通过该数据表来标记和保存目标应用的包名和类名、该应用的广播组件、广播组件的组件名称之间的映射关系。当且仅当首次对某一应用实施广播组件禁用时，才需要利用反向工程向该数据表添加数据，在其它情况下，只需将通过目标应用的包名和类名访问该数据表，便可快速地获取该目标应用所涉的广播组件，大大减少实施本发明所需的内存消耗。

由此可知，在时间顺序上，目标应用非运行的情况主要特指该应用处于未启动状态下的时间段。

二、目标应用运行情况下的广播组件禁用：

目标应用被运行，意味着目标应用进程进入调度队列，因此，不同于前一情况下的静态表现，在这种新情况下，应当以动态视角来观察目标应用进程的生命周期。

目标应用运行的情况下，有几个时间段被本发明关注，具体而言，包括：目标应用已启动但未进入运行所述组件调用指令的入口点的进程生命期、虽进入运行该组件调用指令的入口点但未执行该组件调用指令的生命期、完成该组件调用指令的调用执行后的后续生命期。可以看出，这里所细分的几个时间段内，即使广播组件被禁用，也不影响目标应用实现其想要实现的正常功能。因此，本发明的一个实施例以这些具体划分的时间段为依据，对目标应用的广播组件的可用状态实施了严格的控制。

同理，前述所揭示的另一实施例中的数据表上记载的映射数据，也自然适用于以上几种细分时间段内。

以上详细分析的需要进行广播组件禁用的两种情况，具体到包括其中细分的时间段，在本发明的典型实施例中，在这些期间，均会将目标应用的广播组件保持为不可用状态。但是，需要强调的是，在这些期间保持广播组件的不可用，并不意味着必然需要在这些期间执行广播组件禁用指令。例如，如果已安装应用新装后即已经由本发明所构造的服务进程禁用了其广播组件，那么，直至该应用运行，其进程进入到组件调用指令的执行阶段之前，并不需要再由该服务进程再次禁用该应用的广播组件。同理，即使应用的广播组件被本文后续的步骤先于组件调用指令的执行而解禁，本领域技术人员也应当知晓，既可以在该组件调用指令执行完毕之后即对该应用的广播组件进行禁用，也可以延续到该应用的进程生命周期结束之后再行对其广播组件实施禁用。也就是说，本发明的实施，依据上述的详细分析，本领域技术人员应当知晓，存在多种可由其进行灵活结合的变化实例。本领域技术人员对本发明的理解，不应受个别简略描述的局限。

如前所述，本步骤执行广播禁用的技术实现，可由一服务进程来执行，该服务进程通过调用setComponentEnabledSetting函数，向其传递需要禁用的广播组件的组件名称如前述的SystemRecerver和常量COMPONENT_ENABLED_STATE_ENABLED，由其将相应的广播组件设置为不可用状态，即可实现对该广播组件的禁用。

对目标应用进行广播组件的禁用对于目标应用的广播接收功能而言是根本性的，目标应用由此将无法通过获取系统广播实现开机自启动、后台自启动等目的，从而便可加快移动终端的开机速度，并且使内存余量更高，使移动终端具有更优的用户体验。然而，目标应用的一些固有功能可能需要利用到广播消息机制，这种情况下，便可以通过本发明的后续步骤S14来满足。

S14、当该应用运行所述组件调用指令时，将其广播组件设置为可用状态：

如前一步骤S13所述，目标应用的广播组件被禁用后，可能影响到该应用的固有的依赖于广播消息的功能的实现。因此，本发明采用本步骤解决这一问题。

依据前一步骤S13对目标应用处于静态和动态两方面的时间段的分析，可以知晓，目标应用利用广播消息的时间节点，是指该应用的进程已经进入运行该组件调用指令的入口点但并未执行该组件调用指令。这一时间节点，也就是前述Hook技术实现挂钩的关键。因此，可以知晓，本发明可以利用一服务进程实现前述的钩子函数，当目标应用进程进入运行该组件调用指令的入口点时，令其转向执行该钩子函数，通过该钩子函数来实现广播组件解禁的目的。

解禁目标应用的广播组件，同理通过调用setComponentEnabledSetting函数实现，通过向该函数传递需要禁用的广播组件的组件名称如前述的SystemRecerver和常量COMPONENT_ENABLED_STATE_DISABLED，便可由该函数将相应的广播组件设置为可用状态，从而实现对该广播组件的禁用。该钩子函数执行完成解禁目标应用的广播组件之后，继续将控制权和相关参数(如Intent)交回所述的组件调用指令，由此便使目标应用固有功能正常实现。当组件调用指令执行完毕之后，可以再次按照步骤S13所揭示禁用目标应用的广播组件，当然也可在目标应用进程结束再行禁用。

需要指出的是，本发明的自启动应用控制方法的各个步骤，尽管在顺序上存在先后逻辑关系，但是，在以本发明构造的进程的单次或多次生命周期中，未必存在必然的时序关系。以下揭示有关的几种灵活变例：

1、如果参照前述本发明的另一实施例，借助一张数据表来获取每个目标应用的广播组件的特征信息(组件名称等)，那么，步骤S11关于获取广播组件仅需执行一次即可。

2、步骤S13中，实现目标应用广播组件的不可用状态设置，并不必然依赖于步骤S12的实现。例如，在首次获取了目标应用的广播组件之后，对其所有广播组件进行禁用操作，只需直接调用setComponentEnabledSetting去执行即可，但当步骤S12和步骤S14执行实现广播组件解禁后，又需依赖步骤S13去再次禁用广播组件。

3、步骤S12和步骤S14，仅用于对目标应用进程的监控和解禁，因此不延及对目标应用处于未运行的静态状态的维护，显然，步骤S14的实现，必然依赖于步骤S12的执行。

进一步需要指出的是，前文关于另一实施例已经揭示，所述广播组件中被设置为不可用状态的依据，可以来源于预设的外部数据表，依照该数据表的相应配置而决定将相应的广播组件设置为不可用状态。因此，理论上，该数据表可以与云端数据相结合进行维护。举例而言，可以在云端建立应用市场中所有应用的包名和类名、其中广播组件的组件名称、针对广播组件推荐是否禁用的状态之间的映射关系，构造一云端数据表，由移动终端的服务进程将本地应用汇总发送给云端，请求云端给出推荐表，以该推荐表来更新本地数据表，从而实现安全防患的效果。云端的数据表中，可以通过统计安装有以本发明实现的程序所收集的针对每个应用是否禁用其自启动的数据，来得出所述的推荐表。本地依据推荐表更新数据表之前，也可先行弹窗询问用户意向，以用户意向为依据确定是否更新涉及某个应用的记录。

以上详细揭示了本发明的自启动应用控制方法的具体实例，本领域技术人员自然知晓，依照该方法可以提供本发明的一种自启动应用控制装置，该装置以模块化和基于过程的思维来实现，与该方法之间存在对应关系，且能达到相同的技术效果。因此，以下即将进行的针对该装置的描述，也将沿用前述方法的概念的原理进行。

请参阅图3，本发明的自启动应用控制装置主要包括获取单元11、监控单元12以及执行单元13。在其另一实施例中，还可以进一步包括一外部数据表15。

本发明首先在获得Root授权的情况下，向Android系统注册一后台服务进程，该服务进程主要实现所述的获取单元11、监控单元12以及执行单元13。其中，所述的获取单元11用于执行本发明前述方法的步骤S11，所述监控单元12用于执行本发明前述方法的步骤S12，而所述的执行单元13用于执行本发明前述的方法的步骤S13和S14。

请结合图4，所述的获取单元11，由几个细分模块构造而成，具体包括：枚举模块111，用于执行前述步骤S111，从系统安装包备份目录中获取已安装应用的安装包；反向模块112，用于执行前述步骤S112，解析该安装包以获取其中的配置文件；获取模块113，用于执行前述步骤S113，解析该配置文件，通过获取其中的广播组件的组件名称而实现其广播组件的获取。

所述的外部数据表15，预存有若干应用所包含的广播组件及其预设的是否禁用的状态标识，执行单元13依据该数据表15的相应配置而决定将相应的广播组件设置为不可用状态。

本发明的自启动应用控制装置，可以配置于各类智能终端尤其是移动终端中，藉由该装置对自启动应用实施有效控制，可以进一步节省移动终端的电量消耗，延长其续航能力，进而还可有效避免恶意应用在后台偷跑流量，这些特点对于彰显该装置的有益效果而言是非常显著甚至出乎意料的。

进一步，本发明实施例的自启动应用控制装置可以结合其他的模块/装置如清理装置，或者省电管理装置，安装于移动终端中，以便在清理软件/缓存/耗电软件检测的过程中，禁止自启动的软件操作，也可以独立以产品形态应用于移动终端的自启动管理，提供给用户建议禁止的应用

在进行具体产品实现阶段，可以在一用户界面上提供给用户禁止或者允许的选择开关，并且可以进一步提供对系统软件的自启动禁止的选项，必要时还可通过通知栏、悬浮窗等清理工具提示用户管理自启动软件。

通知栏提示的效果请参阅图5：

通知栏中可以展示出新安装的软件中有几款拥有自启权限，并展示拥有自启权限的软件图标，用户由此便可一目也然。点击该通知栏，

悬浮窗提示的效果请参阅图6：

点击小悬浮窗可展开大悬浮窗，内部提示文案为：新增3款自启动软件，点此处理。

点击通知栏/悬浮窗上的引导后跳转到应用了本发明的方法的软件中图7所示的强劲加速页面，同时，强劲加速页面会将新增的自启动软件用“新增”二字标识出来，置顶显示，方便用户管理。如果发现系统未Root，强劲加速页面可以进一步提醒用户停用相关应用以便实现禁止该应用的自启动的目的。可见，结合以上揭示的这些方式，移动终端便可依照本发明实现的逻辑，以更为人性化的方式去实现自启动应用的控制。综上所述，本发明的技术能够深度禁止目标应用的开机自启动功能，可以加快移动终端的开机速度，节省手机电量和流量，并且确保目标应用的正常使用。本发明不仅可以应用于Android操作系统中，还可以用于具有类似架构和机制的操作系统环境中。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种自启动应用控制方法，其特征在于，包括以下步骤：

从已安装应用的配置文件中获取其广播组件；

监控该应用运行时的事件行为，以确定其是否运行组件调用指令；

在该应用未运行组件调用指令时，其广播组件被设置为不可用状态；

当该应用运行所述组件调用指令时，将其广播组件设置为可用状态。

2.根据权利要求1所述的自启动应用控制方法，其特征在于，从已安装应用的配置文件中获取其所述广播组件的步骤包括如下子步骤：

从系统安装包备份目录中获取已安装应用的安装包；

解析该安装包以获取其中的配置文件；

解析该配置文件，通过获取其中的广播组件的组件名称而实现广播组件的获取。

3.根据权利要求1所述的自启动应用控制方法，其特征在于，采用钩子函数的方式实现对所述应用的运行进程的事件行为的监控。

4.根据权利要求3所述的自启动应用控制方法，其特征在于，所述钩子函数所挂钩的组件调用指令为可用于激活Android组件的调用指令。

5.根据权利要求4所述的自启动应用控制方法，其特征在于，该组件调用指令特指以可用于传递消息的Intent对象为传递参数的startActivity或startService函数。

6.根据权利要求2所述的自启动应用控制方法，其特征在于，采用setComponentEnabledSetting函数，以所获得的广播组件的组件名称为参数，设置所述广播组件的状态。

7.根据权利要求1所述的自启动应用控制方法，其特征在于，每次完成所述组件调用指令的执行后，或者当该应用的进程结束其生命周期后，重新将所述的其广播组件设置为不可用状态。

8.根据权利要求1所述的自启动应用控制方法，其特征在于，所述广播组件中被设置为不可用状态的依据，来源于预设的外部数据表，依照该数据表的相应配置而决定将相应的广播组件设置为不可用状态。

9.一种自启动应用控制装置，其特征在于，包括：

获取单元，用于从已安装应用的配置文件中获取其广播组件；

监控单元，用于监控该应用运行时的事件行为，以确定其是否运行组件调用指令；

执行单元，用于在该应用未运行组件调用指令时，保持广播组件被设置为不可用状态；而当该应用运行所述组件调用指令时，将其广播组件设置为可用状态。

10.一种移动终端，其特征在于，其包括如权利要求9所述的自启动应用控制装置，该装置用于降低该移动终端的能耗和/或流量。