dragonfly: encapsulating android for instrumentation university of málaga
Post on 23-Feb-2016
47 Views
Preview:
DESCRIPTION
TRANSCRIPT
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?
top related