Battery drain when recording GPS track in background

[ioctl-user]

I have LineageOS 17.1 (Android 10) device with OSMAnd+ from F-Droid. Regardless of track record interval settings (I have used 30 second for the following record), OSMAnd wakes CPU each second. Please see attached Battery Historian screenshot.

At that, it seems, GPS data itself was written with correct 30 seconds interval.

[sonora]

Yes, I had researched this a lot, but in the end found no other way to implement that a track is reliably logged under all new versions of Android with all their power saving mechanisms and limiting device wakeup. Please refer to http://osmand.net/help-online/technical-articles#BackgroundRecording, in particular section (C2), for some detail. In a nutshell: If I let the device go to sleep, I cannot reliably and repeatedly wake it up again at certain times.

In connection with what I documented here http://osmand.net/help-online#trip_recording_stops, that is the only setup I could find to reliably work across all my test devices without losing tracks or track portions.

[naoliv]

How do others implement/do it?

For example: https://github.com/BasicAirData/GPSLogger https://github.com/mendhak/gpslogger/

[sonora]

@naoliv They are struggling: Just check their Issue logs for related entries.

From what I see we may in fact be top notch when it comes to solving this across versions and vendors...

[ioctl-user]

I have tested these packages from F-Droid with periodic polling: https://f-droid.org/packages/net.fabiszewski.ulogger/ https://f-droid.org/packages/com.rareventure.gps2/

Android make them sleep after 10 minutes in background mode.

But, may be it's possible to increase OSMAnd wakeup period from 1 to 2..5 seconds for background record mode? It may give significant battery economy.

[sonora]

From what I recall, there is no such parameter... the poll time is system given, I simply keep the chipset in always on mode.

[ioctl-user]

The Signal messenger uses 1 minute timeout for devices without Google APPs; it's working even in full doze mode. I am not sure, but it seems this delay is implemented here: https://github.com/signalapp/Signal-Android/blob/master/app/src/main/java/org/thoughtcrime/securesms/util/AlarmSleepTimer.java

[sonora]

It's a long story, see some reading here: #5632. I think I had experimented extensively with AlarmManager, there was no way to get it to reliably work universally.

[ioctl-user]

I have tried to build OSMAnd myself to experiment with this issue, but didn't succeed. Which is the easiest way to build version close to binary from F-Droid? Is there any good docker image for this purpose or something like that?

[naoliv]

@ioctl-user see https://github.com/RussianFox/osmandbuilddocker

[ioctl-user]

@ioctl-user see https://github.com/RussianFox/osmandbuilddocker

I have downloaded this project, created docker image, entered it, entered /osmand/build/android directory, run ./gradlew build , and it failed. Command build_nightly is absent in the docker image. Here is a log part after build rerun:

/osmand/build/android/OsmAnd/AndroidManifest-debug.xml:53:31-63 Error:
        Attribute application@label value=(@string/app_name_free) from AndroidManifest.xml:53:31-63
        is also present at AndroidManifest.xml:53:31-63 value=(@string/app_name).
        Suggestion: add 'tools:replace="android:label"' to <application> element at AndroidManifest-debug.xml:5:5-24:19 to override.

See http://g.co/androidstudio/manifest-merger for more information about the manifest merger.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':OsmAnd:processFreecustomLegacyArm64DebugManifest'.
> Manifest merger failed : Attribute application@label value=(@string/app_name_free) from AndroidManifest.xml:53:31-63
        is also present at AndroidManifest.xml:53:31-63 value=(@string/app_name).
        Suggestion: add 'tools:replace="android:label"' to <application> element at AndroidManifest-debug.xml:5:5-24:19 to override.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 24s

UPD: I find command nightly_build. Trying it...

[ioctl-user]

It seems application must request REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission to avoid sleeping after a few wake up.

[sonora]

I believe this to be the same as manually excluding the app from battery optimization? I had tested that on about half a dozen devices and never found it to make a difference.

[ioctl-user]

I believe this to be the same as manually excluding the app from battery optimization?

It seems its not... With the attached patch OsmAnd wakes each time and access GPS data as expected (I have tested with 1 minute record interval). It's not save all that points, but that looks like another problem.

ignore_battery_optimization.patch.txt

[ioctl-user]

Could you confirm that the attached patch prototype fix wake up problem?

[sonora]

It seems the patch you suggest may be problematic on many devices, and with gpogle policy? https://stackoverflow.com/questions/44862176/request-ignore-battery-optimizations-how-to-do-it-right

Also, reading the documentation, it still looks to me that does nothing else than adding the package to the white list, something I have found does not have the desired effect on many devices.

Your second observation: A wake-up without saving a point could indicate a fix was not found before gpx was killed again, (a problem the current solution does not have any more).

[ioctl-user]

Also, reading the documentation, it still looks to me that does nothing else than adding the package to the white list, something I have found does not have the desired effect on many devices.

On my device I see clear difference with that patch. I use Battery Historian to see wake up statistics. May be some vendors make "customization" to save battery, that make device ignore that setting. I have no many devices to test it. If so, owners of such devices can use little intervals, when OsmAnd not going sleep at all.

Your second observation: A wake-up without saving a point could indicate a fix was not found before gpx was killed again, (a problem the current solution does not have any more).

It's not a big problem. Modern devices obtain first fix in 3..5 seconds after warm GPS start. So, OsmAnd can wake 10 seconds before planned time and enable GPS to get good precision. Even for 30 seconds fix period this mode should give 66% battery save on recording. Using 5 minutes period should give 97% battery saving and so on.

[sonora]

Ok, but do you see any difference between using your patch and using the as-is version of OsmAnd and manually adding the app to the battery optimization white list? (I think that's all your patch does.)

[ioctl-user]

Something strange is going on with my build. APK built with https://github.com/RussianFox/osmandbuilddocker have no background GPS access permission option.

Which SDK version should be used? 26?

[ioctl-user]

Ok, but do you see any difference between using your patch and using the as-is version of OsmAnd and manually adding the app to the battery optimization white list?

Yes, I did. For now I cannot check it again, because I cannot build good version with my modifications.

[ioctl-user]

ping

[vshcherb]

It looks this discussion becomes irrelevant cause OsmAnd will need special permission - https://developer.android.com/training/location/background. We're not going to apply for it cause majority of people doesn't need that functionality, so we're not going to AlarmManager functionality which allows to wake up every 30 seconds or 2 minutes. So, in that sense OsmAnd will be just requesting continuous GPS update.

The decision has not been made yet cause we're still investigating how to publish application to Google Play and we still can't pass the verification process.

Possibly solution will come from Android API solution cause we're going to use requestLocationUpdates(... ) and if Android Core will handle it in a smart way excessive battery drain issue will be resolved.

[ioctl-user]

Here is a good example of battery save recording with configurable interval: https://f-droid.org/ru/packages/net.fabiszewski.ulogger/

Battery-efficient GPS logging is really needed for multi-races and hiking trips. Recording directly in OSMAnd will allow examine path and help orienteering.

[sonora]

So what's the battery drain for that app? Current OsmAnd should be about 5% per hour on older systems up to Android 4.4, 2-3% per hour for newer systems (see my documentation at https://osmand.net/help-online/technical-articles#BackgroundRecording). (Make sure you don't keep the screen on all the time during recording, that consumes magnitudes more power than keeping GPS on on newer devices.)

[ioctl-user]

With ulogger it was 1.1%/hour when recording each 30 seconds during night test near the window. All fixes were recorded without spaces.

UPD:

When this bug was open, recording with long intervals didn't imply CPU sleeping. Following this new document, did OSMAnd changed recording strategy last year?

My Android version 11.0.