Falling Asleep with Angry Birds, Facebook and Kindle – A Large Scale Study on Mobile Application Usage
Matthias Bohmer¨ Brent Hecht Johannes Schoning¨ DFKI GmbH Northwestern University DFKI GmbH Saarbrucken,¨ Germany Evanston, IL, USA Saarbrucken,¨ Germany [email protected] [email protected] [email protected] Antonio Kruger¨ Gernot Bauer DFKI GmbH Fachhochschule Munster¨ Saarbrucken,¨ Germany Munster,¨ Germany [email protected] [email protected]
ABSTRACT music, sightseeing, and navigating. In this way, the mobile While applications for mobile devices have become ex- phone has become increasingly analogous to a “Swiss Army tremely important in the last few years, little public infor- Knife” [15, 17] in that mobile phones provide a plethora of mation exists on mobile application usage behavior. We de- readily-accessible tools for everyday life. The number of scribe a large-scale deployment-based research study that available applications for mobile phones – so called “apps” logged detailed application usage information from over – is steadily increasing. Today, there are more than 370,000 4,100 users of Android-powered mobile devices. We present apps available for the Android platform and 425,000 for Ap- two types of results from analyzing this data: basic descrip- ple’s iPhone1. The iPhone platform has seen more than 10 tive statistics and contextual descriptive statistics. In the case billion app downloads2. of the former, we find that the average session with an appli- cation lasts less than a minute, even though users spend al- Despite these large numbers, there is little public research most an hour a day using their phones. Our contextual find- available on application usage behavior. Very basic ques- ings include those related to time of day and location. For tions remain unanswered. For instance, how long does each instance, we show that news applications are most popular interaction with an app last? Does this vary by application in the morning and games are at night, but communication category? If so, which categories inspire the longest interac- applications dominate through most of the day. We also find tions with their users? The data on context’s effect on appli- that despite the variety of apps available, communication ap- cation usage is equally sparse, leading to additional interest- plications are almost always the first used upon a device’s ing questions. How does the user’s context – e.g. location waking from sleep. In addition, we discuss the notion of a and time of day – affect her app choices? What type of app virtual application sensor, which we used to collect the data. is opened first? Does the opening of one application predict the opening of another? In this paper, we provide data from a Author Keywords large-scale study that begins to answer these basic app usage Mobile apps, usage sensor, measuring, large-scale study. questions, as well as those related to contextual usage. In addition to the descriptive results above, an additional ACM Classification Keywords contribution of this paper is our method of data collection. H.5.2 User Interfaces: Evaluation/methodology All of the data for this paper was gathered by AppSensor, our “virtual sensor”, that is part of a large-scale deployment General Terms of an implicit feedback-based mobile app recommender sys- Human Factors, Measurement tem called appazaar [4]. appazaar is designed to tackle the problem presented by the fact that, as mentioned above, an INTRODUCTION enormous number of apps are available. Based on the user’s Mobile phones have evolved from single-purpose commu- current and past locations and app usage, the system rec- nication devices into dynamic tools that support their users ommends apps that might be of interest to the user. Within in a wide variety of tasks, e.g. playing games, listening to the appazaar app we deployed AppSensor, that does the job vital to this research of measuring which apps are used in which contexts.
Permission to make digital or hard copies of all or part of this work for In the next section, we describe work related to this paper. personal or classroom use is granted without fee provided that copies are Section three provides an overview of AppSensor and other not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or 1 republish, to post on servers or to redistribute to lists, requires prior specific Wikipedia: List of digital distribution platforms for mobile de- permission and/or a fee. vices, http://tiny.cc/j0irz 2 MobileHCI 2011, Aug 30–Sept 2, 2011, Stockholm, Sweden. http://www.apple.com/itunes/10-billion-app-countdown/ Copyright 2011 ACM 978-1-4503-0541-9/11/08-09....$10.00. aspects of our data collection process. In section four, we studies with the fine-grained measuring of app usage. In this present our basic and context-related findings. Discussion way, we are able to (1) study large numbers of users and (2) of implications for design, as well as the limitations of our large numbers of applications, all over a long time period. study, is the topic of section five. Finally, we conclude by Previous work has had to make sacrifices in at least one of highlighting major findings and describing future work. these dimensions, as Table1 shows. Furthermore, the mo- bile phones used in related studies have been mostly from the last generation, i.e. they could not be customized by the RELATED WORK end-users in terms of installing new applications. Work related to this paper includes that on mobile user needs and mobile device usage and deployments in the wild. For APPSENSOR AND DATA COLLECTION instance, Church and Smyth [6] analyzed mobile user needs In this section, we describe our data collection tool, AppSen- and concluded that context – in form of location and time sor. Because context is a known important predictor of the – is important for mobile web search. Cui and Roto [7] in- utility of an application [3], AppSensor has been designed vestigated how people use the mobile web. They found that from the ground up to provide context attached to each sam- the timeframe of web sessions is rather short in general but ple of application usage. browser use is longer if users are connected to a WLAN. Verkasalo [18] showed that people use certain types of mo- Lifecycle of a Mobile App bile services in certain contexts. For example, they mostly In order to understand the AppSensor’s design, it is impor- use browsers and multimedia services when they are on the tant to first give the AppSensor’s definition of the lifecycle move but play more games while they are at home. of a mobile application (Figure1). The AppSensor under- stands five events in this lifecycle: installing, updating, unin- Froehlich et al. [10] presented a system that collects real us- stalling, opening, and closing the app. age data on mobile phones by keeping track of more than 140 types of events. They provide a method for mobile ex- perience sampling and describe a system for gathering in- situ data on a user’s device. The goal of Demieux and Los- !"#$%&'(")& guin [8] was to collect objective data on the usage and inter- actions with mobile phones to incorporate the findings into ,-*("& the design process. Their framework is capable of tracking *."$& the high-level functionality of phones, e.g. calling, playing games, and downloading external programs. However, both $*+&!"#$%&'(")& of these studies were very limited in number of users (maxi- #$(+/--& '$#$(+/--& mum of 16), length of study (maximum 28 days), and num- ber of apps. '.)/+"& Similar to this work, McMillan et al. [16] and Henze et al. [12] make use of app stores for conducting deployment- Figure 1. The lifecycle of a mobile app on a user’s device according to based research. McMillan et al. [16] describe how they different states and events. gather feedback and quantitative data to design and improve a game called Yoshi. Their idea is to inform the design of the The first event that we can observe is an app’s installation. application itself based on a large amount of feedback from It reveals that the user has downloaded an app, e.g. from an end-users. Henze et al. [12] designed a map-based applica- app market. Another event that is observable is the update tion to analyze the visualization of off-screen objects. Their of an app, which might be interpreted as a sign of endur- study is also designed as a game with tasks to be solved by ing interest in the application. However, since updates are the players. The players’ performances within different tasks sometimes done automatically by the system and the update are used to evaluate different approaches for map visualiza- frequency strongly depends on the release strategy of the de- tions. However, app-store-based research is so far limited to veloper, the insight into usage behavior that can be gained single applications and has a strong focus on research ques- from update events is relatively low. The last event we can tions that are specific to the deployed apps itself. In this capture is the uninstall event, which expresses the opposite work, we focus on gaining insights into general app usage of the installation event: a user does not want the app any- by releasing an explorative app to the Android app store. more.
Another similar approach to this work is followed by the However, these maintenance events only occur a few times AppAware project [11]. The system shows end-users “which per app. For some apps, there might even be only a single apps are hot” by aggregating world-wide occurrences of app installation event (e.g. when the user has found a good app) installation events. However, since AppAware only gathers or even none at all (e.g. for preinstalled apps like the phone the installation, update, and deinstallation of an application, app). Maintenance events are also of limited utility for un- the system is not aware of the actual usage of a specific app. derstanding the relationship between context and app usage. For instance, a user might install an app somewhere but use In summary, this research is unique (to our knowledge) in it elsewhere (e.g. an app for sightseeing that is installed at that it combines the approach of large-scale, in-the-wild user home before traveling). Users Apps Days Comment Verkasalo [18] 324 ∼14 67 Investigation of contextual pattern of mobile device usage. Froehlich et al. [10] 4-16 - 7-28 System for collecting in-situ data (pre-installed). Demieux and Losguin [8] 11 - 2 A study with a strong focus on device usage (distributed via SMS). Girardello & Michahellis [11] 19,000 - - Measuring popularity instead of usage (released to Android Market). McMillan et al. [16] 8,674 1 154 Exploring world-wide field trials (released to iPhone App Store). Henze et al. [12] 3,934 1 72 Evaluation of off-screen visualization (released to Android Market). AppSensor (this paper) 4,125 22,626 127 Large scale study on app usage (released to Android Market).
Table 1. Overview of related app-based studies conducted in-situ on participants’ devices. The table shows fine grained usage analysis (rows 1-3) and large-scale studies (rows 4-6).
Instead, AppSensor is designed to continuously sample a on whether the application a user is running is the same as user’s application usage. In other words, we are especially before (if as(t1) = as(t2)) or whether it has changed (if interested in the two app states of being used and not be- as(t1) 6= as(t2)). ing used, which can both be inferred from the open and close events. These events naturally appear much more often Implementation and Deployment and in a much shorter period of time than the maintenance AppSensor is implemented as a background service within events. They enable us to observe app usage on a more fine- Android and is installed by end users as part of the appazaar grained level and provide a much more accurate understand- application. This app traces context information that is avail- ing of context’s effects on app usage. able directly on the user’s device (e.g. location, local time, previous app interaction) and app usage at the same time. In order to gather data on the being used and not being used The recommender algorithms of appazaar rely on this data states, AppSensor takes advantage of the fact that the An- and appazaar’s app was the means for enabling the data col- droid operating system can report the most recently started lection reported in this paper. The applied sampling rate is application. Because of this feature, we know the app with 2 Hz. AppSensor collects data every 500ms in a loop that which the user is currently interacting. We are thus able to starts automatically as soon as the device’s screen is turned infer which single app is in the state of being used owing to on and stops when the screen is turned off again. When the fact that the Android operating system only shows one the device goes into standby-mode3, we consider which app app to the user (as does the iPhone OS). Therefore, we can was left open and omit the standby time from the applica- presume that all other applications are consequently in the tion’s usage time. The measured data is written to a local state of not being used in terms of not showing their graph- database on the user’s device and only periodically uploaded ical interface. In this study, we do not consider background to a server. In case of connectivity failure, the data is kept in applications that are not interacted with through a graphical the database and attached to the next transmission. user interface, e.g. background music apps that can be con- trolled through gestures. The first version of appazaar was released to the Android Market in May 2010. In August 2010, we released a version Formal Description of AppSensor with the AppSensor as presented in this paper. Of course, the As noted above, the AppSensor is meant to be a sensor that data collected by AppSensor is primarily designed to provide indicates the currently used application at a given time t. “the best app recommendation” within the appazaar appli- Formally speaking, the sensor can be described as follows: cation, i.e. to inform the recommendation process of apps to Let A = {a1, . . . , an} be the set of apps that are available a user in a given context [5]. For security and privacy rea- ∗ for a mobile device and let A = A ∪ {} be the set of appli- sons, the system uses hash functions to anonymize all per- cations with which a user can interact. means that the user sonal identifiers before the data is collected, and we do not is currently not using any application. For most current plat- query any additional personal information like the name, age forms, e.g. Google’s Android, this set is usually defined by or sex from the user. the applications available on the corresponding application stores. Since the number of applications is growing, this set Application Categorization is not static, but has a defined number n of elements. With In order to get a more high level understanding of our data, time given as t, the AppSensor shall provide the following we felt it was necessary to add categories to the applications values: opened by our users. To do so, we mined the Android Mar- a if app a is used, as(t) = i i ket for each app’s category (see Table2). As such, the cat- if no app is used. egories are largely given by the apps’ developers: they – as domain experts – assign their apps to the categories when as(t) With respect to the lifecycle of mobile apps the value uploading them to the Android market. The only exception describes the application with which a user is currently in- to this rule occurred in some minor manual modifications. teracting. The value is distributed on the nominal scale For instance, we merged all games of the categories Arcade A∗ given by the set of available applications. Therefore, & Action, Brain & Puzzle, Cards & Casino, and Comics into the only conclusion that can be drawn on the mere sensor 3 data of two measures at times t1 and t2 is a comparison Determined by screen-off and screen-on events. one Games category. Due to the special nature of browsers variables such as time and location. In both sections, our – they do not have clear cut domain scope – we have sepa- primary resolution of analysis is the “application category” rated them into their own dedicated Browsers category. For as defined above, but in the second section we do highlight some apps, no categories are available on the Android Mar- some interesting application-level temporal patterns. ket. These are either test applications by developers that ap- pear only on a few devices, applications that are distributed via other channels (e.g. pre-installed by device manufactur- Basic Descriptive Statistics ers), default Android apps (e.g. settings), or apps that have On average, our users spent 59.23 minutes per day on their been taken out of the market and whose category was not devices. However, the average application session – from available anymore4. We manually added categories for some opening an app to closing it – lasted only 71.56 seconds. apps where possible. For the branded Twitter clients of some vendors (e.g. HTC), we added the category of the original Table2 shows the average usage time of apps by category, Twitter app (Social). To the default apps responsible for han- which ranged from 36.47 seconds for apps of unknown cat- dling phone calls we added the Communication category. As egory and 31.91 seconds for apps of category Finance to we did with the browser, we also put the settings app into its 274.23 seconds for category Libraries & Demos. The most- own category (Settings) due to its special nature. Since the used Libraries & Demos apps as measured by total usage main menu on Android phones itself is also an app and it time are inherent apps of the operating system (Google Ser- is treated as such from the system’s perspective, we addi- vices Framework, default Updater, Motorola Updater). It tionally removed such launcher apps from the results since was interesting to see that this category has a much longer average session than the games category, whose most used they give little insight into app usage behavior. Finally, it is 5 important to note that each app can only have one category. applications are Angry Birds, Wordfeud FREE , and Soli- taire. On the low end of the session length spectrum of apps with known categories, we found the Finance category. Characteristics of Final Dataset The most used apps of this category are for personal money The results reported in this paper are based on data from management (Mint.com Personal Finance), stock market the 4,125 users, who used appazaar between August 16th, th (Google Finance app), and mobile banking (Bank of Amer- 2010 and January 25 , 2011. The users were spread out geo- ica). The briefness of the average session in this category graphically, although most stayed in the United States or Eu- does not speak well for the success rate of financial applica- rope during our study (see Figure2). Within the timeframe tions on the Android platform. of 163 days, they generated usage events for 22,626 differ- ent applications and the deployment of our AppSensor was !"#$%&'( )**+ ),%-./+"%$ 01"2*3"'(.)**+ able to measure 4.92 million values for application usage. !"#"$%" &'()* *+,*-./01 2 We advertised appazaar on Facebook and Twitter and two 84"9,1$:.;05"#.$?.@:0<415'. 34"5"10 *6- *-,67./01 posts about the system appeared on two well-known technol- A$$B=0.34"5"10'.4C9$1#85"5B0< ogy blogs (Gizmodo and ReadWriteWeb), helping us reach a D<5E0= -() &&,-)./01 A$$B=0.85F/'.G0=F'.H5I0 J$::!"41594$" ((7 &+,K)./01 A$$B=0.854='.L5"M10"9.C8C'.N2K.854= growing number of users. ;<$M!194E49O 7'6+) +7,&K./01 J5=0"M5<'.PE0<"$90'.AD5/#/ CQ$FF4"B *)+ +7,-7./01 85<#09'.>5<1$M0.C15""0<'.J<54B/=4/9 C$145= R*( +),+K./01 3510S$$#.?$<.@"M<$4M'.D%4990<'.D%009T01# G5Q$$U.35"95/O.3$$9S5==.V76'.PC;W.C1$<0J0"90<'. CF$<9/ *(R +R,K(./01 W3X.8$S4=0 W0%/ -(& +(,77./01 W0%/Y$S'.<0MM49.4/.?!"'.>>J.W0%/ C0994"B/ 7 +(,-7./01 T0?5!=9.C0994"B/.@FF T0?5!=9.><$%/0<'.C#O?4<0.><$%/0<'.T$=FQ4". ><$%/0< 76 -&,67./01 ><$%/0< P"90<954":0"9 (& -+,K6./01 Z8TS.8$E40/.[.D\'.D\.A!4M0.8$S4=0'.;Q$9$3!"45 8!=94:0M45 7*6 (),-K./01 ;5"M$<5.Y5M4$'.8!/41'.J5:0<5 J$:41/ *')&) K7,**./01 T54=OC9<4F'.]#1M\40%0<'.T4=S0<9.8$S4=0 A5:0/ )'()) 77&,)R./01 @"B
)" Contextual Results: Chains of App Usage (" An important contextual variable in usage behavior are the zero or more applications used before an application is '" opened and the zero or more applications used afterwards. &" We defined an “application chain” as a sequence of apps that are used without the device being in standby mode for longer %"
5+2'6+217#)8' than 30 seconds. In total, we can distinguish 1,841,226 $" such sessions in our data set. Examples include one in #" which a user started with Grocery iQ (Shopping), switched to GrubHub Food Delivery (Lifestyle), and ended with Epi- !"#$%&#'()%&#'*+,#'-.'!//'/#$'0%1234 !" curious Recipe App (Lifestyle). Another user started with the #*+" $*+" %*+" &*+" '*+" (*+" )*+" ,*+" -*+" #.+" $.+" %.+" &.+" '.+" (.+" ).+" ,.+" -.+"
#$*+" #!*+" ##*+" AroundMe (Lifestyle) Find A #$.+" #!.+" ##.+" app and then continued with Starbucks (Shopping), Google Maps (Travel), Find A Star- bucks, Google Maps, Find A Starbucks, Dolphin Browser Figure 4. Daily average usage duration of opened apps per launch in minutes. HD (Browser), Find A Starbucks, Google Maps, Find A Star- bucks, and Google Maps.
Contextual Results: Application Usage over Time Figure6 demonstrates the distribution of application chains AppSensor allows us to record temporal information about by the number of applications that occur in the chain. As the application usage. Figure3 shows the total number of ap- y-axis of Figure6 is on a log-scale, it can be seen that the plication launches in our sample according to hour of the majority of sessions (68.2%) only contain a single applica- day. It can be seen that total application usage (in terms of tion. In other words, people turn on their phone, use a single launches) is at its maximum in the afternoon and evening, app, and put their phone back in standby. This tendency to- peaking around 6pm. Our participants generally start using wards the use of a small number of applications during an applications in the morning between 6am and 7am, and their interaction with the mobile device is further evidenced by activity grows approximately linearly until 1pm. Activity in- the fact that only 19.5% of application chains contain two creases slowly to a peak around at 6pm. Application usage apps, and only 6.6% contain three. minimum is around 5am, although it never falls below 16% of its maximum. We also looked into the number of unique apps used within a session, as can be seen in Figure7. The first bar in this Figure4 shows the average time people spent with an ap- figure is of course identical to the first bar in the preceding plication once they opened it with regard to the hour of the figure. We found a maximum of 14 unique apps in an app day. There is a peak around 5am with 6.26 minutes of av- chain. A vast majority of users use a very small number of erage app usage time. The average application session is unique apps during an interaction with their device. Thus – less than a minute, however, reaching a minimum of around according to our analysis of sessions – people who use more 40 seconds at 5pm. Interestingly, the graph in Figure4 is than 14 apps in sequence tend to re-use apps they already nearly opposite that in Figure3. This means, that when peo- have used before within the same session. ple actively start to use their devices, they spend less time with each application. This might be due to apps that peo- Examining the amount of time our users spent in each appli- ple explicitly leave active while sleeping with standby-mode cation chain, we found that 49.8% of all recorded sessions prevented, but there are other possible explanations. are shorter than 5 seconds. The longest session we observed has a length of 59 minutes and 48 minutes. Between these Figure5 shows the change in the relative usage of the appli- two end points, the curve has a similar exponential decay to cation categories over the course of the day in terms of num- that in Figure6 and7. ti eylkl htteapue eti communication a is next used app the app, that each likely For very used. been is have ses- apps it more those or the only two along considers where values graph sions the This to such, non-zero. As app are category. one diagonal same from the transitions in the indicates another Accordingly, figure the chain. appli- of application between diagonal an probabilities in transition categories the cation shows 9 Figure chains. application the of 5.9% only in was first browser used a Interestingly, application. mail standard called app an appli- 6.2% SMS SMS app, an sms with default (9.5% initiated cation were the sample of our 15.7% that within found chains we deeper, Digging shows). category 8 the Figure the (49.60%) to chains belongs all of application half first nearly appli- for of that is analysis chains our cation in statistic revealing most the Probably sessions increases. aggregated scarcity We and out 237. session. flattens is graph a length the Maximum in since used apps 40 apps than of longer Number 6. Figure users our by (white). done morning the launches in time, app trough application of and of (green) percentage percentage evening the maximum the to category’s in refers peak each their value indicating reach green cell games with Each example, row, For by launches. minimum. normalized of category’s are each terms Colors indicating in category. white category and each by for usage hour each app within relative Hourly 5. Figure 5DI=#=D:;/J/K:$0 C0$$67D8#3D07 203#4/5#6789:;/ E73:=3#D7$:73 P=0N683DQD3L M643D$:ND#
,96 ihtepoeapiain n .%wt the with 5.9% and application, phone the with 9.6% ), !"#$%&'()'*++"&&%,+%-' R:1:=:78: !#$###$###" <7U70@7 S90--D7T -:=/H06= !$###$###" 5D1:;3L4: ?=0@;:= S:33D7T; 29:$:; FD7#78: C0$D8; !##$###" G#$:; H:#439 S-0=3; 2=#Q:4 S08D#4 !#$###" O:@; 2004; !$###" !##" !#" !" !,A+. &&A+. &A). !A&. ,A". ,A'. 'A). %A+. !A%. ,A). %A(. "A(. "A!. ,A*. ,A&. ,A%. %A". ,A". ,A,. &A'. )A+. !" !,%B(,&/ !"#$ !"A". &!A!. .%,/01'()'2%-3(,'4!"#$%&'()'25%"%,67889':-%;'<==->' 'A%. !A(. ,A!. ,A%. 'A,. &A'. !A(. ,A). 'A,. "A'. "A!. ,A+. ,A'. ,A&. %A,. ,A%. ,A,. 'A". )A). ))B,'%/ !#$ %" !&A(. %*A%. "A&. !A,. ,A(. ,A&. %A,. ,A%. ,A,. 'A&. )A*. 'A!. "A!. ,A". ,A%. &A+. %A). !A'. ,A). 'A,. "A(. '%B(%%/ "#$ !)A(. %'A&.
!!" 'A,. "A". ,A%. ,A". &A%. %A&. !A%. ,A). 'A*. "A'. "A&. !A&. ,A). ,A&. "A). ,A". ,A,. 'A*. )A(. &,B%%"/ %#$ %!A(. ",A%. 'A%. "A&. ,A&. ,A%. &A". %A". !A(. ,A). (A%. "A'. "A). !A%. ,A+. ,A(. "A'. ,A!. ,A,. 'A*. )A%. !%" %%B&%*/ &#$ "!A'. %!A*. &A&. "A(. ,A&. ,A%. &A,. %A". !A". ,A). (A'. "A). "A&. !A'. ,A*. ,A(. "A%. ,A!. ,A,. 'A(. )A&. %,B+&+/ '#$ &!" "!A&. %"A). 'A,. "A". ,A&. ,A". &A&. %A!. !A". ,A(. (A,. %A%. !A*. !A&. ,A). ,A). "A". ,A!. ,A,. 'A'. )A,. %*B!(!/ (#$ Communication !*A(. %&A).
&%" 'A+. !A+. ,A". ,A%. 'A!. %A,. !A!. ,A(. 'A&. %A). !A*. !A&. ,A(. ,A(. !A). ,A". ,A,. 'A". )A+. '(B*+'/ )#$ !&A). %+A&. &A(. "A,. ,A". ,A%. 'A%. %A!. !A%. ,A). &A*. &A!. !A+. !A!. ,A'. ,A&. !A+. ,A%. ,A,. 'A&. *A!. '!" *%B&**/ *#$ !,A&. &&A*. &A&. "A!. ,A". ,A%. 'A&. %A%. !A&. ,A'. 'A!. %A(. !A). ,A+. ,A&. ,A%. !A+. ,A%. ,A,. 'A!. *A,. Handcent !,+B'',/ +#$ '%" &+A,. &A!. "A,. *A&. ,A!. ,A%. 'A". %A". !A&. ,A'. &A+. %A,. !A*. ,A(. ,A%. ,A%. "A,. ,A&. ,A,. &A). )A). !")B,(+/ !,#$ (as '"A(.
(")#" %A*. !A*. (A*. ,A!. ,A&. 'A,. %A". !A&. ,A'. &A%. "A(. "A,. ,A(. ,A%. ,A". "A!. ,A'. ,A,. &A%. )A%. !&"B(&"/ !!#$ '&A*. %A'. !A+. (A!. ,A!. ,A&. &A). %A". !A". ,A&. &A". "A'. "A,. ,A'. ,A". ,A". "A". ,A%. ,A,. &A%. )A,. !'*B*)(/ !"-$ ''A". iue7 curne fssin codn onme fuiu apps unique of session. number a to within according used sessions of Occurrences 7. Figure %A*. !A+. 'A+. ,A". ,A(. &A*. "A*. !A%. ,A&. &A,. "A). "A,. ,A'. ,A". ,A". "A". ,A%. ,A,. &A". (A+. !"#$"%&'(") !(*B,*"/ !-$ $!" $#" %!" %#" &!" &#" '!" '#" #!" ''A". !" #" !"#$%&'()'*++"&&%,+%-' %A). !A+. 'A+. ,A!. ,A). &A+. "A+. !A". ,A&. &A,. "A'. "A". ,A'. ,A". ,A". "A". ,A&. ,A,. &A". (A*. !#$###$###"
!$###$###" !(+B,!*/ "-$ iue8 aeoiso rtue p ihnasession. a within app used first of Categories 8. Figure !##$###" '(A!. !#$###"
()**+,-./0)," %A). !A*. 'A+. ,A!. ,A*. &A'. "A+. !A". ,A&. %A). "A&. "A!. ,A'. ,A". ,A". "A%. ,A%. ,A,. &A%. (A&. !$###" !)"B+%'/ 1))23" !##" %-$ !#" ''A). !" 45)6375" &A,. "A,. (A,. ,A!. ,A+. &A'. "A). !A%. ,A%. %A&. "A". "A". ,A(. ,A". ,A". "A%. ,A%. ,A,. &A&. (A(. !)%B+(%/ &-$
8).-/2" '(A*.
!" %A(. !A+. (A!. ,A". ,A*. &A(. "A). !A!. ,A&. %A&. "A!. "A&. ,A'. ,A". ,A". "A". ,A". ,A,. &A,. (A(. ()*-.3" !)+B*,!/ '-$
%" ')A!.
95):+.0;-<=" %A). "A". 'A*. ,A!. ,A(. &A(. "A). !A!. ,A&. %A,. "A%. "A%. ,A%. ,A". ,A". "A". ,A". ,A,. &A&. (A&. !*&B,!"/ (-$ +,>,)6," &" '(A!. !"#$%&'()'.,/0"%'122-'/,'3%--/(,' %A). "A". (A,. ,A!. ,A(. &A+. "A). !A". ,A&. %A!. "A". "A%. ,A&. ,A". ,A%. "A&. ,A". ,A,. &A". (A(. 8?)@@-,A" '" !)(B,',/ )-$
B/*73" '&A*. (" %A). !A+. (A%. ,A". ,A). 'A". "A*. !A". ,A'. %A!. "A%. "A". ,A&. ,A%. ,A". "A). ,A". ,A,. &A!. )A,. C763" !(%B,*,/ *-$
)" '%A%. D+20*7:-/" %A+. !A). (A*. ,A!. ,A*. 'A&. %A!. !A%. ,A'. %A,. "A". "A!. ,A'. ,A%. ,A%. %A,. ,A". ,A,. &A!. )A&. !'%B*%'/ +-$ 15/;72" *" '"A,. &A!. !A(. )A&. ,A!. ,A). 'A*. %A(. !A%. ,A'. "A+. "A%. !A+. ,A'. ,A%. ,A". %A,. ,A". ,A,. &A!. )A'. 87E,A3" +" !&!B%,%/ !,-$
8@)5<3" &+A,. ," &A'. !A&. +A!. ,A!. ,A). 'A). %A'. !A&. ,A(. %A". "A%. "A,. ,A'. ,A%. ,A%. %A". ,A". ,A,. &A&. )A&. F-G73<=27" !"%B(%+/ !!-$ ./01/203#4/ H7G757,.7" !#" 5#6789:; &+A',. F-I5/5-73"J"K7*)" !!" %A**. !A*(. )A*+. ,A!&. ,A'(. &A)). "A+(. !A"%. ,A&). %A)(. "A&(. "A,%. ,A(,. ,A%,. ,A"(. "A%,. ,A"'. ,A,". &A%!. (A*%. L7/2--; !'" !B)+( !B(** !B)," !B*!, N,<75
Specific Application Usage Our results show that mobile phones are still first and fore- most communication devices. This is not only due to phone Although we focused our analysis at the application category calls, as smart phones provide a variety of new ways to level, we did analyze several important and/or well-known communicate (e.g. instant messengers, email, voice over individual applications. Figure 10 shows the usage times IP). Nevertheless, this finding certainly qualifies the mobile of specific applications with regard to time. In contrast to Figure5, the numbers in Figure 10 are not normalized by 6See http://market.android.com/details?id=com.rovio.angrybirds The AppSensor the of Use Making apps. used bet- recently very should between systems navigation operating support phone func- ter single mobile a of such, is utilizations As there particular apps. that than the suggests between rather be- This cohesion chains tional switch apps. application new frequently in opening users apps only used that already suggest tween also results Our opened have they once night. app the an in Additionally, within it time apps. more the of spend func- kinds of they non-communication different hours the by late of provided use the tionality more during make indicates sleeping they diagonal said, not night The That are thinking. column. of people a line when in Knives” categories Army to “Swiss row as phones a (high). green in to categories (low) yellow from from are ranges transitions probability The The category. same chains. the in app apps in between probabilities transitions Transition 9. Figure hpigls p s ihsen p)w a distinguish a can we (e.g. app) apps sightseeing different a famous use vs. a they app in if list mall location), shopping pedestrian same same (i.e, the may city people loca- through two walking their though even con- be on the instance, of For depend adding uncertainty recognition. the by – text decrease that case can propose our one We context-reasoning in mobile for apps [ 14]. needs users’ tions i.e. the – instance, For services to [9], context. Dey according user’s to a services According adapting apps. involves used actually context-awareness his on based the text apply may One well as applications itself. novel devices inform new of to as customization potential and has this design device, the user’s a on residing apps 5)6"-")&%7879&(# '#((+,)*-.)#, /,.&".-),(&,. AppSensor ?"#=+*.)@).; <+3.)(&=)- A&:&"&,*& F,G,#$, B4#DD),C 5):&%.;3& !"#$%&" B&..),C% E4&(&% 0),-,*& '#()*% 1-(&% 2&-3.4 BD#".% E"-@&3 B#*)-3 >&$% E##3% IKJRL MMJNL RPJSL RRJPL RMJRL RRJOL RPJML OJIL NJPL MJOL NJSL QJSL NJQL IJKL NJSL OJQL SJKL OJQL OJUL SJKL NJIL ie iet xmnn h c-ytmof eco-system the examining to rise gives !"#$%&" RPJIL RPJQL KJKL UJRL QJRL KJML MJPL SJOL QJNL KJQL QJPL MJML QJML MJSL KJOL QJUL MJSL NJRL IJSL UJKL MJNL AppSensor '#()*% KPJOL MNJIL MNJRL MSJIL KMJML MQJML IMJIL INJML MKJML MOJQL MMJML MOJIL RSJML IMJML MKJML MPJKL MSJML INJRL NQJQL MNJRL MMJOL '#((+,)*-.)#, PJRL PJRL PJPL PJPL PJRL PJPL PJPL PJRL PJPL PJPL PJPL PJPL PJPL PJPL PJPL PJPL PJPL PJPL PJPL PJPL PJPL /,.&".-),(&,. o nern srscon- user’s a inferring for PJIL PJIL PJIL PJIL PJKL PJML PJKL PJIL PJIL PJKL PJQL PJIL PJRL PJIL PJML PJML RJOL PJPL PJIL PJIL PJML 0),-,*& RQJRL IJRL IJML IJSL IJKL IJQL IJML KJOL RJOL SJQL IJNL RJNL RJKL KJPL IJML IJQL IJUL MJML RJQL KJOL MJQL 1-(&% PJIL PJML PJML PJRL PJKL PJIL PJKL PJKL PJNL PJKL PJIL PJNL PJQL PJML NJRL PJML PJIL PJNL PJRL PJNL PJIL 2&-3.4 AppSensor PJML PJQL PJKL PJIL PJIL PJIL PJUL QJIL PJML PJIL PJRL PJIL PJNL IJNL PJNL PJKL PJML PJPL PJRL PJIL PJIL 5)6"-")&%7879&(# PJNL PJSL PJNL RJKL PJML PJML UJNL PJSL RJPL PJNL PJIL PJKL MJPL PJOL RJIL PJSL PJIL PJNL PJIL PJNL PJKL 5):&%.;3& MJUL RJUL IJRL MJIL RJML RJIL PJUL IJPL RJPL IJOL RJKL IJQL PJUL RJML NJRL RJPL RJQL QJNL RJML QJIL RJQL <+3.)(&=)- to RRJOL RJOL RJNL IJKL PJKL MJPL IJUL IJOL IJNL IJQL IJOL MJUL IJQL IJML RJSL IJUL IJRL OJNL PJNL IJRL IJSL >&$% MJIL NJSL KJIL KJSL KJOL IJOL QJIL NJUL KJNL SJIL IJUL NJIL KJML MJIL MJRL KJIL MJQL IJOL IJQL KJRL MJOL
,ti hudnthv ag neg- large a web- have not of should impact. instead this ative apps [2], native devices many mobile employ Since on to sites prefer to applications. are seem dedicated browser users a within via the available provided that also are that insight services the most However, cases, as these regarded For be AppSensor can imprecise. that applications meaning or such The limited from dictionary. a deduced in plan- be word route can a up transportation looking public to ning from everything un- well for not used is that purpose by general derstood more a have apps Some Limitations time- of the ranking estimated exploit the can on apps. factor – as 13] share usage [1, dependent filtering techniques collaborative knowledge basic like applying using after i.e. dependencies context-aware – on approach post-filtering that a systems an follow recommender instance, exploiting For study. by presented the efficient more made AppSensor mobile be suggest can that applications systems recommender – Context-aware activity same the in restaurant. be a for might looking they and probably app app instance, map guide a For restaurant between swapping a people. constantly to more are possible users or be two two if would of it contexts itself, the apps compare used meta- any the without on Even information tourist. the and shopper the between ?"#=+*.)@).; PJML PJKL PJNL PJKL PJQL PJML PJSL PJQL IJUL RJRL PJKL PJML PJSL PJML RJNL PJSL PJRL PJPL PJML PJNL PJNL A&:&"&,*& RNJIL MJUL QJPL IJRL MJML IJKL RJQL MJPL PJPL RJSL MJOL RJKL IJPL IJML IJML RJQL RJQL MJML RJPL IJIL RJSL B&..),C% IOJSL RRJUL IJUL IJUL QJQL NJQL MJOL IJSL KJSL QJNL QJIL KJOL MJPL RJOL NJPL NJQL QJQL SJIL RJSL QJIL MJNL hswsormi oiainfrconducting for motivation main our was This . rvdso h srscnetmgtb limited. be might context user’s the on provides
AppSensor B4#DD),C RIJKL RQJNL KJSL KJKL KJRL MJNL QJKL KJML KJSL KJRL QJRL MJSL KJKL MJRL MJSL KJUL KJPL NJRL MJML KJOL KJML B#*)-3 PJML PJML PJKL PJRL SJNL PJSL PJQL PJNL PJKL PJNL PJKL PJML PJIL PJML PJOL PJOL PJSL MJML PJKL PJNL PJQL BD#".% PJIL PJIL PJIL RJIL PJPL PJRL PJQL PJQL PJIL PJML PJPL PJKL PJKL PJRL PJPL PJRL PJRL PJPL PJRL PJKL PJML o ntne e rwe a be can browser web a instance, For . E4&(&% RNJNL RPJIL RQJSL RRJNL RPJIL RMJKL RIJKL RPJNL NJKL OJNL SJPL QJML UJOL UJSL NJQL UJQL OJML OJML QJPL OJKL OJRL E##3% RJQL NJNL IJOL MJML RJQL RJIL RJNL KJOL RJSL IJKL RJPL MJIL IJIL MJIL IJML RJSL RJUL QJNL RJKL IJSL IJIL E"-@&3 RNJSL RRJNL RRJRL MJNL MJQL KJNL MJUL MJML MJOL KJKL KJKL IJKL UJRL QJQL QJQL MJUL KJIL MJRL MJIL QJPL NJRL F,G,#$, B-(D3&% KMKTUSK KOTMSU RITQQN OOTURR MQTPON IRTSOO RMTQSN MRTRRM IQTRMR RITKQR MRTIQO KOTMSU RTUIU ITSUM ITNRR KTNSM MTUMN RTKNN OTNIP RTKUN ROP F%&"% RTUSI RTKPM ITMOK RTQUM ITIPS RTONM RTUQK RTKKP RTMSN RTMOM RTPOI RTPSS ITOMU RTSQK ITRUM RSQ MOS QQI MIO MKS NQ HDD% RTISS RTMRP RTIIP IOR RSQ RMQ IMU RMI RUU KUO MRI MPM RMP UUQ RRS KKU QM UP IO R U r-td nhwfs n a tr e app. new a start can informal one an fast how conducted on we posi- pre-study as correctly constraints, is these rate given sample tioned our power impact believe We and high increase a consumption. might at the load However, system than decrease. the higher will frequency de- is accuracy chosen the frequency different rate, swapping be between sample the switching the to is If of needs user quality a applications. rate often the sample how impacts on The This pending rate. data. not sample measured currently its is on user pends the the that Thirdly, device. deduced his Oth- be using obvi- device. only is the can of sensor it usage the de- erwise active Secondly, in during available i.e. off. only all, ously turned at and used standby is application vice no when context user’s the Furthermore, purposefully usage. is valid as mode valued be standby Moreover, also when not can standby. does occurs disabled prevents user that the that usage as app app long an as use non-usage, has standby intentionally of into user time go the devices rea- some that most the after However, time device. of the her de- uncertainty used with the The not increase away will running. put context still and soned app leave user’s an the might with to user relate vice A not do activity. that values current return might it stance, the sensor, every Like slightly population. a general the have to than may affinity usage general high app toward in a affinity that higher participants with assume our adopters may Thus, early we are apps. users – our apps of new some find to participants platform people underlying the the supporting on of domain information the detailed to due no have we While apps. are into widgets points most However, entry measure simply apps. cannot of of usage we part widget-based Therefore are the widgets application. screen applications’ home that platform the problem Android the the on have Similarly, we application. the open the the Inter- from time, as the background same browsing the the is at in and mu- net – running to perspective listening player system’s is the operating user with a – if instance, sic For multitasking. ing the row. of each design yellow within through current normalized increasing are The white, and by app indicated each is of usage time low usage app) the each indicate for Percentages (i.e., row red. each at Within peak day. a the reaching throughout and time usage Application 10. Figure D8#3E8:/C-- A00748/B#-6 C4#:$<40<>/" C4#:$<40<>/! CH7:I/J9:K6 M#4
AppSensor %#$ !,?*. !,?&. '?%. "?). ,?". ,?). &?,. !?(. !?*. %?%. ,?'. !?*. %?". antb sdt esno a on reason to used be cannot AppSensor’s &#$ !,?). '?&. "?,. ,?&. ,?*. %?". !?*. !?+. %?,. "?,. +?). !?*. %?%. '#$ snterrfe.Frin- For error-free. not is (?". %?,. %?*. !?!. "?+. !?'. !?+. %?*. %?*. +?). *?). !?+. %?*. ilrtr h browser the return will sntcpbeo track- of capable not is (#$ (?!. "?". "?". !?). "?%. "?,. !?). &?,. "?". +?". (?*. "?". &?!.
cuayas de- also accuracy )#$ appazaar '?*. !?%. %?+. "?*. !?). !?*. "?&. &?%. &?,. *?". &?*. %?". &?!. *#$ !,?!. &?'. "?(. (?!. !?(. "?,. "?*. %?%. &?%. )?). %?%. &?,. &?!. +#$ !!?". '?%. %?(. )?(. (?(. "?%. %?'. &?!. &?*. '?%. "?". &?,. %?+.
i.e. – !,#$ %?). %?". )?*. (?*. !?+. %?'. &?*. &?). +?*. %?%. !?&. '?,. &?). !!#$ &?". &?&. (?%. )?!. "?*. &?(. '?". &?%. *?!. !?*. !?,. '?). &?,. !"-$ hte rntan not or Whether evening. they the when sta- in device their bed mobile in on their lying use day are and the laptop, the during or be PC Facebook might tionary use it people instance, us- For that general case services. to underlying transferred the be of cannot age findings our course, Of fmr hn410uesoe eidlne hnfour contri- than following longer the period included others): paper a (amongst this butions over short, users In 4,100 This months. than applications. more mobile of sen- of virtual of usage a deployment physical the defined public to we measuring contrast locations), for In for sor GPS usage. (e.g. collec- application sensors data mobile the fine-grained – on knowledge with tion our combined of store app was best of the deployments means by to research – deployment-based time of method first the the For studied age. and conceptualized we sor paper, this In CONCLUSION wild. the in other deployed and be cannot these least For at device. every an on service, reasons background possible as not implemented is sen- be which The to needed openness. itself required sor the platform Android provides the Android on because implemented The was vendor. paper device’s this the in sys- used of operating policies underlying the the and on tem depends strongly system a • • %?*. '?). '?%. (?". %?(. '?(. '?*. &?&. %?". ,?'. !?,. '?(. &?".
hnlne esoswt w rmr ps n h first the and apps, more or frequent two more with much (4) sessions are app; longer app each than one with only time with actively less sessions spend people short they when devices (3) their broadly use day; more the are others throughout whereas employed (e.g. apps), usage social relative and in music spikes intense some somewhat (2) still have voice); are apps and (text phones communication mobile for mostly (1) used findings): conclu- other following (among the sions to led that analysis context-related a usage average categories, seconds that app 72 and between average), than extensively (on differs less time time spend a but at app apps an using that with day almost showing a spend data hour users an device sample mobile our findings) other of (among analysis descriptive a !-$ rmwr o nlzn mr hn plcto us- application phone smart analyzing for framework a : %?(. '?,. %?'. '?(. "?(. &?+. '?). &?). "?+. ,?&. !?,. '?). &?!. "-$ %?(. '?!. '?'. )?(. &?%. (?'. (?'. &?(. '?+. ,?%. !?,. '?*. %?'. %-$ AppSensor %?&. (?". '?*. )?). "?'. &?). (?&. &?,. (?'. ,?'. ,?+. (?*. &?!. &-$ %?(. (?). '?%. (?+. %?*. (?". )?&. &?!. &?%. ,?(. ,?(. (?&. &?,. '-$ AppSensor %?!. (?,. %?*. '?*. %?!. '?(. )?(. &?,. "?,. ,?). !?,. )?%. &?%. AppSensor sntpsil nApesihn,or iPhone, Apple’s on possible not is (-$ &?!. &?). &?&. '?%. "?'. (?,. (?*. &?(. &?+. ,?&. !?". (?(. &?'. )-$ %?(. '?,. '?(. (?*. &?+. '?!. '?*. &?+. %?%. !?,. !?&. '?,. &?). swdl elybewithin deployable widely is *-$ rvddu ihtedata the with us provided %?*. '?*. &?%. (?". '?%. (?,. &?*. &?*. &?,. ,?(. "?,. &?*. &?*. +-$ "?+. &?'. %?!. %?%. )?%. '?&. &?!. &?%. &?). !?!. %?,. &?(. '?(. !,-$ "?*. '?). '?!. !?*. )?). '?). %?'. &?!. "?'. "?,. '?,. %?&. &?*. !!-$ 56#78/29$8 ./01/203#4/ AppSensor ,?&!. ,?!+. ,?!&. ,?!+. ,?&). ,?(&. !?+&. ,?'(. ,?,(. ,?%". &?''. ,?*!. !?+!. AppSen- "@&,+ !@'*& !@&() 568:6 &*% )*! (!' (', ",+ )") &') %,+ !(+ %&! app within a session is very likely to be an app for com- 7. Cui, Y., and Roto, V. How people use the web on munication; (5) when people are traveling they are more mobile devices. In Proceeding of the 17th international likely to use multimedia apps and they are surprisingly conference on World Wide Web, WWW ’08, ACM less likely to use travel apps, (New York, NY, USA, 2008), 905–914. • the conceptual design of our research method, namely the 8. Demumieux, R., and Losquin, P. Gather customer’s real AppSensor as a virtual sensor for measuring mobile app usage on mobile phones. In Proceedings of the 7th usage. international conference on Human computer interaction with mobile devices and services, We believe that the MobileHCI community should be aware MobileHCI ’05, ACM (New York, NY, USA, 2005), of this data set. Therefore it is our plan to make the whole 267–270. 7 data set available to the community , allowing others to draw 9. Dey, A. K. Understanding and using context. Personal their own conclusions and perform their own analysis that and Ubiquitous Computing 5, 1 (Feb. 2001), 4–7–7. may go beyond what we have found in the data. To our knowledge this is the first attempt to analyze application us- 10. Froehlich, J., Chen, M. Y., Consolvo, S., Harrison, B., age at this scale and we believe that our work provides data and Landay, J. A. Myexperience: a system for in situ to verify and deepen findings of the sort that Demieux and tracing and capturing of user feedback on mobile Losguin [8] and Verkasalo [18] have presented in their pre- phones. In Proceedings of the 5th international vious but smaller studies. conference on Mobile systems, applications and services, MobiSys ’07, ACM (New York, NY, USA, For future work, we will use the findings of this paper to 2007), 57–70. further inform the design of the appazaar recommender sys- 11. Girardello, A., and Michahelles, F. Appaware: which tem. The chain of previously used apps will provide much mobile applications are hot? In Proceedings of the 12th information about users’ tasks and intentions. Develop- international conference on Human computer ing models that are able to predict the next-to-be-used app interaction with mobile devices and services, will dramatically increase the usefulness of an app recom- MobileHCI ’10, ACM (New York, NY, USA, 2010), mender system. We are also working to better understand 431–434. our location-based results with more detailed spatial analy- sis. 12. Henze, N., Poppinga, B., and Boll, S. Experiments in the wild: public evaluation of off-screen visualizations REFERENCES in the android market. In Proceedings of the 6th Nordic 1. Adomavicius, G., and Tuzhilin, A. Context-Aware Conference on Human-Computer Interaction: recommender systems. In Recommender Systems Extending Boundaries, NordiCHI ’10, ACM (New Handbook, F. Ricci, L. Rokach, B. Shapira, and P. B. York, NY, USA, 2010), 675–678. Kantor, Eds. Springer US, Boston, MA, 2011, ch. 7, 13. Herlocker, J. L., Konstan, J. A., and Riedl, J. 217–253. Explaining collaborative filtering recommendations. In Proceedings of the 2000 ACM conference on Computer 2. AppsFire.com. Infographic: iOS Apps vs. Web Apps. http://blog.appsfire.com/ supported cooperative work, CSCW ’00, ACM (New York, NY, USA, 2000), 241–250. infographic-ios-apps-vs-web-apps, accessed on Feb. 15, 2010. 14. Kaasinen, E. User needs for location-aware mobile services. Personal and Ubiquitous Computing 7, 1 3. Barkhuus, L., and Polichar, V. Empowerment through (May 2003), 70–79. seamfulness: smart phones in everyday life. Personal and Ubiquitous Computing (Dec. 2010), 1–11. 15. Kray, C., and Rohs, M. Swiss Army Knife meets Camera Phone: Tool Selection and Interaction using 4.B ohmer,¨ M., Bauer, G., and Kruger,¨ A. Exploring the Visual Markers. In Proc. of Joint Workshops MIRW ’07 Design Space of Recommender Systems that Suggest and MGuides ’07 (2007). Mobile Apps. In Proc. of Workshop CARS ’10 (2010). 16. McMillan, D., Morrison, A., Brown, O., Hall, M., and 5.B ohmer,¨ M., Prinz, M., and Bauer, G. Contextualizing Chalmers, M. Further into the wild: Running Mobile Applications for Context-aware worldwide trials of mobile systems. In Pervasive Recommendation. In Adj. Proc. of Pervasive ’10 Computing, P. Floreen,´ A. Kruger,¨ and M. Spasojevic, (2010). Eds., vol. 6030 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg, Berlin, Heidelberg, 2010, 6. Church, K., and Smyth, B. Understanding mobile ch. 13, 210–227–227. information needs. In Proceedings of the 10th international conference on Human computer 17. Satyanarayanan, M. Swiss army knife or wallet? IEEE interaction with mobile devices and services, Pervasive Computing 4, 2 (Apr. 2005), 2–3. MobileHCI ’08, ACM (New York, NY, USA, 2008), 18. Verkasalo, H. Contextual patterns in mobile service 493–494. usage. Personal and Ubiquitous Computing 13, 5 7Access to the anonymized data set is available upon request. (2009). You can try the app and browse the data on your Android