Dragonfly: Encapsulating Android for Instrumentation University of Málaga

1. Dragonfly: Encapsulating Android for InstrumentationUniversity of Málaga Ana Rosario Espada María del Mar Gallardo DamiánAdalid

2. Index • Introduction • Android Overview • Formalization • Dragonfly Design • Static Monitor • Dynamic Monitor • Conclusions

3. A Runtime Verification Framework for ANDROID Applications INTRODUCTION

4. Introduction More than 6 million of differentapplications Differentkinds of applications in themarket

5. Verification Techniques • RV types • Synchronous Asynchronous • Internal External • Offline Online RuntimeVerification RV is based on the observation of the traces generated by the execution of a system to detect errors of its behavior.

6. A Runtime Verification Framework for ANDROID Applications AndroidOverview

7. AndroidArchitecture 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. AndroidRuntime Dalvik Virtual Machine Linux Kernel Power, File system, drivers, process, management, etc.

8. Android System

9. AndroidSystem Each application may be composed of different components: • Activity: anindependentvisual 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. A Runtime Verification Framework for ANDROID Applications FormalizingAndroid

11. FormalizingAndroid We consider that applications may be in one of the following states: • Inactive: the main thread does not yet exist. • Active: themain thread of the application has been • initialized and some service or activity is active. • Paused: theapplication is initialized but none of its components isactive.

12. FormalizingAndroid The configuration of an Android application is given by a tuple: • ID: theapplicationidentifier. • State: active, inactiveorpaused. • Components: a list of activities, services, contentprovidersorbroadcast receivers. • Eventqueue: each of which may be directed to one or several components of a system application.

13. FormalizingAndroid Androidisbasicallyanevent-driven OS.Thewholesystem, itsapplications and itscomponentsevolvethroughevents. Weformalizethoseevents as transition rules, referredtothe wholesystem, anapplicationor a component. Eachelementextractedfromtheeventqueue of anapplicationmayrelease concrete eventsforanycomponent of theapplications.

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

15. A Runtime Verification Framework for ANDROID Applications Dragonfly DESIGN

16. Functionality Events Verificationwithobservers Monitor throwingevents And listeningthe traces

17. Dragonfly Architecture Source Monitor EventGenerators Application Manager INSTRUMENTATION Android Monitor Engine Observer Threads AllocatedObjects Error Reports Profiling data Emulator Emulator … Emulator AndroidModel

18. Application Manager • Generates random events using Monkey Source Application Manager EventGenerators $ adbshellmonkey-p your.package.name -v 500 Emulator Emulator Emulator

19. Monitor Engine INSTRUMENTATION Android Monitor Engine Android Monitor Engine Manager Source Threads AndroidModel AllocatedObjects Abstract Monitor Engine Profiling data Manager … GenericModel • Tools to extract information • DDMlib -> adb • JDI • DDMliballowustostartAndroidDebug Bridge and getusefulinformationfromthesources. • JDI (Java Debug Interface) isneededtodetectmethodentryevent and otherspecificevents.

20. Instrumentation and observers Observer INSTRUMENTATION Observer Android Monitor Engine AndroidObservers AndroidModel Observer GenericObserver Error Reports AspectOrientedParadigm GenericModel Instrumentation : Spring AOP DSL: Lambdaj + AspectJ

21. A Runtime Verification Framework for ANDROID Applications Example

22. Activity Life Cycle

23. Activity Life Cycle

24. A Runtime Verification Framework for ANDROID Applications Static Monitor

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 ANDROID MODEL DDMlib Staticinfo Build

27. A Runtime Verification Framework for ANDROID Applications Dynamic Monitor

28. Dynamic Monitor Dynamic data correspond to the sequence of events fired by the system or by theuser. We define three types of events: • Actionsrelatedtothestate of components LISTENERS • Methodcalls • Exceptions

29. Dynamic Monitor Monitor Source Application Manager Stimulationevents Android Monitor Engine USB orWireless Returnevents AndroidModel

30. A Runtime Verification Framework for ANDROID Applications ConcluSIons & FUTURE WORK

31. Conclusions • Wehavedeveloped a toolcapable of: • VerifyingAndroidApplicationsonruntime • Extendingtheverificationtootherplatforms • Saving a lot of verificationproperties • Writingtheproperties in a semanticlanguage

32. FutureWork • ImprovetheDRAGONFLY’scapabilitiescombiningDDMlibwithothertools • ImproveDRAGONFLY’sefficencytryingothertypes of instrumentations and DSL’s

33. Thanks!! Questions?