How to estimate the battery life of a smartphone in less than one hour?

Posted on by Olivier PHILIPPOT
Reading Time: 6 minutes

Knowing the battery life of a smartphone is important because it’s one of the first purchase criteria. This is the more critical for the fleets of devices (in B2B mode) for the companies. In fact, poor autonomy will lead to a productivity decrease or customer insastisfactions. It’s therefore necessary to have a good strategy to choose its devices as well as the applications that will be hosted on it.

Traditional approaches to estimate battery life

A first approach is to rely on data provided by manufacturers. However, the limit of this approach is that those data are based on usage scenarios that aren’t necessarily representative of yours. The risk is to have a reality of autonomy far removed from what you have estimated. Especially since some features (such as taking pictures for example ..) may not be optimized on a certain type of smartphone and will be very used in your use. This criticism is also valid for tests carried out by external laboratories.

A second approach is to perform tests on real devices and perform the target scenario. Tools exist to launch benchmarks automatically but you can also perform your tests manually. The advantage is to have a realistic autonomy. The only problem is that these tests are very time-consuming. And that doesn’t give the right to the error. Indeed, if you want to change a parameter on the smartphone (brightness …) or add an application to test, you must restart the entire test campaign.

One last approach is to let users do the testing. You wait for your users feedback or you use the fleet deployment tools (MDM) to trace the information. This has the advantage of being inexpensive, the disadvantage is that there is a hidden cost: if there is a problem, there will inevitably be insatisfaction and unproductivity generated. And that forces you to choose a device that may need to be replaced.

The innovative approach of GREENSPECTOR

To meet this need to control the battery life of devices (and to choose the right device as soon as possible), GREENSPECTOR proposes an approach based on on real but unitary measurements with a projection algorithm. The process consists of 3 stages:

  • Measurement of the main features on the devices to be evaluated
  • Configuring a target scenario
  • Data projection and analysis

Use case

We want to estimate the autonomy of a traditional use on a smartphone Samsung Galaxy S7. The use can be a use in company but also an intensive personal use:

  • 30 minutes of internet browsing
  • 30 minutes of social network
  • 30 minutes of telephone conversation
  • 30 minutes of taking pictures
  • 10 minutes of video recording
  • 30 minutes of e-mail
  • 30 minutes of videoconference
  • 30 minutes of Microsoft Word
  • 10 minutes train reservation
  • 30 minutes of geolocation

This scenario is deliberately generic but we could add a specific application or an exotic use …

Functionality measurement

We use the module Free Runner of GREENSPECTOR which allows perform manual tests. These actions can be empowered but in the approach of this article, we focus on rapid testing oriented exploratory tests. If a larger benchmark is needed, automation would be of interest.

For each step of the scenario (navigation, taking a photo …), we launch the Free Runner module and we carry out a scenario representative of a real use over 1 minute.

The GREENSPECTOR module sends the measurements directly to the GREENSPECTOR server. In the end it took us just over 10 minutes to get all the measurements. If we want a little more precision (or representativeness), we can do more iterations.

At this stage, the most consuming features or applications can be identified.

Implementation of the budget strategy

Within the GREENSPECTOR interface on the Budget tab, you will be able to initiate a projection of autonomy:

You will be guided in the budget configuration. A first step is to specify the autonomy you want to achieve. If you’re on a fleet of devices, you probably want your user to have at least 9 hours of battery life to finish the day without recharging the phone.

GREENSPECTOR then offers you the possible steps of the scenario. They come from the measurements you have done previously.

The most complicated step for you now is going to be to specify how many times or how long you want the action to happen. For example, we use 30-minute target durations, so you have to enter this data for each step. No worries, this can be changed later.

You can then validate and let the algorithm calculate. No time to have a coffee, the results of the projections are immediate:

Analysis of the results of the algorithm

The first warning in the window means that the projection of battery life according to your scenario and the real measures allow to say that the autonomy of 9 hours will not be respected.

This information is found in the projection graph:

  • The 1st bar is the available capacity of usable energy over 9 hours: The capacity of the Samsung Galaxy S7 phone is 3000 mAh.
  • the 2nd bar is the energy distribution (the unitized bugdets) by functionality if you want to respect the autonomy.
  • The 3rd bar is the consumption projection associated with real measures.

It can be seen, the actual measured consumption is 3300 mAh while the capacity of the phone is 3000 mAh. We will see below what to do to correct this.

The notion of unit budget appears on the graph and on the right-hand side. This is the ideal distribution of energy consumption on each feature to respect autonomy. Here are the main principles of the algorithm:

  • To stay close to a real use, the algorithm adds a period of inactivity that corresponds to what the user would do between his actions (Idle foreground)
  • A deep sleep period is added which corresponds to a long-term inactivity of the phone (Idle background)
  • The idle periods that you will define (for example an idle corresponding to a lunch break) will be associated with a budget that is based on the reference consumption of the phone
  • To the actions, will be assigned a budget which corresponds to a maximum consumption of x2 the reference consumption.

In the end, the unit budget of each action is the amount of energy that a unit action must not exceed. Like that, you can check against the actual measurement if the action consumes too much:

We see here that the consumption of navigation is important and exceeds the budget. This feature contributes to the lack of respect of the desired battery life.

In the end, you can analyze the data outside GREENSPECTOR and for example visualize the battery discharge curve:

How to obtain a correct autonomy?

A first axis is to replace the phone. Indeed, you can choose the wrong device for your use. Ideally, the projections of autonomy will make it possible to carry out a benchmark to avoid a change too late.

Then maybe the scenario isn’t enough realistic. It will then be necessary to rethink the use: is the video conference via mobile really viable? Unfortunately, this approach is generously dismissed because we always want more digital service on the devices. The following approaches will then be more appropriate.

The unit budget will be useful to apply a better strategy:

  • On system applications (camera for example), we will study the possibility of setting the application differently to find optimizations and reduce consumption to stay within the defined budget.
  • For other applications like browsers we will be able to benchmark alternative applications. It’s likely, for instance, that videoconferencing solutions aren’t all equal in terms of energy consumption.
  • For applications developed by a third party and you master, you can incorporate a criterion in the specifications to meet the desired budget.
  • Finally for applications or websites developed internally, you can integrate GREENSPECTOR and budgets in the software factory to optimize the consumption of your applications as soon as possible and thus detect energy and energy problems. performance before your users.