Transcript Applications

Dragonfly: Encapsulating Android
for Instrumentation
University of Málaga
Ana Rosario Espada
María del Mar Gallardo
Damián Adalid
Index
•
•
•
•
•
•
•
Introduction
Android Overview
Formalization
Dragonfly Design
Static Monitor
Dynamic Monitor
Conclusions
2
A Runtime Verification Framework for ANDROID Applications
INTRODUCTION
3
Introduction
More than 6 million of
different applications
Different kinds of applications in the market
4
Verification Techniques
RV types
• Synchronous
• Internal
• Offline
Asynchronous
External
Online
Runtime Verification
RV is based on the observation of the traces generated by the execution of
a system to detect errors of its behavior.
5
A Runtime Verification Framework for ANDROID Applications
ANDROID OVERVIEW
6
Android Architecture
Application
Built-in(phone, contacts, browser), Third-party/Custom
Application Framework
Telephone Manager, Location Manager, Notification Manager, Content
providers, Windowing, Resource Manager, etc.
Libraries
Graphics, media, database, WebKit, etc.
Android Runtime
Dalvik Virtual
Machine
Linux Kernel
Power, File system, drivers, process, management, etc.
7
Android System
8
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
9
A Runtime Verification Framework for ANDROID Applications
FORMALIZING ANDROID
10
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.
11
Formalizing Android
The configuration of an Android application is given by a tuple:
•ID: the application identifier.
•State: active, inactive or paused.
•Components: a list of activities, services, content
providers or broadcast receivers.
•Event queue: each of which may be directed to one
or several components of a system application.
12
Formalizing Android
Android 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.
13
Formalizing Android
Once the event has arrived at the event queue, it is distributed
to the corresponding components.
14
A Runtime Verification Framework for ANDROID Applications
DRAGONFLY DESIGN
15
Functionality
Events
Monitor throwing events
And listening the traces
Verification with
observers
16
Dragonfly Architecture
Source
Monitor
Event
Generators
Application Manager
Allocated
Objects
Emulator
Emulator
Emulator
Profiling
data
Android
Monitor
Engine
INSTRUMENTATION
Threads
Observer
Error
Reports
…
Android Model
17
Application Manager
• Generates random events using Monkey
Source
Event
Generators
Emulator
Application Manager
$ adb shell monkey -p
your.package.name -v 500
Emulator
Emulator
18
Monitor Engine
Android Monitor
Engine
Manager
Android
Monitor
Abstract
Monitor
Engine
Engine
Source
Android Model
Allocated
Objects
Profiling
data
…
Tools to extract
information
• DDMlib -> adb
• JDI
Manager
INSTRUMENTATION
Threads
Generic Model
•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.
19
Instrumentation and observers
Observer
Android
Monitor
Engine
INSTRUMENTATION
Android
Observers
Android Model
Observer
Observer
Generic
Error Paradigm
Aspect
Oriented
Observer
Reports
Generic Model
Instrumentation : Spring AOP
DSL: Lambdaj + AspectJ
20
A Runtime Verification Framework for ANDROID Applications
EXAMPLE
21
Activity Life Cycle
22
Activity Life Cycle
23
A Runtime Verification Framework for ANDROID Applications
STATIC MONITOR
24
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…
25
Source
Static Monitor
Static info
DDMlib
Build
ANDROID
MODEL
26
A Runtime Verification Framework for ANDROID Applications
DYNAMIC MONITOR
27
Dynamic Monitor
Dynamic data correspond to the sequence of
events fired by the system or by the user. We
define three types of events:
•Actions related to the state of components
LISTENERS
•Method calls
•Exceptions
28
Dynamic Monitor
Monitor
Source
Application Manager
USB or Wireless
Android
Monitor
Engine
Android Model
29
A Runtime Verification Framework for ANDROID Applications
CONCLUSIONS & FUTURE WORK
30
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
31
Future Work
• Improve the DRAGONFLY’s capabilities
combining DDMlib with other tools
• Improve DRAGONFLY’s efficency trying other
types of instrumentations and DSL’s
32
Thanks!!
Questions?