The most common solution is to calibrate the % reporting, commonly called battery calibration, by running full discharge and charge cycles.

A full discharge cycle is achieved by using the device until it shuts down by itself. It is then required to attempt to restart it unplugged until it won’t restart at all. This determines the real 0%.

A full charge cycle is achieved by charging the phone past the 100%. Charging for 12 hours is one way of doing it, charging for 2 hours past the 100% another way. This determines the real 100%.

However it has been noted that many phones stops charging as soon as they reach 100%, but such phones usually report accurate % in the first place as they use a very different % calculation technology.

Doing one discharge + one charge cycle usually improves % readings dramatically. Doing those cycles a couple of times can also improve it further.

If no improvements can be seen from those cycles, you might be using an extended battery on a device not supporting extended battery properly. Then you can enable the ‘% based on mV‘ in the calibration settings, though it’s only valid if the mV reported by Android OS is consistent.

For years Google has added restrictions to app running in background, to improve battery consumption, is it successful?

I ran tests with and without task killer for the purpose of verifying this in a real use case, no fluf, no bs.

See the results after months running with and without a task killer (click on screenshot for full-screen):

Look at the avg. on-off line, it shows average run-time when screen’s on or off. 9 hours vs 7 hours, 7 days vs 2 days. Active task killer is a clear winner here, no doubt, no discussions possible.

The process of calibration helps maximize battery life by ‘teaching’ Android the maximum % and voltage range supported by the battery.

This will ensure the longest running time on battery and enhance the life of the battery.

How to to calibrate my battery?

The calibration process does not require any application! It’s a matter of running full charge and discharge cycles. An app can definitely help though!

A full charge cycle starts at near 0% and ends at 100% when the battery is not charging anymore (usually one hour to two hours after reaching 100%).

A full discharge cycle starts at 100% (best after a full charge cycle) and ends at 0% or more realistically when the phone shutdown by itself and it becomes impossible to restart it without plugging it in.

What can I gain from battery calibration?

Simply said, without calibration a device might shutdown at 3% or charge upto 99%. After running calibration a few times it will shutdown at 1 or 0% and charge up-to 100%. Tested on an Iconia A500 and a HTC Sensation!

How can Battery Monitor Widget help calibrate my battery?

The app can help set an alarm for an actual end of charge, and also measure the % and voltage ranges.

It will then measure the aging total battery capacity from a starting value (usually the device’s specs).

How to use the Calibration screen?

You first need to run some full charge and discharge cycles. At least from 100% to 3%. It is best to run the cycles until the % and voltage ranges are maximized. This screen can be used to check range evolution over time.

Once the ranges are maximized, this can be used as initial real-life specifications (which may slightly differ from manufacturer’s specs), except the actual battery capacity which usually follows specifications.

Over time, the calibration screen will provide information on battery aging and it’s new total capacity.

Please refer to that page for more details.

An example?

Let’s consider an example with a HTC Sensation device. A battery having a voltage from 3200 to 4200 with a capacity of 1520mAh. That’s the manufacturer’s specs but real-life shows it’s different (for every phone).

On that phone I initially got a voltage ranging from 3353 upto 4206, capacity from 3% upto 100%.

After 3 full charge/discharge cycles ranges went to 3170-4212 and 1% upto 100%!

If in the future voltage ranges from only 3230 upto 4196 (as it happened with an old HD2 battery), then the actual capacity will be reduced accordingly.

Battery manufacturers make battery safe range from 2800mV up-to 4300mV, while it’s considered empty at 3200mV on Android (that’s kinda 40% remaining capacity). So going there won’t hurt any battery (well, no guarantees obviously).

There are 2 factors that degrade batteries:

1. Batteries have limited cycles, so the more cycles the sooner the battery will age, deteriorate or even die.
2. Charging and heat are not welcome either for batteries. Above 70%, heat accelerates battery aging.

The second factor is often dealt with by manufacturers by offering an option to limit the maximum charge level while plugged.

This is what the Battery Life eXtender mod from XDA member Ezekeel is all about!  And 3C All-in-One Toolbox allows you to configure it when available in your custom kernel, see here for more information.

For more information on how to extend your battery life, here is an interesting Wiki (see battery life chapter). 

The important points are those:

-Keep battery cool, and avoid charging past 70% while using the device possibly causing over-heating.

-You can discharge your battery fully (voltage going down to 3200mV) it won’t hurt as 3200mV is the safe threshold mentioned in the Wiki above!

Android Firewall requires specific support from the Android kernel. If not implemented, it will not work.

Most custom Kernels do implement required support for IP filtering, eg the Firewall.

Since Android 10.0, apps that are not visible are considered unwanted and killed even if excluded from battery optimizations.

Additional steps required for Android 10+.

This may also affect unlock keys APK which are prevented from being used by their main app counterpart to check for feature unlocking. In case of doubts, open app UI, open left navigation panel, settings (at the top) and select battery optimization. From there, find the app and exclude it (not optimized).

Please note that many manufacturers are modifying this mechanism with their own, and apps cannot ask for exclusion from such, it must be done manually.

If the above and below for non-stock Android, are not enough to keep app running, please send a support request from app settings, help and support to get help with this issue.

You will find below, information for OnePlus, Samsung, Sharp, Huawei, MIUI 10, 12 and Realme XT devices.

For Oxygen OS (OnePlus devices) please refer to this page to exclude the app and the unlock key from any optimizations, here are screenshots showing where to find that option.

For MIUI 10, the following screens show how to manually disable those restrictions. There are actually 3 options that can be enabled, battery saver, autostart and in other permissions, possibly to be started by other apps.

For MIUI 12, the following screens are also available. Please select the app and prevent battery savings.

The following screens show the same on Samsung devices.

The following screens applies to Huawei devices

The following screens show the same on Sharp devices. Realme XT devices requires an extra step shown in last screen on the right.

This results in apps being killed, and often not allowed to restart even if those are excluded from OS optimizations.

• In such situation you need to add a notification shorcut (app’s settings, notifications, options at the bottom) to tell the OS the app is visible.
• An alternative, some users confirmed working, is to add the overlay widget from app’s overlay widget settings.

Multi-variant packs can have a variant selection and an actual preview beneath it.

Options replaced by Android notification settings on Android 10 and above:

• Keep alive
  • Prevents (as much as possible) the OS from killing the notification pack process. This helps reduce unneeded process restarts.
• Hide icon
  • The icon will not show in status bar if enabled. The icon and notification remain visible in the notification list drop-down.

Standard options available on all versions of Android:

• Enable graphic
  • Shows an historical graphic instead of the detailed text information. The width determines the visible historical range.
• Show legend
  • Adds a legend on the left of the graphic showing min/max values.
• Width
  • Width used by each historical data. The larger the width the less points are visible. 
• Graphic, background and icon colors
  • Select the histogram, its background or the right icon colors, including transparency.

The governor is the algorithm used to control the CPU frequencies between the defined minimum and maximum frequencies. It is always possible to change those min/max frequencies, but the governor will decide how to regulate it between those min/max, and it may well change those min/max frequencies on its own (very likely).

Each governor offer a set of options which can be changed in CPU governor tab of CPU manager.

Here is a list of most used governors and how they control CPU frequencies:

• Performance: frequency is always set to the max frequency. Maximum battery usage
• Powersaver: frequency is always set to the min frequency. Minimum battery usage
• OnDemand: frequency raises when CPU load (%) goes beyond a threshold and decreases when it goes below another threshold.
• Interactive: same as OnDemand except it automatically and slowly decreases back to min frequency. Usually consumes more than OnDemand.
• Hotplug: Only available on some phone/custom kernels with dual cores. It is used to turn off one of the core when load is below a given threshold.

Note that custom Kernels or manufacturers can predefine various thresholds and even different governors than those above.

Usually the OnDemand and Interactive thresholds can be set (in the boot settings of the  app).

Best and most used up-thresholds for OnDemand is 65% and 25% for down-threshold.

The Interactive up-threshold is also mostly set at 65%.

Raising the up-threshold will make the device less reactive. Raising the down-threshold will keep device responsive but consume more.

Another factor is used with this 2 governors, the sampling rate, which is the rate in micro-seconds to check the CPU load. Increasing the value decreases responsiveness and vice-versa. Custom ROM mostly set this value between 10 and 15 milliseconds.

To get CPU temperature information you will have to send a request from app settings, help and support, mentioning your issue (no message no reply), and the list of files under /sys folder containing temp in their names, and possibly their content.