A First Inside Look at Pokémon GO Battery Drain. You won’t catch many, if your battery dies so quickly.

Ever since its public release in Australia, New Zealand, and United States, Pokémon Go, the augmented reality mobile game from Nintendo and Niantic Labs, has quickly captured the fascination of the app world. Within one week, it became the Number 5 most popular app among US Android daily app users.

The location-based augmented reality (AR) game brings AR experience — interacting with pokémon in the real world — by using almost all of the power-hungry components of a typical smartphone: camera and sensors, GPS, Screen, CPU, GPU, and network radios. As such, it has also become one of the most battery-constrained apps among the 2 million or so apps in the consumer app marketplace.

In this following, we report on the first in-depth study of how battery is drained by Pokémon GO using the proprietary energy drain diagnostic tools from Mobile Enerlytics. Our study answers questions concerned by the the millions of pokemon GO fans and gives insights that assist pokemon GO developers on how to go about cutting down its battery drain.

  1. How long will my battery last for common play scenarios?
  2. How long will the recommended battery saving techniques extend my battery life?
  3. Which phone components consume most of the battery?

We used a Nexus 6 phone for all the experiments. Its battery capacity is 2400mAH. We installed pokemon GO version 0.33.0, as well as our battery drain diagnostic tool. Screen brightness was kept 30% of the maximum level 255. A Pokemon GO fan then interacted with the app using WiFi on a university campus with good WiFi coverage, while its battery drain information is being collected and analyzed.

1. How long will my battery last for common play scenarios?

Like any sophisticated app, Pokémon GO comes with many possible play scenarios a fan can be engaged in. For starters, we tested four common scenarios the app can be in: Idle, Walk, Collect Pokeball, and Capture Pokemon.

Figure 1 shows how long a fully charged battery will last if the app stays in each of the four scenarios, without turning on the two battery saving options: battery saving mode is off, and AR mode is on.

Figure 1: Battery life when Pokemon GO stays in each of the 4 scenarios.

We see that Capture Pokemon is the most battery intensive scenario, depleting the battery in just 1.95 hours. The scenario uses augmented reality to show pokemon characters on the camera screen. In addition, the user needs to throw Poké balls from screen bottom to capture the Pokemon. This involves all of the phone’s power hungry components like camera, CPU, GPU and screen. Other scenarios do not use camera which cuts down their battery need. We do not observe much battery drain difference between idle (stationary) and walk scenario. The reason could be that the avatar changes position within the game’s map often even when the phone is stationary.

2. How effective are the recommended battery saving techniques?

The Pokemon GO developers anticipated the battery as a major roadblock to the overall user experience, and built into the app two battery saving configuration options: battery saving mode and AR off mode. The battery saving mode is designed to save screen energy while walking, by dimming the screen and slowing the refresh rate, if the user points the top of the phone towards the ground, a natural holding position while walking.

The AR off mode is designed to cut the app’s camera battery drain, another major source of the app’s battery drain. When the AR mode is off, the camera will not open up when it is time to capture a Pokémon, and the user loses the AR experience of having her actual surroundings just behind the pokemon.

We analyzed the effectiveness of the two options on the game’s battery drain for Walk and Capture Pokemon scenarios. Figure 2 shows how long the battery will last if the app stays in walk, with the battery saving mode on or off, under several screen brightness levels. We see that the battery saving mode extends the battery life by 23% , 30%, and 40% for brightness levels 30%, 50%, and 80%, respectively.

Figure 2: Life of a fully charged battery when Pokemon GO stays in Walk.

Figure 3: Life of a fully charged battery when Pokemon GO stays in Capture Pokemon.

Figure 3 shows how long the battery will last if the app stays in Capture Pokemon, with AR mode on and off, under screen brightness level 30%. We see that disabling AR mode nearly doubles the battery life.

3. Which phone components consume most of the battery?

Figure 4: Component power draw breakdown for Capture Pokemon Scenario

Figure 5: Component power draw breakdown for Walk Scenario

To gain insight into how Pokemon GO drains the battery, we used our tool to break down its total battery drain into portions from engaging different phone components needed to delivery the overall user experience. Figure 4 shows the total battery drain and breakdown of the game under AR on and AR off for a 2-minute play of Capturing Pokemon (throwing a ball every 10 seconds). To make it easier to relate the energy drain with the component power draw, we show battery drain (and breakdown) in terms of average power over the app play duration. Figure 5 shows the total battery drain and breakdown of the game under normal mode and battery saver mode for a 2-minute play of Walk. We see that

(1) The major battery saving for battery saving mode comes from Screen (19%) and for AR off mode comes from Camera (56%);

(2) GPS drains only about 4–7% of the total app energy;

(3) Interestingly, the app drains little battery doing networking (~5 mA), as it performs infrequent networking of fairly low volume data (about 7 KBytes every 30 seconds for the Idle scenario.)

(4) And though there is no augmented reality in AR Off mode, GPU actually drains 3X more battery (~150 mA) than in AR On mode (~49 mA).

Figure 6: Timeline of Component-wise power draw in Capture Pokemon.

To understand the above GPU power behavior and gain further insight on Pokemon GO’s battery drain behavior over time, we used our tool to show the timeline of the power draw by different components while the game was in Pokemon Capture with AR On mode and AR Off mode, and the user threw a ball towards pokemon every 10 seconds. We see that

(1) For both AR On and AR Off, Screen and GPS are turned on all the time, drawing steady power, while Camera is on only for AR On mode;

(2) Surprisingly, for AR On, GPU and CPU power draw is high initially but both gradually decreases significantly around 35 second CPU with GPU power almost becoming zero! The likely reason is that when AR mode screen just started, CPU and GPU were engaged actively to instantiate the 3D animated objects (such as Ball, Pokemon) on camera screen. Afterwards, the only major task left was to compute the coordinates using motion and position sensors (e.g accelerometers, gyroscopes) to correctly position the already instantiated 3D objects on the camera screen.

(3) For AR Off mode, although the green background is static, there are regular changes on screen such as the shade of pokemon which results in continuous use of GPU and CPU.

(4) We did not include the power consumption by sensors used in app as they are insignificant. For example, Gyroscope consumes 1.5 mA and Accelerometer consumes 1.3 mA.

Conclusion

In summary, our analysis has shown that the AR experience of Pokemon Go comes at a hefty toll on the battery — draining battery almost twice as fast compared to AR off when capturing Pokemons. We expected battery saver mode to take close to zero power, but it only reduced battery drain rate by just 19%. Pokemon Go drains fully charged phone battery in as little as 2 to 4 hours on a high-end phone (Nexus 6) making it one of the most battery-hungry apps ever.

Our patented app battery management (ABM) solution, Eagle, demonstrated that CPU and GPU are the biggest consumers of battery in almost all scenarios and should be optimised first by the Pokemon app developers; camera and screen are power hungry components and users should keep them off longer with AR off and battery saver mode on to extend their battery life by 2x and 19% respectively. 

“Love Thy Enemy” — How I instantly found energy glitches in Spotify by comparing it against Apple Music using Eagle

Our battery-drain testing (shown in Figure 1) in our previous blog revealed that in foreground music playback, Spotify performs far worse than all of its competitors, draining battery at alarming 55% and 23% faster than Apple Music and Google Play Music, respectively.

Figure 1. Battery draining test results for foreground playback

Now imagine that I am a developer of the Spotify app and am familiar and comfortable with all the major modules of the app developed over the years, and was shocked to see the gap. How do I go about figuring out the reason for the huge gap in order to eliminate the culprit and make Spotify battery drain come close to Apple Music?

It turns out from talking to developers we learned this is something many app developers have been trying to do — to figure out why is my app draining more battery than a competing app or than my app’s previous release two weeks ago.

To facilitate this task, we introduced the Energy Diffing feature to Eagle which allows instant, head-to-head comparison of battery usage of two apps at the source-code level. The intended usage, of course, is for competitive analysis of similar apps, e.g. Spotify and Apple Music, or different releases of the same app.

Eagle— source-code-level battery drain comparison

Eagle gives source-code-level insights into why one app execution consumed more energy than the other. The diffing is unidirectional: when we invoke DiffView on Eagle trace A against trace B [trace A — trace B], the output shows a table listing all the methods in trace A along with their corresponding difference in energy consumption and in the number of calls (between the two traces). The tabular view is accompanied by a call graph view (like in Figure 3) of trace A, where each method node’s color indicates the energy difference in the two traces; the redder the node, the more energy drain the method in trace A over in trace B.

Finding UI energy inefficiency in Spotify

Since we have a fairly efficient reference app at hand, Apple Music, we can analyze the energy inefficiency of Spotify by simply invoking Eagle on [Spotify — Apple Music], for the contested usage scenario, i.e., foreground music playback.

I ran the apps on Nexus 6 phone under LTE. During the experiment, both apps are on their respective player activities playing music for 1 minute each without any user interaction — as shown in Figure 2.

Figure 2: Screenshot of Spotify and Apple Music player screen.

Table 1: Table view output of Eagle on [Spotify — Apple Music] for 1-minute foreground music playback.

Figure 3: Call-graph output of Eagle on [Spotify — Apple Music] for 1-minute foreground music playback.

Table 1 shows the diffview’s table view output and figure 3 shows a pruned call graph after diffing [Spotify — Apple Music]. We immediately see here that the path containing “ProgressBar.setProgress()” brings most of the energy difference. Referring back to the table view, I found that the progress bar was actually set 1192 times more in Spotify compared to Apple music in the 1-minute play — Spotify updates the progress bar 21 times per second, while Apple music only updates progress bar once per second.

Such high frequency update is completely unnecessary if you do the simple math. A typical phone screen has 1024 pixels horizontally. A 4-minute song will advance the progress bar by roughly 4 pixels per second. In other words, in Spotify, four out of five consecutive updates do not even move the progress bar by a single pixel.

I reduced this update frequency to update every 200 ms (moving the progress bar by 1 pixel) by modifying and recompiling the apk. This does not bring any noticeable change in the UI, but extends the battery life from 5.3 hours to 11 hours as shown in Figure 1.

PS: Out of curiosity, I also diffed [Apple music — Spotify] using DiffView which outputs the annotated call graph shown in Figure 4. The root method node is green signifying that overall Apple music consumed less energy than Spotify, but still there are red nodes present in the layout hierarchy measurement. This is due to the parameter misconfiguration bug discussed in our previous blog which is not present in the Spotify app.

It is fascinating to see Eagle can also uncover energy inefficiencies of a more efficient app when comparing it to a less efficient app !

 

Figure 4: Call-graph output of Eagle on [Apple Music — Spotify] for 1 minute foreground music playback.

Drop us a line at sales@mobileenerlytics.com or visit our website.

 

Apple Music, the latest Music app, also has energy glitches (How we reduced its battery drain by 18%)

Apple music has recently entered the fray to become the newest addition to the crowded family to offer online music service, aiming to win over a large fraction of the music fans.

apple-methodology
Testing methodology

While the public is undergoing heated debating how Apple Music fairs against the incumbents in terms of features and business models, we performed a head-to-head comparison of Apple Music app with some of the most popular music apps in the energy efficiency dimension. Specifically, we repeated the same battery draining test for comparing top Streaming Music apps reported in our recent blog (see sidebar for methodology) on the Apple Music app.

Our testing results (shown in Figure 1) shows that in background music playback, Apple Music is trailing behind, draining battery 9% and 40% faster than Pandora and Google Play Music, respectively. In foreground playback (shown in Figure 2), however, it is leading the pack, draining 14% less power than the previous champion, Google Play Music.

apple-back
Figure 1. Battery draining test results for background playback
apple-front
Figure 2. Battery draining test results for foreground playback

Finding UI Energy bug in Apple Music playback

To find out whether there is room to improve the energy efficiency of Apple Music, we employed Eagle, the industry’s first source-code-level energy profiler. Specifically, we played music for 1 minute of Apple Music (in music player page as shown in Figure 3), and used Eagle to profile the energy consumption of the app process and break down the energy to each method in the source code.

Figure 3. Screenshot of Apple Music music player page

Figure 4 below shows a branch of the energy-drain-annotated call tree output by Eagle, that contains top energy consuming methods during the 1-minute music playback. Since the energy is inclusive, the method call at the bottom of the call tree is the method that actually consumes most of the energy. In this case, method ViewRootImpl.performMeasure(II)V is at the bottom, which suggests that Apple Music spends most of the energy in performing measurement of the UI hierarchy.

As we know, Android performs UI hierarchy measurement only when any view in the UI changes its size, typically due to content changing. However, during music playback in Apple Music, the only UI elements that have content updates are the song elapsed time text, remaining time text, and the progress bar, none of which changes its size in updating. This suggests an energy inefficiency in measuring the UI hierarchy.

Figure 4. A branch of the energy-drain-annotated call tree (by color) that contains the energy hotspot in Apple Music playback in foreground

Finding the root cause of the energy inefficiency boils down to finding which UI element is causing the UI hierarchy measurement energy. We find out this culprit UI element by searching for method View.requestLayout() in Eagle method-level profiling output, since whenever a UI element changes its size, it will invoke the View.requestLayout() method to inform the system that a UI hierarchy measurement is needed.

Eagle shows that the only parent of this method is TextView.checkForRelayout(), which in turn is only invoked by TextView.setText(). Given that the only changing text in the music player is the song elapsed time and remaining time texts, and the number of TextView.setText() invocation equals the number of times the two texts are updated (once per second), we finally figured out the reason for high UI measure hierarchy energy In Apple Music: both song elapsed time and remaining time are displayed as a TextView with “dynamic width” (i.e. wrap_content). As a result each time the time texts are refreshed, the Android system has to perform a UI measure hierarchy to adjust the UI to fit the size of the new contents, even though the new content has the same length as the old content.

The impact of the energy bug

Without the appsource code, we fixed the problem by setting breakpoint at TextView.checkForRelayout() method using jdb, and changing the layout width of the two time texts to static width upon hitting breakpoint.

To confirm the bug’s impact on energy drain, we repeated the battery drain test as before. The fix reduced the total energy of the Apple Music process, and extended the battery life in playback, by 18% (Figure 2 in orange).

As always, we plan to benchmark and publish the battery performance of the latest releases of popular music apps, and welcome streaming music app vendors and music fan to repeat these experiments on different handsets following the above simple methodology.

 

How I Cut Google Play Music Energy Drain by 15% with Mobile Enerlytics

Our previous blog on the battery-draining tests of three popular music apps Pandora, Spotify, and Google Play Music showed that the Google Play Music app is more energy-efficient and battery-friendly than competing apps, in streaming music from the Internet.

sidebarReaders in Reddit asked what about the energy drain when playing Music stored locally on the device, a feature supported by several apps such as Google Play Music. Such a feature allows users to enjoy listening to preloaded music when there is no network connection, or play prepaid albums.
On the contrary, our testing results (shown in Figure 1) shows that playing music from local actually drains slightly more battery than streaming music from the Internet, for Google Play Music 6.1! The battery-drain test was the same as before (see sidebar for methodology).

one
Figure 1. Time to drain the entire battery

Solving the mystery with Mobile Enerlytics

To understand why playing local music drains unexpectedly high energy, we used the Eagle source-code-level energy diagnostic tool. Eagle accurately breaks down the total energy drain of an app run at the source-code-level, e.g., by each app method.

The app energy breakdown by component output of Eagle (Figure 2) shows that while playing music from local indeed incurs no network energy, the app process incurs 56% higher CPU energy than streaming music from the Internet (in light blue).

two
Figure 2. Energy breakdown
table
Table 1.Top energy-draining methods in Google Play Music 6.1 when playing local music

To find the root causes for the high CPU energy in playing local music, we next looked at the method-level energy breakdown of Eagle. Table 1 shows the top 10 (inclusive) energy draining methods during 1-minute local music playing in Google Play Music output by Eagle. We see that at top of the list are standard Android framework methods of class android.os.Handler and android.view.Choreographer, which perform generic message and callback handling for the app and will always be the top methods for most Android apps. What is interesting is that there are 3 methods of class android.graphics.drawable.AnimationDrawable among the top 10 (in blue), which indicates that the app spends a major chunk of energy in rendering animations.

However, there is no visible animation in the music player view we profiled, shown in the app screenshot in Figure 3(a). In fact, the only animations during music playing are the playing indicators in the album screen and play queue screen, circled in Figure 3(b) and 3(c). All three screens belong to the same activity and users can navigate between them with 1 or 2 clicks. Our observations suggest that Google Play Music spends a major chunk of the CPU energy on rendering animations that are invisible to users, which could be an “invisible animation UI energy bug”.

taylor
Figure 3: Screenshots of Google Play Music app

The impact of the energy bug

By hacking the app apk, we confirmed the energy bug is due to the app failing to consider the visibility of the play indicator animations, which results in a considerable amount of energy spent on animations that are invisible to users.

To confirm the bug’s impact on energy drain, we removed it by making the following 2 changes to the app:

  1. Adding code to check whether the play indicator is visible to user before starting its animation;
  2. Adding visibility change callback (i.e. onVisibilityChanged()) in the play indicator to handle its visibility change, i.e. start, stop its animation when it becomes visible, invisible, respectively.

We then repeated the battery drain test as before. The fix reduced the CPU energy of the Google Play Music process by 4.3X (Figure 2 in blue), and the total app energy drain by 15% (Figure 1).

Interestingly, after we learned the intricacies of the invisible animation energy bug in playing local music, we went back to the online streaming playing mode, and found the bug also exists in Google Play Music when streaming music from the Internet. The impact on energy drain is less, since there is only one invisible animation in play queue screen, as opposed to multiple invisible animation in both play queue screen and album screen when playing local music.

We have reported this issue to Google Play Music team.


Do you have an app?

user      No.

dev      Yes, I develop apps.

sales      Yes, I market apps.

[Icons]

Music Lovers: Switch Streaming Music Apps and Extend Your Battery Life by 2X

Since Pandora first launched music streaming 15 years ago, the music streaming category of mobile apps has become crowded with over a dozen popular alternatives today, many of which are undergoing rapid revisions. For example, Spotify releases a new version of its mobile app every two weeks. As a result, deciding on which music service to choose has become often difficult. In fact, a simple Google search for “Pandora vs. Spotify” today churns out over 4 million search results, which attempted direct comparisons of leading music streaming services along a multitude of dimensions, such as song selections, features, user experience, and business model.

Since battery drain is an important factor that affects user experience, we carried out a head-to-head comparison of the battery drain rate of 3 leading streaming music apps.

To isolate the impact of other apps running on the devices, we tested the battery draining rate of the recent versions of Pandora, Spotify and Google Play Music in the lab.

Screen Shot 2015-12-21 at 9.47.15 PM Our methodology for the test consists of three steps. In step 1, we measured the battery life in playing music in foreground and background, respectively. We uninstalled all the other third party apps from a Nexus 6 phone so that no other background task was running. We then put each of the three music apps in the streaming music mode to play music from a pre-selected music categories, under WiFi (see sidebar for details). We measured how long it takes to drain the entire battery for each app. The results are shown in the following graphs.

 

fg

bg

In Step 2, we measured how much time real users spend playing music in foreground and in background using their smartphones. The analytics from Eagle of 15,000 Android users who have installed at least one of the three music apps above shows that 83% of the total music app usage is spent on playing music in the background. On average, users spend 10 minutes playing music in foreground and 49 minutes playing music in background per day.

Finally in Step 3, we calculated the expected battery life in playing music under typical user behavior, as the weighted average battery life of the above measured battery life when playing music in foreground and in background,  weighted by the percentage foreground (17%) and background (83%) playing time measured on the 15,000 Android phones.

blog-typical

The results, shown above, show that Google Play Music drains over 2X less battery compared to Spotify, and Pandora drains 70% less battery than Spotify. In other words, for a music fan who spends a lot of time playing music on her smartphone, switching from Spotify to Google Play Music can extend the battery life and hence listening time by 2X!

We plan to benchmark the battery performance of other streaming music apps and we also welcome streaming music app vendors to repeat these experiments on different handsets following the above simple methodology.

Are pre-installed apps more power hungry?

Carriers as well as handset manufacturers pre-install several apps on mobile devices that they sell. In this post, we exhaustively study pre-installed apps by leveraging the rich energy profile information that Eagle provides — our analysis below is based on data collected from 70K+ devices. One primary concern that users have about pre-installed apps, which leads them to be used less often, is about their battery usage being high. This concern gets magnified given that users quite often can’t delete these apps unless they root their phones, etc. In sharp contrast to this preconceived notion, we show that pre-installed apps actually have similar power draw as apps with similar functionality from the Google Play store. Our conclusion: power usage of these pre-installed apps is not worth losing sleep over!

Our battery management app, Eagle, has a patented technology to accurately keep track of both the time and energy spent inside each app. For this study, we analyzed data collected by Eagle from three different Android device manufacturers: Samsung, HTC and Motorola.

We first averaged apps we see across all the users of Eagle and compared the number of pre-installed apps that users have on average compared to the total number of apps. Amongst the three most popular Android device manufacturers, Samsung phones have the highest percentage of pre-installed apps (25.6%) followed by HTC (23.3%) and Motorola (12%) (see Figure 1).

Figure 1: Number of pre-installed vs. total apps across device manufacturers.

The Table below shows the average daily usage across the different device manufacturers, with Samsung devices being used the least (88 mins. per day) compared to Motorola and HTC. In terms of usage across different pre-installed apps, Samsung devices have the least usage at ~6 mins per day compared to 12.6 mins per day for HTC devices.

 Screen Shot 2015-02-14 at 3.08.29 pm

The next question we ask is how often are pre-installed apps actually used compared to apps that users install directly from the app stores (see Figure 3). Interestingly, HTC phones have the highest usage of pre-installed apps at 12% of total daily usage across all apps. Samsung is second at 7% followed by Motorola at 6%. Next, looking at the breakdown in time spent across the variety of pre-installed apps for these manufacturers (see Table above), a few other notable trends emerge: The pre-installed Browser on Samsung and HTC phones is used for about 2 minutes per day whereas Motorola users use the pre-installed browser very infrequently. However, given that Samsung devices are used less often on a daily basis, hence, we next compare each pre-installed app’s usage in terms of percent time spent across all pre-installed apps (see Figure 4). In terms of Camera apps, Samsung and Motorola phones seem to have a popular pre-installed Camera app whereas the pre-installed Camera app on HTC devices seem less popular. For Motorola devices, the most popular pre-installed app is a Gallery app at 50% usage. Samsung devices also have a non-trivial usage of the Gallery app at 17% across all pre-installed apps.

Figure 3: App usage on Samsung, HTC and Motorola devices.

Figure 4: App usage across pre-installed apps on Samsung, HTC and Motorola devices.

The low usage of pre-installed apps compared to user installed apps should come as no surprise, as they were not actively downloaded by the user to serve a specific need — hence user may sometimes be not even aware of them. Moreover, several myths prevail about pre-installed apps: (1) overall they draw more power, (2) and they draw a lot of power in the background, i.e. even when they are not used — yet they can not be deleted easily.

In Figure 6, we compare the foreground power drawn by the six most popular user-installed apps versus the six most popular pre-installed apps. We see they are remarkably similar, suggesting that pre-installed apps should not be discriminated in terms of power efficiency!

Figure 5: Average foreground power (mA) for user-installed and pre-installed apps on Samsung devices.

Next, we pick groups of pre-installed and user-installed apps with identical functionality, e.g. Samsung Clock and Android clock, and perform a head-on comparison within each group. The first set consists of five such groups of Samsung pre-installed apps versus user-installed apps. Figure 7 shows the power draw of the two competitors within each group is largely a wash — there is no clear winner or loser. This further validates our previous finding that pre-installed apps are not drawing more power than their user-installed counterparts.

Figure 6: Foreground power between pre-installed samsung apps and user-installed apps on Samsung devices.

So far, the pre-installed apps seem to be vindicated as not being overall “power hungry” when they run in the foreground. But in the background — do they consume more power? To answer this, we analyzed the “background” power usage of a few of the most popular pre-installed apps and user-installed apps on 8K devices. Figure 8 below shows a scatter plot for these apps as the average daily background power over the app’s average daily usage time. Amongst the user-installed apps as well there is no clear trend as there are apps that draw more power in the background (e.g., Facebook Messenger) and those that do not (e.g., Facebook). Moreover, on comparing two different browsers: Chrome which is user-installed and Samsung Browser which comes pre-installed, we find that they are quite similar in terms of background power usage. Samsung Video Player when compared to YouTube draws more power though and hence it appears that there may be room for power-improvement in Samsung Video Player. Hence, background usage corroborates what we found about foreground usage earlier — that pre-installed apps seem to be consuming as much power on the average as their user-installed counterparts.

Figure 7: Background power draw of a few apps compared to their daily usage on Samsung devices.

So far, we’ve focused only on pre-installed apps as installed by device manufacturers: What about pre-installed apps as provided by carriers? Are those more or less power-hungry? Figure 9 below, groups similar apps by functionality, while including a user-installed app, an AT&T pre-installed app and a Verizon pre-installed app in each group. Once again, based on the data below, we can’t argue that Verizon or AT&T pre-installed apps are more or less power hungry!

Figure 8: Foreground power usage of groups of apps with similar functionality while comparing user-installed, AT&T and Verizon apps per group, on Samsung devices.

Conclusion: In this article, we’d set out to examine whether pre-installed apps are indeed consuming more power than their user-installed counterparts. Contrary to preconceived notions about pre-installed apps, they actually do not consume any more power in either the foreground or the background. Hence, our recommendation to smartphone users: if battery usage is your concern, there’s no need to root your device to delete the pre-installed apps.

How I Reduced the Idle Energy Drain of 2048 app by 87% using Eagle

If you haven’t heard of the 2048 game, this puzzle game got insanely popular after a hacker news article. Today, if we search 2048 on Google Play we get a listing of more than 250 apps!

Searching 2048 in Estar shows that the second most popular version of 2048, Estoty Entertainment Lab app, with more than 10 million downloads and average rating of 4.4, has only 3 energy stars compared to 4 or 5 of its counterparts.

In this blog post, I show how I used Eagle to study the energy consumption behavior of this app and reduced its idle energy by 87%. I fire up Eagle, connect the phone, and start energy profiling 2048 app. I play the game for a short while and look at the results. In addition to fine-grained energy breakdown among program entities such as threads and methods, Eagle also accurately reenacts the power draw over time of every major power-draining phone component. Browsing through these power lines, one thing that instantly caught my attention was that while playing the game, even though I had been idle most of the time, thinking next move and not interacting with app, the CPU and GPU power consumption of the app never dropped — the app continues to drain high power while I was idle.

So, next I collect another energy profile where I do not interact with the app at all. The app is just sitting idle on the screen not animating, not doing anything. As earlier, I saw that CPU and GPU again continue to drain excessive power.

Going back to the method energy breakdown by Eagle quite clearly shows that the app called library method nativeRender 1617 times even when the screen had no new content to show.

Thus Eagle has exactly pinpointed that I need to look at calls to Cocos2dxRenderer.nativeRender from Cocos2dxRenderer.onDrawFrame method for reducing the energy of this app. To fix this problem and generate a new app apk, I use apktool to decompile the app and edit dalvik bytecode files, in particular Cocos2dxRenderer.smali. Looking at Cocos2dxRenderer.smali file, we see that onDrawFrame directly calls nativeRender method without checking if the app has any new content to draw. Right after the frame is rendered, onDrawFrame is called again, creating a loop of repeated drawing.

The fix is simply that whenever there is a user action, such as pressing a key, increment a counter by a value corresponding to the number of times nativeRender should be called. Then, onDrawFrame decrements the counter and only calls nativeRender iff counter > 0. Even though bytecode is more verbose than Java, I just had to add 44 lines of code in Cocos2dxRenderer.smali file. The full patch can be found here.

Time for testing! I recompile the app using apktool, install it on the phone and collect idling energy profile. Now, I find that the CPU and GPU are indeed idle when the use is idle, and whether the user actively playing the game or being idle, the app gameplay has no noticeable difference.

An Inconvenient Truth about Mobile

How often do users charge their smartphones? Are mobile phones mobile enough to hold charge for a day? How does short battery life affect user behaviour and user experience?
We answer these questions via the following infographic generated by analysing data collected by Mobile Enerlytics from 37k Android users across 100+ countries.

All the data logged by Mobile Enerlytics is strictly anonymised; we don’t collect any information that may identify individual users.

Breakdown of users using external battery backup is obtained from here.

Mobile Enerlytics logs remaining battery percentage and phone charger connect/disconnect events; we use these event timings to generate charging and blackout related insights. The phone usage is defined as the ratio of screen-on time over wall-clock time.

Mobile Music

What are the music listening patterns of smartphone users? Which music streaming app drains the least amount of phone battery? The following infographic shows the answers from analysing data collected by Mobile Enerlytics from 37k Android users across 100+ countries.

music