Dragonfly: Encapsulating Android for Instrumentation

University of Málaga

Ana Rosario EspadaMaría del Mar Gallardo

Damián Adalid

2

Index

• Introduction• Android Overview• Formalization• Dragonfly Design• Static Monitor• Dynamic Monitor• Conclusions

3

INTRODUCTIONA Runtime Verification Framework for ANDROID Applications

4

Introduction

More than 6 million ofdifferent applications

Different kinds of applications in the market

5

Verification Techniques

Runtime VerificationRV is based on the observation of the traces generated by the execution of

a system to detect errors of its behavior.

RV types• Synchronous

Asynchronous• Internal External• Offline Online

6

ANDROID OVERVIEWA Runtime Verification Framework for ANDROID Applications

7

Android ArchitectureApplication

Built-in(phone, contacts, browser), Third-party/Custom

Application FrameworkTelephone Manager, Location Manager, Notification Manager, Content

providers, Windowing, Resource Manager, etc.

LibrariesGraphics, media, database, WebKit, etc.

Android RuntimeDalvik Virtual

Machine

Linux KernelPower, File system, drivers, process, management, etc.

8

Android System

9

Android System

Each application may be composed of different components:

•Activity: an independent visual screen for the user

•Service: particular task embedded inside a specific application

•Content provider: allows to provide data from one application to another

•Broadcast receiver: manages the messages sent by the system or the applications

10

FORMALIZING ANDROIDA Runtime Verification Framework for ANDROID Applications

11

Formalizing Android

We consider that applications may be in one of the following states:

•Inactive: the main thread does not yet exist.

•Active: the main thread of the application has been initialized and some service or activity is active.

•Paused: the application is initialized but none of its components is active.

12

Formalizing Android

The configuration of an Android application is given by a tuple:

•ID: the application identifier.

•State: active, inactive or paused.

•Event queue: each of which may be directed to one or several components of a system application.

•Components: a list of activities, services, content providers or broadcast receivers.

13

Formalizing AndroidAndroid is basically an event-driven OS. The whole system, its applications and its components evolve through events.

We formalize those events as transition rules, referred to the whole system, an application or a component.

Each element extracted from the event queue of an application may release concrete events for any component of the applications.

14

Formalizing Android

Once the event has arrived at the event queue, it is distributed to the corresponding components.

15

DRAGONFLY DESIGNA Runtime Verification Framework for ANDROID Applications

16

Functionality

Events

Monitor throwing eventsAnd listening the traces

Verification with observers

17

Dragonfly ArchitectureMonitor

INST

RUM

ENTA

TIO

N

Threads

Allocated Objects

Profiling data

…

Application Manager

Android Monitor Engine

Observer

Event Generators

Source

Emulator

Emulator

Emulator Android Model

Error Reports

18

Application Manager

• Generates random events using Monkey

Source

Emulator

Emulator

Emulator

Application ManagerEvent Generators

$ adb shell monkey -p your.package.name -v 500

19

Monitor Engine

…

Threads

Allocated Objects

Profiling data

Sour

ce

INST

RUM

ENTA

TIO

N

Abstract Monitor Engine

Android Monitor Engine

Generic Model

Android Model

Manager

Manager

Android Monitor Engine

Tools to extract information• DDMlib -> adb• JDI

•DDMlib allow us to start Android Debug Bridge and get useful information from the sources.•JDI (Java Debug Interface) is needed to detect method entry event and other specific events.

20

Instrumentation and observers

Error Reports

INST

RUM

ENTA

TIO

N

Android Monitor Engine

Observer

Android Observers

Observer

Generic Observer

Android Model

Generic Model

Observer

Aspect Oriented Paradigm

Instrumentation : Spring AOPDSL: Lambdaj + AspectJ

21

EXAMPLEA Runtime Verification Framework for ANDROID Applications

22

Activity Life Cycle

23

Activity Life Cycle

24

STATIC MONITORA Runtime Verification Framework for ANDROID Applications

25

Static Monitor

Static data are properties or values from the:

• Smart-phone: battery status, serial number…

• I/O’s: GPS status, camera status, signal strength…

• Applications: identifiers, names, main threads…

• Components: types, set of states…

26

Static Monitor

Source

DDMlibANDROID

MODELStatic info Build

27

DYNAMIC MONITORA Runtime Verification Framework for ANDROID Applications

28

Dynamic Monitor

Dynamic data correspond to the sequence ofevents fired by the system or by the user. Wedefine three types of events:

•Actions related to the state of components

•Method calls

•Exceptions

LISTENERS

29

Dynamic Monitor

SourceMonitor

Application Manager

Android Monitor Engine

Android Model

USB or Wireless

Stimulation events

Return events

30

CONCLUSIONS & FUTURE WORKA Runtime Verification Framework for ANDROID Applications

31

Conclusions

• We have developed a tool capable of:

– Verifying Android Applications on runtime

– Extending the verification to other platforms

– Saving a lot of verification properties

– Writing the properties in a semantic language

32

Future Work

• Improve the DRAGONFLY’s capabilities combining DDMlib with other tools

• Improve DRAGONFLY’s efficency trying other types of instrumentations and DSL’s

Thanks!!

Questions?