CN107590013B

CN107590013B - 一种检测Android应用Service构件泄露的高效方法

Info

Publication number: CN107590013B
Application number: CN201710790636.4A
Authority: CN
Inventors: 马骏; 陶先平; 吕建
Original assignee: Nanjing University
Current assignee: Nanjing University
Priority date: 2017-09-05
Filing date: 2017-09-05
Publication date: 2020-12-04
Anticipated expiration: 2037-09-05
Also published as: CN107590013A

Abstract

本发明提供了快速检测安卓应用潜在的Service构件泄露的方法。其特征在于，包括以下步骤：步骤1、重复尝试“启动(start)并停止(stop)”以及“绑定(bind)并解绑(unbind)”应用在其AndroidManifest.xml文件中所声明的各个service；步骤2、获取应用堆栈内存；步骤3、分析应用堆栈内存，鉴别泄露的Service构件。本发明的能准确的检测安卓应用潜在的Service构件泄露风险，具有全自动、效率高、可重现等特征。

Description

一种检测Android应用Service构件泄露的高效方法

技术领域

本发明专利涉及安卓软件应用，内存泄露检测领域，尤其涉及一种检测安卓应用Service构件泄露的高效方法。

背景技术

近年来，随着移动设备的普及，基于移动设备的安卓应用数量不断增加。然而，由于安卓复杂的生命周期管理机制，开发安卓应用极容易引入泄露Service构件的可能性。这些潜在的应用构件的泄露，会不断消耗系统内存等资源，导致应用卡顿甚至崩溃，极大的影响用户体验和商家品牌形象。为此，如何自动化高效的检测应用潜在的Service构件的泄露，有着极大的意义。然而，现有检测安卓应用Service泄露的工作要么需要大量的人工介入，要么难以重现泄露场景。为此，本发明旨在为安卓应用潜在的Service构件的泄露现象的自动化检测提供一个快速检测方案。

发明内容

本发明主要针对现有工作的不足，提出了一种检测Android应用Service构件泄露的高效方法。

该方法基于以下现实：安卓应用往往包含一系列的Service，这些Service中部分仅仅供应用内部使用(“android:exported＝false”)，还有一部分可供本应用之外的其他应用的各种构件所使用(“android:exported＝true”)；对于“android:exported＝true”的Service，其他应用的构件可以通过startService()或bindService()两个API来访问该应用；通常情况下，两种方式都会创建Service实例；当不需要使用该服务的时候，应用构件可以通过stopService()或unbindService()两个方法来停止服务或解除对服务的绑定。当一个Service实例被停止并且没有其他构件绑定该服务的时候，系统则会自动销毁该Service实例；安卓系统为了管理应用的Service实例，在应用对应的ActivityThread实例中提供了专门用于记录处于运行态的服务的域mServices；当一个Service实例被创建，则会在mServices域中添加对该实例的间接引用，当一个Service实例被销毁，mServices域也会自动删除相应的引用关系。通过对mServices域值的比较，可以判断Service实例是否已被销毁；不能被GC回收的Service实例，一定存在通往GC root的不包含SoftReference、WeakReference、PhantomReference、FinalizerReference以及Finalizer类型对象的路径。

为了实现上述发明目的，本发明采用的技术方案为：

一种安卓应用Service构件泄露的高效检测方法，其特征在于，分为主程序(Master)与客户端检测应用(APK_checker)两部分。主程序(Master)运行在PC端，客户端检测应用(APK_checker)运行在测试安卓设备(安卓实体机或虚拟机)上。其主要步骤包括：

步骤一、主程序(Master)借助Android-Debug-Bridge(ADB)安装待检测应用APK_target；

步骤二、主程序(Master)借助Android-Debug-Bridge(ADB)安装客户端检测应用(APK_checker)；

步骤三、主程序(Master)以“Start模式”启动客户端检测应用(APK_checker)；

步骤四、客户端检测应用(APK_checker)以“Start模式”尝试检测待测应用所发布的各项服务；

步骤五、主程序(Master)记录相应应用堆栈内存；

步骤六、主程序(Master)以“Bind模式”启动客户端检测应用(APK_checker)尝试检测待测应用所发布的各项服务；

步骤七、客户端检测应用(APK_checker)以“Bind模式”尝试检测待测应用所发布的各项服务；

步骤八、主程序(Master)记录相应应用堆栈内存；

步骤九、分析获取得到的应用堆栈内存，检测泄露的应用构件。

运行在测试安卓设备(安卓实体机或虚拟机)上的客户端检测应用(APK_checker)负责不断“启动/停止”或“绑定/解绑”指定服务并记录相应应用的堆栈，其具体工作流程如包含如下步骤：

1)获取待检测应用APK_target的AndroidManifest.xml文件，确定应用所包含的所有Service列表，记为L_Srv；

2)依据启动模式不同，采取不同处理逻辑：

a)若启动模式为“Start模式”，针对L_Srv中每个Service，重复start/stop该Service；

b)若启动模式为“Bind模式”针对L_Srv中每个Service，重复bind/unbind该Service；

为了获取待检测应用APK_target的AndroidManifest.xml文件，确定应用所包含的所有Service列表，客户端检测应用(APK_checker)具体通过以下步骤来实现该功能：

1)利用逆向工程工具对待检测安卓应用.apk文件进行反编译，获取应用AndroidMenifest.xml描述文件

2)分析AndroidMenifest.xml文件，查找<service>标签，确定应用的服务列表；针对每个<service>标签所刻画的服务srv_i，若其“android:exported”属性为“true”，则将srv_i加入待检测服务列表L_Srv；若其“android:exported”属性为“false”,但<service>标签包含<intent-filter>子标签，则同样将srv_i加入待检测服务列表L_Srv。对于包含<intent-filter>子标签的<service>标签，需要进一步分析该<intent-filter>子标签，则需要进一步分析该子标签，获取其所包含的<action>标签的“adroid:name”属性的值，记为srv_i.act；在该过程中，若果有多个<intent-filter>标签，则随机抽取一个；若选中的<intent-filter>标签包含多个<action>子标签，则随机抽取其中一个，并以它“adroid:name”属性的值记为srv_i.act。

客户端检测应用(APK_checker)针对L_Srv中每个Service，重复start/stop该Service，包含以下步骤：

1)针对权力所获得的应用服务列表L_Srv中的每一个服务srv_i∈L_Srv，重复以下步骤k次(k>＝2，由用户指定)

a)利用安卓系统提供的startService(Intent intent)API来启动对应服务srv_i。特别的，若srv_i.act不为空，则需要在参数intent中通过intent.setAction(srv_i.act)的方式来指定具体的action。

b)利用安卓系统提供的stopService(Intent intent)API来停止先前启动的服务srv_i。特别的，若srv_i.act不为空，则需要在参数intent中通过intent.setAction(srv_i.act的方式来指定具体的action。

客户端检测应用(APK_checker)针对L_Srv中每个Service，重复bind/unbind该Service，包含以下步骤:

1)针对所获得的应用服务列表L_Srv中的每一个服务srv_i∈L_Srv，重复以下步骤k次(k>＝2，由用户指定)：

a)利用安卓系统提供的bindService(Intent intent,ServiceConnectionconnection,int flags)API来启动对应服务srv_i。特别的，若srv_i·act不为空，则需要在参数intent中通过intent.setAction(srv_i·act)的方式来指定具体的action。flags＝BIND_AUTO_CREATE。

b)利用安卓系统提供的unbindService(Connection connection)API来解除对先前绑定的服务srv_i的绑定。

本发明所提出安卓应用Service构件泄露的高效检测方法的步骤四要完成获取得到的应用堆栈内存的分析，检测泄露的应用构件，具体包括以下步骤：

1)针对一个转储的应用堆栈.hprof文件，首先获取其中所包含的所有Service对象实例，用S_srv表示；

2)针对所获得的每一个Service对象实例s∈S_srv进行逐个鉴别，判定s是否已经被销毁，若s被判定为已销毁，则将其从S_srv中删除；

3)针对处理后得到的S_srv中的剩余对象实例s，进一步判定其是否是泄露的，若是则将其从S_srv中删除；

4)返回S_srv，即获得所有泄露的Service实例。

要判定一个给定的Service实例s是否被销毁，则是依据该s是否被某个ActivityThread实例所管理，即判断是否存在如下的引用关系序列：at→mServices→array[]→s，其中at表示应用所对应的一个ActivityThread实例。若存在这样一个引用关系序列，则s被at表示的ActivityThread实例所管理；否则，s则被认为是被销毁的。

要判定一个给定的销毁了的Service实例s是否泄露，具体包括以下步骤：

1)获取Service实例s到达所有GC root的路径，记为L_P；

2)从L_P中去除所有包含java.lang.ref.SoftReference、java.lang.ref.WeakReference、java.lang.ref.PhantomReference、java.lang.ref.FinalizerReference以及java.lang.ref.Finalizer类型对象的路径；从L_P中去除所有以java.lang.Daemons$FinalizerDaemon类对象结尾的路径，同时从L_P中去除包含FinalizerWatchdogDaemon线程的路径

3)若L_P为空，则s不是泄露的；否则，s则是泄露的。

本发明能够自动化地实现以下功能：逐个启动并销毁待检测安卓应用的各个Service实例，收集安卓应用堆栈内容，并通过进一步分析所转储的应用堆栈内容，鉴别泄露Service构件实例。相对现有其他工作而言，本发明具有以下有益效果：

1)自动化；

2)高效率；

3)可重现。

附图说明

图1为本发明实施例的Service泄露检测方法的整体架构和流程框架。

图2为本发明实施例的分析堆栈文件识别泄露Service实例的流程。

具体实施方式

下面结合本发明实例中的附图，对本发明实施例中的技术方案进行清楚、完整地的描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部实施例。基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明的保护范围。

1.主要过程：

图1所示为本发明提供的一种安卓应用Service泄露高效检测方法的整体架构和流程框架图，图1中：

系统整体分为主程序(Master)与客户端检测应用(APK_checker)两部分。主程序(Master)运行在PC端，客户端检测应用(APK_checker)运行在测试安卓设备(安卓实体机或虚拟机)上。

对于待检测的一个安卓应用，我们首先安装待检测应用APK_target；然后，安装客户端检测应用(APK_checker)；再然后，针对应用每个服务，分别尝试重复“启动/停止”或“绑定/解绑”该服务多次，并转储应用运行时刻堆栈；最后，利用内存分析工具分析转储的堆栈文件，以确定泄露的Service实例。

图2所示为本发明中自动化分析堆栈文件(即.hprof文件)，并进一步鉴别泄露Service实例的流程。针对每一个待分析的堆栈文件(即.hprof文件)，首先找出其中所包含的所有的Service子类集合S_class；然后，针对S_class中的每一个子类，找到其所有Service实例，存并添加到列表S_srv之中；接下来，遍历S_srv的每一个实例s，依据该s是否被某个ActivityThread实例所管理，即判断是否存在如下的引用关系序列：at→mServices→array[]→s，其中at表示一个ActivityThread实例。若存在这样一个引用关系序列，则s被at表示的ActivityThread实例所管理；否则，s则被认为是被销毁的，则将s从S_srv中删除。

再然后，则要逐个判断剩余在S_srv的每一个实例s是否真是泄露的，而这是通过对s到达所有GC root的路径进行分析而得到的。简单而言，首先需要获取s到达所有GC root的路径的集合，记为L_P；逐一处理L_P中的每一条路径p，若路径p包含任何java.lang.ref.SoftReference、java.lang.ref.WeakReference、java.lang.ref.PhantomReference、java.lang.ref.FinalizerReference以及java.lang.ref.Finalizer类型对象，则将路径p从L_P中删除。此外，进一步从L_P中去除所有以java.lang.Daemons$FinalizerDaemon类对象结尾的路径，同时从L_P中去除包含FinalizerWatchdogDaemon线程的路径。当L_P中所有路径都处理完毕，若L_P为空，则判定实例s不是泄露的实例，而是有可能会被GC回收的；否则，L_P不为空，则实例s仍在某些地方被引用而不能被GC回收，从而判定实例s为泄露的实例。

以上的实施例仅为说明本发明的技术思想，不能以此限定本发明的保护范围，凡是按照本发明提出的技术思想，在技术方案基础上所做的任何改动，均落入本发明保护范围之内。本发明未涉及的技术均可通过现有的技术加以实现。

Claims

1.一种安卓应用Service构件泄露的高效检测方法，其特征在于：分为主程序Master与客户端检测应用APK_checker两部分；主程序Master运行在PC端，客户端检测应用APK_checker运行在测试安卓设备上，其具体步骤包括：

步骤一、主程序Master借助Android-Debug-Bridge安装待检测应用APK_target；

步骤二、主程序Master借助Android-Debug-Bridge安装客户端检测应用APK_checker；

步骤三、主程序Master以“Start模式”启动客户端检测应用APK_checker；

步骤四、客户端检测应用APK_checker以“Start模式”尝试检测待测应用所发布的各项服务；

步骤五、主程序Master记录相应应用堆栈内存；

步骤六、主程序Master以“Bind模式”启动客户端检测应用APK_checker尝试检测待测应用所发布的各项服务；

步骤七、客户端检测应用APK_checker以“Bind模式”尝试检测待测应用所发布的各项服务；

步骤八、主程序Master记录相应应用堆栈内存；

步骤九、分析获取得到的应用堆栈内存，检测泄露的应用构件；

步骤九具体包括以下步骤：

步骤9.1、针对一个转储的应用堆栈.hprof文件，首先获取其中所包含的所有Service对象实例，用S_srv表示；

步骤9.2、针对步骤9.1所获得的每一个Service对象实例s进行逐个鉴别，判定s是否已经被销毁，若s被判定为已销毁，则将其从S_srv中删除；

所述步骤9.2判定一个Service实例s是否被销毁，则是依据该s是否被某个ActivityThread实例所管理，即判断是否存在如下的引用关系序列：at→mServices→array[]→s，其中at表示一个ActivityThread实例；若存在这样一个引用关系序列，则s被at表示的ActivityThread实例所管理；否则，s则被认为是被销毁的；

步骤9.3、针对步骤9.2处理后得到的S_srv中的剩余对象实例s，进一步判定其是否是泄露的，若是则将其从S_srv中删除；

所述步骤9.3判定一个Service实例s是否泄露，具体包括以下步骤：

步骤9.3.1、获取Service实例s到达所有GC root的路径，记为L_P；

步骤9.3.2、从L_P中去除所有包含java.lang.ref.SoftReference、java.lang.ref.WeakReference、java.lang.ref.PhantomReference、java.lang.ref.FinalizerReference以及java.lang.ref.Finalizer类型对象的路径；从L_P中去除所有以java.lang.Daemons$FinalizerDaemon类对象结尾的路径，同时从L_P中去除包含FinalizerWatchdogDaemon线程的路径；

步骤9.3.3、若L_P为空，则s不是泄露的；否则，s则是泄露的；

步骤9.4、返回S_srv，即获得所有泄露的Service实例。

2.根据权利要求1所述的安卓应用Service构件泄露的高效检测方法，其特征在于，步骤四、步骤六包含如下步骤：

步骤2.1、获取待检测应用APK_target的AndroidManifest.xml文件，确定应用所包含的所有Service列表，记为L_Srv；

步骤2.2、依据启动模式，选择不同处理逻辑：

步骤2.2.1、若启动模式为“Start模式”，则针对L_Srv中每个Service，重复start/stop该Service；

其中的步骤2.2.1包含以下步骤：

步骤2.2.1.1、针对步骤2.1所获得的应用服务列表L_Srv中的每一个服务srv_i∈L_Srv，重复以下步骤k次，其中k由用户指定，且k>＝2：

步骤2.2.1.1.1、利用安卓系统提供的startService(Intent intent)API来启动对应服务srv_i；若srv_i.act不为空，则需要在参数intent中通过intent.setAction(srv_i·act)的方式来指定具体的action；

步骤2.2.1.1.2、利用安卓系统提供的stopService(Intent intent)API来停止先前启动的服务srv_i；若srv_i·act不为空，则需要在参数intent中通过intent.setAction(srv_i·act)的方式来指定具体的action；

步骤2.2.1.2、转储应用当前的堆栈内容

步骤2.2.2、若启动模式为“Bind模式”，针对L_Srv中每个Service，重复bind/unbind该Service；

其中的步骤2.2.2包含以下步骤：

步骤2.2.2.1、针对步骤2.1所获得的应用服务列表L_Srv中的每一个服务srv_i∈L_Srv，重复以下步骤k次，其中k由用户指定，且k>＝2：

步骤2.2.2.1.1、利用安卓系统提供的bindService(Intent intent,ServiceConnection connection,int flags)API来启动对应服务srv_i；若srv_i.act不为空，则需要在参数intent中通过intent.setAction(srv_i.act)的方式来指定具体的action；flags＝BIND_AUTO_CREATE；

步骤2.2.2.1.2、利用安卓系统提供的unbindService(Connectionconnection)API来解除对先前绑定的服务srv_i的绑定；

步骤2.2.2.2、转储应用当前的堆栈内容。

3.根据权利要求2所述的安卓应用Service构件泄露的高效检测方法，其特征在于，其中的步骤2.1具体包括以下步骤：

步骤2.1.1、利用逆向工程工具对待检测安卓应用.apk文件进行反编译，获取应用AndroidMenifest.xml描述文件；

步骤2.1.2、分析AndroidMenifest.xml文件，查找<service>标签，确定应用的服务列表；针对每个<service>标签所刻画的服务srv_i，若其“android:exported”属性为“true”，则将srv_i加入待检测服务列表L_Srv；若其“android:exported”属性为“false”，但<service>标签包含<intent-filter>子标签，则同样将srv_i加入待检测服务列表L_Srv；对于包含<intent-filter>子标签的<service>标签，需要进一步分析该<intent-filter>子标签，获取其所包含的<action>标签的“adroid:name”属性的值，记为srv_i.act；在该过程中，如果有多个<intent-filter>标签，则随机抽取一个；若选中的<intent-filter>标签包含多个<action>子标签，则随机抽取其中一个，并以它“adroid:name”属性的值记为srv_i.act。