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.


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.