CN105138372A - 一种基于Android系统的后台服务管控系统及方法 - Google Patents

Abstract

本发明公开了一种基于Android系统的后台服务管控方法，包括：创建数据库表；应用启动服务时，判断所述服务否存储在数据库表中；在所要启动服务的应用存储在数据库表中时，则启动所要启动服务的应用相应的服务，同时禁止其它应用启动对应的服务。本发明所提供的后台服务管控方法实现了从软硬件级保护系统的完整性，在启动阶段和运行阶段都可以对系统的完整性运行可信衡量；在启动过程中启动完整性通过检测的程序，对系统程序被恶意修改过和程序实施不启动和报告操作；实现了对移动终端进入系统时作了安全防护技术，提高了系统的抗攻击性；实现了在系统运行阶段实现的检测系统的安全性，对关键参数和代码作完整性度量。

Description

一种基于Android系统的后台服务管控系统及方法

技术领域

本发明涉及计算机通讯技术领域，尤其涉及一种基于Android系统的后台服务管控系统及方法。

背景技术

随着智能手机的大量普及，越来越多功能新颖、创意十足的应用不断地给用户带来学习以及生活上的乐趣与便利，而人们在日常生活中也越来越离不开这些应用。当前，市场上很多应用都使用了消息推送功能，且很多应用都使用同一家公司提供的推送功能，这些推送机制除了给应用推送实时消息以外，还能知道所有使用了该推送功能的应用包名和后台服务名，进而让使用了该推送机制的所有应用之间进行相互唤醒后台服务，以达到实时接收消息和延长应用驻留时间。

但是对于Android智能手机用户而言，经常会遇到用户为了省电将一些应用结束后，这些应用在后台服务又偷偷运行起来，并且每次都是几个固定的应用同时运行的问题。原因是这些应用使用了同一个公司的消息推送接口，当其中一个应用被结束后，其它使用了同一个消息推送接口的应用会再次唤醒该应用的后台服务。

Android中多个应用之间相互唤醒后台服务(Service)属于应用自启的一种途径，目前现有自启管控实现方案大多对后台自启行为和开机自启行为进行管控，实际上只是简单对用于监听网络变化和系统开机的广播接收器进行控制，设置其为可用与不可用，以阻止应用通过收到广播后启动服务的自启行为。而这种自启管控方法对多个应用之间相互唤醒后台服务的行为无法有效管控。

发明内容

本发明的主要目的在于解决现有技术中多应用之间相互唤醒后台服务的问题，在有效阻止后台服务被其它应用唤醒的同时，确保后台服务能够被所属应用启动，达到对应用程序自启的有效管控。

为实现上述目的，本发明提供的一种基于Android系统的后台服务的管控方法，所述方法包括以下步骤：

创建数据库表，其中，所述数据库表中包括：应用的应用包名以及应用身份标识；存储在所述数据库表中的应用的后台服务仅能通过对应的应用自启进行启动，其它应用禁止启动；

应用启动服务时，根据所要启动服务的应用的应用包名和应用身份标识判断所述服务是否存储在所述数据库表中；在所要启动服务的应用存储在所述数据库表中时，则启动所要启动服务的应用相应的服务，同时禁止其它应用启动所述对应的服务。

进一步地，所述根据所要启动服务的应用的应用包名和应用身份标识判断所述服务是否存储在所述数据库表中包括以下步骤：

获取所要启动服务的应用的应用包名；

查询所述数据库表中是否存储有所述应用包名对应的应用身份标识，若存在，获取所要启动服务的应用的应用身份标识；

判断所要启动服务的应用的应用身份标识与所述数据库表中查询得到的应用身份标识是否相同，若相同，则所要启动服务的应用存储在所述数据库表中。

进一步地，所述数据库表还用于存储应用自启管控状态，

若所述应用自启管控状态为关闭状态时，则将对应应用的应用包名、应用身份标识和对应的应用自启管控状态存储入所述数据库表中；

若所述应用自启管控状态为开启状态时，则将对应应用的应用包名以及应用身份标识从所述数据库表中删除。

进一步地，对所述数据库表中的数据通过内容解析器进行查询。

进一步地，通过所述数据库表的内容提供器接口与外部设备进行查询、和/或增加、和/或删除、和/或记录操作。

本发明还提供了一种基于Android系统的后台服务管控系统，所述系统包括：数据库表、存储判断模块以及开关控制模块；

所述数据库表中包括：应用的应用包名以及应用身份标识；存储在所述数据库表中的应用的后台服务仅能通过对应的应用自启进行启动，其它应用禁止启动；

所述存储判断模块，用于应用启动服务时，根据所要启动服务的应用的应用包名和应用身份标识判断所述服务是否存储在所述数据库表中；

所述开关控制模块，用于在所要启动服务的应用存储在所述数据库表中时，启动所要启动服务的应用相应的服务，同时禁止其它应用启动所述对应的服务。

进一步地，所述存储判断模块用于，

获取所要启动服务的应用的应用包名；

查询所述数据库表中是否存储有所述应用包名对应的应用身份标识，若存在，获取所要启动服务的应用的应用身份标识；

判断所要启动服务的应用的应用身份标识与所述数据库表中查询得到的应用身份标识是否相同，若相同，则所要启动服务的应用存储在所述数据库表中。

进一步地，所述数据库表还包括：应用的应用自启管控状态，

若所述应用自启管控状态为关闭状态时，则将对应应用的应用包名、应用身份标识和对应的应用自启管控状态存储入所述数据库表中；

若所述应用自启管控状态为开启状态时，则将对应应用的应用包名以及应用身份标识从所述数据库表中删除。

进一步地，所述数据库表中的数据通过内容解析器进行查询。

进一步地，还包括：所述数据库表的内容提供器接口，用于与外部设备进行查询、和/或增加、和/或删除、和/或记录。

本发明所提供的后台服务管控方法实现了从软硬件级保护系统的完整性，在启动阶段和运行阶段都可以对系统的完整性运行可信衡量；在启动过程中启动完整性通过检测的程序，对系统程序被恶意修改过和程序实施不启动和报告操作；实现了对移动终端进入系统时作了安全防护技术，提高了系统的抗攻击性；实现了在系统运行阶段实现的检测系统的安全性，对关键参数和代码作完整性度量。

附图说明

图1为本发明实施例提供的一种基于Android系统的后台服务管控方法的步骤流程图；

图2为本发明实施例提供的SQLite数据库表维护流程图；

图3为本发明实施例提供的启动后台服务时的处理逻辑流程图；

图4为本发明实施例提供的一种基于Android系统的后台服务管控系统的系统框图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

以下结合说明书附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明，并且在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

Android系统中服务的启动有startService和bindService两种，以bindService方式启动的服务生命周期短，在绑定它的活动(Activity)或服务结束后，此类服务也就结束了。而以startService方式启动的服务生命周期长，这种服务只有通过显示调用stopService或Service的stopSelf方法才能结束。

而Android系统中的startService启动有两种途径：

第一种途径是在Activity、Service和Application中调用startService方法，而startService方法是Context类的，其实Activity、Service和Application都是继承于Context抽象类，frameworks\base\core\java\android\content\Context.java类中抽象方法startService(Intentservice)，该方法由Context的子类ContextImpl实现，而ContextImpl类调用ActivityManagerNative.getDefault()得到ActivityManagerProxy对象，通过ActivityManagerNative.getDefault().startService()将启动服务的任务交给了ActivityManagerService类来完成，全路径为frameworks\base\services\java\com\android\server\am\ActivityManagerService.java，即最终的启动服务的任务其实是ActivityManagerService来完成的。

第二种途径是通过am指令启动服务，如：amstartService-npkgname/serviceclass，即可启动一个服务。其实，执行该指令启动服务本质上还是通过ActivityManagerService的startService方法来启动服务。

由以上两种启动后台服务的途径可以得出结论：所有启动应用后台服务的方法本质上都是通过ActivityManagerService的startService方法实现的。本发明实施例在分析启动后台服务原理的基础上，通过修改Androidframework层中的ActivityManagerService代码，进而扩展启动后台服务时的处理逻辑流程，使Android设备(包括Android智能手机、平板电脑等设备)具备能够有效阻止多个应用之间通过相互唤醒后台服务的机制而达到应用的自启，同时也确保了后台服务能够被所属应用启动，达到对应用程序自启的有效管控。

参照图1，图1为本发明实施例提供的一种基于Android系统的后台服务管控方法的步骤流程图。本发明提供了的一种基于Android系统的后台服务的管控方法，所述方法包括以下步骤：

步骤S101：创建数据库表，其中，数据库表中包括：应用包名以及应用身份标识(UID)；数据库表中存储的应用只能自启后台服务，而未存储在上述数据库表中的其它应用均被禁止启动该应用的后台服务。本实施例中的数据库表为SQLite数据库表，SQLite数据库是一个开源的嵌入式关系数据库，实现自包容、零配置、支持事务的SQL数据库引擎。具有高度便捷、使用方便、结构紧凑、高效性、高可靠性等特点。与其它数据库管理系统不同的是，SQLite的安装和运行非常简便，在大多情况下，只要确保SQLite的二进制文件存在即可开始创建、连接和使用数据库。

存储在SQLite数据库表中的应用的后台服务仅能通过自启的方式进行启动，其它应用则禁止启动存储在SQLite数据库表中的应用；

步骤S102：应用启动服务时，根据所要启动服务的应用的应用包名和应用身份标识判断该服务是否存储在SQLite数据库表中；；以及

步骤S103：在所要启动服务的应用存储在SQLite数据库表中时，则启动所要启动服务的应用相应的服务，同时禁止其它应用启动对应的服务。

进一步地，步骤S102具体为：获取所要启动服务的应用的应用包名；查询SQLite数据库表中是否存储有应用包名对应的应用身份标识，若SQLite数据库表中存在上述应用身份标识，获取所要启动服务的应用的应用身份标识；判断所要启动服务的应用的应用身份标识与SQLite数据库表中查询得到的应用身份标识是否相同，若相同，则所要启动服务的应用存储在SQLite数据库表中，具体参详下文参照图3。

当所要启动服务的应用存储在SQLite数据库表中时，除当前所要启动服务的应用以外的其它应用均停止启动所要启动的服务，即禁止后台服务的自启操作；当所要启动服务的应用没有存储在SQLite数据库表中时，继续启动当前所要启动的服务，即打开后台服务的自启操作。

进一步地，本发明实施例提供的一种基于Android系统的后台服务管控方法不仅能够阻止多个应用之间通过相互唤醒后台服务的机制而达到应用的自启，同时也确保了后台服务能够被所属应用启动，即实现了提供管控应用的开关作用。

进一步地，SQLite数据库表还用于存储应用自启管控状态，若应用自启管控状态为关闭状态时，则将对应应用的应用包名、应用身份标识和对应的应用自启管控状态存储入SQLite数据库表中；若应用自启管控状态为开启状态时，则将对应应用的应用包名以及应用身份标识从SQLite数据库表中删除。能够实时地对SQLite数据库表中的数据进行更新，进而达到更有效的对应用后台服务启动的管控。

进一步地，对于本实施例中SQLite数据库表中的数据查询操作是通过内容解析器(ContentResolver)进行查询的。

进一步地，本实施例中还为SQLite数据库表提供了内容提供器(ContentProvider)接口，通过ContentProvider与外部Android设备等进行数据的查询、和/或增加、和/或删除、和/或记录操作。

参照图2，图2为本发明实施例提供的SQLite数据库表维护流程图。首先创建一个存放应用包名和应用UID的SQLite数据库表，列出Android设备中所有应用及其自启管控状态，存储在SQLite数据库表中存放的应用状态为开启自启状态，未存储在SQLite数据库表中的应用状态为禁止自启状态。当用户执行关闭操作时，将相应应用的应用包名和应用UID存放入SQLite数据库表，当用户执行打开操作时，则根据相应应用的应用包名，把该应用从SQLite数据库表中删除。

参照图3，图3为本发明实施例提供的启动后台服务时的处理逻辑流程图。图3呈现了ActivityManagerService启动服务时的处理逻辑补充。如图3所示，在启动服务之前，首先通过Intent获取需要启动服务所属应用的应用包名，再根据此应用包名从SQLite数据库表中查询出此应用对应的应用身份标识UID1。若UID1不存在，说明Service所属应用允许其它应用启动该应用服务，此时启动服务后结束；若UID1存在，说明该应用的所有服务只限于自启的启动方式，其它应用将无法启动该应用的后台服务。此时先通过Binder.getCallingUid()获取启动服务的应用的应用身份标识UID2，再判断UID1与UID2是否相等，即进行判断启动后台服务的应用是否就是Service所属的应用本身，如果是，则直接启动服务，否则直接退出结束进程。进一步地，图3中启动服务的操作是ActivityManagerService中原有操作，本实施例在此不进行赘述。

参照图4，图4为本发明实施例提供的一种基于Android系统的后台服务管控系统的系统框图。本发明还提供了一种基于Android系统的后台服务管控系统，系统包括：SQLite数据库表401、存储判断模块402以及开关控制模块403；

SQLite数据库表401中包括：应用的应用包名以及应用身份标识；存储在SQLite数据库表401中的应用的后台服务仅能通过对应的应用自启进行启动，其它应用禁止启动；

存储判断模块402，用于应用启动服务时，根据所要启动服务的应用的应用包名和应用身份标识判断该服务是否存储在SQLite数据库表401中；

开关控制模块403，用于在所要启动服务的应用存储在SQLite数据库表401中时，启动所要启动服务的应用相应的服务，同时禁止其它应用启动对应的服务。

进一步地，存储判断模块402用于，获取所要启动服务的应用的应用包名；查询SQLite数据库表401中是否存储有应用包名对应的应用身份标识，若存在，获取所要启动服务的应用的应用身份标识；判断所要启动服务的应用的应用身份标识与SQLite数据库表401中查询得到的应用身份标识是否相同，若相同，则所要启动服务的应用存储在SQLite数据库表401中。

当所要启动服务的应用存储在SQLite数据库表中时，除当前所要启动服务的应用以外的其它应用均停止启动所要启动的服务，即禁止后台服务的自启操作；

当所要启动服务的应用没有存储在SQLite数据库表中时，继续启动所述当前所要启动的服务，即打开后台服务的自启操作。

进一步地，SQLite数据库表401还包括：应用的应用自启管控状态，若应用自启管控状态为关闭状态时，则将对应应用的应用包名、应用身份标识和对应的应用自启管控状态存储入SQLite数据库表401中；若应用自启管控状态为开启状态时，则将对应应用的应用包名以及应用身份标识从SQLite数据库表401中删除。

因此，通过使用本发明实施例提供的基于Android系统的后台服务管控方法使Android设备(包括Android智能手机、平板电脑等设备)具备能够有效阻止多个应用之间通过相互唤醒后台服务的机制而达到应用的自启，同时也确保了后台服务能够被所属应用启动，达到对应用程序自启的有效管控作用。本发明所提供的基于Android系统的后台服务管控方法实现了从软硬件级保护系统的完整性，在启动阶段和运行阶段都可以对系统的完整性运行可信衡量；在启动过程中启动完整性通过检测的程序，对系统程序被恶意修改过和程序实施不启动和报告操作；实现了对移动终端进入系统时作了安全防护技术，提高了系统的抗攻击性；实现了在系统运行阶段实现的检测系统的安全性，对关键参数和代码作完整性度量。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种基于Android系统的后台服务管控方法，其特征在于，所述方法包括以下步骤：

创建数据库表，其中，所述数据库表中包括：应用的应用包名以及应用身份标识；存储在所述数据库表中的应用的后台服务仅能通过对应的应用自启进行启动，其它应用禁止启动；

应用启动服务时，根据所要启动服务的应用的应用包名和应用身份标识判断所述服务是否存储在所述数据库表中；在所要启动服务的应用存储在所述数据库表中时，则启动所要启动服务的应用相应的服务，同时禁止其它应用启动所述对应的服务。

2.如权利要求1所述的后台服务管控方法，其特征在于，所述根据所要启动服务的应用的应用包名和应用身份标识判断所述服务是否存储在所述数据库表中包括以下步骤：

获取所要启动服务的应用的应用包名；

查询所述数据库表中是否存储有所述应用包名对应的应用身份标识，若存在，获取所要启动服务的应用的应用身份标识；

判断所要启动服务的应用的应用身份标识与所述数据库表中查询得到的应用身份标识是否相同，若相同，则所要启动服务的应用存储在所述数据库表中。

3.如权利要求1所述的后台服务管控方法，其特征在于，所述数据库表还用于存储应用自启管控状态，

若所述应用自启管控状态为关闭状态时，则将对应应用的应用包名、应用身份标识和对应的应用自启管控状态存储入所述数据库表中；

若所述应用自启管控状态为开启状态时，则将对应应用的应用包名以及应用身份标识从所述数据库表中删除。

4.如权利要求1-3中任一项所述的后台服务管控方法，其特征在于，对所述数据库表中的数据通过内容解析器进行查询。

5.如权利要求1-3中任一项所述的后台服务管控方法，其特征在于，通过所述数据库表的内容提供器接口与外部设备进行查询、和/或增加、和/或删除、和/或记录操作。

6.一种基于Android系统的后台服务管控系统，其特征在于，所述系统包括：数据库表、存储判断模块以及开关控制模块；

所述数据库表中包括：应用的应用包名以及应用身份标识；存储在所述数据库表中的应用的后台服务仅能通过对应的应用自启进行启动，其它应用禁止启动；

所述存储判断模块，用于应用启动服务时，根据所要启动服务的应用的应用包名和应用身份标识判断所述服务是否存储在所述数据库表中；

所述开关控制模块，用于在所要启动服务的应用存储在所述数据库表中时，启动所要启动服务的应用相应的服务，同时禁止其它应用启动所述对应的服务。

7.如权利要求6所述的后台服务管控系统，其特征在于，所述存储判断模块用于，

获取所要启动服务的应用的应用包名；

查询所述数据库表中是否存储有所述应用包名对应的应用身份标识，若存在，获取所要启动服务的应用的应用身份标识；

判断所要启动服务的应用的应用身份标识与所述数据库表中查询得到的应用身份标识是否相同，若相同，则所要启动服务的应用存储在所述数据库表中。

8.如权利要求6所述的后台服务管控系统，其特征在于，所述数据库表还包括：应用的应用自启管控状态，

若所述应用自启管控状态为关闭状态时，则将对应应用的应用包名、应用身份标识和对应的应用自启管控状态存储入所述数据库表中；

若所述应用自启管控状态为开启状态时，则将对应应用的应用包名以及应用身份标识从所述数据库表中删除。

9.如权利要求6-8中任一项所述的后台服务管控系统，其特征在于，所述数据库表中的数据通过内容解析器进行查询。

10.如权利要求6-8中任一项所述的后台服务管控系统，其特征在于，还包括：所述数据库表的内容提供器接口，用于与外部设备进行查询、和/或增加、和/或删除、和/或记录。