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