All posts by jindal

How I Cut Google Play Music Energy Drain by 15% using Eprof

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 using Eprof

To understand why playing local music drains unexpectedly high energy, we used the Eprof source-code-level energy diagnostic tool. Eprof 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 Eprof (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 Eprof. Table 1 shows the top 10 (inclusive) energy draining methods during 1-minute local music playing in Google Play Music output by Eprof. 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 eStar Energy Saver 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 our popular battery management app eStar provides — our analysis below is based on data collected from 70K+ devices in January 2015. 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, eStar, has a patent-pending technology to accurately keep track of both the time and energy spent inside each app. For this study, we analyzed data collected by eStar from three different Android device manufacturers: Samsung, HTC and Motorola. Moreover, for Samsung, we also study the apps across their five most popular models: Samsung S3, S4, S5, Note 2, and Note 3.

We first averaged apps we see across all the users of eStar 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). Amongst Samsung phones, the latest models: Samsung S5 and Note 3 have the highest percentage of pre-installed apps at 27.2% and 26% respectively. Older models such as Samsung S3 and S4 have the smallest percentage of pre-installed apps at 22.8% (se Figure 2).

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

Figure 2: Number of pre-installed and total apps across Samsung devices.

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 users of eStar: if battery usage is your concern, there’s no need to root your device to delete the pre-installed apps.

Should you upgrade from S4 to S5 this holiday season

Connected devices have become de facto holiday gifts with device activations significantly higher compared to an average day. And according to a recent survey, long battery life is the most desired trait consumers look for in a smartphone.

Naturally, with Samsung being the Android market leader, the following question arises — should a Galaxy S4 user upgrade to Galaxy S5 this holiday?Although Galaxy S5 has a 10% bigger battery than Galaxy S4, but it also has a slightly larger screen, a significantly higher resolution camera and more powerful CPU and GPU.

The following infographic compares the battery life of S4 with S5 by analysing anonymised data of 6,000 users collected by Estar over 2 months.

We assume a user is a gamer if the app that spends most time on the screen is a game. Similarly, if the top foreground app is a music app (messaging app) then the user is a music fan (messaging lover). Also, inactive users rarely turn the screen on (<5% of the total time phone is powered on) whereas active users keep the screen on for more than 20% of the total time.

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

If you haven’t heard of 2048 game, this puzzle game got insanely popular earlier this year after a hacker news article. Now, just a few months later, 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 the eprof tool to study the energy consumption behavior of this app and reduced its idle energy by 87%. I fire up the Eprof client, 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, Eprof 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 Eprof quite clearly shows that the app called library method nativeRender 1617 times even when the screen had no new content to show.

Thus Eprof 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.

The new app apk can be downloaded here. Eprof is currently under alpha, subscribe here to get an email when it is available.

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 Estar Battery Saver from 37k Android users across 100+ countries.

All the data logged by Estar Battery Saver app 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.

Estar Battery Saver 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.