Very high battery consumption/battery temperature increase/low performance/frequent crashes during car routing

[breversa]

Description

While OsmAnd has never been really high on performance and low on battery use (compared to Magic Earth for instance), it’s currently very battery-hungry, especially during routing (up to 30%/hour according to Battery Guru)

Steps to reproduce

Battery consumption during routing:

1. Open OsmAnd
2. Pick a destination
3. Start routing (either real or simulated) with screen on and voice guidance on (I use https://github.com/k2-fsa/sherpa-onnx)
4. Check the battery use once routing is finished

Battery consumption without routing (= static)

1. Open OsmAnd
2. Check the battery use after a while

Actual result

This is the battery consumption during two simulated test routings:

"Par heure" = Per hour "Batterie utilisée" = Battery usage "Durée totale" = Total duration "Capacité utilisée" = Used capacity

Battery consumption is around 25-30%. Osmand also randomly crashes from time to time if the map is very complex/detailled.

This is the battery consumption just displaying the map:

Battery consumption is around 15%

Expected result

Battery consumption should be lower.

This is the battery consumption while the phone is idle but with the screen on (light theme):

"Durée totale" = Total duration "Utilisée" = Used "Taux de décharge" = Discharge rate

"Temps d’écran allumé" = Screen-on time "Temps d’arrêt de l’écran" (bad wording) = Screen-off time

Your Environment (required)

OsmAnd Version: 4.7.10
Android/iOS version: LineageOS 18.1/Android 11
Device model: Wileyfox Swift 2 Plus (2700 mAh at 92% health = 2477 mAh max)

Similar behaviour happens also on:

OsmAnd Version: 4.7.17
Android/iOS version: /e/OS 2.0/Android 11
Device model: Samsung Galaxy S9 (3000 mAh at 60% health = 1798 mAh max)

This is a continuation of https://github.com/osmandapp/OsmAnd/issues/19511#issuecomment-2105633921

[Guylby]

I've tried a battery test with different settings;

On my Sony Xperia 10iii, with a 4380mAh battery at 80% health according to battery Guru (so 3506mAh available), I simulated navigation along the same route both time for 30mn. Screen brightness was set at 100%, voice guidance at 50% volume. No POIs were shown on map.

With a default Light theme Osmand rendering style, No animations OFF, Animate my position ON and Map orientation on "Movement direction": Battery started at 70% and got to 61% after 30mns, so about 18%/hour.

With the profile I always use for navigation: Light theme LightRS map rendering style, No Animations ON, Animate my position OFF and Map orientation on "North always up": Battery started at 74% and got to 70% after 30mns, so about 8%/hour.

With the LightRS no animations profile, with the phone idle displaying the map: From 50% to 47% after 30mns, so about 6%/hour.

Rendering styles and maybe animations seem to have a huge impact on battery consumption.

[breversa]

Thank @Guylby for your contribution!

I forgot to add that I used the default car settings (with TTS on), so no orientation change, no theme change, etc (I’m not even sure what "Animate my position" means).

However, I wonder if the battery consumption difference between your two first tests (18% vs 8%) comes first and foremost from the theme used, or the map orientation: although I didn’t mention it, I have the feeling that map rotation/orientation seem to take a heavy toll on performance (this was the reason I initially replied to https://github.com/osmandapp/OsmAnd/issues/19511#issuecomment-2105633921 as I thought it was a rendering issue).

I don’t have my test Wileyfox handy at the moment, but could you maybe do two tests, changing only the map orientation?

[Guylby]

@breversa I've tested the Osmand default profile with the map orientation set to "North is up" and saw no difference in battery usage compared to the Orientation following movement, in 30mn I got from 57% to 48% battery so 18%/hr again.

You might want to try turning the animations off: No animations set to ON and Animate own position to OFF. This is what made the biggest difference to me. Basically the settings make so that the display only updates 1 frame per second and disables the smoothing animations between each frame (no smooth zoom in an out, no smooth movement on the map). I guess that it lowers the rendering load and so results in a much lower battery consumption.

Going a step further and setting the screen to turn off when no directions are to be provided make another huge difference. I know that with it, I did several 5-6h trips with full routing that only cost me ~20% battery.

[breversa]

@Guylby : thanks for you reply, but this issue is not about reducing battery use: it’s about finding if some of OsmAnd’s algorithms are objectively inefficient.

[vshcherb]

We did investigation but didn't find anything specific yet. Going to reopen or merge with another issue once we have more details

[breversa]

More details:

• OsmAnd seems to crash more when actually driving around (with routing on) than simulating guidance.
• OsmAnd seems to crash more often when speed goes up (> 50 km/h): it crashed at least 3 times in 20 minutes again yesterday while I was on the highway, making it pretty much unusable, but stabilized once I was off the highway driving slower in the city. I believe it’s tied to the higher frequency of map objects to be rendered/updated.
• Maybe it’s tied to the complexity of the map? My tests were done using the Europe − France − Greater East − Bas-Rhin map.
• Battery temperature can go very high during routing: it went from about 30°C to 50°C in a hour. This does not happen with other navigation apps (e.g. Magic Earth).
• Using the developer’s widget, RAM consumption seems to be constant at about 80-100 MiB, which leads me to think of a CPU issue instead (maybe OsmAnd is using only one core? only big cores? only small cores?).

[Guylby]

@Guylby : thanks for you reply, but this issue is not about reducing battery use: it’s about finding if some of OsmAnd’s algorithms are objectively inefficient.

Yeah I understand but battery usage is directly tied to how much power and load is placed on the phone, so lower battery usage = lower power use per hour= more efficient routing.

From the tests I did the main power draw seems to be from rendering the map. Have you tried disabling animation and animate my position to see if that helps with your battery temps and crashes? Less frames to render should lighten the load on the GPU and your battery.

[breversa]

From the tests I did the main power draw seems to be from rendering the map. Have you tried disabling animation and animate my position to see if that helps with your battery temps and crashes? Less frames to render should lighten the load on the GPU and your battery.

I will test your suggestions to measure the impact of those settings. Maybe that will help circumvent the root cause. :-)

[breversa]

I did two short 10-minute tests yesterday with "No animation" and "Don’t animate my position" on, in a dense urban setting, no highway.

OsmaAnd didn’t crash, but in both cases, battery dropped by about 1%/minute (global, not only OsmAnd use), and the battery temperature climbed from 30°C-something to well over 40°C.

So my current conclusion is that the "No animation" and "Don’t animate my position" options have little to no impact on these performance issues. :-( More extensive tests may be required though.

[DmitryAlexei]

It may be a problem of constantly redrawing the map during navigation, especially when the auto-zoom is enabled. Please try to disable everything you don't need for navigation in your driving profile (these preferences will affect only driving, other profiles will remain the same):

• you can disable 3d relief, contour lines, hillshades and slopes
• in menu > configure map > details you can disable unneeded details
• in menu > configure map > hide try to mark unneeded objects (boundaries, house numbers, underground objects, POI labels and POI icons, etc.)
• set map magnifier by 100% (long press + or - on the map screen) (this may be the main issue) As mentioned before you can also disable autozoom (navigation > settings > navigation settings > map during navigation > auto zoom) and (or) use only vector maps. Online maps may consume additional power, especially if they are not previously downloaded.

Please give us feedback about the source of additional battery drain in your case.

[breversa]

Hello @DmitryAlexei,

Here’s a small preliminary feedback:

• I only use downloaded maps, not online
• Map magnifier is always at 100%
• I did a simulated test on my Wileyfox Swift 2 Plus (1h-drive, but mostly highway outside cities) with 3D relief, hillshades and contour lines off (they were ON before, as I feel that they improve the guiding instructions perception): the display was smoother but it still consumed about 25-30%/hour and the phone was warm. OsmAnd did not crash, but I never crashed on simulated routing anyway. I will test it again in real conditions when I have the chance (I don’t drive everyday).
• I forgot to add that I used 3D view with a rather strong inclinaison (à la Magic Earch), so the horizon in quite far and rendering has to do a lot of inclinaison calculations, I guess, which might be optimizable?

[EssBee59]

Hello! I do not think, that Osmand have a very high battery consumption, but I am interested by any optimization: As biker I have no problem by tours < 100 km, by longer tours I prefer to use a power bank. (I use intensively the option screen on/off, and switch the display off 15 seconds after a voice announcement)

To reduce the battery usage by very long tours , I set the smartphone in "aeroplane mode".

To evaluate the basic battery / CPU usage I started two small tests: -at home I start a navigation for biking -swtich the screen off, and wait 30 minutes -in test1 "auto-centre map view" = 5 seconds, in test2 "auto-centre map view=15 sec

It seems, the CPU usage (consequently the battery usage?) differ grantly between the 2 tests:

CPU gesamt = sum CPU CPU im Vordergrund = CPU in foreground ... (please ignore the relative CPU consumption, in test1 other apps were active, so only the absolute consumption should be considered: I think, the CPU consumtion were in test1 3 times higher as in test2!)

So, till now I used a value of 5 seconds for auto-centre map view. By the next long tour, I will test with a value of 10 seconds.

Can any body confirm my test results?

regards

[EssBee59]

Now I compared with a real navigation: (Bike route of 50 km, auto-centre map view = 5) Sum CPU 1h 42 m CPU in foregroud 21 m

I have to retest with auto-centre map view=10 or 15, but the saving potential with this parameter will probably remain limited (15 min less CPU from 100) regards

[breversa]

It may be a problem of constantly redrawing the map during navigation, especially when the auto-zoom is enabled. Please try to disable everything you don't need for navigation in your driving profile (these preferences will affect only driving, other profiles will remain the same):

* you can disable 3d relief, contour lines, hillshades and slopes

* in menu > configure map  > details you can disable unneeded details

* in menu > configure map > hide try to mark unneeded objects (boundaries, house numbers, underground objects, POI labels and POI icons, etc.)

* set map magnifier by 100% (long press + or - on the map screen) (this may be the main issue)
  As mentioned before you can also disable autozoom (navigation > settings > navigation settings > map during navigation > auto zoom) and (or) use only vector maps. Online maps may consume additional power, especially if they are not previously downloaded.

Please give us feedback about the source of additional battery drain in your case.

More feedback after a 20-minutes drive (urban, both highway and lower speed), with 3D relief OFF, hillshade OFF, elevation lines OFF (it was never on to begin with), weather OFF but "Disable all animations" OFF and "Animate my position" ON:

• no crash! :-)
• but phone still warms up quickly, and battery drain is still very significant (but maybe a tad lower ; I couldn't measure precisely though)

[EssBee59]

Hello breversa,

Thank for the tipps! I started a tour today with your recommandations above and

-"auto-centre map view"=15 -Screen on/off (only 15 sec on after a voice message) -aeroplane mode on

By a tour of nearly 37 km my battery state slowed down from 100% to 90%! (my smartphone has a battery of 5,000 mAh, CPU is snapdragon 8+ gen1)

My max distance per day on the race-bike is 170 km, so the battery will reach, no need for power bankI I am very satisfied with this setting.

regards

[EssBee59]

Am other tour with the new settings as above described: -83 km, duration 4 hours -Battery unload 95% to 55 %

It seems, the result depends on the tour itself (number of voice announcemnts as example), but the most important is, the battery will reach for my longest daily tour.

[breversa]

After changing my Samsung Galaxy S9 for a Fairphone 5 (https://www.gsmarena.com/compare.php3?idPhone1=8966&idPhone2=12540#diff-g960f,,), I’m no longer experiencing low performance nor crashing, even with 3D terrain, animated position, etc.

I haven’t measured the consumption yet though. Maybe there’s still something to be done here, and also for lower-end devices.

[bernot]

In general I am using Android Smartphones with Battery Power > 5000 mAh.

GPS Chip requires much Power, even the GSM connection. If the signal is low, more Power is required, the Chip becomes hot and Software crashes more often.bsimetumes this requires a restart or reboot of Android

While Android 6 manage to receive GPS Signal with Display Off, Android 11 needs to have Display on to have GPS Signal.

So if display is off from Android 11 no GPS position is updated and no new calculation is done, which leads to less power consumption.

Beside hardware selection and osmand itself configuration and operation mode ist essential to power consumption, performance and stability.

[sonora]

Android 11 needs to have Display on to have GPS Signal.

This is not generally true, simply the mechsnisms have changed. You need to e.g. have a service (visible in the Android notification bar, like OsmAnd uses during navigation or trip tecording) to ensure continuous GPS position updates and processing as needed.