AVP

An Android Virtual Playground

François Gagnon

, Frédéric Lafrance

, Simon Frenette

and Simon Hallé

Cégep Sainte-Foy, Québec, Canada

Thales Research and Technology, Québec, Canada

Keywords:

Android, Virtualization, Test-bed, Network Experiment, Automated.

Abstract:

This paper presents a virtual test-bed for the Android platform named AVP - Android Virtual Playground. The

focus of AVP is the automatization of the manipulations required to perform a network experiment, in a very

broad sense, involving Android virtual devices. A central objective of AVP is data collection during experi-

ments. Together with describing the different steps of using AVP, from the speciﬁcation of the experiment to

the visualization of the results, the paper presents the current capabilities of AVP.

1 INTRODUCTION

In the last decade, mobile devices such as smart-

phones have penetrated the consumer world at an in-

credibly fast pace. Nowadays, most people use mo-

bile devices for various tasks: communications, bank-

ing, shopping, etc. Several actors are taking advan-

tage of this massive acceptance of mobile technology.

Application developers try hard to obtain a market

share with a speciﬁc idea/feature. Hackers now have

access to a very interesting tool, providing entry into

various networks and access to an abundance of per-

sonal (and often sensitive) information.

In this paper, we share our ideas and experiences

in developing a fully automated test-bed for the An-

droid platform. Our test-bed aims to be generic

enough to be used for many different purposes. Be

it to test a mobile application on multiple hardware

platforms for compatibility (both at the library level

and the graphical level), or to inspect the security as-

pect of an application. The test-bed is large in scope to

take advantage of the different modules already avail-

able instead of focussing on a particular aspect and

digging deep. The solution is named Android Vir-

tual Playground (AVP), pointing to the fact that it is

a framework allowing us to perform several different

activities (hence the term playground).

We strongly believe automated test-beds for mo-

bile platforms are an important component for speed-

ing up the research related to this ﬁeld. This has been

the case with automated test-beds for malware analy-

sis in the PC world (Massicotte and Couture, 2011).

The paper is structured as follows. First, section

2 places AVP in context with existing approaches for

Android virtualization and experimentation. Section

3 gives a brief overview of AVP. The core of test-bed

is described in Sections 4 and 5, respectively its capa-

bilities and how it is used. Then, Section 6 concludes

with ﬁnal remarks and Section 7 discusses avenues

for future work.

2 RELATED WORK

Our work can be related to two different ﬁelds: An-

droid emulation solutions (see Section 2.1) and An-

droid experimentation frameworks (see Section 2.2).

AVP aims to instrument the various virtualization

methods available for Android and provide automated

control of user deﬁned experiments with a rich set of

functionalities. This section presents projects related

to AVP.

2.1 Virtualization Solutions

Below is an overview of the main solutions used for

Android virtualization. Through AVP, we aim to har-

ness as many of those as possible.

• Google. distributes a modiﬁed version of the

open-source QEMU

emulator (Bellard, 2005). It

can run native Android apps under the x86, ARM

http://qemu.org

Gagnon F., Lafrance F., Frenette S. and Hallé S..

AVP - An Android Virtual Playground.

DOI: 10.5220/0005016500130020

In Proceedings of the 5th International Conference on Data Communication Networking (DCNET-2014), pages 13-20

ISBN: 978-989-758-042-0

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

and MIPS architectures. Its purpose is to allow

Android developers to test their apps on a “real”

Android system. This emulator has several ad-

vantages over other emulators. It is supported

by Google, and as such offers features that many

other emulators do not provide. For example, it al-

lows two emulator instances to communicate with

each other or with the host machine using doc-

umented mechanisms. On the other hand, it is

known to be slow, particularly when running un-

der a non-x86 architecture.

• Genymotion. is a French company distributing

a virtualization solution for Android. It relies on

the well-known VirtualBox

hypervisor (Watson,

2008) and on the compatible images that can be

built from the Android source code. Those im-

ages are then modiﬁed to add Genymotion’s own

apps and services that can be used to control the

virtual machine remotely. They offer a different

set of capabilities than the Google emulator. In

Genymotion, the virtual machines are much more

responsive since they take advantage of virtual-

ization features offered by VirtualBox (instead of

being emulated).

• AndroX86.

is an open source project offer-

ing ports of the Android OS for different x86 plat-

forms. As a result, Android can be run in conven-

tional hypervisors such as VMWare Workstation

as well as bare metal on some supported hard-

ware conﬁgurations (e.g., Lenovo Ideapad S10-

3T). This solution provides great performance at

the cost of functionalities inherent to a mobile de-

vice (e.g., no support for SMS).

• Manymo. is a software as a service solution for

Android virtualization. It allows one to launch

Android virtual machines through a web interface.

These machines can then be controlled through

a command-line interface and run Android apps.

The main limitation of this platform is the num-

ber of launches and concurrent devices available,

which are both very small for non-paying users.

AVP differs from these projects as it is not meant

to provide new ways of virtualizing the Android en-

vironment. Instead, AVP builds on top of exist-

ing virtualization solutions to take advantage of their

strengths. AVP is designed to support multiple under-

lying virtulization options.

https://www.virtualbox.org/

http://www.android-x86.org/

2.2 Android Experimentation

Frameworks

Several tools to perform experiments in Android ex-

ist; mainly focussing on android sandboxing for dy-

namic (behavioral) malware analysis. Some are pre-

sented below to contrast them with AVP.

• TaintDroid. (Enck et al., 2010) is a modiﬁcation

of the Android API to allow tracking of sensitive

data through tainting. Tainting is a technique in

which data from sensitive sources is tainted. As

the data moves around the system (through vari-

able assignments, ﬁles and inter-process commu-

nication), the taint is propagated. If tainted data

escapes the system (through an internet connec-

tion, SMS, etc.), a notiﬁcation is made system-

wide, so that monitoring tools can detect it. Taint-

Droid focuses entirely on taint propagation and

does not provide automation

• AASandbox. (Blasing et al., 2010) is an Android

malware sandbox implemented at kernel-level. It

is entirely automated but focuses only on system

call tracking.

• DroidScope. (Yan and Yin, 2012) is another An-

droid malware sandbox located at hypervisor level

(a modiﬁed version of QEMU). DroidScope of-

fers an interesting level of automation. However

it focuses entirely on malware analysis; providing

information on taint propagation, memory state

and process state.

• Bouncer. is Google’s own solution designed to

prevent malicious applications from being added

to the Play Store. Since it is proprietary software,

little is known about its inner workings (Lock-

heimer, 2012; Percoco and Schulte, 2012). It

seems to run Android applications under Google’s

emulator for a few minutes and observe their be-

havior. Upon suspicious behavior, control can be

transferred to a human for further analysis.

• JOESandboxMobile.

is another proprietary so-

lution for Android malware analysis. It offers a

fully automated platform, but one which is fo-

cussing entirely on malware analysis.

• Monkeyrunner.

is Google’s API to automate

the control of their modiﬁed QEMU emulator.

This project does not focus on malware analysis

AVP can be used to automate the experiment ﬂow of

TaintDroid

http://www.joesecurity.org

http://developer.android.com/tools/help/monkeyrunner

_concepts.html

DCNET2014-InternationalConferenceonDataCommunicationNetworking

and do provide a more generic capability of cre-

ating experiments. However, the API is limited to

one emulator while AVP can integrate several.

Most of the tools available for Android applica-

tion analysis focus on a very narrow view of behavior

(e.g., taint tracking, malware behavior). In contrast,

AVP aims to provide the widest possible behavioral

view. In particular, by integrating several existing and

custom tools as AVP modules, it is possible to gather

more information. AVP targets a wide range of exper-

iments, not only those related to malware analysis.

Static solutions to malware analysis (code-based

analysis) are not discussed here since their ofﬂine na-

ture sets a very different scope from AVP. However,

static analysis solutions can be included in an experi-

ment system like AVP.

AVP distinguishes itself from existing solutions in

three ways. First, it is platform-agnostic: it can lever-

age several different virtualization technologies, and

has been built with expansion possibilities in mind.

Second, it fully automates the process of experimen-

tation in an Android environment; allowing to pre-

form controlled, custom and repeatable experiments.

Finally, it offers a wider scope than current solutions

by focussing not only on malware analysis, but on a

more general concept of experiment execution.

3 IN A NUTSHELL

This section provides an overview of the test-bed.

More details are provided in the following sections.

AVP was designed in order to perform different types

of experiments with Android devices in a virtual envi-

ronment. The main focus was automating the test-bed

and collecting data during the experiments.

Figure 1 presents the high-level workﬂow of AVP.

First, the user speciﬁes an experiment, both in

terms of the Android virtual devices (AVDs) to use

and the actions to perform. The experiment speciﬁca-

tion (what we call a scenario) is given to the system

through an XML ﬁle (1).

Next, the system validates that the scenario is cor-

rect (2). Validation is performed at different levels:

• Syntactic validation of the XML document (e.g.,

are the commands understood?)

• Resources validation (e.g., are all the required

AVDs available on the host?)

• Semantic validation of the action sequence (e.g.,

can an action really be executed in the current ex-

periment context?)

Whenever validation fails, the program terminates

with an error message. AVP also has a set of softer

validation rules that are considered best practice but

can be violated (e.g., timer issues, resources libera-

tion). In the later case, the system will provide warn-

ings but still perform the experiment.

Third is the execution phase (3), which represents

the heart of the test-bed. At this point, AVP instru-

ments an Android virtualization technology in order

to manipulate AVDs (e.g., start an AVD); it executes

actions on the AVDs and their applications; and then

collects experiment data (which is why the test-bed

was developed in the ﬁrst place). Most collected data

is linked to the behavior of the AVD or one of its ap-

plications. Section 4 will provides details regarding

the possible "actions" and the data collection capabil-

ities of AVP.

At the end of the execution phase, the test-bed au-

tomatically performs a clean-up phase (4). The in-

ner workings are actually quite similar to those of the

execution phase, but we keep it conceptually distinct

because it is out of the user’s control.

Finally, once the experiment is over, the user can

visualize and/or process the data collected during the

experiment (5). Data visualization can also be done

in real time during the experiment.

4 CAPABILITIES

This section deals with the core of our test-bed: the

actions it can perform automatically (Section 4.2) and

the data it can collect (Section 4.3). But ﬁrst, the vir-

tualization solutions supported in AVP are presented

(Section 4.1).

4.1 Virtualization

When building AVP, we did not want to create our

own virtualization environment. Instead, we wanted

to take advantage of the best existing solutions to em-

ulate Android devices. While studying existing vir-

tualization technologies, it quickly became apparent

that their objectives are not identical. For instance,

Google’s modiﬁed

version of the QEMU emulator

aims to provide an experience close to a physical An-

droid device in terms of functionalities (e.g., SMS

and calls). On the other hand, Genymotion

(For-

merly AndroVM/BuildDroid

), based on VirtualBox,

provides a more ﬂuid emulation targeting Android

apps developers requiring only limited functionality

Available through the ADT (Android Development

Tools) environment.

http://www.genymotion.com

http://androvm.org

AVP-AnAndroidVirtualPlayground

Figure 1: Android Virtual Playground Workﬂow.

(e.g., no support for SMS) but a more responsive ex-

perience.

Instead of choosing one technology, AVP was de-

signed in such a way that it could use different under-

lying technologies. As a consequence, the user has

access to a wider range of functionalities. As Section

5.1.1.3 will show, this choice has an impact on the

semantic validation of a scenario.

AVP currently supports four Android engines:

• Google’s modiﬁed QEMU emulator [Google em-

ulator]

• Genymotion’s free version emulator [Genymotion

emulator]

• Our own custom modiﬁed Google emulator

[Modiﬁed Google emulator]

• A real physical device

All of the above rely on ADB (Android Debug

Bridge) which provides a common mechanism to in-

teract with all of them. However, they all have par-

ticularities that need to be instrumented differently by

AVP. In the rest of the paper, unless explicitly men-

tioned, we focus on the Google emulator as it is the

most complete in terms of functionalities.

4.2 Actions

The set of actions supported by our test-bed can be

divided into two categories: lab actions and device

actions. A lab action (see Section 4.2.1) is an action

that is performed by our test-bed software (possibly

on a set of AVDs), while a device action (see Section

4.2.2) is an action that is executed by an AVD (as in-

structed by AVP).

4.2.1 Lab Actions

4.2.1.1 AVD Manipulation. AVD manipulation

actions are actions that aim to manipulate AVDs.

Examples of such actions are: create/deleteAVD,

start/stopAVD, push/pullFile, unlockAVD.

Most actions are self-explanatory, however, some

have details of interest. Starting and stopping AVDs

can be modiﬁed through the use of snapshots. AVP

allows the user to either boot (or not) from a snapshot

and save (or not) to a snapshot when closing. The

support for snapshots provides important advantages:

• It signiﬁcantly speeds up the booting process,

which is interesting in the context of performing a

large amount of experiments in batch.

• It allows containment of an experiment, that is,

the effect of an experiment has no repercussions

on the subsequent experiments (e.g., leaving an

application installed). This is of tremendous im-

portance for data collection experiments.

4.2.1.2 App Manipulation. One of the key ele-

ment with mobile devices is the manipulation of ap-

plications, referred to as "apps" on mobile platforms.

AVP supports three action related to manipulating

apps: InstallApp, StartApp, and StartMonkey. The

StartMonkey action will run the monkey

application

exerciser tool in the context of the speciﬁed app. This

is very interesting to perform an experiment simulat-

ing a user interacting with an application. The data

collection can then provide some behavioral informa-

tion regarding the tested app.

http://developer.android.com/tools/help/monkey.html

DCNET2014-InternationalConferenceonDataCommunicationNetworking

4.2.1.3 Lab Manipulation. Lab manipulations

are actions that are handled by the test-bed. The Wait

action allows the user to specify an amount of time for

the lab to pause before executing the next action. A

similar action, WaitForUser, can be used to pause the

lab until the user perform a speciﬁc action. Both the

the above actions are not dependant on any virtualiza-

tion technology. Hence, they are always available.

Starting an AVD (boot) is a process that can take

a long time

. Therefore, it is important for the lab

to wait until the device is booted before proceeding

further. An additional action called WaitForAVDBoot

achieves this.

Similarly, the installation of an application is not

instantaneous. AVP can wait until an application has

been installed through the WaitForAppInstall action.

Note that since the "wait" actions are blocking by

nature (while all other actions are non-blocking) they

come with an associated timeout threshold. When the

threshold is reached, the corresponding action is con-

sidered a failure and the experiment is aborted.

Finally, two actions can be performed by the lab

that will directly affect the AVDs: SendSMSToAVD

and CallAVD. This will result in sending an SMS

(resp. call) to a speciﬁc AVD as if it would have been

sent by another Android device.

4.2.2 Device Actions

The last type of actions supported by AVP are device

actions. These are actions that will be executed by the

AVD themselves. To achieve this, we developed an

Android app (named commandCatcher) that the lab

can install on an AVD and then invoke to request spe-

ciﬁc tasks to be executed by that AVD. The invoca-

tion is done through the intent broadcasting mecha-

nism which can be triggered from outside the AVD.

The list of device actions can be extended quite

easily simply by adding new capabilities to our com-

mandCatcher library. So far, the following device ac-

tions are implemented:

• Call: the device will initiate a phone call to a spec-

iﬁed number.

• SendSMS: the device will send the speciﬁed SMS

message to the speciﬁed number.

• Navigate: the device will open a web browser to

the speciﬁed URL.

If the Call or SendSMS action targets a device

also running inside AVP, the two devices will actually

communicate with one another. On the other hand,

specifying a phone number not inside AVP will result

From a few seconds to a few minutes depending on the

physical machine and the virtualization acceleration.

in only the ﬁrst half of the communication establish-

ment taking place (nobody is at the receiving end).

4.3 Data Collection

While executing an experiment, the main objective of

AVP is to collect data. To this end, we have iden-

tiﬁed some information worth having and developed

the corresponding mechanisms to collect it. Here is

the list of information that AVP can collect at this mo-

ment and their corresponding supported actions (fur-

ther details are provided below):

• SMS Activity: Start/StopRecordSMS

• Phone Call Activity: Start/StopRecordCalls

• Network Trafﬁc: Start/StopRecordNetworkTrafﬁc

• Running Processes: StartRecordProcesses

• System Calls Activity: Start/StopStrace

• Taint Propagation Activity:

Start/StopRecordTaintDroid

AVP can gather SMS and call activities (both out-

going and incoming). In doing so, it gathers the

sender and recipient of the exchange, and for SMS

the actual data exchanged. For the Google emulator,

this is done by installing an app inside the AVD that

will hijack SMS and call activities. However, we no-

ticed that it is possible (and quite easy) for a malicious

app to bypass this monitoring mechanism by avoid-

ing the built-in functionalities for SMS and call. To

circumvent this limitation, we slightly modiﬁed the

Google emulator to have a lower level access to SMS

and call activities, which is much more difﬁcult to by-

pass. This is the main difference between the stock

Google emulator and our modiﬁed version.

Network activity is recorded in a pcap ﬁle to al-

low further forensic of Internet access. Of particular

interest is the IP visited (e.g., publicity sites or botnet

Command and Control centers) as well as data down-

loaded (e.g., malicious payloads).

The list of running processes plus their usual in-

formation

can be obtained. this list is automatically

refreshed each time there is a change in process activ-

ity. This provides us with the evolution of processes

during an experiment.

System calls are monitored through the strace

utility. This provides the list of system calls for a

much deeper analysis.

Finally, through the use of TaintDroid (Enck et al.,

2010), AVP is able to track sensitive data leaking from

an AVD. This, however, requires a speciﬁc AVD con-

ﬁguration (through the use of particular image ﬁles).

process ID, owner ID, process Name, etc.

http://sourceforge.net/projects/strace/

AVP-AnAndroidVirtualPlayground

Thus, AVP treats TaintDroid as its own virtualization

technology (similar to Google emulator except it sup-

ports the taintdroid data collection process and instru-

ments the start mechanism in a different way).

Other pieces of data are always collected by AVP;

this information serves mainly as debug information.

More speciﬁcally, the logcat

stream and system logs

from the scenario execution (executed actions and is-

sued commands) are collected.

In the future we plan to integrate new data collec-

tion capabilities to AVP. In particular, by adding sup-

port for tools similar to TaintDroid (see Section 7).

5 USING AVP

As shown in Figure 1, the user interacts with AVP at

two moments. Initially, the user must create an XML

scenario describing an experiment (see Section 5.1);

this is the input to AVP. Then, after the experiment

has been executed, the user can visualize the data col-

lected (see Section 5.2).

5.1 Scenario

A scenario is made of two sections: devices and ac-

tions. The ﬁrst section speciﬁes which Android de-

vices will be used in the experiment. For each device,

the user must provide an ID, the underlying technol-

ogy and the device name. The ID is used through

the scenario to identify this device. The technology

refers to the virtualization technology used to power

the device (e.g., taintdroid meaning the Google emu-

lator with the TaintDroid images is used). Finally, the

name refers to the AVD ﬁlename on the host.

The second section is the sequential list of actions.

All actions are non-blocking (that is AVP will go to

the next action right after having issued the command

to execute the speciﬁed action) with the exception of

wait actions.

For instance, let’s consider an experiment for the

behavioral analysis of an application. Such an experi-

ment can be speciﬁed with 3 stages of actions: setup,

start collecting information, application execution.

In the setup phase, the lab will poweron (Star-

tAVD) the necessary AVDs. We can suppose only one

AVD "A" to host the appliction. In order to maintain

this AVD clean, we could use the option to boot from

an existing snapshot but not persist the changes, hence

leaving the snapshot unmodiﬁed after the experiment.

After waiting for device "A" to boot (WaitForAVD-

Boot), the unlock command is issued (UnlockAVD).

The Android logging system:

http://developer.android.com/tools/help/logcat.html

Then, data collection mechanisms are activated.

Depending on what we expect to observer, we can

decide what data to collect. For instance, if we

want to observe the communication behavior of

an App, the following would be interesting: SMS

(StartRecordSMS), calls (StartRecordCalls), network

trafﬁc (StartRecordNetworkTrafﬁc) and tainted data

(StartRecordTaintDroid).

Now the application is ready to come in play. The

app must ﬁrst be installed (InstallApp). Once the in-

stallation is over (WaitForAppInstall), the app can be

launched (StartApp). Then, we can use the Monkey

tool to perform a speciﬁed number of random actions

in the application context (StartMonkey). It would

also be possible to interact with the App in a more

precise manner (e.g., clicking on speciﬁc buttons in a

speciﬁc sequence); however, this requires a very App-

speciﬁc sequence to be speciﬁed.

Finally, it is possible, but not mandatory, to stops

the data collection mechanisms and the AVD. Upon

reaching the end of the scenario, the lab will close

each open handle in a speciﬁc way (e.g., open AVD

are turned off, data collection feeds are stopped).

5.1.1 Scenario Validation

Before the execution of an experiment begins, the sce-

nario must be validated. Validation occurs at three

different levels: syntactic, resources, and semantic.

5.1.1.1 Syntactic Validation. The syntactic vali-

dation is straightforward enough in XML. First, the

document structure is tested (e.g., is there a list of

devices before the list of actions?). Then, each ac-

tion is validated by ﬁrst making sure the action exists

and then verifying that the parameters to those actions

are correct, that required parameters are present, and

that they all have meaningful values. A last syntac-

tic check is performed to make sure all the devices

referenced in the actions belong to the list of devices

deﬁned in the scenario.

5.1.1.2 Resources Validation. Resources are val-

idated using a simple validation process that makes

sure the devices listed in the scenario exist and that

they can be used by the speciﬁed technology. The

Google emulator, Modiﬁed Google emulator, and

TaintDroid emulator can all support the same set of

QEMU-based AVDs. However, Genymotion has its

own set of VirtualBox-based AVDs. In addition, the

validation process veriﬁes that the applications used

in the different actions exist in their given locations.

DCNET2014-InternationalConferenceonDataCommunicationNetworking

5.1.1.3 Semantic Validation. The semantic vali-

dation is much more complex. AVP currently covers

only a small portion of the possible semantic rules.

Here are a few examples of semantic validation rules:

• Most actions cannot be performed on an AVD that

is not running.

• Some actions can only be executed if the AVD in-

volved is of a speciﬁc technology. For instance,

actions related to calls and SMS are not applica-

ble to a Genymotion AVD. Similarly, starting and

stopping physical devices is not supported.

• Some actions are strongly dependent on one an-

other. For instance, StartApp should always be

preceded by a corresponding InstallApp.

AVP also produces warnings that will not prevent

the execution but indicate a potential mistake in the

scenario for the following reasons:

• When a wait action is usually necessary but omit-

ted in the scenario (e.g., between starting an AVD

and executing an action on that AVD).

• When a stop action occurs without a preceding

corresponding start action.

• When a start action has no following correspond-

ing stop action. Although the lab will compensate

during the clean-up phase, this might indicate an

error on the user’s part.

5.2 Data Analysis

AVP will collect a lot of information during an exper-

iment. Moreover, the type of information collected

will vary from one experiment to the other (depend-

ing on which data collection mechanisms are used in

each experiment and the data actually generated by

the AVDs/apps). Since data collection is at the core

of AVP, the log format is easily searchable and AVP

comes with visualization tool for the logs. Each piece

of data collected during an experiment is stored in a

ﬁle speciﬁcally related to the nature of the data, then

log ﬁles are aggregated in a more generic ﬁle based

on the similarity of their content. Finally, all the in-

formation is aggregated into a master ﬁle.

Each entry of each log ﬁle contains ﬁve elements:

• Time: the timestamp of the event.

• Thread: the identiﬁcation of the AVP thread that

generated the event.

• Location: the origin (e.g., the method, class, li-

brary) of the event.

• Level: the importance of the logged event (Trace,

Debug, Info, Warning, Error).

• Message: a message describing the event.

5.2.1 Log Files

For each device, the information related to the lab ex-

ecution ﬂow for that speciﬁc device is stored in a ﬁle

(then, this information is aggregated in common ﬁle

for all devices). The following log ﬁles are generated:

• Output/Error information of the processes used by

AVP (e.g., adb.exe, aapt.exe) in one ﬁle per pro-

cess (and again aggregate all processes informa-

tion in a single ﬁle).

• Sent/Received SMS are stored in a per-device ba-

sis (and SMS activities for all devices are aggre-

gated in a single ﬁle.) The same occurs for calls,

system calls, running processes, and tainted data.

• Logcat output per device (and aggregated).

• A number of logging ﬁles related to the lab exe-

cution (e.g., debug, warnings, errors).

• Pcap ﬁles containing network trafﬁc logs on a per

device basis only.

5.2.2 Data Visualization

To facilitate the visualization of collected data, AVP

includes a generic log viewer. The log viewer will au-

tomatically create one view per log ﬁle. This feature

allows us to add the capabilities of logging new infor-

mation (i.e., creating new log ﬁles) without the need

to modify the log viewer. The log viewer allows for

searching and ﬁltering of data.

6 CONCLUSION

AVP (Android Virtual Playground) is a virtual test-

bed for the Android platform. The main objective of

AVP is to collect data during network experiment (on

Android), while its main strength is the high level of

automation it provides (from creating and launching

Android AVDs, to forcing AVDs to perform speciﬁc

tasks, while collecting data from several viewpoints).

Some solutions already exist for Android virtual-

ization/experimentation. However, they are either ex-

tremely limited in terms of capabilities (e.g., actions

to perform, data to collect) or they provide little (or

no) automation mechanisms. One interesting feature

of AVP (when compared to other existing solutions)

is the ability to use multiple virtualization technolo-

gies. As a result AVP can to harness the individual

strengths of each technologies.

The main challenge while developing AVP was

the lack of maturity of the existing virtualization so-

lutions for Android, especially when compared with

AVP-AnAndroidVirtualPlayground

their PC counterparts. Hence, properly instrument-

ing the virtualization environments and stabilizing the

execution of experiments proved to be more difﬁcult

than expected.

7 FUTURE WORK

AVP can be extended in several ways. Below are

some of the avenues we are currently working on, or

expect to work on in the near future.

At the user-level, it would be interesting to provide

a graphical user interface as an alternative to the XML

scenario writing step.

At the core of AVP lies the actions it can perform

during an experiment. This is where most of the fu-

ture work resides. Possible extensions are:

• Supporting new virtualization technologies and

integrating existing data collection solutions (such

as TaintDroid).

• Taking AVD screenshots during an experiment.

• Analyzing in more details the logcat output in or-

der to keep a more accurate representation of an

AVD’s current state (e.g., detect the classical case

where an app stops working).

• Providing more support for the integration of a

physical device (e.g., can we achieve something

similar to snapshots of AVDs with respect to

cleaning the device after an experiment).

From a networking point of view, we are inter-

ested in deploying a single experiment on several dif-

ferent physical host in such a way that all the AVDs

remain connected with one another, see (Gagnon

et al., 2010). For instance, even if AVDs A and B ac-

tually run on different physical machine, they should

be able to communicate through SMS.

Our experiment speciﬁcation language will evolve

(e.g., conditional execution and loops) with new uti-

lization cases of AVP that require more expressive

constructs. Moreover, to effectively support batch

execution of similar experiment, we plan to gener-

alize our scenario concept to introduce the notion

of templates. For instance, a scenario template de-

scribing an experiment could be written without in-

cluding the details on the application to use (for ac-

tions such as: InstallApp, WaitForAppInstall, Star-

tApp, and StartMonkey). Then, the scenario template

could be reused (and specialized) for each application

in a given dataset.

Regarding scenario validation (see Section 5.1.1)

signiﬁcant work remains to be done, in particular to

augment our semantic validation capabilities. More-

over, it would be interesting to provide a continuous

runtime monitoring engine that would detect (and ide-

ally try to recover from) problems occurring at run-

time. An example is the failure to install (or start) an

application in an Android device (possibly due to a

malformed apk/manifest).

ACKNOWLEDGEMENTS

We would like to thank Thales Canada inc. for their

support through this project. This work is funded

by the National Sciences and Engineering Research

Council of Canada through grants RDA1-447989-13

and RDA2-452896-13.

REFERENCES

Bellard, F. (2005). Qemu, a fast and portable dynamic trans-

lator. In USENIX 2005 Annual Technical Conference,

FREENIX Track - Abstract, pages 41–46.

Blasing, T., Batyuk, L., and Schmidt, A.-D. (2010). An

android application sandbox system for suspicious

software detection. In 5th International Conference

on Malicious and Unwanted Software (MALWARE),

pages 55–62.

Enck, W., Gilbert, P., Chun, B.-G., Cox, L. P., Jung, J.,

McDaniel, P., and Sheth, A. N. (2010). Taintdroid:

An information-ﬂow tracking system for realtime pri-

vacy monitoring on smartphones. In Proceedings of

the USENIX Symposium on Operating Systems Design

and Implementation (OSDI).

Gagnon, F., Esfandiari, B., and Dej, T. (2010). Network in

a box. In Proceedings of the 2010 International Con-

ference on Data Communication Networking (DC-

NET’10).

Lockheimer, H. (2012). Android and security.

http://googlemobile.blogspot.ca/2012/02/android-

and-security.html.

Massicotte, F. and Couture, M. (2011). Blueprints of

a lightweight automated experimentation system: a

building block towards experimental cyber security. In

Proceedings of the First Workshop on Building Anal-

ysis Datasets and Gathering Experience Returns for

Security (BADGERS ’11), pages 19–28.

Percoco, N. J. and Schulte, S. (2012). Adventures in

bouncerland - failures of automated malware detec-

tion within mobile application markets. BlackHat

USA.

Watson, J. (2008). Virtualbox: bits and bytes masquerading

as machines. Linux Journal, 2008(166).

Yan, L. K. and Yin, H. (2012). Droidscope: seamlessly

reconstructing the os and dalvik semantic views for

dynamic android malware analysis. In 21st USENIX

conference on Security (Security’12), pages 29–44.

DCNET2014-InternationalConferenceonDataCommunicationNetworking