Kraken.me Mobile: The Energy Footprint of Mobile Tracking

Abstract

Power consumption can make or break the success of mobile applications. This is especially true for applications requiring constant access to sensor readings as sensors tend to consume considerable amounts of energy. A lot of attention has been focused on reducing power consumption for hardware sensors both from a hardware and software perspective. However, mobile phones enable applications to also gather software artifacts employing so called soft sensors, e.g., calendar, contacts, browsing history, etc. Soft sensors are especially important when considering personal assistant systems, life logs etc. They provide additional deep insight into human behavior patterns and user goals. Unfortunately, most tracking application do not consider these soft sensors and their power consumption is mostly unknown. In this paper we introduce the Kraken.me mobile tracking application. It is part of the Kraken.me framework, tracking mobile, desktop, and social interactions. The application tracks both hard and soft sensors to enable the creation of rich user profiles. Our main contribution is a thorough evaluation of the power consumption of each individual sensor used and the combination in the Kraken.me application. Using a high-accuracy measurement setup, we provide an in-depth power analysis of both soft and hard sensors. We believe these insights can help researchers and developers of mobile tracking applications to design more power efficient and, thus, more successful tools.

A Systematic Survey on Android API Usage for Data-Driven Analytics with Smartphones

“…Furthermore, the Google Activity Recognition Transition API 43 can detect a user's specific activity type constants (i.e., IN_VEHICLE, ON_BYCYLE, RUNNING, STILL, WALKING) to identify when a user starts or stops a specific activity [109]. Therefore, through mobile sensors and Google Activity Recognition APIs mentioned above, the physical activity state information are currently collected and utilized in many existing studies (e.g., [34,16,103,104]).…”

“…Location APIs (e.g., LocationManager, LocationProvider) and Google Location Services API are representative API frameworks mainly used to collect location context information in many existing studies (e.g., [20,17,101,110,102,37,103,104,23,16,15,27,68]). In terms of efficiency and accuracy, Google Location Services APIs are superior to the Location APIs.…”

“…Long click [17,18,87,30,28,66,75,78,77,84,86,80,15] 13 Typing [21,37,103,104,30,28,70,69,61,68,54,57,58,75,78,77,84,86,82,83,80] 21 Scroll (Including Pinch and Swipe) [17,87,30,28,69,68,67,66,49,58,74,75,78,77,139,15,80,88] 18…”

“…Among 45 studies using interaction data, 18 studies use terms related to type of touch interaction (i.e., click, long click, typing, scroll, pinch, swipe) to describe the type of touch interaction used in References [17,21,37,87,88,103,104,15,70,69,61,68,67,139,73,74,77,80]. The 16 studies which are the names of Accessibili-tyEvent related to the type of touch interaction (TYPES_VIEW_CLICKED, TYPES_VIEW_LONG_CLICKED, TYPES_VIEW_TEXT_CHANGED, TYPES_VIEW_SCOLLED) were used to describe the touch interaction used in References [18,30,28,66,49,132,57,58,75,84,86,79,82,83,81,78].…”

Upgrading Wireless Home Routers for Enabling Large-Scale Deployment of Cloudlets

“…But other responsive use cases or dataset are imaginable, e.g., speak, activity, face, object or gesture recognition [20]. To ensure repeatability across different benchmark runs, the input data consisting of location values is fixed and equal, i.e., we ignore the tracking of sensor data that is not relevant for this paper, but we reference to our previous work for measuring sensor tracking [26]. For our benchmark purpose, we created six datasets varying in their data size (50kB, 100kB, 200kB, 300kB, 400kB, 500kB) in advance to measure their impact.…”