Collect battery life improvement tips for knowledge base

Falco shared this idea 1 month ago
Collecting votes

Locus developers spend a lot of effort to save every milliamp hour of power. We did reach optimization levels where complex solutions will only safe less than 0.1% batter life per hour.

But what is happen on user devices? Most of us don't know the tricks to save battery life and we waste up to 100 times more batter life then new locus optimisations will gain us.

We should collect tipps for better battery life to appreciate all the optimization effort of locus developers. Otherwise our careless handling of battery power will disrespect the optimisation effort.

There are even some important locus features to help improving batter life and most of us don't know about them.

I will start with the following tipps:

  • benchmark battery lifetime with locus on custom roms. I got hugh margins across android versions. With full LCD power I got track recording times from 4 hours to 8,5 hours. Up to 100% Battery life improvement just by using a different rom! Unfortunately the older unsecure roms perform best

  • Try to avoid using SD cards, they are rated around 200mW/h and sometimes they don’t get into a proper idle state (I didn’t prove how much % batter life gain could be expected here)
  • Keep plane mode on and use offline routing, because some roms have problems to enter a proper mobile network idle state
  • Disable wlan, nfc, bluetooth during navigation because you only rarely need them on tour
  • try to reduce screen on time by using locus screen activation/deactivation features
  • use sound alert or voice navigation to reduce screen on time even more
  • Bt gps devices produce better signals with same amount of current like your internal gps because the have larger antennas then your phone. (BT communication signals take way less current then your phone gps and if you would, you can avoid locus track recording and track with an gps logger, locus can disable unused BT connection during screen off time to save even more power)
  • Keep your system clean especially if you have an old android version. Older systems have better battery lifetime but worse background activity management. Which means a phone with many apps will lose the benefit of a small, old, but very efficient operating system. Maybe you should consider using a 2nd phone setup for offline usage without any installed apps. An old android system isn’t recommend anyway for online usage, which means it will make even more sense to setup a navigation only phone if you want to achieve up to 100% batterylife improvement by doubling your screen on time. By the way if you are alone, In case of an emergency it make sense to have 2nd phone anyway because you may break your exposed navigation phone during an accident.

Does anyone have any other tipps to add?

Best Answer

On of the first points should be an effort based compareation, maybe as an introduction:

"Most of the following battery lifetime improvement tipps just save arround 10 to 30% battery life and take alot of effort to apply. Think about investing into a powerbank to get much more battery life before you spend your time on complicated battery runtime benchmarks."

Comments (85)


"Magic One Click"

This feature saves work one to two hours per day!

Of course, it is also of great importance to save battery!

We search for and optimize ON / OFF display, GPS, etc. and you are trying to save minutes.

Here are hours!


Condor and his dream :).

Anyway, we have a small topic in docs already: . It is more about performance, but it's close to battery saving.

Thanks for nice tips! I believe that Michal, who take care about our manual page, should improve this page to some "Tips for best performance & battery saving" and add useful tips we find in this topic in short & clean presentation. Michal? ;)

Jiří M. aka Menion



Yes, I understand your fear of such a simple and revolutionary change and progress Locus ;-)

Programmers work long hours to save the people for a few minutes. This requirement is the exact opposite! ;-)

If a dead and dysfunctional add-on 160L, then how much could my design cost?


And I've also found a mistake here now. I'm writing there ;-)


I did my ROM Benchmark on 2D satellite view to monitor that nothing got turned off by Android power saving modes and did find out that older ROMs keep CPU on lowest possible power all the time which did result into a consistent current flow. Background services of newer ROMs ware not able to hold lowest possible power cpu power state and create a lot of spikes in current flow.

I know the performance FAQ, locus performance considerations should be on point 1 of battery safing checklist because I would expect large margins of battery life if I test a proper map rendering with complicaed vector styles and many overlayers. I didn't use map rendering for ROM benchmarking because there is no way to create reproduaceable test setups with real GPS data.


This is correct (test environment). That's why for these cases I use NMEA simulation where I'm able to play exact situation again and again. Probably similar like mentioned "Lockito" by Condor (never tried it).

Seems that this method is missing in our docs, but try this:

  1. record a track with Locus and have enabled settings > GPS > NMEA recording
  2. find recorded NMEA file in Locus/data/nmea directory
  3. copy this file into Locus/cache/nmea directory
  4. open Locus and in the top menu of GPS screen choose > GPS simulation > NMEA

Since then, an only fourth step will be necessary of course.



I've never been able to get this done. Locus has always stayed "standing" in one position. That's why another app.


Never, really?? Try my most used NMEA file ... few years old bike trip from Prague with my wife ;)


When we added simulation, we talked about it. You were looking at the cause. Your answer was: The NMEA file is too much! (about 300m of record).

We will not go looking now in which topic it was.

Since then, I have started using another application for that purpose.

Searching for Locus forum is awful ... But I'm looking for your answer......


It is impossible to find it........

And exactly in this topic I wrote you:

"It would be great if the Locus simulation worked just like Lockito"


But it does not matter....

These and similar functions like heart transplants in the fitness center I do not use in the map application ;-)

I'm worried about map and POI features and geocaching and navigation :)

And of course the removal of thousands of unnecessary nonsense clicks.


No Way!

Glad that I have my whole tracking data based on NMEA files downloaded from my GPS logger. Now I can replay my whole outdoor life :D

It does work great if I use my GPS Logger NMEA data which have enoght fields to be used in simulator.

By the way, if you don't record to much NMEA fields you will just need 18mb NMEA files for 100.000 points

I did allready thought about fake gps but was affraid how much effort it will take to setup an actuall track to check the expense of map shades and vectore themes. In worst case they are so expensive that it should be considered to setup a lightweight navigation map and use the full loaded map only for planning, well we have enoght quick button features to do it, but is it worth to setup it up like this? Let's find out :)



Finally serious analysis and constructive thinking!

I look forward to results and suggestions and solutions.

Thank you for all.



Yes, simulation works today OK!

I also found a specific NMEA file on which I tested 21.02.2018. The one I sent You, which you said was too big to simulate. (536.6 kB).

I remember that you wrote to me that the simulation is primarily intended for static fitness exercises in the fitness center to work with sensors.

After this answer, I am no longer interested in this feature.

And that's exactly what I'm referring to (about this) on my lectures too.



If I correctly understand you for repeated simulation, "Lockito - Fake GPS itenerary" is ideal.


Results for hillshade:

with powerfull devices like Sony Z3 Compact no battery lifetime change between hillshade off and on for navigation on a 10 hour long cycle tour simulation with 2500hm uphill and 2500hm downhill. Results are in margin of error, one run with 3% improvement and one run with 2% degration.


An interesting result. Hmmm...


Would be another story on slow devices or with many manually scrolling through the map.


Hmm, I'm also surprised. Hill shading is another bunch of quite complex mathematical computations, so I expected that increased CPU usage will bring higher battery usage. But seems that CPU is marginal compared to GPS & screen battery consumption. Nice, thanks.


For me there is a lot more limiting factor in the temperature of the battery (devices) in the summer. I finish at high temperature and protect the charging. Powerbank only supplies the device for work.

There were situations that demanded a robust solution :D

(And I know the consequences for the battery)


GPS was off during simulation, which means more CPU weighed results. But screen was set 100% and old battery was used to shorten the test to 10 hours.

Normal outdoor use would be arround 12 to 20hours for my device. It's exceptional that it does manage to handle 22hour of wlan surfing or 24h video or 43h idle screen on time with min brightness and all this only with 2600mAh :D


I did select the most mountainous region I have with many small canyons and my prefered zoom level 16 with 150% magnification. As expected 80% of the tour doesn't show many hill shades on screen on navigation style zoom levels and 100km track with zoom level 16 doesn't have alot of hill shade tiles to handle. At least not a considerable amount for 10 hours screen on time.


The reason your length of time is Quad-core.

My Octa-core can not do more than 8 hours of full work.

The sons of the dual-core device have the same 14-20 hours of work.


with locus only it does disable 3 of 4 cores. And even the one core is sitting on lowest possible clock speed (300mhz) nearly all the time. Here you will find a problem with bloaded ROMs. My Z3 compact does enable more 1-3 cores on bloaded roms.

Tipp: use 2 Phones, one with perfect navigation capabilities which can be even more tuned by the use of older ROMs and use a more recent one as daily driver.

I use 2 devices anyway during trips without friends, because I need something to call emergency service if I will have an accident and my navigation phone is very exposed, a hard crash will have 10 to 40% chance to break my navigation phone.


I'm carrying a son with a cellphone :D And for long trips I have a spare Outdoor Hammer phone with the endurance up the moon.


Most people don't need to apply any battery safing tipps because they can just invest 100g to 200g mass in a power bank to gain 100 to 400% improvement.

In most cases tough outdoor phone users are not interested in battery safing tipps if they don't improve at least 30% because they care less about equipment weight. But if you replace your glas backpannel with a much thinner carbon back pannel and remove all cameras to save 10% of phone weight, you will care alot about 10% more batter drain because all the weight improvement effort will be wasted by a too large power bank.

You may think which crazy people spend so much effort to save 10g? Ask competitive sports people like cyclelist who spend 1000$ and more to save just 1000 gramms of weight on the equipment. Non of them will use a tought ourdoor device :D


@Menion do you remember the first line of the topic:

We did reach optimization levels where complex solutions will only safe less than 0.1% battery life per hour.

1000s of operations doesn't drain nearly anything on todays mobile cpus, if we doesn't make mistakes where we loop such things, we don't have much to worry about cpu battery drain. CPU wakeups, cpu clock (voltage) raises, wireless signal senders/receivers, screen on time and external hardware like sdcards, usb (OTG) are much more hungry then locus core usecases.


I have another tipp:

- if you have to use screen lock because your screen does take false inputs because your display is sweaty. Clean the display because many phones will raise the cpu clock speed on touch to give user snappy experiences. For example all ROMs for my Z3 Compact do raise CPU speed from 300mhz to 1500mhz on touch.


And another tipp, inspired by @Condor powerbank temperature management setup:

- care about your battery temperture range. For example a cyclelist you will have to deal with to cold battery degration.


runtime with 30°C battery 8 hours (20°C ambient at home, 4 runs average)

runtime with 45°C battery 9 hours (35°C ambient in car, 3 runs average)

don't have benchmarks with 20°C because I would need to aircool it on my bike but didn't have reproduceable loads for benchmarking during tour

I guess arround 35 to 45°C is the sweat spot because everthing below has worse results and will matter more then most of the tipps and tweaks. But ambient temperature, airflow and insulation is much more difficult to adjust which means you have just to life with it and keep an eye on the other ways to improve batter life.

The problem of cyclelists: it's way to much airflow and the load of the CPU and battery is to low to heat it up. Even without any airflow on my testbench it does just add 10 kelvin. On cycle the battery is always dead even with air temperature and perform alot worse then on my testbench :(

Phones does work much better if you hold it in your warm hand.


On of the first points should be an effort based compareation, maybe as an introduction:

"Most of the following battery lifetime improvement tipps just save arround 10 to 30% battery life and take alot of effort to apply. Think about investing into a powerbank to get much more battery life before you spend your time on complicated battery runtime benchmarks."


Results for Vector:

Openandro Maps MTB Theme vs raster map on 2 devices Z3 Compact devices

10 hour run: 10-13% less drain without vectore map on magnified tiles map with zoom level 12

But you need an external SD card to hold maps as tiles for zoom level like 16. Will an SD card map consume more power then realtime CPU rendering? Maybe sd card read only doesn't consume much? Only one way to find it out


Here my vector + hill shade GPS simulation cpu frequency usage after 22 hours screen on time and with 50% LCD power. 35 to 40 hours screen on time is easily possible with just 2600mAh without GPS or BT if you don't go full beans on LCD brightness.

Well done Locus team, that's just impressive!e3381865b8f85f8039736e80a7ecf909

Stay tuned for my SD Card map tiles results. My testbench is does corrently contain three Sony Z3 Compact devices for best average results :D


Test Device A (less stable results with android 6 background services)

Vectore with Openandro MTB Theme: 7:55 and 8:25

Zoom 12 tile map local flash: 9:00

Zoom 16 tile Map SD Card: 9:35

Device A has a stronger battery then Device B because it get more android 5 screen on time then Device B, but sony's android 6 is just wasting it, CarbonRom marshmallow isn't better either ;)

Test Device B (more stable results an android 5, because less random battery waste by background services)

Vector with Openandro MTB Theme: 10:10 and 10:20

Zoom 12 tile Map local flash: 11:25

Zoom 16 Tile Map SD Card: 11:35

No difference for SD card map reads

Maybe Z3 Compact has a proper SD card handling or SD card read operations are much less expensive or there is some caching involved. (my test database with zoom 16 tiles for the 100km GPS simulation is only 100mb small)

change the tipp "Try to avoid using SD cards, they are rated around 200mW/h and sometimes they don’t get into a proper idle state (I didn’t prove how much % batter life gain could be expected here)"

to: "Benchmark how your device handle Map access from SD card, they are rated around 200mW/h and sometimes they don’t get into a proper idle state, but normaly you should not expect any benefits by avoiding SD cards"

and move it to the last place of the collection of tipps

My main device, the third one, is still busy with lightweight BT GPS NMEA sequence battery tests


Good day Falco,

thanks for amazing tests!

Seems that vector maps make really a difference close to 10%. Did you test it on a bike? Just asking because average speed = frequency how often Locus have to load new tiles. In the car at zoom level 16 it will be a lot more then on bike.

Also ,you compare same devices with Android 5 and Android 6. Age and usage of batteries in these devices is similar?


Openandro MTB is really expensive, my old Samsung S4 mini did even strugle to render tiles in realtime.

Compared to GPS it doesn't matter much. But 10% for comparing the most expensive vectore theme with tile rendering is at least worth to mention.

The Testcase is a 2500hm MTB Tour ( but with lunch break and travel to trainstaition, in summary a average large distance MTB tour which should be a common usecase

Here some details about my NMEA simulation

I can't compare it to road bike or car because:

- car and road bike are faster but will have less tiles per kilometer because they use other zoom levels

- car and road bike vectore themes are less demanding then MTB themes

I really don't know if they are more or less demanding.

My Android 5 to 6 compare was done on same device, don't compare device A with device B because it's not the same battery and not the same LCD. Device A and B is used to double the amount of runs to get better average % values.

I guess we can't provide any numbers about Android battery performance because it's highly dependend on preinstalled services and cpu power management.

I will try to create a common assumtion:

Normaly you will have 0 to 20% improvement between ROMs of different android versions

Normaly you will have 0 to 10% improvement between ROMs of same android version

With Bloaded stock roms you could see 10 to 50% improvement with tuned ROMs

And if you compare the worst bloaded ROM with the highest demanding android version with the best possible outdated custom rom and the best tuned profiles, you will may see up to 100% improvement.

Android tests are highly device related and even ROM patch version related.

I can only tell that you should test Android 5. Sorry @Menion for this recommendation, I know the pain of old APIs. I would even go so far and stay on an outdated locus app version to keep my battery lifetime ;)

Here is a recommendation test order:

Baseline with corrent ROM - 2 runs

Android 5 vendor A - 2 runs

Android latest - vendor A - 2 runs

Android latest - vendor B - 2 runs (compare to vendor A because latest unofficial roms could have battery drain bugs)

repeat testing searching for a less recent but more tuned ROM, use Android 5 runs as baseline

This order is painfull because for downgrades and for rom vendor switch you may need to use different custom recovery versions to flash them. But 2 runs with 10hours each is will slow down your testing anyway.

Don't mix hardware and check the battery voltage and temperature because temperature and discharge cutoff/charge cutoff voltage will matter more then backgroundservice battery drain. Don't use new parts for tests, 200 hours stresstesting isn't good for your battery and screen. Be carefull with OLED because you may have different colors between costom roms which will change OLED screen power consumtion. Maybe min brightness could be a tipp but would be painfull to test because you will get crazy long runtimes.


I do plan to adjust the low voltage cut off. high voltage is already maxed out with 4,35V, I don't want to blow up my battery with 4,5V. But I will change the already good low voltage cut off from 3.2 to maybe 3.0 or even 2.8. This is less dangerus but will kill the durability of the battery. Not recommanded! But maybe worth it ;)

Cell will fail below 2.5v and if the android shutdown isn't fast enogh or will drain to much power or if I forgett to carefully charge it back to 3.0 at soon as possible it is very likely to weare out crazy fast. Target hight performance lifetime: 20-50 cycles, then it will get replaced after 1-2 years. This has to be the very last way to improve anything because it is a huge environmental waste. At least I hope the 25€ battery was made under fair working conditions.

I may have to think about tasker warnings for critical battery voltages if my phone does alow me to mod this important feature.

Unfortunately the amount of battery energy isn't worth any temperature management solutions, everthing would add more weight then benefit. it would be a lot more fun to build somethings which holds temperture or something which even heats it up.

Chemical soltions would be possible but one time usage solutions are just stupid from an environmental standpoint.


There is one thing which is a little bit difficult to understand.

All my messurements are based on 10 hour runtime.

Which means if my device is running 10 hours with no CPU load and vector maps will decrease the runtime by 1 hour, it will be only 10% decrease but does acutally consume 1000 % more CPU power.

For example my BT sequence tuning test did only save 5 to 10% (2nd run is still running to tell if it is 5% or 10% because I have up to 5% messurement errors and need multible runs to get correct numbers) but did actually improve BT consumtion by 30% which will get very usefull if you have less demanding work on your phone (no internet, medium screen brightness, no interaction with other apps). I did exect 50 to 90% less BT power because I did reduce data amount by factor 10 but this didn't happen.

But I still guess 10 hour runtime target is a good common baseline. If you have more runtime you would benefit much more from the safings. Otherwise many people are working with less then 10 hour screen on time and need to turn display off to be able to at least record the whole planed track.


I'm starting to lose in your analyzes...

They are very scientific. (The problem is also my English).

Not just me, we need simple answers - the result.


The Vector map has less power than the Raster.

External GPS (BT) consumes XX% more.

Determine GPS consumption (approx.). According to this, we know how much you can save on automated GPS On / Off.

What is the difference in the display 80% or 100% (In the summer outside we could even survive to 80%) Is that important? How much.

And so on...

Such answers and results are enough for us.

We can all understand.

Thank you for all.


External GPS (BT) consumes XX% more. is dependent on the load of your system.

Here an example:

If you need alot of brightness and mobile network for livetracking your device would only run 10 hours. If you have no background services, didn't enable any wireless services and use only 50% screen brightness, your device will run 35 hours.

Now lets add GPS

Power user 10 hour will drop to 7 hours

efficient user 35 hour will drop to 14 hours

which means, 30% more consumtion for power users but 60% losses for efficient users

Why does this happen?

Here example numbersfor easy calculation

700 points energy is available and we need 30/h for GPS and 70/h for all other consumer = 7 hours

700 / ( 0 gps + 70) = 10 hours power user

700 / (30 gps + 70) = 7 hours power user with GPS

700 / (0 gps + 20) = 35 hours efficient user

700 / (30 gps + 20) = 14 hours efficient user with GPS

How should we define the power saving in %?

I would suggest 100% Screen + 0% background CPU load + 0% wireless signlas:

  • it's commun for outdoor usage to have much screen brightness, old tough phones with less background services and no mobile internet usage
  • It would be equal with people wo have a litttle bit of background CPU load and a alittle bit less screen brightness or equal to people with much less screen brightness but little bit of background cpu and mobile services

I did think about power management sensor readouts for subsystems. You could get power consumtion per Screen, GPS, CPU, and wireless services with special apps or direct over ADB, but I don't trust these values because they are highly dependent on the used sensors and the used data to translate the readout to energy values.

Do you have any suggestions or Ideas for the summary? I didn't create a summary like this because I can't hide the context of my results to give valueable results.


What is the difference in the display 80% or 100%

that is highly device dependend, some devices scale linar other degressiv or progressiv.

80% Brightness on linear Device A consume 80% power

80% Brightness on progressive Device B consume 70% power

80% Brightness on degressive Device C consume 90% power

If we map these results with power user and efficient user we will have 6 different results.

Power user does use 50% for Screen and 50% for other services

Effeizient user does use 100% for screen and 0% for other services

Screen dim from 100 to 80% does save between 5% and 30% power. And this range is based on known power draw of the screen. I can't give ranges for GPS because I don't trust power management readout for GPS sensors because who know who many GPS related components are not messuered by the current sensor? Only the total runtime is the truth and unfortunantly we do mix all consumers there.


I like your work hours numbers 20, 30 40! :D

My device (HTC M9 - 2840mAh) did not last for more than 6-8 hours. NEVER. (Full use 3-4 hours)

I like to stay out with + powerbank 16,000 mAh (real mAh) 8-14 hours.

And all this I have to do to keep the unit temperature below 46 ° C (Safety Disconnection Charging Limit)

So all numbers over 20 hours are beyond the bounds of understanding for me and my friends (different High end devices).

We all use powerbanks 15-30,000 mAh.

Only my son has 5,000 because he has only a dual core device.

We must use this (plus saving measures) to survive in the field from morning to evening.

So the only question is for us:

What can we do differently (better) in order to extend the battery life of 1-2 hours.

For the concept of use:


live streaming online wifi 50% display

8-12 hours. No problem for some devices even more.

Real use:

display 30-60% under out light conditions. In the summer 80-100%. Whenever possible, the Off display (typically 60-120s auto off display), GPS, GSM, Data, Locus, (no recordings of the route!, If yes, then -2 hours), Navigation / guidance, inevitable android system, occasional - internet browser, live map, POI notif, camera, all other kill app, process.

4-8 hours (subject to availability of GPS, GSM, etc.)


6 to 8 hours with 2800mAh

And 10 000mAh power bank usage 8 to 14 hours, I guess the power bank values are for full use but even then it does not match.

I mean, 14 hours for 14000mAh?

I hope this wasn't in flight mode, because I can't imaging 1000mAh drain without using games.

If you need mobile internet, you should check multible ROMs, like suggestest in one of the first points:

  • first try with a factory reset because most of the times you will have a bad app on your device
  • and then go on with other ROMs to check how these do perfom
  • could solve mobile network idle power consumtion issues
  • could improve CPU power management (very importand for high performance CPUs)

Ok, wait a minute, I did just consider to look at an review to find out that this isn't far of the delivered condition.

You should get up to 13 hour with 1% brightness and flight mode. And 9 hours with medium brightness and WLAN browser usage.

Lats say you did realy hurt your battery, you can calculate 70 to 80% (10 hous idle and 7 hours wlan)

I don't know if this is a software issue, but on the other hand, it can't be a hardware issue.

The Data sheat confirm it, you should get 25 hours 2G talking time. Which means there is an software issue or your display does drain your battery very hard even with 1% brightness.

Try to check this before you switch ROMs:

  • use flight mode and only enable GPS or BT GPS
  • Record a Locus Track with display off
  • Record a Locus track with display 1%

If you get 30 hours recording time without display and 10 hours recording time with display, You maybe have a Display which doesn't dimm the background enogh and use to the LCD cristals to make the screen more dark.

If you make display benchmarks, it would be enoght to monitor current flow in mA over an hour and calculate the average of the low values.

This give me an Idea to check for Software vs hardware issues.

If you have very consistenz current flow +/- 50mA you have an hardware related battery drain problem because your power consumtion baseline is high (or you have just to much background services to see any peeks :(

But if you have peeks with 150mA or more difference than there is clearly something going on in the background which could be fixed.

Make the 2 hours current flow test with flight mode without GPS and the empty locus 2D satelite screen first I do use which is a bad tool compared to others, but I'am just familar with it. You get an table with history data of your locus testrun with 10%/h values, and if you click on it you will see 284mAh/h


Thank you for the answers.

The times were ... when I played with ROM. I do not have time for that.

The battery is new I changed a month ago.

In the standby mode (night when sleeping) the drop is less than 1% per hour (3-5% in 8 hours) that's OK.

It's not just about my device. We use Samsung S7, S8. Note 8, Lenovo, Experia, Xiaomi, etc.

If you ask for a game. My son M9 will be eliminated in 1.5-2 hours at Rael Racing 3. If he does not stop the device protection + 51 ° C

Did you ever see geo Cacher without a powerbank cable?

I'm not yet :D

Outdoors with Locus, I have power consumption of 1300-2000mA. In a quiet state without Locus (and all GPS etc.) 120-250mA.

So, our use of the device is about 10x higher than that of a conventional user. Or 5 times larger than a manager with a lot of calls, email, internet, apps.

That's why my (and my friends) questions.


My old HTC Desire 500, custom ROM

for 5 years of use:

3 x battery

1 x power supply module

2 x mainboard (including power module)

This is how the geocacher device works.

Yes for vacation if I do not use Locus (Without Geocaching)

without a problem, M9 will last for 2 days.

If I did not use Quick Charge (also powerbank QC, car charger QC) so at work I do not have a chance to recharge the battery by more than 10% per hour. QC is about 30% per hour.


Maybe you should select phones with better hard and software setup if you don't have time to figure out if this is a hardware or software fault.

I do only have 3x S4 mini and 3x Z3 Compact and did start with an ipod Touch 3G.

S4 mini get 12 hours wlan surfing with medium brightness out auf 1600mAh and get 20 hours idle

z3 compact does have nearly double battery and get 22hour wlan and 45h idle

HTC Desire 500 did get 14h idle out of 1800mAh and 8 hour wlan which is already 50% behind.

your Samsung S7 should get 30h out for 3000 but don't open the browser, it will kill the battery after 7 hours, maybe a software issue because S8 get 28hour idle screen on time and 12hours with browser out of 3000mAh. Halft of the energy is somewere else used if you compare it with my devices ;)

Note 8 same like S7

It isn't normal that all these devices can't reach S4 mini or Z3 compact. Even my 2009 ipod touch got 5 hours out of 800mAh which is nearly as much as S4 mini.

There are some stupid things going on in 90% of the android devices.


But by the way, android 7 and 6 did destroy my s4 mini performance, it's still my dayli driver and I have to say that they aren't as good as 4 and 5. But I need the features on my daily driver, so I had to pick a spezial navigation device setup where I don't need mult window or multilangueage keyboard switch and where security isn't that importand.


Yes it is ... stupid android process.

And I have an uninstall or ban 70% application (from manufacturer). FB, Skype, Massenger and all this ballast I do not use.

Yes my old good HTC p3600 Trinity (2006) has endured a full load day.

The car holder (packaged) is so robust I use it today! He survived and resisted 4 cars and 5 telephones.

But it is 2018 and we must live with what is available and usable.


"I have power consumption of 1300-2000mA"

Why? With or without mobile data transfer? Please make a baseline test without anything and 1% brightness I guess you did miss a very hungry process or you have just a bad mobile connection and some processes which try to squeeze through the bad connection.

Mobile data is pretty much unpredictable and acces is really hard to limit because everything is allowed to ask for internet.


This is a graph of my normal day. Without Locus and GPS. If Locus and GPS are used, the consumption curve will be steeper than the charge curve.

I do not have a chart at the moment.


most of the tipps care about 20 to 60ma battery save per hour. You need to find the things which are draining 1500mA in total because you shouldn't have more then 500mAh if everything is on.

Mobile data is the one exception I know, just try a day without mobile data and without wlan.

If you will go down from 2000mAh to 400mAh you have found your issue.

Just in case internet is really the issue, it's easy to play with mobile data on/off, you can turn on mobile data if you do open a certain app and if you close the app it could be disabled.

Problem with internet is the slow processing of the requests and responsens, especially with bad connection. The phone will be 1-3minutes under load to handle little amount of data over bad connections where it would just take some secounds over wlan. And the baddest thing, this problem is happen in background while somethings is doing anything with internet which you don't even see because it's just a kind of data sync.

And you need a system wide adblocker especially if you have any free to use app on your phone, these stupid apps will load commercials over the internet.

I don't know where to start, there are thousends of things which could go wrong with your battery if you do have an active mobile connection...


If you turn off Internet, wifi, data, GPS and cellphone lasts a week :D

This is a wife case :-) 2 weeks


Ok, then everything is ok, now you have to think how you could optimice the internet usage because 80% is drained by mobile connections and 20% is drained by the other things. Don't try to save 1/10 of your 20% because you won't even notice the overall 2% improvement.

Try to half your data and cellphone based consumtion. This is even more importand if you don't have good signal.

For example if just locus, browser and one communication tool has internet access and you are offline all the time until you want to request something or until you expect an answer from anybody because you have an appointment with a person.

If you really need to be reachable all the time, use a 2nd device for availability because basic phones are much more efficient with mobile connections because there are no stupid background services polling for data.


These are not the answers we are looking for.

We are looking for a solution to what settings to use while maintaining the necessary functionality. Extend 1-2 hours of operation.

For example, not using raster but vector, off shadowing, Display off 120s, not using BT GPS but internally.

These measures and their relevance are important to us.

No way off data, off GPS, off Locus. This is not a solution ;-)


Internal GPS and locus and display does use 200-400mA, you can save 50mA there if you improve as much as you can.

But this wont help you to fix your 2000mA drain issue. Because you would have an 1950mA drain issue after the improvements :D


Yes it is a solution.

standard automatic measures:

We take these actions (in the afternoon) if the battery is below 40% data off, 30% switch to extreme save mode - auto off GPS, off GSM (or flight mode) at 15% to rescue mode - just GSM everything else off.


If off GPS and Locus then the device lasts for 2 days.



The solution (used by all Geocachers) is powerbank more than 10,000 mAh.

Without it, it is not going to be buoyant.

In my case, an auto-refrigerator with a supply of frozen cubes. To be able to charge the mobile at least to 40-50%

Thank you for the nice discussion and your advice and tests.

Stefan - Condor


I guess the 2 points:

  • Keep plane mode on and use offline routing, because some roms have problems to enter a proper mobile network idle state
  • Disable wlan, nfc, bluetooth during navigation because you only rarely need them on tour

Should go on top of the list with an an importand note "these could drain 50 times more current then each of the other power saving tipps could save you", I wasn't aware that these could be such a huge issue. It doesn't make sence to fight for every 20mA/h if somebody didn't limit the mobile services and waste 1000mA/h with background internet acitivties.

And yes I agree with you, mobile internet and cellphone management can't be part of an locus faq, it's just to complicated and way out of scope.

I can also confirm the huge current amound based on my S4 mini which will go from 30°C to 50°C if I have a bad mobile data signal and want to work 30 minutes with it. At this point I did just restart the phone because I did guess that something was broken. But your numbers tell me that this crazy battery drain behaivor could be normal...

Thank you for getting to this point, that will prevent that alot of people waste there time by improving the wrong things.

If I just think about the previous order, "ROM tuning on first place..." you would spend 5 to 10 hours of work and make 80 hours of benchmarks just to find out that the 100mA/h you did save don't even appear in the real world benchmark result.

For me, 20mAh is a big accomplishment because it will almost add 1 hours battery life for my average 240mA/h load :D


I have an idea, we could use mA/h values instead of % values.

I just need to recalculate my benchmark results. For example if somebody does read "tile maps instead of vectore theme could save 30mA/h" it would be more clear what anybody could expect.

The only problem is that I can't use real time values from current sensors. I did already find out that these current sensores are very inaccorat, at least at my Z3 Compact. For example for many of my 10 hour runs I got overall battery capacity result from 1900mAh to 2300mAh which is not less then 20% failure! And we can't messure 10% improvement if current sensore values are up to 20% wrong :(

And because I don't know if my old battery does have 1900 or 2300mh (but runtime did only change by 0-5%), That means I can't provide absolut values like:

Z3 Compact does use 200mA/h for internal GPS and medium brightness but 140mA/h without GPS. But I can tell based on the missing runtime that we have an gap of 50-60mA/h

Warning: all these mA/h of this example are fake and should just ilustrate the problem of current messurement.

And one more funny story, I did just find out that 2 of my 4 Z3 Compacts (I have 3 compleate ones and 1 spare motherboard) does have a broken GPS unit (no satelites after 20 minutes), didn't even notice that because I use always BT GPS :D Properly a worn out antenna pin, a common issue of this model.


I did already compare tiles maps with vectore maps based on Openandro MTB theme.

@Locus Team, do you have any statistics about used vectore themes? After I did 6 runs for me any my MTB Theme requirements I would like to add one or two common used vectore themes to my benchmark marathon.


Unfortunately, values about the usage of vector themes are not known to use. You may only expect with quite high probability:

Hike & Bike theme is set as default theme + most of the users (up to 80%) use Locus Map mainly on Hike & Bike activities, then the winner is ... Hike & Bike theme.

But do not expect any changes here. Most of power will be definitely consumed by IO operations and this is independent on the selected theme.


Is there any widely known OLED optimiced theme for vector maps? I plan to test OLED screen usage as well because OLED drains exeptional more power if you join max brightness with bright maps or bright dashboards.


To be true, I have absolutely no idea.

You are the first one I know, who cares with such perfection about battery/cpu usage, sorry.


Only theoretically could have a lesser use of the night mode vector map.


Where could I find it?


I just click the icon to the quick right panel ;-) OK. Moment.... I'm looking....

Menu, Seting, Maps, Advanced, Colored mod maps, ON


Ok, that is a a extrem change. I guess this could save alot on OLED. I would be not surpriced if there is about 750mW (200mA) to save.

But an inverted theme is maybe to much, at least I can't work with it. I did thought about a theme with darker colors instead of going crazy with deep black :D


My favorite theme at night (the only one) :-)

Besides Menion's left-hand buttons :DDD


Something like this would be much better

It will be useable but could easy save 50% of oled power consumtion.

But I don't find anything like this as vectore theme.


We would need to use watt instead of amps for accurate definitions, but because it's more easy to calculate with mA/h we need to do some math. Normally you would just use the rated voltage of 3,7 but because Android doesn't use the full range of the battery we need to calculate with 3,8v (Actually average voltage over all my readouts during drain from 4,35 to 3,3v is 3,83v)

Now a small storry about my latest test results

I did try to make my life easier by using tools which “calculate” power consumption of system components. All of them are fake because the values would be able to achieve with my battery.

I know how these tools work. They of only the following data:

  • Hardware information
  • CPU time per process
  • LCD brightness level
  • WLAN and Mobile working state and activity
  • GPS state and activity

If you map the Hardware information with the states of the system processes you could calculate power consumptions.

And Now I will tell you what did happen on my Z3 Compact, the app didn’t know it very much and did use some common values for power consumption.

For example, the app did look for LCD 4.6 inch and got me the following power consumtion map:

287mw for 0% (was set with tasker to get below 9%)

900mw for 100%

Let’s think about the 287mw, battery does have have 10.500mW/h if you drain it from 4.35 to 3.0. Which means around 10000mW/h for 4.35 to 3.0

If you don’t have any mainboard, the LCD alone would drain that in 35h, which can’t be true because I get over 40hours with LCD and mainboard.

Let’s check the current flow to prove that apps who display display power consumption are fake, 287mW ~ 75mA which is just wrong because the real power management device told me around 36 to 40mA current flow including mainboard.

Summary: don’t trust power consumption values of subsystem level. They are just interpolated based on active time, state and known devices/technologies


I assumed this fact. Thank you for confirmation ;-)

Old HTC 500 I could run without battery from external power supply and see real consumption mA.

The new M9 (solid battery) can only measure this mA (mA) from external power only when the device is overheated. The device disconnects the battery from charging. (orange LED flashes + overheat alarm) In this state, the external power consumption is consumed by the device (without consuming battery charge)


Well, the subsystem messurements are "assumtions" But the whole system power draw is acutally correct. It is even more correct to readout the whole system battery current values instead of messuring before transformation on an external power supply.

The whole system power draw gets messured by a real current sensor in the phone.

But every value split for subsystem like LCD is using 70% and CPU is using 30% are just assumtions.

Maybe the CPU does have a sensor as well but don't know if an application is able to get any CPU current sensors values. At leaast I know that values for LCD are only based on runtime and level and not on current, I guess WLAN, BT, Mobilenetwork are just assumtions like the LCD is.

My LCD test is almost done, I find out that my LCD power draw is progressive and not linear like the app assumed it.

Unfortunently everthing below 50% brightness is difficould to read because it does consume almost nothing below 50% and there is to much idle noise to find the values where the CPU didn't drain anything.

Don't know the baseline of my LCD but I know the differences between the levels:

0% to 10% = +3mA

10 to 20% = +3mA

20 to 30% = +5mA

30 to 40% = +10mA

40 to 50% = +25mA

50 to 60% = +45mA

60 to 70% = +45mA

70 to 80% = +45mA

80 to 90%= +45mA

90 to 100%= + 50mA



Here is the answer to my question. Does the importance of bothering in the summer to 80% (critical visibility) display?

DOES NOT HAVE for 5-10mA - nothing.

It is more efficient off GSM data ;-)

Meaning less than 50% (ideal 40%) If it is not possible then use the required 90-100%

well thank you


Don't forget, these are LCD results with a small screen. And 100% brightness on a Z3 Compact is 550cd/m³, I have plenty of brightness to spare with this display compared to my old S4 mini with just 330cd/m³ ;)


I use tasker to stay on 40% and switch very quickly to 100% if needed:

And if you force your phone to record a track, you could spend a bit of energy on a highcontrast dashboard with only 10% display brightness, it will be active all the time anyway because of the track recording. That's the point where this idea did start to build up.


Now I have found cool things, I found a proper study with real test probes

And for more recent devices:

And here a full list of publifictions:

I did use these documents to confirm my test results.

Before you read these values, calculate how much mA/hour does is your current setup need to get a feeling for the possible improvements. For example I could get 16 hours Navigation out of 2700mA which is only 170mA average load. And Power users with a lot of mobile network usage do have 800 to 2000mA average load.

LCD: an Z3 Compact does use around 1200mW (320mA) for 550cd/m³ brightness. Power consumption could be very progressive. Brightness from 100 to 80 could save half of the display consumption. And 100 to 90 could save a third in extreme cases. A Z3 Compact isn’t that progressive, but it still save 190mW (50mA) for with 90% and 340mW (90mA) from 100 to 80% But I need to confirm this values because it’s based on only one device.

OLED: does consume more power than LCD on high brightness, dark map styles could save 300mw to 600mW (75 to 150mA) if you do use 100% which is needed on most OLED devices because they aren’t good at peak brightness. I will test my old S4 mini with a common vector theme give you a baseline for OLED because it could be anything between 600mw and 1500mW (150mA to 400mA)
Mobile network: You don’t need to disable phone services, as long as nothing is transmitted you could leave it on, it’s less than 10mW (3mA) but don’t let any app poll anything from the internet. Data transfer could by very expensive depending on network data amount it could consume 500mW to 1500mW (130-400mA). Use offline Maps and don’t use free tools with commercials. Disable Mobile Data is recommended, at least disable background data to minimize data transfer to foreground actives. And don’t transmit large amount of data over GSM, that’s even worse because your modem will be much longer on full power.

CPU: use android battery monitoring to hunt for services which use to much CPU time, if you just look at locus alone you won’t find much improvements. You don’t need to disable hill shade on recent devices, we can’t measure any benefit. You could may try to benefit from a tile map, but don’t use online maps. Ana offline tile map could save you around 100mA

GPS: an Samsung S3 use 400 to 450mW (105-120mA) stop your track recording and turn your display off on each break which is longer than 1 minute because locus could disable GPS if it does not record and does not display your position. And set your location service configuration to “device only” Some GPS devices try to compensate the small antenna by putting 1000 or even 2000mW into it. Make sure to use devices with reasonable sized antennas, for example an external devices connected over BT would need less power for GPS + BT signals because it could have a much more efficient antenna.

BT GPS: We still use old BT Versions for example 2.0 for GPS Communication. BLE isn’t useable for GPS because NMEA did got removed from the lightweight protocol and everything need to be reinvented.

Testing Is still in work. Don’t know if 45mW(12mA) for Audio BT is the same like BT GPS because it does sound way do good.

There is maybe a possible improvement by reducing number the NMEA sequences. But not if this is really using only 12mA


OLED confirmation:

A dark theme could save up to 80% OLED power, a bright theme does consume 5-times more energy.

on small less bright displays like S4 mini it would save arround 750mW (200mA)

Large devices could save much more, maybe 1500mW (400mA)

But the tested night mode was a bit extreme:

44f7944b982a5d60cc2476326ccaf228 15ff3a430259098786dcfe1e17222716

based on a black screen I did calculate the OLED power consumtion, 200mA for the light one and 40mA for the dark one.

You should look for a theme with darker colors or at least a special black theme. Everything will better then an inverted map. A theme with dark colors would save 20-50% and black themes like the invertion would save 60-80%

CPU - discover wrong results during confirmation: 100mA was a miscalculation

you will save arround 10 to 40mA with tiles maps depending on your hardware. (remember, it could still be alot if your target is 10 hours runtime with 2500mAh battery, 25mA would give you an extra hour)


LCD -here are 4 runs of screen brightness tests for 2 devices.

2d94768bfa03d7a924edc981e862f4f3Based on the testrun I did discover a special behaivor of Z3 Compact LCD Display. It does scale different below 50% and over 50%

You can actually see this during screenbrightness change. Between 0 and 50% very smooth because it get scaled slowly, but between 51 an 100% brightness change does stutter because change between steps is much larger.

Z3C 1 and Z3C 3 are tuned roms and Z3C 2 does have some strange results with the stock rom.


External NMEA GPS Recorder with Bluetooth will save a lot of overall energy because they use proper antenna designs.

My example consumes 31mA GPS + 12mA Bluetooth slave (GPS Logger) + 14mA Bluetooth master (Phone). This does save 50% overall (50mA) and it does save 90% on the phone (90mA)

This won't just save power, it will give you much better GPS accuracy.

Here some details for my example:

I did modify a QStarz QT 1300 GPS and replace the 320mAh with a 560mAh LiPo. (

560mAh is enough for 18 hours without BT, which means just 31mA for GPS including writing NMEA data to flash.

Or 13 hours including Bluetooth: 12mA Bluetooth + 31mA GPS and flash write. 12mA for BT make sense because it match to the result of the study.

To compare, here are examples of 3 Z3 Compacts after 7 hour runtime, as you see signal strength could vary from device to device:


And that’s a QT1300 (the weakest device you could possibly get) on the same place:


Just think about it, the device has such a good antenna that it will only need 30mA for GPS to get perfect results.

Remember, Smartphone GPS would use 3 to 6 times more energy to get a barely useable signal.

Another pro is the possibility to record a track without your smartphone. It will use 31mA for track recording and your smartphone would use 120 to 300mA for display off track recording which is 4 to 10 times more.

You could just get any external device, it doesn't matter, everthing will be way better then your phone because even a tuned keychain destry the phone GPS performance.

Off Topic:

I did tell that 2 of 4 Z3 Compact ware broken in my last commend, that wasn't true. The GPS is just to week to get any signal indoor. It need to be in a room near a window.


Beside the night mode, one can use the blank, dark map. There is also the black & white theme mentioned here


This Theme will drain almost nothing on OLED, like the allways on clock and notification screen. thanks for sharing.

In the meantime I did just hit 1000 hours screen on time across all devices with my benchmarking things... I have a huge excel file for all my crazy power tuning stuff. At least I found an activity where I could use outworn lipo batteries because I would feel bad don't using them :D

Tomorrow I will publish a diagramm for Z3 Compact LCD power consumtion where you will find a sweet spot. I can't publish it yet because I need more runs to get an average.

Last week I did start extracting voltage and current readout histories from the database of my power monitor with my rooted phones.


Just did my own experiment on my S5 neo (AMOLED), and I did not see any difference between the 3 setups I have tried for 30 min each:

- GPS OFF; screen ON; Black&White theme

- GPS OFF; screen ON; Standard theme

- GPS OFF; screen ON; Standard theme; Airplane ON

In all 3 cases, I've lost about 7 points in the % battery. A bit disappointed ...


Don't forgett to compare 1% with 100% brightness to find out if your test setup is able to give you any results. Because I guess there was something wrong because even the tiny S4 mini did benefit alot.


Power bank tuning: if your power bank get's hot you are wasting capacity.

- try to change charging speed by using other power bank ports

- try to change charging behaivor in android (but try to avoid slow charging at home, for example condition based slow charging profile with tasker)

And now more crazy stuff:

I did figure out that some Quickcharge 2.0 compatible devices could take not only specified 5V and 9V but would accept any voltage between 5 and 9 volt! Why is that great? Normally you need a DC to DC converter to convert power bank battery voltage to 5 volt and then in the phone it does get converted from 5 volt back to battery voltage. If you want to squeeze everything out of your power bank batteries, you could baypass one of the two DC to DC circuits if you device is able to handle it.

Currently I do check how well build the circuit of my Z3 Compact is to figure out if it is more efficient to bypass my selfmade powerbank DC to DC circuit

To be honest, it is scarry to put anything from 7.0 to 8.4V of my two NCR18650B direct on USB. I do messure my efficiency results by current over time with an USB tester ( which is able to handle 4V to 30V which will cover even quickcharge 4.0+

Don't forget to label your overvolted USB ports, because they are not backward compatible with 5V USB anymore ;)


As I did expect, the DC to DC stepdown with "97% efficiency at 6,5V and 3,5W" does drop alot in efficiency if you double or even triple the power. I lost 10% with 6W to 10W power draw at 7,0 to 8,6V

Which means my powerbank is now 10% larger then before. Now I have 100 hours screen on time ;) Ok, to be honest, I actually use the spare battery for my bicyle lamp. Nobody would need 100 hours screen on time with just 117g Phone and 98g power bank. Maybe a trail runner would be interested in such a lightweight setup.

Only if something goes wrong I need to plug my selfmade battery to usb adapter in to repurpose my bike lamp battery.


I did start with benchmarking Mobile services (2G, 3G, 4G) with live tracking and did search for large consumers. I was surprised how efficient a controlled system could use mobile services. You can use mobile internet the whole day without a power bank.

Mobile Internet connection: power consumption is highly dependent on the signal strength of your service and the transmitted amount of data. In Summary the target should be: transfer as less data as possible and work with large datasets only if you have a good connection. It is possible to draw from 190mW to 4000mW (50mW to 1000mA) per hour which means here could be the most important component to improve battery life. In some cases even more important than display brightness. You need at least Android 5 otherwise you can’t manage internet connection based on active app.

  • Disable background Data, and check if your apps don’t request any data if you don’t open them (reset data usage and check if there is still 0kb after 1 hour screen on time)
  • Preload needed things every time you have a very good connection (only useful on high demanding apps which support caching)
  • Organise use of demanding use cases/apps to open them less frequently to benefit from disabled background data usage (make only sense if background data disabling did actually work)
  • use apps instead of browser (only if background data stay 0kb, otherwise you would lose your benefit with just another battery draining app)

Here an example how an optimized setup could perform: (only 50mA to 200mA for internet)

70% Screen Brightness always on, BT GPS, Locus Vector Map, Locus Live tracking 60 seconds interval and Mobile Internet from 2G up to 3G

Optimized System in worst case: Bad Service, barely available connection with 0% to 20% Signal of 2G

  • ~7 hours runtime 360mA (1350mW/h)
  • modem: ~200mA (750mW/h)
  • Many failed live track Points: 1400 errors and 100 successful (420 points where expected: 7x60)
  • Run did consume 1,7mb data
  • Problem with bad service: modem is always on full power and you have many reconnect attempts

Optimized System in best case: Great Service, with 80% to 100% Signal of 3G (HSDPA)

  • ~12 hours runtime 210mA (800mW/h)
  • modem: ~50mA (190mW/h)
  • 0 errors


I have done some more test without auto-brightness, and indeed the B&W theme and the Night mode save between 1 and 3 points on the remaining % battery on my 30 min tests (eg -2 instead of -5%) depending on the brightness (tested at 10 and 100%).