Battery drain

[rebastion]

I love OsmAnd (using the plus/paid/live version), but I find it to be almost unusable in the wild, because it drains my phone battery faster than I can hike a short trail.

It is hard to pin this down. I am not actively recording the route, I have enabled infos on the map relevant for pedestrian (trails, landscape features, points of interest, topography, etc) and I even have a medium battery optimization mode on on my phone (Samsung S8), but still... I would say the app drains the battery in about 1-3h.

I realize how bad a bug report this is, but maybe helpful for the devs to generally look into battery-optimization as a really really important core feature of an app that is used far away from power outlets :+1:

[sonora]

I often use OsmAnd's track recording on an S8 for 12 hours straight per day, and get away for 3 consecutive days before recharging. How do you attribute the drain to OsmAnd ? Any chanceit could be another app running in parallel?

[rebastion]

Nothing running in parallel, but might it be something active in OsmAnd that is particularly battery hungry? Some layer, setting, etc?

[sonora]

Well, the screen is off, right? An active route could be one thing (even if the actual turn by turn navigation is still off. The other thing I can think off is if you use e.g. the car profile, which per default has the address bar visible on top of the map screen, which continuously tries to detect the postal address. (I use the Browse map profile in the wild.)

But in any case, the battery drain sounds just too excessive (by one order of magnitude) for any of that to be plausible somehow.

What kind of battery run times do you normally get on that device with OsmAnd off?

[rebastion]

Hi. With screen off, I cannot navigate :) I am not sure if the drain is the same with an active route or just having the map open. Definitely no care mode active. Browse map or walking is usually what I am on. My battery usually lasts for a day 12+ h

[scaidermern]

How long does your battery last when using a different app with active screen and active GPS?

[rebastion]

Hard to say, I am not testing lab :) But if I compare it to google maps with active navigation... I would say OsmAnd drains the battery before I reach the end of my hike

[Codain]

I know this kind of behaviour is nearly impossible to track (as explained in OsmAnd FAQ) but I face the same issue.

When routing from Paris to Nantes, Google Maps with traffic will leave my battery half full while OsmAnd on airplane mode will leave my battery around 20% and Android displays a burning message. When phone is power supplied, Google Maps is nearly neutral but OsmAnd keeps draining battery.

As a consequence I use OsmAnd only on short journeys, and always on airplane mode to increase chance to be able to use the phone once arrived.

I have the feeling this is mainly due to drawing (searching into data to know what to display + drawing) but have no clue. As an embedded software developer I did a quick analysis of OsmAnd source code and have found room for improvement on some functions. @vshcherb I can open an issue to submit those improvements for OsmAnd team to review.

I use last OsmAnd+ version on Android.

[promeneur]

i confirm the problem of battery consumed in 3 hours (Samsung S7) this year for the first time i use intensively Osmand to follow a road i built with my PC by just following the cursor over the road. I did not use routing feature because this feature consumes battery in one hour.

my bike trekkings this year : 650 km and 450 km

I set all the features supplied by Samsung to save battery: no network, mid saving battery feature, no screen rotating, no sound etc.

i set Osmand screen to display only map, time and battery level. I used no standard map but road maps. map was following my direction. i do not use sound guidance or contour line or shadowing. i did not display anything you can add by setting, only map.

Result : battery was empty after 3-4 hours.

Happily i made experiment before trekking. i carried a backup battery to keep on trekking after noon. Even with this backup battery i must stop my trekking at 4 or 5 pm because the backup battery is also empty.

[scaidermern]

I've noticed that it makes a significant difference in heat generation (and thus battery consumption I guess) if the following setting get's turned off: App profile -> Navigation settings -> Animate own position.

[pebogufi]

@scaidermern I never understood, what "Animate own position" is really good for. In help i find: "Animate own position turns on animated map panning of "My position" during navigation". When it is OFF, the panning also works (in simulation). I understand this panning, that map is always turned, so that driving direction is always straight to top of screen. Am i wrong ? So - what is it good for ?

[scaidermern]

@pebogufi Actually I'm not really sure, maybe the panning becomes smoother?

[sonora]

Yes, the panning does not jump from position to position, but the map motion is interpolated to create a smoother impression. Quite possibly a cause of battery consumption, I never use the feature.

A nd I also always use the map in 'No rotation - North is up' mode, which also saves considerable screen redrawing.

Can you attribute the excessive battery consumption to any of these modes?

[naoliv]

Could it be caused by any combination of the following cases/features?

• "Native library not supported on this device" (where OsmAnd will probably use slower code; #7047 for example)
• "Use OpenGL rendering" (the description says "use hardware accelerated OpenGL rendering (may use more battery, or not work o very old devices)")
• "Safe mode" enabled (which may also use slower code and thus use more battery)

[promeneur]

We do not have to guess what to do. Please Osmand supply a "saving mode" and a button to switch to saving mode as we do when we want to switch Android to saving mode.

Thanks

[sonora]

Yeah, but as long as it is unclear what is causing the drain on your device, there cannot be a saving mode... ;)

So far I cannot reproduce anything even close to what you are describing, on any of my test devices, both very old and very new ones...

[promeneur]

@sonora i get this problem with Samsung S2 Plus Lineage (Android 7) and Samsung S7 Android 10.

In my opinion using satellite localization plus just displaying a moving map consumes much electricity. This is normal. It is not a bug. Osmand must optimize their algorithms.

In a first approach for bike or foot trekking and in case of just following the cursor along a displayed track i suggest a "degraded mode" :

• degraded mode <-> display every 15 s, 30 s etc. or never the position (calculate and display)
• normal mode when approaching a crossroad

Other idea :

• do you use static image or svg image ? svg consumes much calculation.
• do you use cpu or gpu to render a changing image as moving map? Gpu is more adapted for this job.

[sonora]

@promeneur All good points, thanks, and I hope all developers can take a look at these!

But the original issue talks about "the app drains the battery in about 1-3h.", and I am rather convinced there must be something else going on here than what can be fixed with just these optimizations, especially since the vast majority of users and devices do not experience anything like that ....

[promeneur]

@sonora

i opened a feature request

https://github.com/osmandapp/OsmAnd/issues/10121

[ghost]

Further to this, I think it is the amount of data being rendered and how often the rendering occurs. I drive around Australia 100 km inland, 15,000 km about half on dirt. OSMand is on my phone on a vent holder, often in the sun, plugged in, screen always on. The sun actually has little effect, it is the heat generated by the phone on some occasions when using OSMand. I have cooked an SD card from the heat generated. Or put the phone in the pocket and it is blistering. I use the offroad map style which renders many more features at lesser zoom levels.
I think it is worse when close to cities where there are many many features to map & render at low zoom levels. Often tracks and the like render but are swamped by other features. Combined with traveling at 100 km/hr, which I presume causes it to render every second or so, I can see this processing load being considerable. I understand that the full render on any change feature is often appreciated for ensuring road names and the like are always fully visible, but on some usages priorities such as power usage far outweigh this feature. Is there any way to log or identify 1) how often the map renders (which I take it will vary between zoom levels when traveling at a constant speed) and 2) the time it takes for a render. Thank you for your time

[osmgit]

I can confirm the high battery drain on navigation. When hiking I always make sure to turn the screen off to avoid the huge battery drain. I usually also turn off navigation to be safe, otherwise if the phone turns on in my pocket by accident it will do the usual navigation draining battery thing and in a few hours and my phone will be dead. I usually only realise when my pocket gets very hot that I left navigation on. If I need directions, I will start the navigation again, find the next turn, then turn off navigation and turn off the screen. This is the only way I can get 8hrs when out hiking. I also have flight mode on. I bring a solar power bank too as a backup.

[sonora]

It looks like we suspect 'rendering' and 'navigation' now as two possible culprits. Could everybody in their reports please mention if these features are used.

Please note that the original issue report talks about hiking for several hours. It is my understanding (but maybe I am wrong) noone would do that with the screen permanently on, and there is also no mentioning of navigation being used.

We can only succeed debugging if we know exactly what everyone is talking about and reporting for. ;)

[Codain]

@sonora Rendering and Navigation are the two options I use on OsmAnd when driving. I don't save GPX nor take photos. Personally I never use OsmAnd on hiking so can't tell about this use case (I love paper maps too much!). But I can easily understand there is the same issue here since even when I create/edit POI on a given street with GPS OFF (so zoom and pan a lot on a limited area) I have the feeling that the battery is draining too quickly. It is a feeling which compares with other phone tasks (such as web browsing or emails), so it's difficult to measure it.

[sonora]

Just to create a cross-link here to the 'experiments' performed in https://github.com/osmandapp/OsmAnd/issues/10121#issuecomment-727256147 (measurements further up that thread).

@vshcherb With all optimization we could likely do in our code, it is my impression that for OsmAnd to just display a map, very little can be achieved. The battery eaters are

• GPS: I notice that this is a pain on old devices. New devices seem orders of magnitude more battery efficient in using GPS. User action could be to disable GPS iwhile not needed.
• Screen: I think little can be done here other than turning the screen off or lowering its brightness.
• The remaining power consumption observed (i.e. cpu cycles actually caused by OsmAnd) was miniscule compared to screen and GPS.

[janblau]

I got the same issue: if i use osmand 3.9.10 on a huawei p30 lite to record a track, it is very much battery consuming compared to the same device using instead oruxmaps

[xandro0777]

The huge differences across devices can't be really fixed by tiny optimizations but needs to be debugged.

Did any of the affected users attempt to look at the logs? Perhaps it might give some hints?

Also, people should look at the battery usage statistics provided by android, on my phone it is settings/battery/phone battery usage. Maybe there is something else going on?

[grimelda]

Similar experience on brand new stock Pixel 5a

• excessive battery usage (70% battery drain after a day of hiking with airplane mode and just browsing no navigation (2h app usage) on compared to battery drain of 40% after a day of hiking through a city with 4G and google maps, 3h app usage)
• often the app stays open even if i lock the screen (on phone open osmand is alive and home button or app switch triggers lockscreen) which often results in me opening phone and its calculaing random routes and adding weird bookmarks in my pocket. Th app reports 2h usage but ifeel like this should be way less as I only opened my phone at certain crossroads to choose which route to take! I estimate actual usage to be around 30min.
• screen redrawing seems to be hugely inefficient- phone is really struggling compared to other maps using offline OSM (tried komoot, organic maps, offline maps)

Learning from above comments will remove the animation setting and will disable unused plugins... Even though this seems like an inefficient build if i need to resort to this?

I do support others who noticed bad usage on navigation even if this issue is not about that- on old Galaxy S7 and young Pixel 3a would easily overheat on airplane mode with nav and sometimes the battery drain would be more than the charging and the phone would die mid navigation.

[scaidermern]

* often the app stays open even if i lock the screen (on phone open osmand is alive and home button or app switch triggers lockscreen) which often results in me opening phone and its calculaing random routes and adding weird bookmarks in my pocket. Th app reports 2h usage but ifeel like this should be way less as I only opened my phone at certain crossroads to choose which route to take! I estimate actual usage to be around 30min.

Maybe there should be a special button in OsmAnd to lock any other interaction. Vespucci has such a button.

[daniel-lo]

Old thread .. but just diggin into OA first time. Having the app consume as much battery as the display is something that should be looked into. Maybe I missed a switch that could stop this from happening.

[seniorm0ment]

Encountering really bad overheating and medium battery drain when using OSMAnd. Pixel 6 Pro, GrapheneOS

[anastasiia936]

From the request to support team: Usual use:GPS tracking for 2-3 hrsUsual battery use -10/-15% After recent updates: tracking for 2 hours used 45% battery, phone was warm from extensive processing. Device info and OsmAnd version: 1) Honor 9, Android 9Ad 2) OsmAnd+ 4.2.6, released: 2022-06-29Ad

[mcmxcdev]

I would love to use OsmAnd as my main cycling navigation app since it is very configurable and open source, but the battery drain is just too much and led to some bad situations ending up with an empty phone.

This excessive draining doesn't happen with either Google Maps, Komoot, Bikemap, or Bike Citizens all of which I used before.

Is there any dev looking at it to provide a fix?

[sonora]

I personally would love to research, but have not yet found a device or configuration which would cause unexpected battery drain. With all my devices what is stated above

Usual use:GPS tracking for 2-3 hrs Usual battery use -10/-15%

seems to be the norm.

[cuu508]

@sonora if you're still interested in troubleshooting this, try the following test protocol:

• From your available devices, pick a device that is relatively recent (model launched in the last 3 years), runs the manufacturer's firmware (not a custom ROM), runs Android 12 or 13.
• Reset the device to factory defaults.
• Install OsmAnd from Google Play.
• Download map data for your local area.
• Use OsmAnd's default settings – do not make any changes to the profiles, or to the global settings.
• Use the car profile, and the navigation mode, pick a destination suitably far away and drive (or cycle, or walk) to it. Important – the phone must be physically moving and changing direction. Testing with the phone stationary on desk will not yield correct results.
• Take note of the battery level every hour or every 30 minutes.

[sonora]

Have not tested recently, but from my notes that scenario uses about 10 percentage points of battery capacity per hour on a Samsung XCover 5, Stock ROM Android 13. What's your experience?

[cuu508]

Somewhere between 30% and 50% (Pixel 4a).

[sonora]

Sounds a bit like #15874...

[MrX-ua]

Seems like the issue still exists. I have had it over different app versions. Only used OSMand on navigation on a bike, have not tested in other conditions. Even with screen off the drain is extremely fast. OSMand consumed at least 20% more then the screen with some off time for the screen. I have pretty much stopped using OSMand because of this. Battery longevity is crucial on long distances. I am Using Poco X3 Pro

[josail]

I know this kind of behaviour is nearly impossible to track (as explained in OsmAnd FAQ) but I face the same issue.

When routing from Paris to Nantes, Google Maps with traffic will leave my battery half full while OsmAnd on airplane mode will leave my battery around 20% and Android displays a burning message. When phone is power supplied, Google Maps is nearly neutral but OsmAnd keeps draining battery.

As a consequence I use OsmAnd only on short journeys, and always on airplane mode to increase chance to be able to use the phone once arrived.

I have the feeling this is mainly due to drawing (searching into data to know what to display + drawing) but have no clue. As an embedded software developer I did a quick analysis of OsmAnd source code and have found room for improvement on some functions. @vshcherb I can open an issue to submit those improvements for OsmAnd team to review.

I use last OsmAnd+ version on Android.

From my autumn hiking I confirm the steep battery drain of OsmAnd App on a new iphone 14 and directly compared to other map and GPS apps like 'PocketEarth' and 'Maps 3D'.

My analysis tells me that the FPS (calculated frames per second, right?) drain the battery fast and heat the mobile accordingly. It would be very helpful to provide one central "energy/battery saver/efficiency" switch in IOsmAnd, which:

1. restricts FPS to maximum on 1 per second
2. calculates neighbouring areas / tiles so that moving does not require recalculation every other second (this is a feature applied to my knowledge in tile based apps in order to significantly reduce the need for online download events, and could also serve to significantly reduce the frequency of rendering/recalculation needed in OsmAnd)
3. adjusts several other options, that could drain the battery significantly to a "battery saving" position/choice, so that it becomes a "one-stop option / button / choice" which can be used for longer hikes. The need to adjust a large number of switches throughout all the options in OsmAnd makes it impractical for many users (including myself) to optimize battery drainage to low levels.

I'm certainly not the best expert on this. But I like to share my ideas for further improving the usability of OsmAnd in hiking and offline situations as a highly valuable map tool. No other app has so many and valuable options for adjusting the display to individual needs. OsmAnd would be close to perfect, if it would use less battery energy throughout a full day of usage.

[xandro0777]

Repeating myself, the code is battery efficient enough on the great majority of other devices so don't look for general improvements of the code.

There must be some very special problems on the devices where it drains battery.

As a first step to debugging this I would suggest everyone with this problem looks through the logs ( eg adb logcat) to find clues of something strange.

[wouter-klein]

Confirming that disabling 'animate own position' solves it for me (Samsung Flip 3), too

On default settings, while navigating, OSMAnd drained the battery by some 20% per hour, while connected to 12W charger! I took my phone out of its protective cover to prevent it from overheating, even while mounted directly in the airflow across the handlebars of my motorcycle.

With 'animate own position' switched off, it's not getting hot at all, and easily charges while navigating

[cuu508]

Sounds like "animate own position" somehow causes it to render with no FPS cap, and the more watts the device's GPU can pull, the bigger the problem.

[promeneur]

@wouter-klein

Confirming that disabling 'animate own position' solves it for me (Samsung Flip 3), too

On default settings, while navigating, OSMAnd drained the battery by some 20% per hour, while connected to 12W charger! I took my phone out of its protective cover to prevent it from overheating, even while mounted directly in the airflow across the handlebars of my motorcycle.

With 'animate own position' switched off, it's not getting hot at all, and easily charges while navigating

I don't understand well. If you switch off 'animate own position' you can't follow your itinerary. No ?

[scaidermern]

I don't understand well. If you switch off 'animate own position' you can't follow your itinerary. No ?

You still can. The animation is just not as smooth as with 'animate own position'.

I always have this feature disabled as it also creates other problems (for example #16081 which affects many users).

[promeneur]

@scaidermern

Thanks

[xandro0777]

On October 26, 2023 10:35:30 AM UTC, promeneur @.***> wrote:

Confirming that disabling 'animate own position' solves it for me (Samsung Flip 3), too

Just for the record, I have animate own position on and it doesn't cause any issues for me.

[sonora]

I propose the issues are severe and widespread rnough for us to have setting "Animate my position" off by app default, though...

[MrX-ua]

Setting "Animate my position" to off did not help me much. The drain is still unacceptable

[cloganklr]

Just want to add my experiences: Charging lag/battery drain has been evident on my last 3 phones: Motorola Droid Turbo, Moto G Power, And Samsung Xcover Pro. The battery drain/charging lag becomes noticable after the 4th or 5th use of OsmAnd, and becomes more and more pronounced the more often the app is used. In other words, the problem grows more severe the longer useage of the app continues.

In my case, my app usage is confined to my 3 different motorcycles, each having a USB power port connected directly to the battery, keyed "on"via a relay. Charging in all cases works perfectly as long as OsmAnd is not running. In each case, my "phones" are dedicated for GPS use only, with no SIM card, nor calling plan, and very few other apps loaded, and none running concurrently with Osmand

I want to love OsmAnd, but it's killing my charging systems and/or batteries!

[sonora]

That sounds very unusual indeed. I have no such experience on e.g thr Samsung Xcover 4s. Have you been able (by selectively disabling) to find out what in particular may be causing the issue, the screen, GPS, track recording route calculation?

[cloganklr]

Interestingly enough, I did just that today. Before leaving on a 150-mile trip, I had turned off almost every feature of OsmAnd that I had previously been using: street name, speed limit, land speed, altitude, et al.

Then on my trip today, I called up my track, and then set out. When I started, my battery level was 85%. Within less than 30 minutes, my level was at 100%. Four hours later (heavy traffic), my level was still at 100%, and I had been running OsmAnd the entire way.

Conclusion: one of the OsmAnd features that I had previously been running was apparently creating the charging lag. My next plan is to add back the features one at a time, until I identify the particular culprit. Of course, it could be a combination, I suppose.

At any rate, I have shelved my plan to abandon OsmAnd, and instead will focus on the root cause of charging lag.