Skip to main content

Track Recording

Overview​

This article covers GPX track recording issues which have been observed for a long time in different versions of Android and iOS. By Background, we mean that the OsmAnd app does not appear in the foreground, especially when the device screen is off (which is different from the internal background definition in devices).

Notes:

  • As of Android 11 (2020/12), there is no longer the system permission option Always allow location access to be used in the background, but this does not limit the background recording of OsmAnd tracks. According to Google's documentation, this is now considered foreground usage because the permission to use the service in the foreground is used internally and the system notification that a track is being recorded is always visible.

  • Note that Android's new wording can be misleading:

    • Allow while using the app means that the app can continuously receive location data as long as it is displayed on the screen or has a visible notification in the Android notification bar, as OsmAnd has during navigation or trip recording. (Technically, this is called foreground mode).

    • Allow all the time, on the other hand, means that the app can in principle obtain your location 'unnoticed' without either of these conditions applying. But Android limits the frequency of location access in this (background) mode to something like once per hour, which is certainly not the correct mode for a navigation app.

Recorded Tracks are Noisy​

There are 2 typical accuracy issues leading to a messy recorded track.

  • Longer standing in the same place, or too frequent point recording (corresponding zig-zagging exaggerates true values)
  • Weak GPS signal or switching to network signal-based location.

Mitigation actions:

  • Pause your recordings while standing, or use the Trip recording plugin’s Minumum displacement filter.

  • Select the time or displacement spacing of your recorded points appropriate to capture the curviness of your trip, but not creating lots of extra points (the spread of which will create noise and exaggerate distance and elevation fluctuations).

  • It is also possible to edit a track later and remove "noisy" points.

  • Or you can use the Trip recording Plugin settings to filter "noisy" points already while recording, based on your experience and recording device. You can filter out points by various criteria:

    • Points with low or zero speed.
    • Points with bad precision (GPS 'hdop').
    • Points closer than a threshold in meters.

  • Google Services API or Android API. You may further change how OsmAnd receives location data on Android devices. In OsmAnd Settings → Location Source select between Google Play Services and Android API, in many cases changing to Android API helps to improve the recorded tracks and makes them less noisy.

Recorded Tracks Have Gaps​

Configuring OsmAnd for Track Recording​

Optimizing Android for Track Recording​

Starting with Android 4.4, power-saving features can limit CPU usage, reduce screen brightness, and kill background apps when the screen is off. This can affect OsmAnd’s performance for outdoor use, map rendering, and track recording. Later versions of Andrid have added AI-based power saving bahaviors like Automatic battery and Automatic power saving, introducing dynamic and even less predictable behavior. To avoid recording issues, at least initially or for debugging, consider disabling power-saving features entirely. Users report that the impact on battery life for most devices is tolerable.

  • Exclude OsmAnd from Battery optimization. In your Android device's Settings, find OsmAnd under Apps, Applications, or App Manager. Locate the Battery, Power Savings or Power Consumption section, and exclude OsmAnd from battery optimization. (Issue #5255)

  • Disable the Power saving Mode. This mode has a high chance of impacting/killing even foreground services, like OsmAnd's trip recording.

  • Disable Adaptive power saving. Having this 'on' will apply system-wide, use-pattern based policies to deactivate/activate the above 'power saving' mode.

  • Diasable Adaptive battery unless you use the OsmAnd app regularly. Adaptive battery works on a per app basis, also use-pattern based. Its effect on a specific app can be reduced by exempting that app from Battery optimization (like setting to Not optimized). However, Adaptive battery can still kill foreground services such as OsmAnd's trip recording, if the device judges OsmAnd to be in your 'rarely used' pool of apps.

Control the Behavior of iOS Background Apps​

iOS can suspend or stop background apps automatically when system resources are reallocated. OsmAnd cannot override this behavior. If track recording is interrupted when the device is locked, this can leave gaps in the recording. You can edit these gaps using the Plan a Route tool.

For more details on how iOS handles location tracking, check out Apple's documentation here.

Tested Power Settings for Android 9, 10, and 11 (Hardy, 2020-08-25)​

The following Power settings have been successfully tested under Android 9, 10, and later 11 (on Samsung devices) to make OsmAnd register tracks without gaps. Please review these 10 settings and set accordingly:

  • (1) Power saving (mode) = OFF (or Optimized in Android 10)
  • (2) Adaptive power saving = OFF (When ON, power saving mode may sometimes be activated, which prevents OsmAnd from logging.)
  • (3) Adaptive battery = ON (Does not affect apps exempted from battery optimization anyway, see (9) below, unless the app is used rarely. To be safe, set to OFF.)
  • (4) Put unused apps to sleep = ON (But exempt OsmAnd is exempted from battery optimization, see (9) below!)
  • (5) Auto disable unused apps = OFF (Seems only present in Android 9.)
  • (6) Optimize settings = OFF (In Android 10 under Device care / Advanced, in Android 11 seems gone.)
  • (7) Auto optimize (daily) = ON (Has no effect here.)
  • (8) Auto restart (at set times) = OFF (Has no effect here.)
  • (9) Optimize Battery Usage (Under Android Settings / Apps / OsmAnd / Battery or Settings / Apps / 3-dots / Special access / Optimize battery usage / All / OsmAnd) = Exempt OsmAnd from battery optimization (very advisable, although not necessary if the app is user-started frequently).
  • (10) Allow background activity = ON for OsmAnd under Apps / OsmAnd / Battery for Android 11

Some of these settings interact, so be accurate. The best search for the above settings by name (with and without the expressions in parentheses). Depending on your version of Android, they may be scattered over these various Android Settings screens:

  • Device care
  • Device care / 3-dots / Automation
  • Device care / Advanced
  • Device care / Battery
  • Device care / Battery / Settings
  • Device care / Battery / App Power Management
  • Device care / Battery / More battery settings

How to Track Traveled Distance​

OsmAnd does not have a special widget similar to an odometer, you can use the Trip Recording plugin to track your traveled distance and reset it when needed.

OsmAnd 3.9: Altitude issues when using Google Play Services​

Google Play has changed its policy, and to comply, OsmAnd, as of version 3.9 (excluding Nightly, F-Droid, and Huawei builds) is required to use Google Play Services to obtain location fixes while running in the background (that is, in Android terminology, as a foreground service with a visible system notification).

After this change, there seems to be an issue with altitude recording: Apparently, Google Play Services interpolates the altitude measurement very aggressively, see GitHub issue #10864. This issue affects Android 10, possibly not Android 11. The issue has already been reported on Google's website, and will probably be fixed on 09-03-2021.

As a workaround, in OsmAnd Settings → Location Source you can switch the location source from Google Play Services to Android API.

OsmAnd 3.9: GPS wake-up now replaced by continuous foreground service (2020/12)​

As of version 3.9, when track recording or navigation is required, OsmAnd continuously supports GPX via the Android background service, and this is visible as an Android system notification.

The prior strategy of using a doze mode and periodic GPS Wake-Up has been removed from our code (commit Drop waking navigation service on alarm), as required by new Google Play restrictions on Background location access. As a result, the following sections (A) and (B) apply only to versions of OsmAnd before 3.9:

(A) GPS Wake-up Strategy

  • (A1) While OsmAnd is used, e.g. Navigation. We keep the system's GPS module on all the time, as continuous location information is key here. Effect on battery use (order of magnitude) seems about 5% per hour on older systems up to Android 4.4, and 2-3% for newer systems.
  • (A2) For background track recording without simultaneous navigation. For recording with up to 15-second intervals, we also keep GPS on, other strategies will not save much battery power.
  • (A3) For intervals >=30sec, we turn GPS on only for each sampling point. This has some noticeable effect on the accuracy of the points recorded but reduces battery usage to an order of magnitude 1.2% per hour for 30-second track recording.

(B) GPS Wake-up Issues

To achieve the GPS wake-up, so far we use the Android Alarm Manger to wake up the device periodically (also from Doze mode, which was introduced in Android 6). New Android versions introduced the following issues:

  • (B1) Alarm Manager's setRepeating() became inexact starting with Android 4.4:
    Mitigation: We now use setRepeating() only up to Android 4.2, the new setExact() method starting with Android 4.4, and setExactAndAllowWhileIdle() for Android 8+. (Issue #5632)
  • (B2) Starting from Android 4.4, systems limit the number of times setExact() is executed repeatedly to e.g. once per 5 or even 15 minutes. (The actual value seems wildly device-specific.)
    No good solution found for now. Current mitigation is we do not use Alarm Manager wake-up, instead keep GPS always on for background track logging on devices with Android 5+ for all recording intervals shorter than 5 minutes. This produces reliable and precise tracks at the cost of higher battery use. (Issue #5632)