一种在安卓动态分析中自动生成文本输入的方法

王成志，杨哲慜，南雨宏，杨 珉

(复旦大学 软件学院，上海 201203)

1 引 言

动态分析是在很多领域用到的一种通过实时执行程序来进行测试评估的方法.现在有很多工作依靠动态分析来检测移动应用程序的bug或者安全漏洞.常见动态分析方法如TaintDroid[1]、SMV-Hunter[2]和AsDroid[3]等通过运行时分析来检测移动应用中的隐私泄露，不正确的SSL使用或者其他恶意行为.

在动态执行应用的过程中往往会遇到应用需要用户文本输入的情况.例如，应用的登录界面需要用户输入账号和密码.通常应用会通过输入控件来接收用户的文本输入.缺少或为应用提供错误的文本输入会导致应用中依赖这些文本输入的代码不能被触发甚至造成应用崩溃.这使得在动态分析中，应用只能执行少量的代码，严重影响了动态分析的效率.因此，动态分析技术面临着巨大的挑战.

在实际研究中，由于待分析的应用数目庞大，为了满足大规模动态分析的需要，研究者将动态分析方法和自动化测试工具(例如，MonkeyRunner1)相结合，利用自动化测试工具驱动应用执行，利用动态分析方法分析应用的行为.在大规模动态分析场景中，为了给应用提供相关的文本输入，提高自动化动态分析的执行代码覆盖率，研究者需要不断和应用交互.然而，巨大的人工干预严重降低了自动化动态分析的效率.

本文分析了现有的能为应用产生输入的工具，这些工具能够为应用产生输入，例如UI输入和系统输入.这些输入能GUIPipper[5]、SwiftHand[8]和PUMA[9]等，这类工具会对应用的UI进行分析建模，以应用的Activity为状态建立一个状够驱动应用的自动化执，触发应用代码.本文发现大部分的工具无法为应用在动态执行中生成相关的文本输入.在这些工具中，有些工具如Dynodroid[4]依赖人工干预，需要研究者手动输入相关文本.其他工具如AppsPlayground[12]和DroidFuzzer[7]采用基于特定启发式的规则或者fuzzing技术(例如，给应用设置一个随机产生的字符串)来为应用产生文本输入.然而，通过上述方式产生的文本输入往往无法满足应用的测试需要.这主要是因为应用程序中很多用户文本输入具有非结构化、且类型特殊的特征，使得测试环境难以自动生成有效的用户输入.例如，有效的电子邮件地址应包含“@”字符，电话号码字段只能接受数字，而随机生成的字符串很可能不符合这样的要求.

为了能够为应用自动化产生符合其要求的文本输入，提高动态分析的覆盖率从而使应用中代码被尽可能多的执行到，本文提出了一种名为AutoSim的分析框架，用于在动态分析时为应用产生相关文本输入.对于一个给定的应用，AutoSim从应用反编译得到静态资源文件中提取出具有语义信息的文本，然后利用一个基于机器学习的分类器来识别UI控件所需要的文本输入类型 (如，电子邮件地址，出生日期和信用卡号码等).同时，AutoSim在应用动态执行的过程中，通过监听应用的上下文信息来拦截需要文本输入的UI控件，并将符合类型的文本注入到该控件中.此外，AutoSim提供了点击模块来触发对应的事件，从而保证应用顺利完成依赖于各类用户输入的测试场景.

为了验证AutoSim系统的有效性，我们分别测试了AutoSim识别应用文本输入类型的准确率以及AutoSim对需要文本输入的控件处理效果，即能否正确识别控件需要的文本输入类型.此外，通过测试AutoSim能否在应用动态执行时帮助增加遍历UI的数目来判断AutoSim是否能够提高动态分析的覆盖率.实验结果显示，AutoSim识别文本输入类型的准确率为88.68%，能够正确处理89.74%的UI控件.对于需要用户文本输入的应用，AutoSim能够帮助自动化测试工具提高33.7%的界面遍历覆盖率.

2 背景与相关工作

2.1 Android用户界面

用户界面是用户可以在应用程序的屏幕上看到并与之交互的所有内容.Android提供了丰富多样的预置本地UI控件.比较常见的UI控件有输入框、按钮、单选框和标签等，这些控件在Android中对应的类分别为EditText、Button、CheckBox和TextView.开发者可以通过这些控件和用户进行交互，并且为这些控件定义不同的属性以展示不同的内容.除了Android框架提供的原生UI控件之外，Android允许开发人员设计自定义UI控件.这些自定义小部件通常继承于Android原生控件，添加微小的修改，使得这些控件可以呈现出不同的外观.

2.2 Android应用文本输入

Android框架提供了一些可编辑的控件来接收用户的文本输入，例如EditText、AutoCompleteTextView和MultiAutoCompleteTextView等.用户可以在这些控件中进行文本编辑，

将相应的文本内容传递给应用.应用根据接收到的文本输入，为用户提供精准的信息或者服务.

图1(a)展示了需要用户输入的UI.用户通过图 1(a)所示用户界面的一些输入框来接收用户的个人信息，如email、first name、last name、birthday和phone等，在用户填入这些信息之后，通过点击“Sign Up”按钮完成对应用的注册.这些文本输入是非常结构化的，类型特定，例如电子邮箱地址、生日和手机号码都是具有特定格式的.当这些UI中的输入框没有被填入内容或者填入错误的内容时，会导致该应用的核心功能以及大量的用户界面无法被访问到.

(a) (b)

2.3 Android用户界面布局

在Android应用开发中，开发者可以通过两种方式来声明UI布局：在XML布局文件中声明UI元素和在运行时实例化布局元素.在XML中声明UI的方式可以更好地将应用的外观与控制应用的行为分离，被绝大部分开发者采用.因此本文只考虑基于XML布局的应用.

图1(b)展示了图1(a)中UI界面对应的XML布局文件的部分内容.图1(b)中的EditText元素对应图1(a)中的email输入框.开发者通过在UI布局文件中定义控件的属性来控制控件的显示，例如，图1(b)中EditText的属性android：hint =“@string/create-email”(第4行和第5行)指示当输入框的内容为空时，应在UI中显示的提示文本.这个EditText的inputType属性(第6行)也表明该输入框需要接收email类型的用户输入.从控件布局属性中提取的内容是语义相关的，UIPicker[6]利用这些内容判断控件接收的文本输入是否为隐私相关，本文通过分析这些内容来判断UI控件需要文本输入的类型.

2.4 Android代码注入框架

Xposed2是一个可以在不修改应用程序情况下更改系统和应用程序行为的框架.Xposed可以通过hook一些关键函数来实现对系统或者应用功能的修改.在Android中，所有的应用进程都是通过zygote进程创建，zygote进程是运行的app-process，app-process在frameworks/base/cmds/app-process/下.Xposed将自己定制的app-process替换掉目标设

2http://repo.xposed.info/

备中的app-process从而修改zygote进程达到hook应用目的.Xposed会将需要hook的方法先指向XposedBridge.jar中的xposedCallHandler方法，然后调用beforeHookMethod和afterHooked-Method方法，这两个方法分别在被hook的方法执行前和执行后被调用.开发者可以自定义beforeHookMethod和afterHookedMethod方法中的行为.在本文中，AutoSim利用Xposed拦截正在加载的UI中所有控件.

2.5 相关工作

在自动化分析方面，Choudhary[7]等人认为目前能驱动Android应用自动化执行的自动化工具根据其采用的对应用采取策略主要分为三类：随机探索策略类自动化工具，基于模型的探索策略类自动化工具和系统探索策略类自动化工具.采用随机探索策略的自动化工具有Dynodroid[4]，这类工具为应用产生随机的事件，例如，随机点击UI上某个位置，来驱动应用执行以及UI的跳转.基于模型的自动化工具主要有态机来指导应用的自动化执行以及UI跳转.而系统类的自动化工具则采用较为复杂的技术，如进化算法[10]来不断改变输入驱使应用自动化执行.

这些自动化工具均无法有效应对需要用户文本输入的UI.在遇到需要文本输入的UI时，有的工具会为需要文本输入的控件产生随机化的文本，如MonkeyRunner、PUMA[9]和Vanar Sena[11]等，有些则直接忽略掉需要文本输入的UI，如Dynodroid[4]等.还有一些如AppsPlayground[12]采用极为简易的基于关键字的方法来为识别控件需要的文本输入类型，并且无法有效处理如开发者自定义控件等情况，效率较为低下.Peng[13]等人采用深度学习的方法为应用生成相关的文本，但是他们的方法无法有效生成结构化特定类型的文本输入.相比于这些工具，AutoSim能够有效的识别应用需要的文本输入的类型，并能够在动态执行过程中高效的将相关的文本注入到应用中.

3 AutoSim的基本框架

图2描述了AutoSim的基本框架.如图2所示，AutoSim自动化生成文本内容的过程主要包括两个阶段：静态UI解析

图2 AutoSim框架示意图Fig.2 System overview of AutoSim

阶段和动态UI驱动阶段.在静态UI解析阶段，AutoSim使用静态分析的方法来分析应用程序中需要文本输入的UI控件所对应的文本类型.在动态UI驱动阶段，AutoSim在应用执行的过程中将准备好的符合UI要求类型的文本注入到UI控件中.静态UI解析阶段产生的配置文件将指导动态UI驱动器在应用动态执行时的注入操作.

3.1 静态UI解析阶段

在静态UI解析阶段，AutoSim首先反编译Android应用，获取到应用的资源文件.从资源文件中提取出UI控件的语义相关的描述信息，通过分析这些语义相关的描述信息来判断控件需要的文本输入类型.为了能够精确的识别UI控件所需要的文本输入的类型，AutoSim采用机器学习的方法，利用从应用中提取出来的语义相关的描述信息训练出一个分类器.该分类器将从应用中提取出的UI控件的语义相关的信息作为输入，输出该控件所需文本输入的类型.

3.2 动态UI驱动阶段

在动态UI驱动阶段，AutoSim会在应用实际执行时监视应用运行的上下文.该阶段主要包含三个模块：基于Xposed的Android框架拦截模块，输入模块和点击模块.拦截模块在应用加载UI的过程中通过Hook的方式拦截即将加载到当前屏幕的所有UI控件，并根据生成的应用的配置文件来检索需要文本输入的UI控件.输入模块会依据配置文件上记录的UI控件所需文本类型的信息将符合该类型的有效文本注入到该控件中.在实现动态UI驱动阶段中，利用Xposed工具在Android框架层拦截UI控件不需要对应用做出任何修改.

4 AutoSim的设计与实现

4.1 语义信息的提取

AutoSim首先利用apktool3工具对Android应用进行反编译，提取应用的资源文件，从反编译的APK程序包中的界面布局文件中提取出控件的UI文本和UI描述文本来获取有价值的语义信息进行分析.

UI文本是在应用屏幕中向用户显示的文本，例如Button的标签，输入框内部用于提示用户的文字.在反编译应用中，大多数UI文本位于/res/values/strings.xml文件中，在控件的属性中由语法@String/[identifier]来定义和引用，此外有些UI文本会直接写在界面布局文件中，如android：hint=“password”.这些语义相关的UI文本能够有效提示和指导用户的操作.本文通过提取UI布局文件中控件的hint属性和text属性的值来获取UI文本.

控件的UI描述文本是仅位于/res/layout/的UI布局文件中，用于描述控件的内容，主要包含控件的id、位置和大小等信息.本文通过提取UI控件的id属性和inputType属性的值来获取语义相关的UI描述文本.表1描述了提取的UI文本和UI描述文本内容样例.

表1 从图1(a)所示UI中提取出的部分资源Table 1 Part of extracted resources from UI shown in Figure 1(a)

AutoSim主要从能够接受用户文本输入的UI控件中提取语义相关的内容进行分析.表2展示了本文中主要关注的能够接受用户输入的UI控件.从表2中可以看出，本文不仅分析能够接受用户文本输入的控件，如EditText，还分析了一些需要点击的控件，如RadioButton和Checkbox等.这主要是因为在UI界面中需要用户交互的不只是输入文本，还需要一些点击选择操作，例如通过点击CheckBox同意相关的协议，通过RadioButton选择性别.此外，本文提供相应的机制来帮助触发点击控件上对应的事件，例如在填写个人信息后，自动点击注册页面上的注册按钮来完成应用自动注册.

3https://ibotpeaches.github.io/Apktool/

表2 十种常见的需要用户输入的控件Table 2 Top ten widgets that require user input

表2中的UI控件均为Android系统提供的原生控件，除了这些原生控件外，本文还分析了开发者自定义的UI控件.开发者在Android系统提供的原生控件基础上进行定义和开发新的UI控件，这自定义控件的源码包含在应用中.对于这些控件，本文通过分析反编译应用获得的这些控件的smali文件得到这些控件继承的Android原生控件.在本文中，我们认为这些自定义的控件和这些自定义控件所继承的原生组件是等同的，这是因为在应用动态执行中使用拦截原生控件的方法同样可以拦截到继承该原生控件的自定义控件.

4.2 基于SVM的分类器

为了能够精确的识别UI控件所需要的文本输入的类型，本文利用标准支持向量机(SVM)和从UI控件中提取出的语义信息训练一个能够精确识别文本输入类型的分类器.标准支持向量机是一种广泛使用的监督式学习模型，能够高效的对数据分类.然而SVM实质是一个二元分类器，而控件需要文本的类型的种类多于两种，因此本文采用一对多(one-versus-rest)的分类策略来实现支持多分类的分类器.在实现时，我们使用了scikit-learn包中的LinearSVC来训练支持多分类分类器.

在训练分类器之前，我们需要确定用户文本输入的种类.由于Android应用的多样性和实际需求，应用会要求用户输入各种各样的信息，导致文本输入的种类数目庞大.在本文中，AutoSim选取最常用的文本输入种类.本文分析了超过1000个从Google Play上下载的应用，收集需要用户输入的控件，人工识别这些控件需要的文本类型，统计各种文本输入类型的数目，并选取比例最高的14种作为要识别的分类.表3显示了本文选取的进行分类的用户文本输入种类以及所占的比例，从表3可以看出，像email、phone、credit card number、birthday和zipcode这些文本输入都是格式化的，随机的内容无法满足需要这些类型输入的控件.

在训练阶段，本文首先分析了超过2000个从Google Play上下载的应用来获取训练样本.我们从这些应用的UI界面中提取出接收用户文本输入控件的语义信息，并且人工标注每一个需要文本输入控件所需要文本输入的类型，将控件的语义信息和需要文本输入的类型一一对应.为了训练分类器，AutoSim需要将训练样本中具有语义信息的原始文本转化成向量.在实现中，我们从字符层面(Character-level)上对文本进行向量转化.相比于常用的从单词，短语和句子层面上对文本进行向量转化，字符层面上的向量转化能够不受文本词法，语法以及句法结构的影响，并且具有良好的效果.本文选用包含26个英文小写字母的字典对训练数据中的文本进行编码.从4.1可知，对于每一个控件，本文分别提取了控件4种属性(hint、text、id和inputType)的文本值.在编码时，我们将每一个属性的文本编码为长度为26位的向量.这个向量上第n位的值表示在字典中偏移量为n的小写英文字母在这个文本中出现的频率.对于每一控件，我们可以得到4个26位的向量，并且把这4个向量组合到一起，形成新的104位长度的向量.SVM将这个104位长度的向量和该控件对应的所需文本的类型作为输入进行分类器的训练.

表3 本文选取的用户文本输入类型在统计样本中所占比例Table 3 Input types and their corresponding ratio in dataset

4.3 配置文件的生成

在获得分类器后，对于一个未知的应用，静态UI解析会提取应用中需要用户文本输入控件的语义文本信息，按照4.2中所述的方法对语义文本信息进行编码，用训练好的分类器对编码好的语义文本进行分类，判断控件需要文本的类型.AutoSim将应用中每一个需要文本输入控件的分类结果保存在以该应用包名命名的静态配置文件中，这些配置文件将会被保存在待测设备中.在应用动态执行时，动态UI驱动器会根据应用的包名加载配置文件，根据配置文件中的信息进行操作.

在静态文件中，除了识别出的控件需要的文本输入类型外，本文还记录了控件的类型.控件唯一的十进制ID可以被用来标记存储在配置文件中的该控件的信息(需要的文本输入类型和控件类型).Android会为每一个在资源文件中定义的控件分配一个唯一的ID，这些ID以十六进制形式存储在应用资源文件的/res/values/public.xml中.在应用动态执行时，控件ID和保存在public.xml中该控件的ID是一致的，因而AutoSim可以在应用动态执行时通过ID来追踪控件.并根据配置文件中保存的控件的信息对控件进行处理.配置文件连接了AutoSim的静态分析阶段和动态驱动阶段，使AutoSim能够满足大规模自动测试分析应用的需要.在大规模自动测试分析应用的场景下，研究者可以用静态UI解析批量处理待测应用，生成对应的配置文件，并将配置文件存储在文件中.动态执行应用时根据应用的包名加载不同的配置文件进行操作.

4.4 基于Xposed的动态UI驱动

在获得应用配置文件之后，动态UI驱动器会把为应用输入控件准备好的填写内容在应用动态执行的过程中注入到控件中.AutoSim利用Xposed工具在android framework层面上进行拦截和注入操作，使得UI在加载完成后，UI中所有需要文本输入的控件都被填写符合类型的文本.动态UI驱动器主要由3个核心部分组成：Android框架拦截模块，输入模块，点击模块.

4.4.1 Android 框架拦截模块

AutoSim利用Xposed工具在Android框架层面上进行增强，获取应用执行时的一些信息.在应用启动阶段，通过Xposed工具AutoSim可以拦截到当前正在被打开的应用的包名.通过获取到的包名，AutoSim可以检索到存储配置文件的位置中是否存在与包名相匹配的配置文件.如果存在，则说明该应用是待测应用，反之则不是.对于存在配置文件的应用，AutoSim会立即加载配置文件，并开始监听应用的执行情况，并在执行时进行自动的填写以及点击操作.不存配置文件的应用在执行的过程中将不会受到AutoSim的影响.

在应用执行阶段，AutoSim通过对Android系统框架中的一些API的监听来拦截正在加载UI的控件.由于Android在绘制UI控件过程中，会调用系统框架提供的API，因此可以通过监听这些API的调用对象来拦截正在绘制的控件.例如通过监听这些控件从android.widget.TextView中继承的的onDraw()方法来获取所有正在绘制的TextView类型的UI控件.通过进一步的确认UI控件的具体类型，可以判断出控件的类型是否为MultiAutoCompleteTextView、CheckBox和EditText等.通过监听setOnclickListener()函数来拦截需要点击的控件，如Button，ImageButton等.之后AutoSim根据控件的类型将被拦截到的控件交给输入模块和点击模块进行处理.

4.4.2 输入模块

在拦截到当前正在加载UI的所有控件后，输入模块负责将准备好的内容根据控件需要的输入类型自动填写到控件中.对于拦截到的正在绘制的UI控件，AutoSim通过这些控件从android.view.View中继承的getId函数获取控件的id.如果应用的配置文件中存在这个id，则表明这个控件是需要用户输入的控件.通过id去检索配置文件中这个控件需要的输入类型，并获取符合该类型的输入.本文事先为14个不同的输入类型各自准备好符合其类型的输入，这些输入均为真实有效的输入.

AutoSim通过调用Android框架提供的API将文本注入到控件中.例如，对于一个类型为EditText的输入框，可以在拦截阶段获取到这个输入框的实例对象.通过调用setText()函数，AutoSim可以将事先准备好的符合这个文本框要求类型的输入注入到该文本框中.在当前界面加载完后，可以看到被注入的输入已经显示在屏幕上.

4.4.3 点击模块

除了输入模块之外，本文也提供了点击模块，使得动态UI驱动器能够自动的触发相应的事件.例如，在一个登陆注册的页面，在填写完与注册相关的信息之后，AutoSim能够自动的去点击注册按钮以提交注册信息.同时点击模块也为自动的遍历应用内所有UI提供了新的思路.在将来的工作中，我们会用点击模块来实现一个高效的Android应用自动化遍历工具，使得更多应用的代码被执行.

对于拦截到的需要点击的控件，AutoSim通过调用这个控件从android.view.View中继承的performClick函数来实现自动点击.需要注意的是，我们不能在拦截到需要点击的UI控件时立即自动点击该控件，这主要是因为其他需要填写的输入控件还没有处理完成.鉴于上述问题，本文采用了延时点击的策略，即通过使用Android框架提供的AsyncTask4来实现一个定时器，在定时器结束后AutoSim会自动点击需要点击的控件.

5 实验与效果评估

在本节中，本文从三个方面对AutoSim进行测试评估：对静态UI解析部分的评估，对动态UI驱动部分的评估和对AutoSim对自动化测试增强效果的评估.在静态UI解析阶段，本文将测试分类器的平均准确率以及对每一类文本输入类型识别的精确率.在动态UI驱动阶段，本文将测试AutoSim能够正确处理UI控件的数目.最后本文将测试AutoSim在自动化测试Android应用的场景下是否能够有效增大自动化测试框架的UI覆盖率.

本文静态UI解析阶段以及分类器训练实验环境为：具有40核心(Intel Xeon E7-4830，2.20GHz)内核版本3.16.0，物理内存大小为132G的Linux服务器.服务器运行的操作系统为64位的Debian，支持python 3.4.2.动态UI驱动阶段的实验环境为具有2GB RAM，运行Android 4.4.4的Nexus 5.

5.1 分类器的训练以及识别效果测试

为了训练分类器，本文从Google Play上随机挑选了1000个应用，从这些应用中提取出997组需要文本输入的UI控件的语义信息，对这些UI控件需要的输入类型进行手工标注，之后用这些数据进行训练和测试分类器的效果.本文采用十折交叉验证的方法来测试基于SVM分类器的平均准确率和在识别不同种文本输入类型的精确度，即随机将数据集分成10份其中9份做训练1份做测试，并通过10次十折交叉验证取平均值来获取准确度和精确度.此外本文还将基于SVM的分类器与AppsPlayground使用的基于关键词的分类器进行对比.由于AppsPlayground没有开源，因此我们实现了简易的符合其描述的基于关键词的分类器.

表4是分类器的测试以及对比结果，从表4中可以看出基于SVM的分类器识别平均准确率为88.68%，高于准确率只有62.7%的基于关键词的分类器.除了平均准确率以外，基于SVM的分类器在识别单个文本输入类型的精确率和召回率均超过基于关键词的分类器.在识别个别输入类型，如fullname，birthday时，基于关键词的分类器的精确率远不如基于SVM的分类器.这是因为基于关键词的分类主要依赖于有限的关键词列表，根据关键词列表中的关键词是否出现在语义信息中来判断输入类型.有限的关键词列表会造成较多的错误，例如，“password”这个词可以被写成“passwd”、“pwd”或者“passcode”等，因而准确识别文本输入类型“password”需要多个关键词.为了能够精确识别并且区分所有14种输入类型需要庞大的关键词列表，而这是不现实的.因此采用机器学习的方法训练出来的分类器会更加高效.

4https://developer.android.com/reference/android/os/AsyncTask

5http://appium.io

表4 不同分类器的识别效果对比Table 4 Classifier comparison result of identifying input types

5.2 动态UI驱动对单个控件处理效果测试

在测试AutoSim的动态UI驱动部分时，本文测试了AutoSim处理单个控件的效果，通过统计AutoSim在应用动态执行时能正确处理控件(将正确的文本填入到正确的控件中)的数目来测试AutoSim对单个控件的效果.本文从200个随机挑选的应用中收集到了234个需要用户文本输入的控件，其中有60个控件是开发者自定义的控件.在通过分类器对控件进行输入类型识别以及生产配置文件后，我们动态执行相关应用，并观察相关控件是否被填入正确的内容.除了测试AutoSim对单个控件的处理效果之外，本文也分别测试了fuzzing技术和AppsPlayground对单个控件的处理效果，并进行对比.

表5为本次测试的结果，由结果可以看到，AutoSim能够正确处理210个输入控件，包括167个Android框架提供的原生控件和43个开发者自定义的控件，分别占比95.98%和71.67%. AutoSim在处理Android原生控件和开发者定义控件上的效果均强于Fuzzing和AppsPlayground.Fuzzing由于采用给控件输入随机的内容，导致其能正确处理的控件数目较少.而AppsPlayground由于采用了基于关键词的分类识别方法，使得其能够识别100个原生控件，但是由于其在处理开发者自定义的控件时采用了fuzzing的技术，没有对自定义控件的输入类型进行有效的识别，因此只能正确处理较少的开发者自定义控件.

表5 针对单个控件的不同方法测试效果对比Table 5 Effectiveness of testing results by different approaches

5.3 AutoSim对自动化测试Android应用影响的评估

为了评估AutoSim是否能够增大自动化测试框架的UI覆盖率，本文测试了AutoSim是否能够有效增加自动化框架在测试Android应用时遍历应用UI的数目.这主要是因为当自动化测试框架遍历到的UI数目的增加表明能够执行到的应用的代码的增加.本文从Google Play上随机选择了30个应用进行测试.此外，我们利用Appium5和深度优先算法来点击UI上的每一个可以点击的控件以实现自动遍历Android应用的工具，通过该工具来自动遍历安装在Nexus 5上的Android应用，统计能够遍历到的UI的数目.我们将AutoSim部署在Nexus 5上，分别测试给需要文本输入的控件填写随机内容时能够遍历的UI的数目和给输入控件由AutoSim注入的内容时遍历的UI数目.我们用基于Appium的自动化遍历工具运行测试应用，统计能够遍历的UI数目.对于每一个测试应用，测试时间不超过1个小时.

表6 AutoSim对应用界面覆盖率的提示效果Table 6 Improvement of AutoSim on improving UI coverage

测试结果表明AutoSim能有效扩大33.7%的UI覆盖率.表6为本次实验的结果，在测试中共有13个应用包含需要用户文本输入的UI，如表6中所示，14个应用不需要用户文本输入，另外3个在打开应用时由于无法连接服务器而导致崩溃.从表6中的数据可以看出，在13个需要文本输入的应用中，AutoSim能够显著增加其中6个应用遍历的UI数目.我们分析另外7个遍历UI数目没有增加的应用时发现，在这些应用中，需要用户文本输入的UI并不会影响应用的正常访问.例如，包名为“com.protogeo.moves”应用中包含有创建应用账号的功能，但是这个功能在设置页面中，即使不创建账号，我们也基本可以访问到应用的所有UI和功能.

6 总 结

在对移动应用自动化动态分析过程中，缺少或者为应用提供错误的文本输入会严重的限制自动化动态分析效率和覆盖率.为了解决这个问题，本文提出了AutoSim.AutoSim采用机器学习的方法来高效的识别应用需要的文本输入的类型，并通过基于Xposed的技术将符合需要类型的文本，在应用动态执行的过程中准确高效地注入到对应的控件中，使自动化动态分析能够通过需要用户输入的UI，执行更多的代码.针对AutoSim的实验评测结果表明，AutoSim能够有效识别应用需要输入的类型，并且能够有效增加在动态分析中遍历到更多的UI，执行更多的代码.