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?