Category Archives: Eprof

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).

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).

Figure 2. Energy breakdown
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 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”.

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.


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.