ZapDroid: Managing Infrequently Used Applications on Smartphones Indrajeet Singh Srikanth V. Krishnamurthy Harsha V. Madhyastha UC Riverside UC Riverside University of Michigan [email protected] [email protected] [email protected] Iulian Neamtiu UC Riverside [email protected]
ABSTRACT More generally, users may only interact with some down- User surveys have shown that a typical user has over loaded apps infrequently (i.e., not use them for prolonged a hundred apps on her smartphone [1], but stops using periods). These apps continue to operate in the back- many of them. We conduct a user study to identify such ground and have significant negative effects (e.g., leak unused apps, which we call zombies, and show via exper- private information or significantly tax resources such iments that zombie apps consume significant resources as the battery). Unfortunately, users are often unaware on a user’s smartphone and access her private informa- of such app activities. We call such seldom-used apps, tion. We then design and build ZapDroid, which enables which indulge in undesired activities, “zombie apps.” users to detect and silo zombie apps in an effective way In this paper, we seek to build a framework, ZapDroid, to to prevent their undesired activities. If and when the identify and subsequently quarantine such zombie apps user wishes to resume using such an app, ZapDroid re- to stop their undesired activities. Since a user can change stores the app quickly and effectively. Our evaluations her mind about whether or not to use an app, a zombie show that: (i) ZapDroid saves twice the energy from un- app must be restored quickly if the user chooses.1 wanted zombie app behaviors as compared to apps from the Play Store that kill background unwanted processes, The classification of an app as a zombie app is inher- and (ii) it effectively prevents zombie apps from using ently subjective. An app unused for a prolonged period undesired permissions. In addition, ZapDroid is energy- should be classified as a zombie app if its resource usage efficient, consuming < 4% of the battery per day. during the period is considered significant and/or if its access of private data is deemed serious. Thus, instead ACM Classification Keywords of automatically classifying zombie apps, we seek to em- D.4.9 Operating Systems: Systems Programs and Utili- power the user by exporting the information that she ties would need to make this decision. Moreover, the way in which a zombie app should be quarantined depends on Author Keywords whether the user is likely to want to use the app again Smartphones; energy; privacy in the future (e.g., a gaming app that the user tried once INTRODUCTION and decided is not interesting vs. a VoIP app that the The Google Play Store has more than 1.3 million user uses infrequently). The apps that a user is likely to apps [22], and the number of app downloads is roughly 1 use again fairly soon must not be fully uninstalled; real billion per month [15]. However, after users interact with time restoration (when needed) may be difficult if there many such apps for an initial period following the down- is no good network connectivity. We seek to enable users load, they almost never do so again. Statistics indicate to deal with these different scenarios appropriately. that for a typical app, less than half of the people who Challenges: We address many challenges en route de- downloaded it use it more than once [13]. Reports also signing and building ZapDroid. First, to motivate the suggest that more than 86 % of users do not even revisit need for ZapDroid, we ask the question: “How often do an app, a day after the initial download [30]. Uninstall users download apps and leave them on their phones, rates of apps however (longer term), of about 15 to 18 % and how do these apps adversely affect the user in terms are considered high [26]. This means that users often of consuming phone resources and privacy leakage?” We leave installed apps on their phones. address this challenge via an extensive user study. Next, Permission to make digital or hard copies of all or part of this work for we ask “How can we detect background apps that either personal or classroom use is granted without fee provided that copies consume high resources or violate privacy in a lightweight are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. manner ?” Such apps are the candidates for being zombie Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy 1For example, [12] reports that there are over 300 million otherwise, or republish, to post on servers or to redistribute to lists, installs of Skype, but the number of active users daily is only requires prior specific permission and/or a fee. Request permissions 4.9 million. Inactive users of Skype may want to disengage from [email protected]. the app to prevent it from using network/energy resources. UbiComp ’15, September 7-11, 2015, Osaka, Japan. Copyright 2015 c ACM 978-1-4503-3574-4/15/09...$15.00. However, they may want quick restoration when needed. http://dx.doi.org/10.1145/2750858.2807550 apps. Continuous app monitoring (e.g., [49]) can be too on the device itself. For the second category, the asso- resource-intensive to be practical. Further, application- ciated data/binaries are removed from the device and level implementations are infeasible since Android does user-specific app state is moved to either the cloud or not allow any app to track the permission access patterns to a different device (a desktop) owned by the user; of other apps. The third challenge is to effectively quar- the transfers occur when there is good network con- antine apps, i.e., “How can we design effective methods nectivity (e.g., WiFi coverage or a USB cable). to ensure that zombie apps are quarantined and remain • Restore an app with all its permissions if the in that state unless a user wants them restored?” With user desires: ZapDroid restores a zombie app on the current approaches, apps’ background activities are con- user’s device if she so desires. The state of the app strained only temporarily [32], until they are woken up is identical to that prior to the quarantine. For the due to time-outs or external stimuli [6, 14]. Finally, “ “likely to restore” category of apps, the restoration How can we restore previously quarantined apps in a time is < 6ms. For the “unlikely to restore” cate- timely way, even under conditions of poor network con- gory, restoration depends on the network connectivity nectivity (if the user desires)?” The restored app must to where the app was stored during the quarantine and be in the same state that it was in prior to the quaran- is typically on the order of a few seconds. tine. Reinstalls from the Google Play Store can be hard if network connectivity is poor and hence, should not be We evaluate ZapDroid via extensive measurements on invoked when it is highly likely that the user will restore 5 different Android smartphones (from 4 vendors). We the app. Further, clean uninstalls can result in loss of show that the overhead of ZapDroid is low ( < 4% of the application state. battery is consumed per day). We show that ZapDroid Contributions: Our framework, ZapDroid, addresses saves more than 2× the energy expended due to zombie the above challenges and allows users to effectively man- app activities, as compared to other popular apps on age infrequently used apps. In designing and building the Google Play Store used to kill undesired background ZapDroid, we make the following contributions. processes; further, unlike these apps, it prevents access to undesired permissions by the zombie apps. • Showcase the unwanted behaviors of candi- date zombie apps: We conduct a month-long study Note that ZapDroid does not require changes to an exter- where we enlist 80 users on Amazon’s Mechanical nal cloud store (for quarantine or restoration); all modi- Turk to download an app (TimeUrApps) we develop. fications are made only in the Android OS. We envision TimeUrApps identifies (other) apps that have not been that the features of ZapDroid will be useful in general, used for the month, on the users’ phones. Once we and our hope is that this could lead to an integration of identify these apps, we undertake an in-house, com- the functions within the Android OS. prehensive experimental study to understand their be- UNDERSTANDING ZOMBIE APPS haviors when they are not being actively used. We find We begin with an in-depth measurement study that has that a zombie app on a typical user’s phone (the me- two main goals: (a) revealing zombie apps, via an IRB- dian user in our targeted experiments) could consume approved user study, and (b) profiling zombie apps to as much as 58 MB of bandwidth and more than 20% quantify their adverse effects both in terms of resource of the total battery capacity in a day. Further, many consumption as well as privacy leaks. of such apps access information such as the user’s lo- cation and transmit this over the network. User Studies • Identify candidate zombie apps that are most We undertake a large-scale user study to identify apps detrimental to the user’s device: We design mech- that are installed but not used. We build an app, anisms that are integrated within the Android OS (we TimeUrApps,and post it to the Google Play Store. We make changes to the underlying Android Framework’s solicit volunteers on Amazon Mechanical Turk to install activity management, message passing, and resource TimeUrApps. TimeUrApps records the following for 30 management components) to track (i) a user’s inter- days: (i) the apps installed on users’ devices, and (ii) actions with the apps on her device to identify unused the timestamps of all events where an app is switched apps, and (ii) the resources consumed and the private to the foreground from the background or vice versa. It information accessed by these apps to determine can- implicitly starts the Accessibility Services [3] upon ac- didate zombie apps, from which the user can choose tivation, which facilitates the collection of this informa- to quarantine those she considers to be zombie apps. tion. This allows the detection of apps that have been inactive for extended periods. • Dynamically revoke permissions from zombie apps, or offload them to external storage: The To be eligible for our study, we required that a user must quarantine module of ZapDroid is invoked based on have at least 40 third-party apps installed. This number user input. She has to categorize a zombie app as was motivated by a Nielsen study [20], which reports either “likely to restore” or “unlikely to restore”; the that the average number of third-party apps on a user’s two categories are quarantined differently. For the first smartphone is 41 (although many users can have a much category, only permissions enjoyed by the zombie app higher number of such apps [13]). A total of 87 users are revoked but all relevant data/binaries are stored downloaded TimeUrApps. We filtered out 7 users that Category Types of Apps Games Role playing and turn-based games goal is to characterize individual app behavior. Second, Tools Memory cleaners and task managers we chose 15 users at random from our 80 volunteers, each Productivity Barcode scanners and cloud drives with a different number of unused apps (ranging from 7 Entertainment Media streaming and ticket sales to 54), and installed all the unused apps from a user Social Social networks and event planning profile on a phone. We then executed all these apps in Table 1: Types of apps in the top 5 categories. background mode without user intervention, to quantify
1.0 the collective impact of the apps. In this section, we only 600 show subsets of our results due to space constraints.
400 For some of the apps, we took additional steps to en-
0.5 sure their proper execution. For example, the Facebook 200 app will not execute unless the user has an account and
Number of Unused Apps Unused Number of 0 has logged onto it on the device (many users who had Fraction of Unused Apps Unused of Fraction Games Tools Social Shopping Lifestyle Facebook installed never interacted with it during our Productivity EntertainmentCommunication Music Personalization & Audio 50 100 200 500 App Categories Number of apps installed month-long study!). A second example was the Angry (a) Categories of apps (b) Fraction of unused apps Birds game; unless the users finished the first level, the Figure 1: App statistics from the user study. app would not have an initial score to check against other users and would not communicate with a server. In this installed new apps just prior to downloading our app, to case, we assume that a user who installed Angry Birds reach the required app count of 40 (so that they could has completed at least one level. Our rendering in the claim the reward that we promised). This left us with above cases provides a conservative estimate of resources 80 users. The data collected by TimeUrApps from each consumed by the apps; a more complex (and possibly re- user’s phone was transferred to our servers using WiFi alistic) profile will incur higher resource drain. as long as access was available within a five day period after collection. If no WiFi access was available for 5 Measuring resource consumption: Our smartphones days, the data was transferred on the cellular network. transfer content over WiFi (we have some limited ex- All the apps that were unused for a period of a month periments over LTE as discussed later). Each device are considered potential zombie apps. We select the top connects to a Man-in-the-Middle (MitM) Proxy, which 5 categories of unused apps (Table1) based on this data logs every IP packet that the device sends out. On the set and perform a more in-depth study. The categories Android devices themselves, we (a) embed a certificate are based on the definitions in the Google Play Store. generated by our proxy as a “root certificate” to en- sure that the proxy can decode all packets sent by the The number of apps in various categories that we ob- device, and (b) install tcpdump to monitor the traffic served in our dataset is plotted in Figure 1a. We see the device sends out on the local network, e.g., UDP that more than 1,000 unique apps were not used in the broadcasts. We used PowerTutor[49] to estimate the one-month test period. We also examine whether the CPU usage and energy consumption by each app. The number of unused apps on a device depends on the to- readings in Joules are converted to a battery percent- tal number of apps installed. In Figure 1b, we show the age. For example, the Samsung Galaxy S4 has a a rating fraction of apps that were never used, for each user, in of 9.88Wh ([email protected] [24]), which corresponds to the month. Interestingly, the results suggest that regard- 9.88 × 3600 J. The percentage of battery power is ex- less of how many apps were installed on a phone, a user pressed relative to this rating. Note that PowerTutor is rarely interacts with more than half of them. not used with ZapDroid; it is only used in our measure- ment study. Offline Measurement Methodology Permission access patterns: Since Android does not au- Once we identify unused apps from our users, we per- tomatically allow us to log the permissions accessed by form offline measurements to determine which of these an app, we root one of our phones and install ZapDroid consume significant resources or access/leak private in- (described later). This allowed us to log the default per- formation while running in the background. We measure missions that were accessed by these applications. the resources consumed in terms of the battery drain, the network bandwidth, and time spent on the CPU. Note Measuring space consumed by zombie apps: As an aux- that we did not measure these on the study subjects’ iliary resource, we measure the disk space consumed by phones since this needs active monitoring (rooting the each zombie app on any user’s smartphone. There are phones) and transferring large volumes of data. two types of data being stored: (i) App Binary: This is user-independent data, which includes the app binary Scenarios considered: Our measurement studies were downloaded from the Google Play Store (.apk) and any conducted on five different smartphones, from four dif- additional data that the app will need for it to function; ferent vendors: a Moto X (Motorola), a Nexus 4 and a the Google Play Store puts a limit of 50MB on the for- Nexus 5 (LG), a Samsung Galaxy S4, and an HTC One. mer and 2GB on the latter [17], (ii) App Data: This is First, we did a quick examination to find the apps that user-dependent data, which is not content created by the consumed the highest resources. We then installed these user herself (e.g., photos) but the byproduct of her inter- apps in isolation, and let them run in background mode action with the app (e.g., temporary files); we only focus without user intervention for a period of 100 hours. Our pso eu 5 Nexus a on apps zombie by consumed Energy (a) zom- apps different bie from Traffic (a) eosreta h collective the that users. apps observe We of zombie user’s set 2b . Figure each selected in to randomly shown due are a transfers be- for network collective the The apps sce- captures of second and the haviors earlier, with described performed nario is experiment usage. next data cellular Our on when limits user Words the impose hurts to operators This due mobile WiFi). LTE to over approx- (similar transferred Friends example, with was for MB time, 38 this a imately over During this communications verified period. We these 12-hour network. off, the cellular for turned the unused is over remained WiFi happen that the volunteer apps If 80 20 our could month. least of apps thus, at most zombie had bandwidth; 20 period; users of with 24-hour MB user a 20 a consume over period, bandwidth same the more of over consume The MB could app background. 1 zombie the than a that in shows activity also the figure con- perform it notifications to app’s the tinued disabled or if ignored even user Worse, the servers. an contin- remote to with consumed synchronization due therefore uous bandwidth, apps network of These likely amount are inordinate user. that the games new interest find to to try bandwidth actively zombie like addition, consume Games in these popular advertisements. of the to Many of due dataset. some our in by apps generated device. the traffic user’s for work a unused on was app) impact: zombie Bandwidth that a app considered (any is im- apps month the zombie showcase of to measurements pact our present we Next, Inferences and rooted Results separately.Measurement with data students this volunteer gathered and 25 phones to Android information app any our with Since tributed us of. provide the rid not get on as did to classified study want user be would our cannot user former the the that something because latter the on
Words With Friends Words With Friends Percentage of Battery Drained MB of Data Used in 100 Hours 1000 10 15 20 25 100 0 5 10 1 iue3 nrycnupinb obeapps. zombie by consumption Energy 3: Figure iue2 ewr rnfr yzmi apps. zombie by transfers Network 2: Figure
CPU Network Pandora p data App AngryBirds Starwars HillClimb Pandora Applications
App AngryBrids Hillclimb LED Flashlight
LED FlashLight Google Currents tepoe eentroe) edis- we rooted), not were phones (the CandyCrushSaga
Google Maps eqatf h net- the quantify we 2a, Figure In
Total n.o obeap nbars) on apps zombie user of per (no. consumed Energy (b) n.o obeap nbars) on user apps zombie per of transferred (no. Data (b)
Battery Percentage MB of Data Transfered 100 in a Day 10 20 30 40 50 60 50 0 0 6 6 7 7 od ihFriends with Words CPU WiFi 8 8 8 8 9 9 9 9 User Devices User Devices 10 10 12 12 13 13 14 14 30 30 32 32 34 34 35 35 , 54 54 tr uhap fteue ae ihst neatwith interact to wishes later user effectively the re- by quickly if to device apps seeks such user’s also store it a However, on them. quarantining apps used frequently ZapDroid ZAPDROID OF OVERVIEW execution AN itself. the by stopping inadequate Thus, users, is user. for apps the concern zombie by of a created is data storage the not required if the and of data app) size the the user-independent by by additional dominated is (and app binary an by up taken smartphone. space her on leakages apps privacy zombie Storage: of has risk user significant in- a a results when is These – there network). identifier that the over dicate device – unique State Phone the HillClimb Read transferred (e.g., network and the accessed ac- was over information communicated this leak of tually that some bits that permission verified the we indicates of privacy; shaded, part is The that background. figure the in Internet the that Note accessed net- a device. from the disconnect of or work) (e.g., WiFi, connectivity with network points the access switch modify addition, location, to In user’s permission the a [29]. to or calling access be requested may apps zombie user permis- most a this is use who can track This a app to zombie tracking sion a get for However, and device. user. to delivery end the advertisement the them for with allows used mostly which associated apps zombie identifier state all unique phone’s almost that the observe access we 4, leaks: privacy Figure and From 22%). permissions about undesirable bat- of of S4’s Use (median typical the Galaxy average over a a on that of on power 24% see tery installed about we apps consumed 3b , phone phones) zombie Figure user’s volunteers’ the In our period, on worse. 24-hour case even such the be of is will number (as larger a apps of [43]. zombie much impact en- as collective times the the three Finally, network been have cellular was could the measurement consumed over ergy this WiFi; that over Note conducted of 3.7V. period). 6% at ( 100-hour about day consumed mAh the per apps Nexus 2300 capacity zombie battery Google the of the of a capacity 4 on battery that 2a) see a We Figure has in which as zom- 5, same popular (the by activities apps CPU bie and network both to due the drain: omit constraints. Energy we space results, to energy expense due our resource details in this captured Since implicitly user. haveis the that by levels completed the records been also app cached stores the that advertisements; database our internal its in updates Hill- revealed spection, is as app such which, One Climb, activities. when network even in background, indulging the not in continu- cycles that CPU trans- apps consume zombie network ously some with however, are, correlate There apps fers. the by caused day. spikes per data consumption: of trans- MB CPU could 100 phones than users’ more some fer on apps zombie of group sga st lmnt h des ffcso in- of effects adverse the eliminate to is goal ’s eseta h mutof amount the that see we 5, Figure From eso h atr drain battery the show we 3a, Figure In o ayzmi ps CPU apps, zombie many For ≈ all 5 ftebteyover battery the of 25% h obeap shown apps zombie the strace in- [27] -based o uoaial urnie;ised h srdecides are user apps the this, instead, Given quarantined; automatically later). not this how overcome discuss to the (we modified with be app received the restores not plicitly are app exter- that quarantined, current using are Second, phone messages Skype) apps. her nal (e.g., quarantined apps since from for interactive features website), updates if new a receive these up- not (e.g., of an will channel know by lack to external incorporated the get an of later must because are she app that date, the features using some stopped temporarily). of she (albeit phone if her Thus, from app the “removes” case). lunch: second free app another No the to zombie (in or the storage cloud moves the free to or of data re- form case) associated to first its with “likely the along as (in restore”, tagged device to is the “unlikely app Depending or zombie store” the apps. zombie whether chosen on the of module quarantines quarantine lessly the above, as put (“unlikely apps: future zombie near Quarantining the in that again restore”). ones using to as to be likely or not restore”) is these be to will (“likely she she declare to future that near may apps the ones in her user zombie as use of (individually) the these metric apps addition, of any zombie In subset on a based app. quarantined. list tag zombie the each and sort by concern the may accessed user bits of The KB/MB), permission MB), terms (in (in the consumed in storage usage and %), network activity (in front consumption seconds), app’s battery the (in zombie via usage each user CPU re- the of either to mary presented of on is iden- (based end above, criteria) as apps access permission tified zombie or consumption candidate source quarantine: the identified. for of be to input accessed apps bits zombie User allows permission This 1 the resource them. to logs their by tracks set (ii) (i) and user; then consumption module the the by apps, these set are For implementation) is our that in prolonged week parameter for interact (a not does periods device. user user’s the a which on with apps Apps all monitors module profiling and apps: architecture zombie profiling high-level and the Detecting show we 6, of Figure In them. iue4 emsin sdb obeapps. zombie by used Permissions 4: Figure
Permission Change State Network Bit Access Network State Network Access Recv Msg from GCM Recv ZapDroid Read PhoneRead State Start Start Any Activity External Storage External Record Audio Broadcasts ZapDroid ZapDroid Location Internet
HillClimb n h neatosbtenismodules. its between interactions the and
Candy Crush Words With Friends yqaatnn nap sressentially user a app, an quarantining By h itas otisasum- a contains also list The . mlmnain nesteue ex- user the unless implementation, Application Name
Guess thePandora Emoji
Angry Brids
Clash of Clans ae nteue’ in- user’s the on Based ZapDroid candidate
akodrdlist ordered rank A LED Flashlight ZapDroid ZapDroid h detection The obeapps. zombie ean ton it retains yzmi apps. zombie consumed by Storage 5: Figure
Injustice Among Us Storage Consumed (MB) 1000 100 seam-
AngryBirds Starwars may
Clash of Clans App Name h rtmdl of module first The APPS ZOMBIE PROFILING AND IDENTIFYING • n sdi ti xctdi h oerud odetect Android; To of part foreground. is the foreground, that in the technology executed in run is that it apps if used ing apps: foreground Detecting via apps. user unused the by as prolonged set for end) interact is value not (the does periods user the which with apps app. zombie apps: candidate unused a resources Finding is consumes permissions that accesses app or unused Any ac- permission patterns. and cess consumption resource their monitors • • designing when goals ditional case). the goals: commonly is Auxiliary (as store require- the only by The that moved. are is app whichments to restore” store to the “unlikely to an needed are changes No smartphone. and ZapDroid stored is Remark: it permissions. where restoration its from re-enables the app subsequently app, prior the restore” downloads in, to module “unlikely to was “likely an permissions. it for restore their To that re-enabling restoration involves of state just apps process same restore” The exact quarantine. the to to of app module restoration the quarantine: the for input, user chosen apps from Restoring the app app, zombie the quarantined ‘untags’ previously user a use To be phone. to are apps which dniyn addt obeap;ised esml reuse simply we instead, apps; zombie candidate identifying 2 ecudhv sdAtvt ieyl alak towards callbacks lifecycle Activity used have could We etal e nnw unrblte ol arise). could po- vulnerabilities allowed, unknown are escalations new such tentially (if application any of Android. of vendor’s version specific Security: particular a a on on working or to device(s) limited be not must on quick. compatibility: be should is Broad apps connectivity of WiFi restoration good and when available), performance cloud device to quar- impact offload The (e.g., not should smartphone. user’s process antine a on resources nificant overhead: Low AngryBrids
Candy Crush Saga most App Binary App Data nri eie,i o l.I te od,it words, other In all. not if devices, Android ZapDroid put iue6 ihlvlacietr of architecture High-level ZapDroid 6: Figure ese ostsytefloigad- following the satisfy to seek We Restore permissions to app if on local local on if Restore app permissionsto Revoke permissionsorship and to cloud/other user device cloud/other to unused Identify device else download and restore and deviceelse download ZapDroid ZapDroid Quarantine Zombie Apps Zombie Quarantine apps xlsvl eie nteuser’s the on resides exclusively virtually Restoration of ActiveStatus Restorationof hudnteclt h privileges the escalate not should get ZapDroid . Detect and Profile Zombie Apps Zombie Detect Profile and ZapDroid napi osdrda be- as considered is app An ZapDroid usage andpermission Profile unused apps: unused Profile nefcsb implemented be interfaces Monitor resource Monitor accesspatterns ZapDroid eoe rmhrsmart- her from removed eet nsdap and apps unused detects hudntcnuesig- consume not should ZapDroid lsie third-party classifies 2 User Input sfotend. front ’s since ZapDroid hudb usable be should ZapDroid : User Input zombie apps with with apps zombie ssassistive uses Export candidate Export profiles to user to profiles ZapDroid zombie apps zombie candidate Identify Identify ae on Based returns sfront ’s is 3rd Party Apps Find Unused Apps User ZapDroid 3rd Party Apps Files Front End User ZapDroid Files Front End User Space User Space
System Space System Space
Permission Service System Files Activity Manager Activity Manager Service /acct Activity Manager Service Quarantine Manager Location Manager Resource Monitor Broadcast Queue WiFi Service /proc/net Network I/O Accessibility Service (a) Detection (b) Quarantine and Restoration Created Used Modified Figure 7: ZapDroid’s modules. partly implemented in Android’s Linux kernel, no user Determining storage: The Resource Monitor in Zap- intervention is required to enable accessibility. At install Droid calls the du command to measure the disk usage time, ZapDroid adds an accessibility service that cus- of an unused app. It essentially measures the space con- tomizes the wake-up trigger by subscribing to the event sumed by three folders (recursively): 1) /data/data/ TYPE WINDOW CONTENT CHANGED. This event
Time (ms) 100 10 (a) 1
iue1:Qaatn overhead. Quarantine 11: Figure -6 1000 0.01
Time (10 s) 100 0.1 ZapDroid 10 1 ZapDroid iigDelay Timing AMS Samsung Galaxy Samsung S5 Galaxy Samsung Nexus Galaxy a iigDelay Timing (a) Operation AIDL iue9 oprsno P mechanisms. IPC of Comparison 9: Figure ZapDroid IPC Mechanism b numdfidvrino nri with Android of version unmodified an (b) , ZapDroid Android BQ spromnewt hto w popular two of that with performance ’s SharedPref identical Energy Consumed (mJ) 200 100 onoddanwbnr rmthe from binary new a downloaded Messenger b Energy (b) AMS ZapDroid Operation eu eie n install: and devices 4 Nexus
Energy per call (mJ) 10 20 50 2 5 ZapDroid Android BQ Samsung Galaxy Samsung S5 Galaxy Samsung Nexus Galaxy AIDL nconstraining in b Energy (b) IPC Mechanism
1000 Time2000 (ms)3000 4000 0 SharedPref a ieTaken Time (a) WiFi LTE 10 5.6 iue1:Rsoainoverhead. Restoration 12: Figure ecom- We Category L Category SD File (MB) sizes 20 5.6 Messenger 30 5.7 40
Time (ms) 10 5.6 1 Security: up. per- wake undesired Defender they using Juice when here from missions apps nor out these preventing Killer point higher in Task we helps much Advanced Finally, a neither achieved. thus, that is and savings quarantined energy awake. once being being up apps upon waking zombie intensive latter’s This resource ZapDroid the apps. and zombie of active 14 artifact to more just compared an with as simply 3 apps is profile zombie user 32 with with lowerthat 4 slightly Ad- profile are both user Defender with with Juice savings and the Killer that Task notice as vanced we activities fact, their In resume they before. processes Then, background often. killed fairly restart the Defender Juice settings) primarily and default is Killer This (using Task Advanced profiles. user with all because, see for We solutions other profile. the user particular the in that apps zombie of ber tligohrtidparty third other stalling A privileges such constraints). enables provide a that space for not Android to of do due version (we app the here modified privileges discussion the up root detailed require backing with a will provided as activities be such such to require activities data; would app’s perform this zombie to However, app apps. the conceiv- zombie could restore one and example, For the avoid. modify ably to vulnerabilities seek unforeseen we privileges to lead that the may escalates which apps also such of but ecosphere, Android of the features the benefits: with any pDroid apps certain yield empower not ceivably does with tions applications Empowering granted. are DISCUSSION permissions imposes new no it app; an because to is granted sions This privileges. an app’s other any Contacts
Energy1000 (mJ) 2000 additional 0 a iigDelay Timing (a) ZapDroid Launcher iue1:Priso evc overhead. Service Permission 10: Figure WiFi LTE 10 oee,ti o nysilrqie hne to changes requires still only not this However, . 8.7 b Energy (b) GPS Operation Category L Category SD setal rvnsteezmi psfrom apps zombie these prevents essentially File (MB) sizes 20 evrf that verify We 8.7 oersrcie osrito h permis- the on constraint restrictive, more , Wifi ae oeta Xeeg oprdto compared energy 2X than more saves utteeoedslo h sr rmin- from users the disallow therefore must 30 Launcher 8.7 Notifications ZapDroid Android 40 8.7 iue1:Comparing Droid 13: Figure Launcher ZapDroid
p oalwi oquarantine to it allow to app Savings (Battery Percentage) 100 150 20 40 Energy Consumed (mJ) 0 50 b nryOverhead Energy (b) Contacts 6 Juice Juice Defender Advanced Task Killer zapDroid ihohrsolutions. other with 9 psfo h mar- the from apps Operation nn aeelevated case no in User Devices GPS ZapDroid 14 n a con- can One Wifi 32 Notifications ZapDroid Android 54 func- Zap- Za- ket (e.g., [21]) since they would now be able to access are not given access to a permission, [36] and [42] propose and possibly leak users’ private data. sending fake information to apps. Blackphone which Coping with delays experienced due to quaran- runs on PrivatOS [10] forks a version of the Android OS tine of interactive apps: Users may install interactive and modifies it to revoke permissions towards keeping or social apps like Yahoo! Mail or Skype but seldom use information private. In all of these efforts, the possible them. However, such apps consume heavy resources for negative consequences from the proposed changes (e.g., the purposes of periodically checking for updates. While the app crashing, or error pop ups [33]) has not been allowing them to run unperturbed continuously could studied in detail. Unlike in these efforts, once a zombie hurt the smartphone resources (e.g., battery), quarantin- app is chosen for quarantine, we freeze it by revoking ing them completely is clearly not the best idea either. all permissions from the zombie app and by preventing To address this, ZapDroid can be modified to reactivate other apps from communicating with it. such quarantined (possibly Category L) zombie apps pe- Killing processes: Applications like Advanced Task riodically in order to enable them to check for updates. Killer [2], BatteryDoctor[9], and Juice Defender[16] are Thus restored, the app can retrieve updates, notify the meant to allow users to kill background processes associ- user and remain active for a preset short period. It is ated with either services or apps to save battery. Apart then quarantined again. The frequency of such tempo- from the high resources consumed by these apps them- rary restorations can be specified by the user; the lower selves (they are always running and monitoring for op- this frequency, the higher the resource savings, but also portunities when tasks should be killed), killing back- the higher the latency in getting notifications. ground apps using these can have other detrimental ef- fects [31]. The killed background processes restart due to Server side examinations of permissions are in- either wakeup triggers or timeouts (some start right back sufficient: We are concerned with the permission usage up [7]) and resume consuming resources and/or access- when the app executes in the background without user ing the user’s private information. Since this process of intervention. A server side examination will simply in- killing and restarting could happen often with these ap- dicate the static permissions requested by an app rather plications, even more resources may be consumed; the than the dynamic usage of such permissions. Further, restarted processes will each time rebuild their state the determination of the frequency of usage of these per- prior to being killed [32]. These functions are infrequent missions when the app is not actively used, requires ex- and thus, lightweight with ZapDroid. tensive testing at the server side. Resource management: There are prior efforts that RELATED WORK try to reduce resource consumption on smartphones [38, There are no papers that share our vision of identifying 44, 39]. However, these efforts are orthogonal to our zombie apps, quarantining them, and restoring them if work. We point out that Android kills background apps the user desires. However, there are efforts related to under low memory conditions, to reclaim memory; how- some of the modules that we build within ZapDroid. ever, these apps can restart when the situation improves, by setting the START STICKY bit [6]. ZapDroid’s goal Profiling applications: Most prior work on profil- is not just to kill apps when the memory runs low, but ing Android applications has been either geared towards to curb activities of unused apps throughout. helping developers build better apps [46, 47], or detecting malicious apps [35]. There are approaches for monitoring CONCLUSIONS app-specific battery consumption [48, 40]; however, they Third party apps, installed but infrequently used by consume high energy themselves. PowerTutor [49] and users, execute in the background consuming smartphone the Android Fuel Gauge [8] use models to estimate the resources and/or accessing private information. We con- energy consumed by apps. ZapDroid leverages the infor- duct an IRB-approved user study that shows the nega- mation with regards to CPU and network provided by tive impact of such apps (called zombie apps). As our the Android OS. For monitoring battery consumption, main contribution, we design and implement ZapDroid, we implement our own tool which functions at a coarse which detects zombie apps, and based on user input, granularity (unlike PowerTutor). It also accounts for en- quarantines them to curb these behaviors. If needed, ergy due to UDP traffic transfers (unlike Fuel Gauge). ZapDroid can later restore a quarantined app quickly Efforts like [45, 37] conduct studies to characterize app and efficiently. We prototype ZapDroid and show that usage habits. However, they do not focus on infrequently it is lightweight, and can more efficiently thwart zombie used apps nor address their effective management. app activity as compared to state of the art solutions that target killing undesired background processes. Managing permissions of applications: Permission Denied [23] and XPrivacy [34] allow a superuser to Acknowledgements: This work was supported by change the permissions granted to apps, but the phone Army Research Office grant 62954CSREP and NSF must be rebooted. In addition, improper user-initiated NeTS grant 1320148. We thank our shepherd Dr. revocations can end up crashing the app or the device Markus Loechtefeld for his constructive comments which (due to revocation of permissions to a system app) [33]. helped us significantly improve the paper. TISSA [50] allows users to dynamically change permis- sions of apps. To prevent apps from crashing when they REFERENCES 19. Network classifier cgroup. 1. 108 apps per iPhone. https://android.googlesource.com/kernel/common/+/andro http://fortune.com/2011/01/28/108-apps-per-iphone/. id-3.10/Documentation/cgroups/net cls.txtt. 2. Advanced Task Killer. 20. Nielsen: US smartphones have an average of 41 https://play.google.com/store/apps/details?id= apps installed, up from 32 last year. com.rechild.advancedtaskkiller. http://thenextweb.com/insider/2012/05/16/nielsen-us-s martphones-have-an-average-of-41-apps-installed-up-f 3. Android: Accessibility Service. rom-32-last-year/. https://developer.android.com/reference/android/acces sibilityservice/AccessibilityService.html. 21. Nova Launcher Prime. https://play.google.com/store/apps/details?id= 4. Android Interface Definition Language (AIDL). com.teslacoilsw.launcher.prime. http: //developer.android.com/guide/components/aidl.html. 22. Number of available Android applications. http://www.appbrain.com/stats/number-of-android-apps. 5. Android Messenger. http://developer.android.com/gui 23. Permission Denied. de/components/bound-services.html#Messenger. https://play.google.com/store/apps/details?id= 6. Android Service Lifecycle. http: com.stericson.permissions.donate. //developer.android.com/guide/components/services.html. 24. Samsung Galaxy S4. 7. Android Task Killers Explained: What They Do http://www.samsung.com/global/microsite/galaxys4/. and Why You Shouldn’t Use Them. 25. SharedPreferences. http://developer.android.com/refer http://lifehacker.com/5650894/android-task-killers-e ence/android/content/SharedPreferences.html. xplained-what-they-do-and-why-you-shouldnt-use-them. 26. Smartphone users waste ‘£6m a year on one hit 8. Android’s FuelGuage. wonder apps’. . . https://android googlesource com/platform/packages/app http://metro.co.uk/2013/05/30/smartphone-users-waste . . s/Settings/+/android-4 3 1 r1/src/com/android/settings -6m-a-year-on-one-hit-wonder-apps-3814805/. /fuelgauge/PowerUsageSummary.java. 27. strace Linux- man page. 9. Battery Doctor. http://linux.die.net/man/1/strace. https://play.google.com/store/apps/details?id= com.ijinshan.kbatterydoctor en. 28. What actually happens when you swipe an app out of the recent apps list? http://android.stackexchange 10. blackphone. https://www.blackphone.ch. .com/questions/19987/what-actually-happens-when-you-s 11. Block Outgoing Network Access For a Single User wipe-an-app-out-of-the-recent-apps-list. Using Iptables. http://www.cyberciti.biz/tips/block-o 29. What do the permissions that applications require utgoing-network-access-for-a-single-user-from-my-ser mean? ver-using-iptables.html. http://android.stackexchange.com/questions/38388/what 12. By the Numbers: 21 Amazing Skype Statistics and -do-the-permissions-that-applications-require-mean. Facts. http: 30. Why do users uninstall apps? http://www.fiercedevel //expandedramblings.com/index.php/skype-statistics/. oper.com/special-reports/why-do-users-uninstall-apps. 13. Digital Diary: Are We Suffering From Mobile App 31. Why RAM Boosters And Task Killers Are Bad For Burnout? Your Android. http://www.makeuseof.com/tag/ram-boost http://bits.blogs.nytimes.com/2013/02/15/digital-diary ers-task-killers-bad-android/. -are-we-suffering-from-mobile-app-burnout/? r=0. 32. Why You Shouldn’t Be Using a Task Killer with 14. Google Cloud Messaging for Android. Android. http: http://developer.android.com/google/gcm/index.html. //forum.xda-developers.com/showthread.php?t=678205. 15. Google Play: number of downloads 2010-2013. 33. XDA Community Support for XPrivacy. http://www.statista.com/statistics/281106/number-of-a http://forum.xda-developers.com/xposed/modules/xpriva ndroid-app-downloads-from-google-play/. cy-ultimate-android-privacy-app-t2320783/page39. 16. Juice Defender. 34. XPrivacy. http://www.xprivacy.eu. https://play.google.com/store/apps/details?id= 35. Batyuk, L., Herpich, M., Camtepe, S. A., Raddatz, com.latedroid.juicedefender. K., Schmidt, A.-D., and Albayrak, S. Using static analysis for automatic assessment and mitigation of 17. Launch Checklist for Android. http://developer.and unwanted and malicious activities within android roid.com/distribute/tools/launch-checklist.html. applications. In Proceedings of the 2011 6th 18. Monsoon Power Meter. International Conference on Malicious and https://www.msoon.com/LabEquipment/PowerMonitor/. Unwanted Software, MALWARE ’11 (2011). 36. Beresford, A. R., Rice, A., Skehin, N., and Sohan, 44. Kemp, R., Palmer, N., Kielmann, T., and Bal, H. R. Mockdroid: Trading privacy for application Energy efficient information monitoring functionality on smartphones. In Proceedings of the applications on smartphones through 12th Workshop on Mobile Computing Systems and communication offloading. In Mobile Computing, Applications, HotMobile ’11 (2011). Applications, and Services, Lecture Notes of the Institute for Computer Sciences, Social Informatics 37. B¨ohmer,M., Hecht, B., Sch¨oning,J., Kr¨uger,A., and Telecommunications Engineering. Springer and Bauer, G. Falling asleep with angry birds, Berlin Heidelberg, 2012. facebook and kindle: A large scale study on mobile application usage. In International Conference on 45. Parate, A., B¨ohmer,M., Chu, D., Ganesan, D., and Human Computer Interaction with Mobile Devices Marlin, B. M. Practical prediction and prefetch for and Services, MobileHCI ’11 (2011). faster access to applications on mobile phones. In 38. Calder, M., and Marina, M. Batch scheduling of ACM International Joint Conference on Pervasive recurrent applications for energy savings on mobile and Ubiquitous Computing, UbiComp ’13 (2013). phones. In Sensor Mesh and Ad Hoc 46. Ravindranath, L., Padhye, J., Agarwal, S., Communications and Networks (SECON) (2010). Mahajan, R., Obermiller, I., and Shayandeh, S. Appinsight: Mobile app performance monitoring in 39. Cuervo, E., Balasubramanian, A., Cho, D.-k., the wild. In Proceedings of the 10th USENIX Wolman, A., Saroiu, S., Chandra, R., and Bahl, P. Conference on Operating Systems Design and Maui: Making smartphones last longer with code Implementation, OSDI’12 (2012). offload. In Proceedings of the 8th International Conference on Mobile Systems, Applications, and 47. Wei, X., Gomez, L., Neamtiu, I., and Faloutsos, M. Services, MobiSys ’10 (2010). Profiledroid: Multi-layer profiling of android 40. Ding, F., Xia, F., Zhang, W., Zhao, X., and Ma, C. applications. In Proceedings of the 18th Annual Monitoring energy consumption of smartphones. In International Conference on Mobile Computing and Internet of Things (iThings/CPSCom), 2011 Networking, Mobicom ’12 (2012). International Conference on and 4th International Conference on Cyber, Physical and Social 48. Yoon, C., Kim, D., Jung, W., Kang, C., and Cha, Computing (2011). H. Appscope: Application energy metering framework for android smartphone using kernel 41. Felt, A. P., Chin, E., Hanna, S., Song, D., and activity monitoring. In Presented as part of the Wagner, D. Android permissions demystified. In 2012 USENIX Annual Technical Conference (2012). ACM Conference on Computer and Communications Security (2011). 49. Zhang, L., Tiwana, B., Qian, Z., Wang, Z., Dick, 42. Hornyack, P., Han, S., Jung, J., Schechter, S., and R. P., Mao, Z. M., and Yang, L. Accurate online Wetherall, D. These aren’t the droids you’re power estimation and automatic battery behavior looking for: Retrofitting android to protect data based power model generation for smartphones. In from imperious applications. In Proceedings of the Proceedings of the Eighth IEEE/ACM/IFIP 18th ACM Conference on Computer and International Conference on Hardware/Software Communications Security, CCS ’11 (2011). Codesign and System Synthesis, CODES/ISSS ’10 (2010). 43. Huang, J., Qian, F., Gerber, A., Mao, Z. M., Sen, S., and Spatscheck, O. A close examination of 50. Zhou, Y., Zhang, X., Jiang, X., and Freeh, V. performance and power characteristics of 4g lte Taming information-stealing smartphone networks. In Proceedings of the 10th International applications (on android). In Trust and Trustworthy Conference on Mobile Systems, Applications, and Computing, Lecture Notes in Computer Science. Services, MobiSys ’12 (2012). Springer Berlin Heidelberg, 2011.