CN104376257A - 应用程序自我保护、主动防御方法与装置 - Google Patents

Abstract

本发明以Android应用场景为例，公开一种应用程序主动防御方法和相应的装置，该方法包括以下步骤：由注册到系统底层的卸载服务进程截获卸载该应用程序的行为；由卸载服务进程将该行为通知与其通信的客户端服务进程；由客户端服务进程还原由该应用程序处理的至少部分数据后，通知该卸载服务进程放行所述卸载应用程序的行为。此外，本发明还基于前述的方法而公开一种应用程序自我保护方法和装置。本发明能够实现对操作系统卸载应用程序过程的监听，能够前置于该应用程序被卸载而进行相关的预前处理，本质上是实现了安全技术中的主动防御功能，可以更有效地保护应用程序的安全。

Description

应用程序自我保护、主动防御方法与装置

技术领域

本发明涉及计算机程序活动控制技术，一方面涉及一种应用程序主动防御方法与装置；另一方面，则涉及一种应用程序自我保护方法和装置。

背景技术

计算机操作系统中的应用程序，使用一段时间后出于各种原因会可能被卸载，作为提供应用程序的开发者，需要了解用户卸载该应用程序的原因，或者吸收用户的相关建议，所以会调查用户卸载原因，以及接收用户的相关建议等。实现了这种追踪功能的应用程序比较普遍，几乎所有操作系统上的应用程序理论上都能实现这种功能，在用户卸载应用程序后，将用户导向一个调查网页，请求用户填写调查问卷，最终获得需要的信息。

现有技术中，以Android为例，第三方应用程序安装后，会在/data/data中建立其数据文件，应用程序监控自身被卸载的方法通常是创建一个子进程用于监控其位于第三方应用数据目录/data/data内的文件清除事件，当系统卸载该应用程序并且把/data/data里面的文件清除时，便立刻访问一个网页显示卸载调查。

上述现有方法存在几个不足：一、Android 4.4版本以上由于系统运行机制不同于之前的版本，这种方法将不再适用；二、只能监听到卸载之后的事件，不能监听卸载前的行为；三、如果应用要监听卸载时，诸如一些安全软件想要还原用户系统配置，清理资源等操作，也无法实现。

对于应用程序的卸载的管理，可以从两个方面来分析，一方面是安全软件需要对其他应用程序实施的卸载监控和保护，另一方面则是某个应用程序自身需要建立对自身运行状态进行保护的安全防护机制。本发明将基于此处的分析，来对应用程序的保护加以考虑。

发明内容

本发明的首要目的在于克服上述的至少一个问题，而提供一种应用程序主动防御方法和装置。

本发明的另一目的在于克服上述的至少一个问题，而提供一种应用程序自我保护方法和装置。

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

本发明提供的一种应用程序主动防御方法，包括以下步骤：

由注册到系统底层的卸载服务进程截获卸载该应用程序的行为；

由卸载服务进程将该行为通知与其通信的客户端服务进程；

由客户端服务进程还原由该应用程序处理的至少部分数据后，通知该卸载服务进程放行所述卸载应用程序的行为。

具体的，所述卸载服务进程基于获取Root权限为前提而被添加到系统底层。通过调用SystemService.addService()函数而将所述卸载服务进程添加到系统底层。

具体的，所述卸载服务进程通过钩子函数挂钩包管理服务进程的与卸载应用程序相关的函数的运行入口点而截获所述卸载应用程序的行为，并通过向该相关函数的调用者返回自定义数据而恢复所述包管理服务进程的运行。较佳的，该钩子函数具体通过监控包管理服务进程调用deletePackage()函数而截获所述的行为。

根据本发明的一个实施例所揭示，当且仅当所述客户端服务进程从其接收到的通知中判断出待卸载的应用程序为该客户端服务进程所属的应用程序时，才执行所述还原数据并通知卸载服务进程放行卸载的步骤，否则通知所述卸载服务进程直接放行卸载所述应用程序。

进一步，通过比较所述通知中所包含的包名与所述客户端服务进程所属应用程序的包名是否相同，而确定待卸载应用程序是否为该客户端服务进程所属的应用程序。

进一步，所述客户端服务进程收到卸载服务进程的通知后，弹出询问窗口，当且仅当接收到通过该窗口输入的表征允许卸载所述应用程序的指令时，才执行所述还原数据并通知卸载服务进程放行的步骤；否则通知所述卸载服务进程阻止卸载所述应用程序。

较佳的，所述卸载服务进程与所述客户端服务进程之间基于Binder机制进行通信。

进一步，所述还原由该应用程序处理的至少部分数据的过程，包括执行如下操作中的一种或任意多种：

清除由该应用程序增添的数据；

恢复由该应用程序修改的数据；

恢复由该应用程序删除的数据；

通过停止由该应用程序注册的服务进程而恢复系统的服务进程注册数据。

具体的，所述由该应用程序修改的数据包括其他应用程序在活动管理服务进程注册的数据。

根据本发明的一个实施例所揭示，所述客户端服务进程独立于所述应用程序而运行。

进一步，所述客户端服务进程接收到卸载服务进程的通知后，调用浏览器访问预设链接的网页。

本发明提供的一种应用程序主动防御装置，包括：

卸载服务单元，预注册到系统底层，用于截获卸载该应用程序的行为，且将该行为通知与其通信的客户端服务进程；

客户端服务单元，用于还原由该应用程序处理的至少部分数据后，通知该卸载服务进程放行所述卸载应用程序的行为。

具体的，所述卸载服务单元基于获取Root权限为前提而被添加到系统底层。

该装置进一步包括注册单元，用于通过调用SystemService.addService()函数将所述卸载服务单元注册到系统底层。

进一步，所述卸载服务单元包括监控单元，该监控单元被配置为通过钩子函数挂钩包管理服务进程的与卸载应用程序相关的函数的运行入口点而截获所述卸载应用程序的行为，并通过向该相关函数的调用者返回自定义数据而恢复所述包管理服务进程的运行。

具体的，所述的监控单元，被配置为通过所述钩子函数监控包管理服务进程调用deletePackage()函数而截获所述的行为。

根据本发明的一个实施例所揭示，所述客户端服务单元，被配置为当且仅当从其接收到的通知中判断出待卸载的应用程序为该客户端服务单元所属的应用程序时，才执行所述还原数据并通知卸载服务单元放行卸载，否则通知所述卸载服务单元直接放行卸载所述应用程序。

进一步，所述的客户端服务单元，被配置为通过比较所述通知中所包含的包名与该单元所属应用程序的包名是否相同，而确定待卸载应用程序是否为该客户端服务进程所属的应用程序。

进一步，所述客户端服务单元，被配置为当其收到卸载服务单元的通知后，弹出询问窗口，当且仅当接收到通过该窗口输入的表征允许卸载所述应用程序的指令时，才执行所述还原数据并通知卸载服务单元放行卸载；否则通知所述卸载服务单元阻止卸载所述应用程序。

较佳的，所述卸载服务单元与所述客户端服务单元之间基于Binder机制进行通信。

具体的，所述客户端服务单元，包括用于还原由该应用程序处理的至少部分数据的还原模块，该还原模块具体包括如下一个或任意多个子模块：

用于清除由该应用程序增添的数据的子模块；

用于恢复由该应用程序修改的数据的子模块；

用于恢复由该应用程序删除的数据的子模块；

用于通过停止由该应用程序注册的服务进程而恢复系统的服务进程注册数据的子模块。

进一步，所述还原模块中，由该应用程序修改的数据包括其他应用程序在活动管理服务进程注册的数据。

根据本发明的另一实施例所揭示，所述客户端服务单元独立于所述应用程序而配置。

进一步，所述客户端服务单元，被配置为当其接收到卸载服务进程的通知后，调用浏览器访问预设链接的网页。

本发明提供的一种应用程序自我保护方法，包括如下步骤：

建立应用程序的客户端服务进程与系统底层的卸载服务进程的通信；

由所述客户端服务进程执行如下过程：

接收所述卸载服务进程的表征卸载该应用程序的通知；

判断该通知中包含本应用程序包名时，弹窗以问询用户意向；

当非接收到表征允许卸载的指令时，通知卸载服务进程阻止卸载。

具体的，所述系统底层的卸载服务进程系预先由其他应用程序向系统注册。

具体的，所述客户端服务进程对应的服务配置于该应用程序的配置文件中。较佳的，该配置文件为Androidmanifest.xml。

具体的，当预定时间范围内未接收到用户指令时，或者当接收到表征不允许卸载的指令时，视为非接收到表征允许卸载的指令而通知卸载服务进程阻止卸载。

进一步，仅当接收到表征允许卸载的指令时，通知卸载服务进程放行卸载。

较佳的，通知卸载服务进程放行卸载之前，先还原由该应用程序处理的至少部分数据。

具体的，所述还原由该应用程序处理的至少部分数据的过程，包括执行如下操作中的一种或任意多种：

清除由该应用程序增添的数据；

恢复由该应用程序修改的数据；

恢复由该应用程序删除的数据；

通过停止由该应用程序注册的服务进程而恢复系统的服务进程注册数据。

具体的，所述应用程序增添或修改的数据为存储于SD卡中的文件。

较佳的，所述由该应用程序修改的数据包括向活动管理服务进程注册的其他应用程序的注册数据。

进一步，所述客户端服务进程接收到卸载服务进程的通知后，调用浏览器访问预设链接的网页。

本发明提供的一种应用程序自我保护装置，包括：包括客户端服务单元，该单元进一步包括：

通信模块，用于建立客户端服务单元与系统底层的卸载服务单元的通信；

接收模块，用于接收所述卸载服务进程的表征卸载该应用程序的通知；

交互模块，用于判断该通知中包含本应用程序包名时，弹窗以问询用户意向；

响应模块，被配置为当非接收到表征允许卸载的指令时，通知卸载服务进程阻止卸载。

具体的，所述系统底层的卸载服务单元属于其他应用程序的预注册的单元。

进一步，所述客户端服务单元对应的服务配置信息包含于该应用程序的配置文件中。具体的，该配置文件为Androidmanifest.xml。

进一步，所述的响应模块，被配置为当预定时间范围内未接收到用户指令时，或者当接收到表征不允许卸载的指令时，视为非接收到表征允许卸载的指令而通知卸载服务单元阻止卸载。

进一步，所述的响应模块，被配置为仅当接收到表征允许卸载的指令时，通知卸载服务进程放行卸载。

进一步，所述的响应模块，被配置为通知卸载服务进程放行卸载之前，先还原由该应用程序处理的至少部分数据。

具体的，该客户端服务单元还包括用于还原由该应用程序处理的至少部分数据的还原模块，该还原模块具体包括如下一个或任意多个子模块：

用于清除由该应用程序增添的数据的子模块；

用于恢复由该应用程序修改的数据的子模块；

用于恢复由该应用程序删除的数据的子模块；

用于通过停止由该应用程序注册的服务进程而恢复系统的服务进程注册数据的子模块。

具体的，所述应用程序增添或修改的数据为存储于SD卡中的文件。

较佳的，所述由该应用程序修改的数据包括向活动管理服务进程注册的其他应用程序的注册数据。

进一步，所述客户端服务单元，被配置为当其接收到卸载服务进程的通知后，调用浏览器访问预设链接的网页。

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

1、本发明通过在系统底层注册卸载服务进程用于监控操作系统进程的卸载行为，并且建立该系统底层注册的卸载服务进程与用户层的客户端服务进程之间的通信机制，可以克服用户层应用程序及其用户层服务进程无法监控自身或者其他应用程序被卸载的缺点，及时发现系统对应用程序自身或者受自身保护的应用程序实施的卸载行为，因应这一行为做出适应性的告警处理，对应用程序自身或者受该应用程序保护的其他应用程序进行了有效的保护，尤其是对于一些安全软件而言，本发明的运用，对该些安全软件实现主动防御和自我保护的效果是非常明显的。

2、本发明通过用户层的客户端服务进程获知目标应用程序即将被删除后，在确定删除该目标应用程序前，可以先行对该应用程序做出卸载前的处理，例如清除由该应用程序产生或修改的数据，停止该应用程序的相应服务进程等，以及可以激活网站链接提供调查问卷进行用户意向调查等，在用户未真正删除目标应用程序之前即可提前完成这些善后工作，避免目标应用程序被删除后将大量垃圾文件或冗余数据遗留于移动终端中，并且有助于应用程序开发者的产品改进。

3、本发明尤其适用于与安全软件技术相结合，而建立一种适于通过接口实现安全软件与应用程序之间互相配合实现应用程序的自我保护的合作机制。具体而言，当卸载服务进程由安全软件实现时，应用程序便可通过向系统注册客户端服务进程，然后通过客户端服务进程与安全软件预注册到系统底层的卸载服务进程按彼此的协议进行通信，由此便可建立两者之间的相互配合，由卸载服务进程将有关卸载行为的通知发送给客户端服务进程，而进一步可由客户端服务进程实施保护应用程序自身的响应，由此，应用程序便可实现自我保护功能。同理，安全软件也可通过自身的客户端服务进程与自身的卸载服务进程之间的通信，来保护受其保护的应用程序以免该应用程序被随意卸载。

概况而言，本发明可以有效保护应用程序不被随意卸载，且在卸载之前可以对与该应用程序相关的资源进行清理、恢复系统环境、显示卸载反馈等与卸载应用程序有关的清理操作。

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

附图说明

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

图1是本发明的应用程序主动防御方法的一个实施例的流程示意图；

图2是本发明的应用程序主动防御装置的一个实施例的原理框图；

图3是本发明的应用程序自我保护方法的一个实施例的流程示意图；

图4是本发明的应用程序自我保护装置的一个实施例的原理框图。

具体实施方式

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

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

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

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

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

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

本发明的有关方法和装置的应用场景，在基于Unix系为基础的操作系统环境中实现的。为了实现本发明的功能，需要将本发明有关的方法和装置实例化成应用程序，获取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权限调用函数，本发明在此不再赘述。

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

本发明的整体构思可以灵活地体现于多个方面，因此，本发明可以实现为多个方法和装置，分别着重于不同侧面解决现有技术存在的问题。

以下结合图1详细揭示本发明的一种应用程序卸载跟踪方法，该方法将提供一种适于对Android操作系统的应用程序的卸载过程进行跟踪的方案。由此，该方法包括如下步骤：

S11、由注册到系统底层的卸载服务进程截获卸载该应用程序的行为。

本实施例所称的卸载服务进程，是指由以本方法所实现的一个程序模块，运行于内存中，通过内存中的相应主进程实现如前所述的提权操作后，向系统注册的一个通信服务进程。以Android为例，该卸载服务进程基于Android系统所提供的Binder机制，向System Manager注册，通过Android提供的固有的Binder机制，在卸载服务进程与其监听的客户端服务进程之间建立C/S架构的沟通管道。具体而言，当获取到系统的Root权限后，为了便于后续实现对系统中其它进程的监听以及相关操作功能，本发明首先启动具有已经获得Root权限的由本方法实例化后得以运行而形成的主进程，通过主进程在系统中插入所述卸载服务进程，例如具体可通过系统调用函数ServiceManager.addService()来实现插入操作，由此实现对本方法实例化程序所构造的卸载服务进程的成功注册，卸载服务进程由此成为系统底层级别的卸载服务进程。需要注意的是，所述卸载服务进程通过上述的配置，已经成为系统级别的服务进程，其权限显然高于其他用户层服务进程或应用进程的权限，因此该卸载服务进程可以作为通信基础，为其他调用它的进程提供通信保障，完成系统与其他调用它的进程之间的通信连接。由此也可以进一步推知，其他任何遵守本发明的卸载服务进程的接口规范的客户端，均可通过Binder机制与本发明的卸载服务进程进行通信，从而与卸载服务进程相配合执行一系列的内存操作，完成特定任务。

因此，所述的卸载服务进程，具有向其注册的用户层客户端服务进程的通信能力，两者之间基于Binder机制进行通信，这种通信方式具有快速稳定的特点。对于本方法的核心要旨而言，所述卸载服务进程主要用于实施对系统包管理服务进程的监控，以便截获包管理服务进程用于卸载某一应用程序的行为，这一行为主要是指通过函数调用激起的指令操作事件行为。

所述的包管理服务进程，即PackageManagerService(PMS)的相关进程，在其运行过程中，当某一因素企图卸载某一应用程序时，就会发送一个Intent给UninstallerActivity，在UninstallerActivity最后会启动UninstallAppProgress的initView方法，并调用如下卸载函数：getPackageManager().deletePackage()，getPackageManager()函数的实现在ContextImpl.java中，它最后会调用到ApplicantPackageManger.java的deletePackage方法，而deletePackage方法进一步又会调用deletePackageAsUser方法……由此，PMS通过一系列的函数调用而实施对待卸载应用程序的卸载过程，最终从PMS内部结构上删除包括Activity、Service、Provider、Receiver等组件，删除code、library和resource等信息，调用installd删除/data/data/packageName以及/data/dalvik-cache等应用安装目录下面的文件，更新Settings中的Package信息等等。这一过程是Android系统固有的应用程序卸载实施过程。可以看出，通过对其中包括deletePackage()在内的相关函数的监控，均可获知PMS正在卸载某一应用程序的事件行为。通过技术手段截获这一事件行为，便可在PMS卸载该应用程序之前，对其卸载行为实施放行、暂停、阻止等干预。

在本发明的一个实施例中，卸载服务进程通过由自身构造一个监控单元110(参阅图2，下同)实现对前述卸载应用程序的行为的监控。具体而言，可以通过监控PMS正式实施卸载动作之前的一个或多个函数来实现，诸如deletePackage()、initView()、deletePackageAsUser()等。由此截获卸载应用程序的行为，对应用程序卸载过程实施必要的干预。

具体而言，所述监控单元的采用Hook技术实现，利用钩子函数对包管理服务进程中的与卸载应用程序相关的诸如上述所列的任意一个函数的运行入口点进行监视，当其运行至该入口点时，即截获对该函数的调用，转向执行监控单元所实现的相应的钩子函数，由该钩子函数依据自身实现逻辑，利用自定义数据来应答所述包服务管理进程中被截获的相应函数的调用者，从而达到前述的目的。看以看出，一旦转向执行钩子函数，PMS的既有进程相应被暂停。

所述的监控单元向所述调用者返回的自定义数据，是指由监控单元预定的向所述调用者反馈的数据，并不排除系统固有常量，例如，监控单元可以通过向所述调用者返回系统预留的空值标识，来导致PMS进程无法继续卸载相应的应用程序，也可以继续向PMS进程的后续指令继续传递监控单元所截获的Intent而实现对PMS进程放行卸载等。本领域技术人员基于钩子线程相关的技术原理，应当知晓这些变通。

这里需要补充的是：术语“钩子”涵盖了用于通过拦截在软件组件之间传递的函数调用、消息、或事件来改变或增加操作系统、应用程序、或其他软件组件的行为的技术。而处理这种被拦截的函数调用、事件或消息的代码就被称为钩子hook函数。钩子通常用于各种目标，包括对功能进行调试和对功能进行扩展。其示例可以包括在键盘或鼠标事件传递到应用程序之前拦截它们，或者拦截系统调用(system call)、或者系统函数行为、函数执行结果等，以监视或修改应用程序或其他组件的功能等等。本实施例即可采用钩子hook函数接管所述应用程序运行时所需的安装自校验操作。

由此可见，通过已经预注册到系统底层的卸载服务进程对包管理服务进程实施监控，便可截获用于卸载目标应用程序的事件行为，卸载服务进程基于该行为可以做进一步的处理。

步骤S12、由卸载服务进程将该行为通知与其通信的客户端服务进程。

卸载服务进程截获卸载目标应用程序的行为后，以前述示例为基础，主要是其监控单元实施这一操作，卸载服务进程进而可以将该行为通知给客户端服务进程，以交由客户端服务进程做相应的处理，等候客户端服务进程进行相应的处理后反馈的信息，再决定是否放行或阻止PMS进程对目标应用程序的卸载。

有必要强调卸载服务进程与客户端服务进程的区别。依据Android原理，所述卸载服务进程是注册到系统底层的，而客户端服务进程则属于用户层的，客户端服务进程被调用运行时，以bindService()方法建立起客户端服务进程与卸载服务进程之间的连接，两者之间便建立起类似于C/S架构的通信渠道，因此，客户端服务进程与卸载服务进程之间可以通过彼此约定的接口实现对各自功能和参数的调用。在本发明的，作为示例，所述卸载服务进程可以在截获相应函数的Intent后，获知待卸载应用程序的包名，向客户端服务进程传递该包名，以便客户端服务进程据此执行后续处理。当然，实践中，卸载服务进程可以传递给客户端服务进程各类参数，并不受限，本领域技术人员可以灵活实现。

因此，可以看出，客户端服务进程所获得的通知，是基于Binder机制获得的，依据这一机制，客户端服务进程可以顺利地与卸载服务进程进行参数传递和相关功能调用。

步骤S13、由客户端服务进程还原由该应用程序处理的至少部分数据后，通知该卸载服务进程放行所述卸载应用程序的行为。

本发明的一个实施例执行本步骤时，是以最简化的方式执行的。因此，客户端服务进程获得所述卸载服务进程的通知后，作为关键动作，识别该通知所包含的包名，以确定PMS所针对的待卸载目标应用程序，然后执行还原由该应用程序处理的至少部分数据的活动。

但是，作为变例，客户端服务单元的实现，可以结合如下多种情形演化更多的变例。需要指出的是，卸载服务进程、客户端服务进程以及所述待卸载的应用程序之间，可以存在多种相互结合的关系，以构成多种变例，具体如下：

1、所述待卸载的应用程序是用于实现所述卸载服务进程、客户端服务进程的同一安全软件。

2、所述待卸载的应用程序与客户端服务进程属于同一应用程序，而所述卸载服务进程由另一安全软件构建。

3、所述客户端服务进程、卸载服务进程均由同一安全软件构建，而独立于所述待卸载的应用程序。

以上几种变例也意味着本发明的客户端服务进程既可以处理自身所属的应用程序的卸载前控制，也可以处理受自身保护的应用程序的卸载前控制。具体而言，卸载服务进程通知客户端服务进程后，客户端服务进程提取该通知所包含的包名并先与自身所属应用程序的包名进行比较以做出判断，或者进一步判断该通知中的包名是否属于已经记录的一个受保护应用程序列表中的某一个，针对不同的判断结果，分为两种情况，执行不同的功能。

客户端服务进程执行判断后，所划分的两种情况以及各种情况的处理逻辑如下：

1、当客户端服务进程判断卸载服务进程发送的通知中的包名属于受保护应用程序列表中的应用程序，或者属于客户端服务进程自身所属的应用程序时，可以调用客户端服务进程的控制逻辑加以处理，然后才通知卸载服务进程放行PMS对该应用程序的卸载；

2、客户端服务进程判断卸载服务进程发送的通知中的包名不属于自身所在的应用程序时，或者进一步确定亦不属于受保护应用程序列表中的应用程序时，则直接通知卸载服务进程放行PMS对该应用程序的卸载。

在本发明进一步完善的一个实施例中，所述客户端服务进程收到卸载服务进程的通知后，可以向系统界面弹出询问窗口，通过该窗口询问客户是否允许待卸载应用程序的卸载，提供类似于“允许”、“拒绝”的选项供用户选定，以此接收表征用户允许或不允许卸载该应用程序的指令，当到该指令后，做出两种相应的处理，其一是通知卸载服务进程(一个实施例中是其监控单元)放行PMS进程对待卸载应用程序的卸载；其二是通知卸载服务进程(其监控单元)向PMS进程返回空值以便阻止PMS进程对待卸载应用程序的卸载。

客户端服务进程的这一处理方法，适宜前置于客户端服务进程对包名的判断而进行，也可以仅仅针对第一种判断情况，也即包名相同的情况而执行本处理方法。具体而言，针对前后两者，也能够导致本发明产生更多的如下的变例：

对于前者，一接收到卸载服务进程的通知即弹窗告警，如果用户允许卸载，则先判断包名是否相同(包括与客户端服务进程自身所在的应用程序的包名和/或受保护应用程序列表中的应用程序包名比较)，如相同，进一步调用客户端服务进程的控制逻辑加以处理，然后才通知卸载服务进程放行PMS对该应用程序的卸载，如果包名不同，则直接通知放行卸载；如果用户不允许卸载，则通知卸载服务进程阻止PMS进程对该应用程序的卸载。

对于后者，当客户端服务进程接收到卸载服务进程的通知，判断包名相同(同上)后，才弹窗告警，如果用户允许卸载，则进一步调用客户端服务进程的控制逻辑加以处理，然后才通知卸载服务进程放行PMS对该应用程序的卸载；如果包名不同，则直接通知放行卸载；如果用户不允许卸载，则通知卸载服务进程阻止PMS进程对该应用程序的卸载。

如前所述，所述客户端服务进程在用户确定允许目标应用程序被卸载后，便按照其自身实现的控制逻辑做后续处理。这一控制逻辑所实现的控制内容主要包括若干可选的方面的任意一项或任意多项。以下列出这些不同方面并加以阐释，供本领域技术人员参照：

1、还原由待卸载应用程序处理的至少部分数据，主要是指清除由该应用程序增添的数据。众所周知的，应用程序在正常使用过程中，都会产生一些数据，主要是以文件的形式保存到相关目录中，例如手机SD卡的存储目录中。一旦应用程序被删除，往往这些数据文件也不再有用，因此，可以被清理。适应这一方面，客户端服务进程可以将待卸载应用程序所增添的这些文件夹以及相应的文件之类的数据予以删除，通过删除其产生的数据而实现将特定存储空间的数据从占有还原到清零的状态，由此而实现数据还原。

2、还原由待卸载应用程序处理的至少部分数据，主要是指恢复由待卸载应用程序修改的数据。同理，待卸载应用程序，特别是一些安全软件，或者一些涉及系统配置信息改变的软件，例如，一种可以通过修改活动管理服务进程(ActivityManagerService，AMS)的广播接收器注册数据而控制与这些广播接收器相关的应用程序的自启动能力的安全软件，此类安全软件对系统的注册数据做出了修改，因此，在其被卸载之前适宜恢复由其做出过修改的注册数据，以免影响被修改了注册信息的应用程序的正常运行。因此，本发明的客户端服务进程可以针对这种情况或者其他类似的情况，而恢复这些数据(例如安全软件即是客户端服务进程的宿主，该安全软件修改了所有第三方应用程序的广播接收器注册信息并且记录在一列表中，客户端服务进程便可以通过读取该列表而获知被修改的注册数据，或者不必依赖于列表，而通过扫描所有应用程序的Androidmanifest.xml文件的配置信息，据此而恢复这些注册数据)。

3、还原由待卸载应用程序处理的至少部分数据，主要是指恢复由待卸载应用程序删除的数据。与前述第2项同理，部分软件可能出于某种目的而将某些文件删除，这些删除的文件同时被备份到临时目录。对于这种情况，客户端服务进程便可根据已知的规则或者相关的记录信息，而将临时目录中的相应文件恢复到原位置，而实现对由待卸载应用程序删除的数据的恢复。

4、还原由待卸载应用程序处理的至少部分数据，主要是通过停止由该应用程序注册的服务进程而恢复系统的服务进程注册数据。部分应用程序运行可能构造有多个服务组件，这些服务组件在运行时分别被绑定到不同的系统服务进程中，以便提供后台服务，这些服务的突然中断可能会影响到某些数据的正常传输。或者某些服务进程未经终止，可能影响到其所属的应用程序的卸载。这些用户层的服务进程，是注册到系统服务进程中的，因此，在系统服务进程的管理链表中便存在其注册数据。本发明可以通过停止这些已注册的用户层的服务进程，而恢复系统的服务进程注册数据到不存在这些用户层服务进程的状态。

5、调用浏览器访问预设链接的网页。软件开发者往往期望获知用户对其应用程序的使用感受，特别是卸载其应用程序的原因，以便收集用户对应用程序的意见和改进建议，以利于对其应用程序做出改进的决策。有时，在用户因为误解企图卸载该应用程序时，通过网页进行适当的引导，也有利于降低误卸载率。因此，可以在所述客户端服务进程接收到卸载服务进程的通知后，即通过startActivity()函数调用一个包含了链接URL的Intent，该链接指向软件开发者的一个预定网页，运行并访问该网页，与用户做进一步的人机交互。当然，这一访问网页的手段也可以在客户端服务进程的整个生命周期的任何时间段给出，例如在其执行完其它控制逻辑之后给出，具体是在客户端服务进程决定通知卸载待卸载应用程序之前给出即可。

可以看出，以上几种选项是可以任意选用的，并且，通常适合应用于客户端服务进程由待卸载应用程序实现的实例中。但是，当客户端服务进程独立于应用程序时，遵守其与应用程序约定的协议，而在该应用程序被卸载之前，由客户端服务进程实现上述的任意一个选项，显然也是可行的。

进一步，上述的任意一个选项，均可以被构造为客户端服务进程的子模块，其中的第1至4项，因其逻辑相对契合，故可以将这些子模块构造到同一个还原模块25(参阅图2，下同)中。当然，还可以构造一个访问模块(参阅图2，下同)来实现调用浏览器访问预设链接的网页的功能。

需要进一步指出的是，所述客户端服务进程向卸载服务进程反馈通知时，可以简单地只给出两种形式，即表征允许或拒绝卸载原来待卸载的应用程序的两种不同形式。因此，对于卸载服务进程而言，只需依据客户端服务进程的两种不同形式而做出不同的处理。PMS在卸载过程，由于被卸载服务进程监控并截获，由于需要等候卸载服务进程对进程资源的释放，而处于暂停状态。卸载服务进程获得客户端服务进程的反馈通知后，依据表征允许的通知，便可直接将进程资源交还给PMS卸载进程，放行PMS卸载进程对待卸载应用程序的卸载操作；依据表征拒绝的通知，卸载服务进程可以将空值作为待给出的自定义数据返回给调用被截获的函数deletePackage()的上级函数，从而以类似技术欺骗的手段阻止PMS卸载原来的待卸载应用程序，实现对这一应用程序的保护。

进一步，依据计算机软件的功能模块化思维，本发明提供一种应用程序主动防御装置，请参阅图2，该装置包括所述的卸载服务单元11和客户端服务单元12。利用该卸载服务单元11和客户端服务单元12来搭建起整个装置的原理框架，从而实现模块化实施方案。

所述的卸载服务单元11，是实现了前述方法中的卸载服务进程的模块化构造的实例。该卸载服务单元11被一注册单元(未图示)预注册到系统底层中，用于截获卸载该应用程序的行为，且将该行为通知与其通信的客户端服务单元12。

本实施例所称的卸载服务单元11，是指由前述方法中的服务进程所构造的一个程序模块，运行于内存中，通过内存中的相应主进程实现如前所述的提权操作后，向系统注册的一个卸载服务单元11。以Android为例，该卸载服务单元11基于Android系统所提供的Binder机制，向SystemManager注册，通过Android提供的固有的Binder机制，在卸载服务单元11与其监听的客户端服务单元12之间建立C/S架构的沟通管道。具体而言，当获取到系统的Root权限后，为了便于后续实现对系统中其它进程的监听以及相关操作功能，本发明首先启动具有已经获得Root权限的由前述方法实例化后得以运行而形成的主进程，通过主进程在系统中插入所述卸载服务单元11，例如具体可通过系统调用函数ServiceManager.addService()来实现插入操作，由此实现对前述方法实例化程序所构造的卸载服务单元11的成功注册，卸载服务单元11由此成为系统底层级别的卸载服务单元11。需要注意的是，所述卸载服务单元11通过上述的配置，已经成为系统级别的服务进程，其权限显然高于其他用户层服务进程或应用进程的权限，因此该卸载服务单元11可以作为通信基础，为其他调用它的进程提供通信保障，完成系统与其他调用它的进程之间的通信连接。由此也可以进一步推知，其他任何遵守本发明的卸载服务单元11的接口规范的客户端，均可通过Binder机制与本发明的卸载服务单元11进行通信，从而与卸载服务单元11相配合执行一系列的内存操作，完成特定任务。

因此，所述的卸载服务单元11，具有向其注册的用户层客户端服务单元12发送通知和接收反馈通知的通信能力，两者之间基于Binder机制进行通信，这种通信方式具有快速稳定的特点。对于本装置的核心功能而言，所述卸载服务单元11主要用于实施对系统包管理服务进程的监控，以便截获包管理服务进程用于卸载某一应用程序的行为，这一行为主要是指通过函数调用导致的指令操作事件行为。

所述的包管理服务进程，即PackageManagerService(PMS)的相关进程，在其运行过程中，当某一因素企图卸载某一应用程序时，就会发送一个Intent给UninstallerActivity，在UninstallerActivity最后会启动UninstallAppProgress的initView方法，并调用如下卸载函数：getPackageManager().deletePackage()，getPackageManager()函数的实现在ContextImpl.java中，它最后会调用到ApplicantPackageManger.java的deletePackage方法，而deletePackage方法进一步又会调用deletePackageAsUser方法……由此，PMS通过一系列的函数调用而实施对待卸载应用程序的卸载过程，最终从PMS内部结构上删除包括Activity、Service、Provider、Receiver等Android组件，删除code、library和resource等信息，调用installd删除/data/data/packageName以及/data/dalvik-cache(对于非系统预装的第三方应用而言)等应用安装目录下面的文件，更新Settings中的Package信息等等。这一过程是Android系统固有的应用程序卸载实施过程。可以看出，通过对其中包括deletePackage()在内的相关函数的监控，均可获知PMS正在卸载某一应用程序的事件行为。通过技术手段截获这一事件行为，便可在PMS卸载该应用程序之前，对其卸载行为实施放行、暂停、阻止等干预。

在本发明的一个实施例中，卸载服务单元11通过由自身构造一个监控单元110实现对前述卸载应用程序的行为的监控。具体而言，可以通过监控PMS正式实施卸载动作之前的一个或多个函数来实现，诸如deletePackage()、initView()、deletePackageAsUser()等。由此截获卸载应用程序的行为，对应用程序卸载过程实施必要的干预。

具体而言，所述监控单元110的采用Hook技术实现，利用钩子函数对包管理服务进程中的与卸载应用程序相关的诸如上述所列的任意一个函数的运行入口点进行监视，当其运行至该入口点时，即截获对该函数的调用，转向执行监控单元110所实现的相应的钩子函数，由该钩子函数依据自身实现逻辑，利用自定义数据来应答所述包服务管理进程中被截获的相应函数的调用者，从而达到前述的目的。看以看出，一旦转向执行钩子函数，PMS的既有进程相应被暂停。

所述的监控单元110向所述调用者返回的自定义数据，是指由监控单元110预定的向所述调用者反馈的数据，并不排除系统固有常量，例如，监控单元110可以通过向所述调用者返回系统预留的空值标识，来导致PMS进程无法继续卸载相应的应用程序，也可以继续向PMS进程的后续指令继续传递监控单元110所截获的Intent而实现对PMS进程放行卸载等。本领域技术人员基于钩子线程相关的技术原理，应当知晓这些变通。

这里需要补充的是：术语“钩子”涵盖了用于通过拦截在软件组件之间传递的函数调用、消息、或事件来改变或增加操作系统、应用程序、或其他软件组件的行为的技术。而处理这种被拦截的函数调用、事件或消息的代码就被称为钩子hook函数。钩子通常用于各种目标，包括对功能进行调试和对功能进行扩展。其示例可以包括在键盘或鼠标事件传递到应用程序之前拦截它们，或者拦截系统调用(system call)、或者系统函数行为、函数执行结果等，以监视或修改应用程序或其他组件的功能等等。本实施例即可采用钩子hook函数接管所述应用程序运行时所需的安装自校验操作。

由此可见，通过已经预注册到系统底层的卸载服务单元11对包管理服务进程实施监控，便可截获用于卸载目标应用程序的事件行为，卸载服务单元11基于该行为可以做进一步的处理，进一步将该行为通知与其通信的客户端服务单元12。

卸载服务单元11截获卸载目标应用程序的行为后，以前述示例为基础，主要借助属于其内部构造的监控单元110实施这一操作，卸载服务单元11进而可以将该行为通知给客户端服务单元12，以交由客户端服务单元12做相应的处理，等候客户端服务单元12进行相应的处理后反馈的信息，再决定是否放行或阻止PMS进程对目标应用程序的卸载。

有必要强调卸载服务单元11与客户端服务单元12的区别。所述的客户端服务单元12，是实现了前述方法所揭示客户端服务进程的模块化构造的实例。依据Android原理，所述卸载服务单元11是注册到系统底层的，而客户端服务单元12则属于用户层的，客户端服务单元12被调用运行时，以bindService()方法建立起客户端服务单元12与卸载服务单元11之间的连接，两者之间便建立起类似于C/S架构的通信渠道，因此，客户端服务单元12与卸载服务单元11之间可以通过彼此约定的接口实现对各自功能和参数的调用。在本发明的，作为示例，所述卸载服务单元11可以在截获相应函数的Intent后，获知待卸载应用程序的包名，向客户端服务单元12传递该包名，以便客户端服务单元12据此执行后续处理。当然，实践中，卸载服务单元11可以传递给客户端服务单元12各类参数，反之客户端服务单元12也然，并不受限，本领域技术人员可以灵活实现。

因此，可以看出，客户端服务单元12所获得的通知，是基于Binder机制获得的，依据这一机制，客户端服务单元12可以顺利地与卸载服务单元11进行参数传递和相关功能调用。

所述的客户端服务单元12，其核心功能在于还原由该应用程序处理的至少部分数据后，通知该卸载服务单元11放行所述卸载应用程序的行为。

本发明的一个实施例中，客户端服务单元12是以最简化的方式执行的。因此，客户端服务单元12获得所述卸载服务单元11的通知后，作为关键功能，识别该通知所包含的包名，以确定PMS所针对的待卸载目标应用程序，然后执行还原由该应用程序处理的至少部分数据的活动。

但是，作为变例，客户端服务单元12的实现，可以结合如下多种情形演化更多的变例。需要指出的是，卸载服务单元11、客户端服务单元12以及所述待卸载的应用程序之间，可以存在多种相互结合的关系，以构成多种变例，具体如下：

1、所述待卸载的应用程序是用于实现所述卸载服务单元11、客户端服务单元12的同一安全软件。

2、所述待卸载的应用程序与客户端服务单元12属于同一应用程序，而所述卸载服务单元11由另一安全软件构建。

3、所述客户端服务单元12、卸载服务单元11均由同一安全软件构建，而独立于所述待卸载的应用程序。

以上几种变例也意味着本发明的客户端服务单元12既可以处理自身所属的应用程序的卸载前控制，也可以处理受自身保护的应用程序的卸载前控制。具体而言，卸载服务单元11通知客户端服务单元12后，客户端服务单元12提取该通知所包含的包名并先与自身所属应用程序的包名进行比较以做出判断，或者进一步判断该通知中的包名是否属于已经记录的一个受保护应用程序列表中的某一个，针对不同的判断结果，分为两种情况，执行不同的功能。

客户端服务单元12执行判断后，所划分的两种情况以及各种情况的处理逻辑如下：

1、当客户端服务单元12判断卸载服务单元11发送的通知中的包名属于受保护应用程序列表中的应用程序，或者属于客户端服务单元12自身所属的应用程序时，可以调用客户端服务单元12的控制逻辑加以处理，然后才通知卸载服务单元11放行PMS对该应用程序的卸载；

2、客户端服务单元12判断卸载服务单元11发送的通知中的包名不属于自身所在的应用程序时，或者进一步确定亦不属于受保护应用程序列表中的应用程序时，则直接通知卸载服务单元11放行PMS对该应用程序的卸载。

在本发明进一步完善的一个实施例中，所述客户端服务单元12收到卸载服务单元11的通知后，可以向系统界面弹出询问窗口，通过该窗口询问客户是否允许待卸载应用程序的卸载，提供类似于“允许”、“拒绝”的选项供用户选定，以此接收表征用户允许或不允许卸载该应用程序的指令，当到该指令后，做出两种相应的处理，其一是通知卸载服务单元11(一个实施例中是其监控单元110)放行PMS进程对待卸载应用程序的卸载；其二是通知卸载服务单元11(其监控单元110)向PMS进程返回空值以便阻止PMS进程对待卸载应用程序的卸载。

客户端服务单元12的这一处理方法，适宜前置于客户端服务单元12对包名的判断而进行，也可以仅仅针对第一种判断情况，也即包名相同的情况而执行本处理方法。具体而言，针对前后两者，也能够导致本发明产生更多的如下的变例：

对于前者，一接收到卸载服务单元11的通知即弹窗告警，如果用户允许卸载，则先判断包名是否相同(包括与客户端服务单元12自身所在的应用程序的包名和/或受保护应用程序列表中的应用程序包名比较)，如相同，进一步调用客户端服务单元12的控制逻辑加以处理，然后才通知卸载服务单元11放行PMS对该应用程序的卸载，如果包名不同，则直接通知放行卸载；如果用户不允许卸载，则通知卸载服务单元11阻止PMS进程对该应用程序的卸载。

对于后者，当客户端服务单元12接收到卸载服务单元11的通知，判断包名相同(同上)后，才弹窗告警，如果用户允许卸载，则进一步调用客户端服务单元12的控制逻辑加以处理，然后才通知卸载服务单元11放行PMS对该应用程序的卸载；如果包名不同，则直接通知放行卸载；如果用户不允许卸载，则通知卸载服务单元11阻止PMS进程对该应用程序的卸载。

如前所述，所述客户端服务单元12在用户确定允许目标应用程序被卸载后，便按照其自身实现的控制逻辑做后续处理。这一控制逻辑所实现的控制内容主要包括若干可选的方面的任意一项或任意多项。以下列出这些不同方面并加以阐释，供本领域技术人员参照：

1、通过一还原模块25中的一个子模块，还原由待卸载应用程序处理的至少部分数据，主要是指清除由该应用程序增添的数据。众所周知的，应用程序在正常使用过程中，都会产生一些数据，主要是以文件的形式保存到相关目录中，例如手机SD卡的存储目录中。一旦应用程序被删除，往往这些数据文件也不再有用，因此，可以被清理。适应这一方面，客户端服务单元12可以将待卸载应用程序所增添的这些文件夹以及相应的文件之类的数据予以删除，通过删除其产生的数据而实现将特定存储空间的数据从占有还原到清零的状态，由此而实现数据还原。

2、通过一还原模块25中的一个子模块，还原由待卸载应用程序处理的至少部分数据，主要是指恢复由待卸载应用程序修改的数据。同理，待卸载应用程序，特别是一些安全软件，或者一些涉及系统配置信息改变的软件，例如，一种可以通过修改活动管理服务进程(ActivityManagerService，AMS)的广播接收器注册数据而控制与这些广播接收器相关的应用程序的自启动能力的安全软件，此类安全软件对系统的注册数据做出了修改，因此，在其被卸载之前适宜恢复由其做出过修改的注册数据，以免影响被修改了注册信息的应用程序的正常运行。因此，本发明的客户端服务单元12可以针对这种情况或者其他类似的情况，而恢复这些数据(例如安全软件即是客户端服务单元12的宿主，该安全软件修改了所有第三方应用程序的广播接收器注册信息并且记录在一列表中，客户端服务单元12便可以通过读取该列表而获知被修改的注册数据，或者不必依赖于列表，而通过扫描所有应用程序的Androidmanifest.xml文件的配置信息，据此而恢复这些注册数据)。

3、通过一还原模块25中的一个子模块，还原由待卸载应用程序处理的至少部分数据，主要是指恢复由待卸载应用程序删除的数据。与前述第2项同理，部分软件可能出于某种目的而将某些文件删除，这些删除的文件同时被备份到临时目录。对于这种情况，客户端服务单元12便可根据已知的规则或者相关的记录信息，而将临时目录中的相应文件恢复到原位置，而实现对由待卸载应用程序删除的数据的恢复。

4、通过一还原模块25中的一个子模块，还原由待卸载应用程序处理的至少部分数据，主要是通过停止由该应用程序注册的服务进程而恢复系统的服务进程注册数据。部分应用程序运行可能构造有多个服务组件，这些服务组件在运行时分别被绑定到不同的系统服务进程中，以便提供后台服务，这些服务的突然中断可能会影响到某些数据的正常传输。或者某些服务进程未经终止，可能影响到其所属的应用程序的卸载。这些用户层的服务进程，是注册到系统服务进程中的，因此，在系统服务进程的管理链表中便存在其注册数据。本发明可以通过停止这些已注册的用户层的服务进程，而恢复系统的服务进程注册数据到不存在这些用户层服务进程的状态。

5、通过一访问模块26，调用浏览器访问预设链接的网页。软件开发者往往期望获知用户对其应用程序的使用感受，特别是卸载其应用程序的原因，以便收集用户对应用程序的意见和改进建议，以利于对其应用程序做出改进的决策。有时，在用户因为误解企图卸载该应用程序时，通过网页进行适当的引导，也有利于降低误卸载率。因此，可以在所述客户端服务单元12接收到卸载服务单元11的通知后，即通过startActivity()函数调用一个包含了链接URL的Intent，该链接指向软件开发者的一个预定网页，运行并访问该网页，与用户做进一步的人机交互。当然，这一访问网页的手段也可以在客户端服务单元12的整个生命周期的任何时间段给出，例如在其执行完其它控制逻辑之后给出，具体是在客户端服务单元12决定通知卸载待卸载应用程序之前给出即可。

可以看出，以上几种模块25、26和子模块(未图示)是可以灵活选用的，并且，通常适合应用于客户端服务单元12由待卸载应用程序实现的实例中。但是，当客户端服务单元12独立于应用程序时，遵守其与应用程序约定的协议，而在该应用程序被卸载之前，由客户端服务单元12实现上述的任意一个模块或子模块，显然也是可行的。

进一步，其中的第1至4个子模块，因其实现的功能逻辑相对契合，故可以将这些子模块构造到同一个还原模块25中。当然，所述访问模块26则相对具有独立性，可以与还原模块25并发执行或择一调用。

需要进一步指出的是，所述客户端服务单元12向卸载服务单元11反馈通知时，可以简单地只给出两种形式，即表征允许或拒绝卸载原来待卸载的应用程序的两种不同形式。因此，对于卸载服务单元11而言，只需依据客户端服务单元12的两种不同形式而做出不同的处理。PMS在卸载过程，由于被卸载服务单元11监控并截获，由于需要等候卸载服务单元11对进程资源的释放，而处于暂停状态。卸载服务单元11获得客户端服务单元12的反馈通知后，依据表征允许的通知，便可直接将进程资源交还给PMS卸载进程，放行PMS卸载进程对待卸载应用程序的卸载操作；依据表征拒绝的通知，卸载服务单元11可以将空值作为待给出的自定义数据返回给调用被截获的函数deletePackage()的上级函数，从而以类似技术欺骗的手段阻止PMS卸载原来的待卸载应用程序，实现对这一应用程序的保护。

依据前述揭示的本发明的应用程序主动防御方法或装置的精神，可以进一步提出诸多应用程序实现实例，通过不同的应用程序来进一步体现和发挥本发明的积极效果。例如：

1、通过构造一个安全软件应用程序，当该安全软件应用程序运行时，即由其注册卸载服务进程、加载客户端服务进程，并且主要由卸载服务进程监控PMS进程的卸载行为，当捕获卸载行为时，即通知客户端服务进程，客户端服务进程据该通知中的包名与自身包名进行比较，知悉用户正企图卸载安全软件应用程序自身时，即弹窗告警，当用户输入表征不允许卸载的指令时，即阻止对自身的卸载。当用户输入表征允许卸载的指令时，即执行文件资源清理、注册数据还原、以及停止其他相关服务等功能，同时调用网页对用户意见进行调查，然后才通知该卸载服务进程放行PMS的卸载。

2、同理可以通过在系统中安装前述的安全软件来实现注册所述的系统卸载服务进程，并且通过该安全软件来管理与其存在协议关系的其他应用程序。这些应用程序遵守这种协议，构造用于与安全软件的卸载服务进程通信的客户端服务进程，以便接收卸载服务进程的通知，而实现自我保护。这种情况下，安全软件可以将这些具有自我保护功能的应用程序包含到一个受保护应用程序列表中，当安全软件的客户端服务进程判断包名属于受保护应用程序时，即转发给相应的受保护应用程序的客户端服务进程。或者，卸载服务单元11直接将通知发送给与自身存在协议关系的多个应用程序的客户端服务进程，由各客户端服务进程判别是否属于删除自身所在的应用程序，当属于这种情况时，参照前述揭示的方案执行后续处理。当卸载服务进程可以以多个客户端服务进程针对同一待卸载应用程序反馈的通知为基础做出自身的后续处理，具体而言，当多个通知中有一个通知未到达时，则即使其他通知指示可以放行卸载，但卸载服务进程也不实际放行PMS进程的卸载，而是等待所有通知均告达时才放行。或者，卸载服务进程可以依据其中一个表征“暂停”的通知，而继续等待该通知的发送方的后续通知，并以该后续通知为依据做进一步处理。

通过上述两个应用实例的阐释，可以知晓，本发明的应用程序主动防御方法或装置，可以实现对整个应用程序的卸载过程的全程追踪，从而可以实现对这一卸载过程的干预，对该应用程序起到保护、善后等作用。

为了进一步体现本发明所述的应用实例，以下以前述第2种应用实例为基础，着重于应用层面，揭示一种应用程序自我保护方法。

如前所述，在Android操作系统中，安装有如前所述的安全软件，该安全软件配置有所述的卸载服务进程，据以实现一个如前所述的卸载服务进程。

参阅图3，本发明的应用程序自我保护方法以此为应用环境，包括如下步骤：

步骤S21、建立应用程序的客户端服务进程与系统底层的卸载服务进程的通信。

按照前一方法的一个实施例所揭示，本方法的应用程序配置有一个用于实现所述客户端服务进程的服务组件，该服务组件被配置于该应用程序的Androidmanifest.xml文件中，在应用程序安装时即向系统进行注册，因此可作为用户层的服务进程运行于系统的后台。

当客户端服务进程得以运行时，便通过bindService()函数将自己与所述安全软件的卸载服务进程进行绑定，建立基于Binder机制的通信渠道。据此，客户端服务进程便可以接收卸载服务进程发送的包含待卸载应用程序包名的通知，也可以向卸载服务进程发送表征允许或不允许(拒绝、阻止)PMS进程继续执行卸载应用程序动作的通知。

步骤S22、由所述客户端服务进程接收所述卸载服务进程的表征卸载该应用程序的通知。

所述卸载服务进程如前所述，直接截获，或者通过其内建的监控单元110截获包管理服务进程(PMS)对deletePackage()等函数的调用之后，向客户端服务进程发送从传递给这些函数的Intent中(当然也可以适应具体实例而利用其它变量形式)获得的包名的通知，该通知即用于告知客户端服务进程，指出PMS进程正试图卸载某应用程序，客户端服务进程接收并在后续处理该通知。所述卸载服务进程向客户端服务进程传递包名，可以直接转发该Intent给客户端服务进程，也可以自身提取该Intent所包含的包名后提供给客户端服务进程。

步骤S23、由所述客户端服务进程判断该通知中包含本应用程序包名时，弹窗以问询用户意向。

所述客户端服务进程接收到该通知后，主要任务在于获取其中所包含的待卸载应用程序的包名，然后比较该包名是否是自身所在的应用程序的包名，当该包名属于自身时，向桌面弹出一询问窗口，以询问用户意向。如前所述，弹窗可以设定“允许”、“拒绝”之类的二选一的选项，并且默认一个时间周期，以便在该时间周期内未收到用户选定指令时，视为用户选定了“拒绝”选区。

步骤S24、当客户端服务进程非接收到表征允许卸载的指令时，通知卸载服务进程阻止卸载。本步骤进一步包括如下子步骤：

当客户端服务进程弹窗后，等候用户回复。当用户选定了“允许”选区时，客户端服务进程通过该弹窗接收到这个表征允许本应用程序被卸载的指令，否则，当用户选定了“拒绝”选区，或者当用户在所述时间周期内未进行任何选定操作时，客户端服务进程均可以产生表征不允许本应用程序被卸载的指令。客户端服务进程继而将这些指令以反馈通知的形式通知给所述的卸载服务进程，所述卸载服务进程则因应反馈通知所包含的不同表征意义的指令做不同的响应处理。

当所述卸载服务进程收到表征不允许(或称拒绝、阻止)卸载本应用程序的指令的相关反馈通知时，如前所述，可以向PMS进程返回空值，从而终止PMS进程对本应用程序的卸载操作，有效地保护了本程序免于被卸载。

当所述卸载服务进程收到表征允许卸载本应用程序的指令的相关反馈通知时，如前所述，可以继续PMS进程的正常执行，以允许卸载服务进程放行PMS进程对本应用程序的卸载操作。

因此，上述的实例出于安全考虑，仅当接收到表征允许卸载的指令时，通知卸载服务进程放行卸载。而将用户未对弹窗进行选定以及客户在弹窗中选定了“拒绝”选区，视为客户端服务进程非接收到表征允许卸载的指令，从而一律通知卸载服务进程阻止PMS进程对本应用程序的卸载。

参阅前述的方法，作为进一步的实施例，本方法在允许本应用程序被卸载时，先于通知所述卸载服务进程放行卸载而可以通过一还原模块25和/或访问模块26实现卸载前的控制逻辑。

这一控制逻辑所实现的控制内容主要包括若干可选的方面的任意一项或任意多项。以下列出这些不同方面并加以阐释，供本领域技术人员参照：

1、通过还原模块25中的一个子模块，还原由本应用程序处理的至少部分数据，主要是指清除由本应用程序增添的数据。众所周知的，应用程序在正常使用过程中，都会产生一些数据，主要是以文件的形式保存到相关目录中，例如手机SD卡的存储目录中。一旦应用程序被删除，往往这些数据文件也不再有用，因此，可以被清理。适应这一方面，客户端服务进程可以将待卸载应用程序所增添的这些文件夹以及相应的文件之类的数据予以删除，通过删除其产生的数据而实现将特定存储空间的数据从占有还原到清零的状态，由此而实现数据还原。

2、通过还原模块25中的一个子模块，还原由本应用程序处理的至少部分数据，主要是指恢复由本应用程序修改的数据。同理，本应用程序，例如，是一种可以通过修改活动管理服务进程(ActivityManagerService，AMS)的广播接收器注册数据而控制与这些广播接收器相关的应用程序的自启动能力的安全软件，本应用程序基于安全考虑对系统的注册数据做出了修改，因此，在其被卸载之前适宜恢复由其做出过修改的注册数据，以免影响被修改了注册信息的应用程序的正常运行。因此，本发明的客户端服务进程可以针对这种情况或者其他类似的情况，而恢复这些数据(例如本应用程序修改了所有第三方应用程序的广播接收器注册信息并且记录在一列表中，客户端服务进程便可以通过读取该列表而获知被修改的注册数据，或者不必依赖于列表，而通过扫描所有应用程序的Androidmanifest.xml文件的配置信息，据此而恢复这些注册数据)。

3、通过还原模块25中的一个子模块，还原由本应用程序处理的至少部分数据，主要是指恢复由本应用程序删除的数据。与前述第2项同理，本应用程序可能出于某种目的而将某些文件删除，这些删除的文件同时被备份到临时目录。对于这种情况，客户端服务进程便可根据已知的规则或者相关的记录信息，而将临时目录中的相应文件恢复到原位置，而实现对由本应用程序删除的数据的恢复。

4、通过还原模块25中的一个子模块，还原由本应用程序处理的至少部分数据，主要是通过停止由本应用程序注册的服务进程而恢复系统的服务进程注册数据。本应用程序运行可能构造有多个服务组件，这些服务组件在运行时分别被绑定到相应的系统服务进程中，以便提供后台服务，这些服务的突然中断可能会影响到某些数据的正常传输。或者某些服务进程未经终止，可能影响到其本应用程序的卸载。这些用户层的服务进程，是注册到系统服务进程中的，因此，在系统服务进程的管理链表中便存在其注册数据。本发明可以通过停止这些已注册的用户层的服务进程，而恢复系统的服务进程注册数据到不存在这些用户层服务进程的状态。

5、通过访问模块26，调用浏览器访问预设链接的网页。软件开发者往往期望获知用户对其应用程序的使用感受，特别是卸载其应用程序的原因，以便收集用户对应用程序的意见和改进建议，以利于对其应用程序做出改进的决策。有时，在用户因为误解企图卸载该应用程序时，通过网页进行适当的引导，也有利于降低误卸载率。因此，可以在所述客户端服务进程接收到卸载服务进程的通知后，即通过startActivity()函数调用一个包含了链接URL的Intent，该链接指向软件开发者的一个预定网页，运行并访问该网页，与用户做进一步的人机交互。当然，这一访问网页的手段也可以在客户端服务进程的整个生命周期的任何时间段给出，例如在其执行完其它控制逻辑之后给出，具体是在客户端服务进程决定通知卸载本应用程序之前给出即可。

可以看出，以上几种模块和子模块是可以灵活选用的，并且，通常适合应用于客户端服务进程由本应用程序实现的实例中。

进一步，其中的第1至4个子模块，因其实现的功能逻辑相对契合，故可以将这些子模块构造到同一个还原模块25中。当然，所述访问模块26则相对具有独立性，可以与还原模块25并发执行或择一调用。

同理，参阅图4，依据计算机程序的功能模块化设计逻辑，进一步揭示一种应用程序自我保护装置的实例，该装置主要通过实例化前述方法中的客户端服务进程而构造一个客户端服务单元12。所述客户端服务单元12包括通信模块21、接收模块22、交互模块23、响应模块24，以及在包括在部分变化实施例中的还原模块25、访问模块26。以下对各个具体模块所实现的功能做进一步的阐述。

所述的通信模块21，用于建立本客户端服务单元12与系统底层的卸载服务单元11的通信。

本应用程序配置有一个用于构造所述客户端服务单元12的服务组件，该服务组件被配置于该应用程序的Androidmanifest.xml文件中，在应用程序安装时即向系统进行注册，因此可作为用户层的服务进程运行于系统的后台。

当客户端服务单元12得以运行时，便通过通信模块21调用bindService()函数将客户端服务单元12与所述安全软件的卸载服务单元11进行绑定，建立基于Binder机制的通信渠道。据此，客户端服务单元12便可以接收卸载服务单元11发送的包含待卸载应用程序包名的通知，也可以向卸载服务单元11发送表征允许或不允许(拒绝、阻止)PMS进程继续执行卸载应用程序动作的通知。

所述的接收模块22，用于接收所述卸载服务单元11的表征卸载该应用程序的通知。

所述卸载服务单元11如前所述，直接截获，或者通过其内建的监控单元110截获包管理服务进程(PMS)对deletePackage()等函数的调用之后，向客户端服务单元12发送从传递给这些函数的Intent中(当然也可以适应具体实例而利用其它变量形式)获得的包名的通知，该通知即用于告知客户端服务单元12，指出PMS进程正试图卸载某应用程序，客户端服务单元12通过接收模块22接收以便在后续处理该通知。所述卸载服务单元11向客户端服务单元12传递包名，可以直接转发该Intent给客户端服务单元12的接收模块22，也可以自身提取该Intent所包含的包名后提供给客户端服务单元12的接收模块22。

所述的交互模块23，用于判断该通知中包含本应用程序包名时，弹窗以问询用户意向。

所述客户端服务单元12的接收模块22接收到该通知后，交由交互模块23获取其中所包含的待卸载应用程序的包名，然后比较该包名是否是本应用程序自身所在的应用程序的包名，当该包名属于本应用程序自身的包名时，向桌面弹出一询问窗口，以询问用户意向。如前所述，弹窗可以设定“允许”、“拒绝”之类的二选一的选项，并且默认一个时间周期，以便在该时间周期内未收到用户选定指令时，视为用户选定了“拒绝”选区。

所述的响应模块24，被配置为当客户端服务单元12非接收到表征允许卸载的指令时，通知卸载服务单元11阻止卸载。

具体而言，所述的客户端服务单元12中，当交互模块23弹窗后，等候用户回复。当用户选定了“允许”选区时，客户端服务单元12的响应模块24通过该弹窗接收到这个表征允许本应用程序被卸载的指令，否则，当用户选定了“拒绝”选区，或者当用户在所述时间周期内未进行任何选定操作时，客户端服务单元12的响应模块24均可以产生表征不允许本应用程序被卸载的指令。响应模块24继而将这些指令以反馈通知的形式通知给所述的卸载服务单元11，所述卸载服务单元11则因应反馈通知所包含的不同表征意义的指令做不同的响应处理。

当所述卸载服务单元11收到表征不允许(或称拒绝、阻止)卸载本应用程序的指令的相关反馈通知时，如前所述，可以向PMS进程返回空值，从而终止PMS进程对本应用程序的卸载操作，有效地保护了本程序免于被卸载。

当所述卸载服务单元11收到表征允许卸载本应用程序的指令的相关反馈通知时，如前所述，可以继续PMS进程的正常执行，以允许卸载服务单元11放行PMS进程对本应用程序的卸载操作。

因此，上述的实例出于安全考虑，所述响应模块24，仅当接收到表征允许卸载的指令时，通知卸载服务单元11放行卸载。而将用户未对弹窗进行选定以及客户在弹窗中选定了“拒绝”选区，视为响应模块24非接收到表征允许卸载的指令，从而一律通知卸载服务单元11阻止PMS进程对本应用程序的卸载。

作为进一步的实施例，本装置的客户端服务单元12在允许本应用程序被卸载时，先于通知所述卸载服务单元11放行卸载而可以通过一还原模块25和/或访问模块26实现卸载前的控制逻辑。

这一控制逻辑所实现的控制内容主要包括若干可选的方面的任意一项或任意多项。以下列出这些不同方面并加以阐释，供本领域技术人员参照：

1、通过还原模块25中的一个子模块，还原由本应用程序处理的至少部分数据，主要是指清除由本应用程序增添的数据。众所周知的，应用程序在正常使用过程中，都会产生一些数据，主要是以文件的形式保存到相关目录中，例如手机SD卡的存储目录中。一旦应用程序被删除，往往这些数据文件也不再有用，因此，可以被清理。适应这一方面，客户端服务单元12可以将待卸载应用程序所增添的这些文件夹以及相应的文件之类的数据予以删除，通过删除其产生的数据而实现将特定存储空间的数据从占有还原到清零的状态，由此而实现数据还原。

2、通过还原模块25中的一个子模块，还原由本应用程序处理的至少部分数据，主要是指恢复由本应用程序修改的数据。同理，本应用程序，例如，是一种可以通过修改活动管理服务进程(ActivityManagerService，AMS)的广播接收器注册数据而控制与这些广播接收器相关的应用程序的自启动能力的安全软件，本应用程序基于安全考虑对系统的注册数据做出了修改，因此，在其被卸载之前适宜恢复由其做出过修改的注册数据，以免影响被修改了注册信息的应用程序的正常运行。因此，本发明的客户端服务单元12可以针对这种情况或者其他类似的情况，而恢复这些数据(例如本应用程序修改了所有第三方应用程序的广播接收器注册信息并且记录在一列表中，客户端服务单元12便可以通过读取该列表而获知被修改的注册数据，或者不必依赖于列表，而通过扫描所有应用程序的Androidmanifest.xml文件的配置信息，据此而恢复这些注册数据)。

3、通过还原模块25中的一个子模块，还原由本应用程序处理的至少部分数据，主要是指恢复由本应用程序删除的数据。与前述第2项同理，本应用程序可能出于某种目的而将某些文件删除，这些删除的文件同时被备份到临时目录。对于这种情况，客户端服务单元12便可根据已知的规则或者相关的记录信息，而将临时目录中的相应文件恢复到原位置，而实现对由本应用程序删除的数据的恢复。

4、通过还原模块25中的一个子模块，还原由本应用程序处理的至少部分数据，主要是通过停止由本应用程序注册的服务进程而恢复系统的服务进程注册数据。本应用程序运行可能构造有多个服务组件，这些服务组件在运行时分别被绑定到相应的系统服务进程中，以便提供后台服务，这些服务的突然中断可能会影响到某些数据的正常传输。或者某些服务进程未经终止，可能影响到其本应用程序的卸载。这些用户层的服务进程，是注册到系统服务进程中的，因此，在系统服务进程的管理链表中便存在其注册数据。本发明可以通过停止这些已注册的用户层的服务进程，而恢复系统的服务进程注册数据到不存在这些用户层服务进程的状态。

5、通过访问模块26，调用浏览器访问预设链接的网页。软件开发者往往期望获知用户对其应用程序的使用感受，特别是卸载其应用程序的原因，以便收集用户对应用程序的意见和改进建议，以利于对其应用程序做出改进的决策。有时，在用户因为误解企图卸载该应用程序时，通过网页进行适当的引导，也有利于降低误卸载率。因此，可以在所述客户端服务单元12接收到卸载服务单元11的通知后，即通过startActivity()函数调用一个包含了链接URL的Intent，该链接指向软件开发者的一个预定网页，运行并访问该网页，与用户做进一步的人机交互。当然，这一访问网页的手段也可以在客户端服务单元12的整个生命周期的任何时间段给出，例如在其执行完其它控制逻辑之后给出，具体是在客户端服务单元12决定通知卸载本应用程序之前给出即可。

可以看出，以上几种模块和子模块是可以灵活选用的，并且，通常适合应用于客户端服务单元12由本应用程序实现的实例中。

进一步，其中的第1至4个子模块，因其实现的功能逻辑相对契合，故可以将这些子模块构造到同一个还原模块25中。当然，所述访问模块26则相对具有独立性，可以与还原模块25并发执行或择一调用。

结合前述实现自我保护应用程序的卸载过程的方案，可以看出，本发明的整体构思也适用于单个的应用程序。这种自我保护的方案，适合结合到沙箱应用程序加固技术中实现，然后通过加固后的应用程序与实现了沙箱技术的安全软件互相配合，更有利于巩固对应用程序的保护，避免应用程序被误卸载或者被恶意卸载。

由于本发明的实施，无论是将本发明的整体构思实现于诸如“360手机卫士”之类的专门的安全软件，还是将其实现为与“360手机卫士”相配合的加固应用程序，均可以实现对应用程序的保护功能，即使应用程序被善意卸载，也能进一步通过清理无效资源、还原相关数据等来实现更为高效的系统资源配置。

综上所述，本发明能够实现对操作系统卸载应用程序过程的监听，能够前置于该应用程序被卸载而进行相关的预前处理，本质上是实现了安全技术中的主动防御功能，可以更有效地保护应用程序的安全。

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

Claims (10)

1.一种应用程序主动防御方法，其特征在于，包括以下步骤：

由注册到系统底层的卸载服务进程截获卸载该应用程序的行为；

由卸载服务进程将该行为通知与其通信的客户端服务进程；

由客户端服务进程还原由该应用程序处理的至少部分数据后，通知该卸载服务进程放行所述卸载应用程序的行为。

2.根据权利要求1所述的应用程序主动防御方法，其特征在于，所述卸载服务进程通过钩子函数挂钩包管理服务进程的与卸载应用程序相关的函数的运行入口点而截获所述卸载应用程序的行为，并通过向该相关函数的调用者返回自定义数据而恢复所述包管理服务进程的运行。

3.根据权利要求2所述的应用程序主动防御方法，其特征在于，该钩子函数具体通过监控包管理服务进程调用deletePackage()函数而截获所述的行为。

4.根据权利要求1所述的应用程序主动防御方法，其特征在于，当且仅当所述客户端服务进程从其接收到的通知中判断出待卸载的应用程序为该客户端服务进程所属的应用程序时，才执行所述还原数据并通知卸载服务进程放行卸载的步骤，否则通知所述卸载服务进程直接放行卸载所述应用程序。

5.根据权利要求4所述的应用程序主动防御方法，其特征在于，通过比较所述通知中所包含的包名与所述客户端服务进程所属应用程序的包名是否相同，而确定待卸载应用程序是否为该客户端服务进程所属的应用程序。

6.根据权利要求1所述的应用程序主动防御方法，其特征在于，所述客户端服务进程收到卸载服务进程的通知后，弹出询问窗口，当且仅当接收到通过该窗口输入的表征允许卸载所述应用程序的指令时，才执行所述还原数据并通知卸载服务进程放行的步骤；否则通知所述卸载服务进程阻止卸载所述应用程序。

7.根据权利要求1所述的应用程序主动防御方法，其特征在于，所述还原由该应用程序处理的至少部分数据的过程，包括执行如下操作中的一种或任意多种：

清除由该应用程序增添的数据；

恢复由该应用程序修改的数据；

恢复由该应用程序删除的数据；

通过停止由该应用程序注册的服务进程而恢复系统的服务进程注册数据。

8.一种应用程序主动防御装置，其特征在于，包括：

卸载服务单元，预注册到系统底层，用于截获卸载该应用程序的行为，且将该行为通知与其通信的客户端服务进程；

客户端服务单元，用于还原由该应用程序处理的至少部分数据后，通知该卸载服务进程放行所述卸载应用程序的行为。

9.一种应用程序自我保护方法，其特征在于，包括如下步骤：

建立应用程序的客户端服务进程与系统底层的卸载服务进程的通信；

由所述客户端服务进程执行如下过程：

接收所述卸载服务进程的表征卸载该应用程序的通知；

判断该通知中包含本应用程序包名时，弹窗以问询用户意向；

当非接收到表征允许卸载的指令时，通知卸载服务进程阻止卸载。

10.一种应用程序自我保护装置，其特征在于，包括客户端服务单元，该单元进一步包括：

通信模块，用于建立客户端服务单元与系统底层的卸载服务单元的通信；

接收模块，用于接收所述卸载服务进程的表征卸载该应用程序的通知；

交互模块，用于判断该通知中包含本应用程序包名时，弹窗以问询用户意向；

响应模块，被配置为当非接收到表征允许卸载的指令时，通知卸载服务进程阻止卸载。