[Help Wanted]: Tracking pauses mid-trip, timeout starts, and never resumes on movement (both iOS and Android)

[kkostadinov-wannabe]

Required Reading

• Confirmed

Plugin Version

"react-native-background-fetch": "4.4.2", "react-native-background-geolocation": "5.3.0",

Mobile operating-system(s)

• iOS
• Android

Device Manufacturer(s) and Model(s)

Iphone 15 Pro Max, Galaxy A16

Device operating-systems(s)

iOS 26.6, Android 16

React Native / Expo version

"react-native": "0.81.5", "expo": "54.0.33", Bare workflow — native projects generated by expo prebuild with a config plugin. New Architecture enabled (RN 0.81 default).

What do you require assistance about?

On both iOS and Android, location updates stop arriving in the middle of an active trip. They correctly engage the stop-timeout while stationary, while getState() still reports enabled: true. Once this happens, movement does not bring updates back: neither motion-activity transitions nor several hundred metres of travel reliably resume delivery. Updates typically return only much later — in our recordings, when the user has been walking again for a sustained period.

Our use case is recording continuous urban travel traces (walking + tram/bus/metro + car), so a multi-minute hole in the middle of a trip is data loss for us, not a battery optimisation. The pattern is especially damaging around public transport: the user walks (tracked fine), waits a few minutes at a stop, boards — and the entire vehicle leg is missing.

We would like help identifying what stops delivery, and what the correct configuration is for "never lose location during an active trip, but still allow the device to park after a long genuine stop" on both platforms.

Recorded evidence

The following is the plugin's own recorded stream (via getLocations()) from an iOS device.
The full JSON is attached. A comparable pattern is observed on Android; we can supply an
Android recording as well if useful.

Trip start — fixes arrive every 7–10 s as expected:

Time (UTC)	lat, lon	accuracy	speed	activity
13:38:54	42.673805, 23.330248	15.1 m	—	on_foot 100%
13:40:34	42.674315, 23.329867	3.5 m	1.14	on_foot 100%
13:41:27	42.674887, 23.330046	2.5 m	1.53	on_foot 100%
13:42:25	42.674543, 23.329105	2.1 m	1.28	on_foot 100%
13:42:34	42.674509, 23.328986	2.1 m	0.84	on_foot 100%

→ Location delivery stops here, 3 min 39 s after the trip began.

Gap: 13:42:34 → 13:47:58 — 5 min 25 s with zero locations. During the gap the user waited
briefly at a tram stop, boarded, and rode one stop. Straight-line displacement across the gap is
370 m (42.674509,23.328986 → 42.675961,23.333060); the travelled path is longer.

Time (UTC)	lat, lon	accuracy	speed	activity
13:47:58	42.675961, 23.333060	4.9 m	1.0	on_foot 100%
13:48:08	42.675927, 23.332914	3.8 m	1.29	on_foot 100%
13:48:18	42.675866, 23.332804	3.2 m	1.14	on_foot 100%

Delivery resumes only once the user is walking again.

What is puzzling about this

1. Delivery stopped 3 min 39 s into an active trip, far short of our stopTimeout: 15
   minutes. We do not understand what, other than stopTimeout, stops delivery this early.
2. The motion API reported on_foot at 100 % confidence throughout — both before and after
   the gap. The device was never classified still, even at the moment delivery stopped.
3. 370 m of displacement during the gap did not produce a motionchange. Given the
   documented ~200 m stationary-exit behaviour on iOS, we expected the stationary region to be
   exited during that leg.
4. It happens on both platforms, which rules out the hypothesis (iOS
   pausesLocationUpdatesAutomatically) as the whole story — see below.

What we have already tried

• iOS: ran with pausesLocationUpdatesAutomatically left at its default, then explicitly set to false. The symptom occurs in both cases. (We understand false implicitly sets disableStopDetection: true and disables preventSuspend; we compensate by parking GPS ourselves with changePace(false) after our own 15-minute idle watchdog.)
• iOS: tried activityType: Other and ActivityType.OtherNavigation. No improvement observed with either.
• Both platforms — app-level resume attempts, neither of which reliably recovers:
  • On onActivityChange with any moving class (on_foot, walking, running,
    on_bicycle, in_vehicle) at any confidence, when getState() reports
    enabled: true and either isMoving: false or no fix for 90 s → we call
    changePace(true).
  • On onHeartbeat, when fixes look stale → getCurrentPosition({samples: 3, timeout: 20}),
    compared against a stored "park anchor"; if displacement exceeds a threshold →
    changePace(true).

Because the activity-based path fires on any moving class at any confidence, and the
recorded stream shows on_foot @ 100 % throughout the gap, we would have expected it to fire.
It did not produce a resume. From the JS side we cannot distinguish between:

• the activitychange / heartbeat events not being delivered to JS in this state, or
• changePace(true) having no effect while the plugin is in this state.

Listeners registered

onLocation, onMotionChange, onActivityChange, onHeartbeat, onProviderChange,
onConnectivityChange. ready() is called once per JS context; start() is called when the
user enables tracking in-app. We never call stop() except when the user disables tracking.

Questions

1. What can stop location delivery mid-trip, well before stopTimeout elapses, on either
   platform? This is our main question — a 3½-minute-old trip being cut with the motion API
   reporting on_foot @ 100 % is the part we cannot explain from the docs.
2. On iOS with pausesLocationUpdatesAutomatically: false, our reading of the docs is that
   location-services should never be turned off by the plugin. Is that correct, and can
   anything override it (desiredAccuracy: Navigation, activityType, Low Power Mode, iOS
   suspending the app)? Is TSLocationManager 4.3.x validated against iOS 26?
3. On Android, what should we check for this symptom — Doze / battery-optimisation
   exemption, OEM background restrictions, foreground-service state? Is there a way to detect
   from the plugin that the service was throttled rather than legitimately parked?
4. What is the intended mechanism that resumes tracking after the plugin parks, on each
   platform? Should changePace(true) from JS always work in that state, and should
   onActivityChange continue to be delivered while parked?
5. Does preventSuspend: true / heartbeatInterval: 60 keep the heartbeat firing in this
   state? We do not appear to receive heartbeats during the gaps. On iOS, if
   preventSuspend is inoperative when pausesLocationUpdatesAutomatically: false, is there
   any way to keep a JS watchdog alive?
6. Is stopDetectionDelay expressed in minutes or milliseconds in 5.x? The typedef and the
   Config summary table say minutes, but the ActivityConfig example in the docs uses
   stopDetectionDelay: 10000 // 10s. We currently pass 15, intending 15 minutes.
7. Could motionTriggerDelay: 30000 be implicated in the Android non-resume? We added it
   recently to avoid false trip starts from indoor pottering; we would like to confirm it
   cannot suppress a genuine resume.
8. Are there known issues with React Native 0.81 / New Architecture where the native side
   keeps running but JS stops receiving plugin events?

[Optional] Plugin Code and/or Config

// Called exactly once per JS context. start() is called separately when the
// user enables tracking in the app.
await BackgroundGeolocation.ready({
  reset: true,

  geolocation: {
    desiredAccuracy: BackgroundGeolocation.DesiredAccuracy.Navigation,
    stopTimeout: 15,                           // minutes
    showsBackgroundLocationIndicator: false,
    stationaryRadius: 25,
    pausesLocationUpdatesAutomatically: false, // iOS; symptom occurs with and without this
    activityType: BackgroundGeolocation.ActivityType.Other,
  },

  activity: {
    stopDetectionDelay: 15,                    // minutes (see question 6)
    disableMotionActivityUpdates: false,
    motionTriggerDelay: 30000,                 // Android only (see question 7)
  },

  persistence: {
    maxDaysToPersist: 1,
  },

  http: {
    autoSync: false,                           // we upload trips ourselves
    batchSync: false,
  },

  app: {
    stopOnTerminate: false,
    preventSuspend: true,
    heartbeatInterval: 60,
    startOnBoot: true,
    enableHeadless: true,
    notification: {
      title: "CityRhythm",
      text: "Enjoy your journey!",
      channelName: "CityRhythm",
      smallIcon: "drawable/ic_notification",
      largeIcon: "drawable/ic_notification",
      priority: BackgroundGeolocation.NotificationPriority.Default,
      sticky: false,
    },
  },

  logger: {
    debug: false,                              // true in dev builds
    logLevel: BackgroundGeolocation.LogLevel.Warning,  // Verbose in dev builds
  },
});

// NOT set anywhere (left at plugin defaults):
//   disableStopDetection, distanceFilter (so 10), disableElasticity,
//   elasticityMultiplier, useSignificantChangesOnly, locationAuthorizationRequest,
//   activityRecognitionInterval, minimumActivityRecognitionConfidence,
//   speedJumpFilter, stopOnStationary, desiredOdometerAccuracy


iOS `Info.plist` (relevant keys):


<key>UIBackgroundModes</key>
<array>
  <string>location</string>
  <string>fetch</string>
  <string>processing</string>
</array>
<key>BGTaskSchedulerPermittedIdentifiers</key>
<array>
  <string>com.transistorsoft.fetch</string>
  <string>com.transistorsoft.customtask</string>
</array>
<key>NSMotionUsageDescription</key>                      <string>…</string>
<key>NSLocationWhenInUseUsageDescription</key>           <string>…</string>
<key>NSLocationAlwaysUsageDescription</key>              <string>…</string>
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>  <string>…</string>
<key>TSLocationManagerLicense</key>                      <string>…</string>


Android: `tslocationmanagerVersion = "4.3.+"` (via Gradle ext vars), license key supplied.
Location permission granted as **Always** / **Allow all the time**; Motion & Fitness (iOS) and
Physical Activity (Android) permissions granted.

[Optional] Relevant log output

[christocracy]

The latest version is 5.4.0.

When you have the same problem on both iOS and Android, that strongly points to a problem in your own Javascript code. There is no correlation between the iOS and Android SDK other than a mostly common API. iOS is written in Obj-c, and Android with Java.

I just took a ~200km roadtrip this weekend with iOS and Android devices. In addition to daily field-testing, I'm not seeing any issues.

What can stop location delivery mid-trip, well before stopTimeout elapses, on either
platform? This is our main question — a 3½-minute-old trip being cut with the motion API
reporting on_foot @ 100 % is the part we cannot explain from the docs.

Unknown. Could be a crash in your own Javascript.

On iOS with pausesLocationUpdatesAutomatically: false, our reading of the docs is that
location-services should never be turned off by the plugin. Is that correct,

Yes.

and can anything override it (desiredAccuracy: Navigation, activityType, Low Power Mode, iOS
suspending the app)?

No

Is TSLocationManager 4.3.x validated against iOS 26?

Yes

On Android, what should we check for this symptom — Doze / battery-optimisation
exemption, OEM background restrictions, foreground-service state? Is there a way to detect
from the plugin that the service was throttled rather than legitimately parked?

See https://dontkillmyapp.com

What is the intended mechanism that resumes tracking after the plugin parks, on each
platform? Should changePace(true) from JS always work in that state, and should
onActivityChange continue to be delivered while parked?

Tracking resumes after the device moves at least 200 meters, regardless if terminated or app in background.

Does preventSuspend: true / heartbeatInterval: 60 keep the heartbeat firing in this
state? We do not appear to receive heartbeats during the gaps. On iOS, if
preventSuspend is inoperative when pausesLocationUpdatesAutomatically: false,

iOS preventSuspend should be avoided. See the API docs for detailed information.

is there any way to keep a JS watchdog alive?

No, impossible.

Is stopDetectionDelay expressed in minutes or milliseconds in 5.x?

milliseconds

Config summary table say minutes, but the ActivityConfig example in the docs uses
stopDetectionDelay: 10000 // 10s. We currently pass 15, intending 15 minutes.
Could motionTriggerDelay: 30000 be implicated in the Android non-resume?

You're jumping at shadows. It's very hard to get the SDK to not track location.

That being said, I would avoid this on iOS: showsBackgroundLocationIndicator: false.

recently to avoid false trip starts from indoor pottering; we would like to confirm it
cannot suppress a genuine resume.

It does not.

Are there known issues with React Native 0.81 / New Architecture where the native side
keeps running but JS stops receiving plugin events?

No. It's very rare for the React Native side to interfere with the proper operation of the SDK. It certainly does not cause it to "stop tracking in the middle of a session". In the very rare case the React Native interferes, things tend to not work at all / build failures.

[PolizerBruno]

We are seeing a very similar symptom after upgrading to v5.4.0, on both iOS and Android.

This is not only visible in background tracking: getCurrentPosition is also timing out with 408 while the SDK/provider state looks healthy.

One production Sentry event captured at the moment of the timeout:

enabled=true
locationEnabled=true
gps=true
network=true
authorization=3
lastLocationAge=466s

Our request is:

await BackgroundGeolocation.getCurrentPosition({
  samples: 1,
  persist: true,
  desiredAccuracy: 50,
  timeout: 20,
  maximumAge: 30000
});

So in this case the SDK reported itself enabled, location services enabled, GPS/network available and authorization granted, but no onLocation had been received for 466 seconds (7m46s), and an explicit getCurrentPosition still failed after 20 seconds.

This is affecting a production check-in flow where location is mandatory. We did not receive these user complaints before the upgrade to v5; after the upgrade, the timeout became visible to users on both platforms.

We are preparing a controlled rollback test to v4.19.4 while keeping the same application behavior/configuration as closely as possible, to compare the 408 rate.

[christocracy]

Are you able to reproduce this?

[PolizerBruno]

We reproduced getCurrentPosition timeout on a physical Android device, but we have not yet reproduced the complete “tracking stops and does not resume after movement” sequence described in this issue.

Test environment

react-native-background-geolocation: 5.4.0
Device: Samsung Galaxy A16 (SM-A166M)
OS: Android 16
App state: foreground

We used the same getCurrentPosition options from our previous comment.

Observed timeline

20:27:57.392Z  onLocation
accuracy=400m
activity=still
confidence=100
is_moving=false
provider.enabled=true
provider.gps=true
provider.network=false
authorization=3

20:28:02.379Z  getCurrentPosition started

20:28:22.530Z  getCurrentPosition rejected
Error: 408

20:28:22.581Z  onLocation error callback
408

The request failed after approximately 20 seconds. No location satisfying desiredAccuracy: 50 was produced during that interval.

Since the only available location had 400m accuracy and the network location provider was unavailable, this particular result may be an expected acquisition timeout rather than the stalled tracking state reported in this issue. We therefore consider this a partial reproduction only.

This test raised one question: when tracking is started or restarted in an area with poor GNSS reception, can start() resolve with enabled: true before the SDK has obtained a usable location fix?

If an accurate position is required immediately afterward, should the application wait for an onLocation event meeting the required accuracy before calling getCurrentPosition(), or is getCurrentPosition() itself the recommended mechanism for waiting for that initial fix?

Is 408 the expected result in this situation, even when a recent coarse location has already been received?

We are continuing to test whether the production cases occur shortly after tracking starts in areas with poor location reception. We will report back if we reproduce the complete non-resume condition with verbose native logs.

[christocracy]

Why this became visible after the v5 upgrade

The v4 plugin ran a 3.x native SDK; v5 runs 4.x. In 3.x, getCurrentPosition fed the last known location into the request unconditionally, and maximumAge was not implemented on Android at all. With samples: 1 that completed the request immediately — you got the cached fix, whatever its age or accuracy, and the SDK never even asked for a fresh one. On timeout it likewise returned any sample it had rather than an error. In practice 408 was nearly unreachable while any last known location existed.

In 4.x, desiredAccuracy and maximumAge became real thresholds. That was deliberate — the old behaviour would happily hand you an hours-old fix — but it means a request that previously resolved with a coarse location now goes to the GNSS hardware and can fail outright.

So your rollback test would show a lower 408 rate, but not because v4 was locating better. It was returning the same coarse fix you're now rejecting.

Note:
Your own log shows why that is plausible: provider.network=false. The Network Location Provider was disabled on that handset, which removes Wi-Fi/cell positioning and leaves GPS as the only source. Indoors, GPS-only can easily produce nothing for 20 s. Please check Settings → Location → Location Services → Google Location Accuracy (and Wi-Fi/Bluetooth scanning) on the A16 and tell me whether it was off. No SDK setting compensates for that.

What to change now
If the check-in flow wants "the best fix available quickly", set a threshold the cached fix can actually meet and judge accuracy yourself:

const location = await BackgroundGeolocation.getCurrentPosition({
  samples: 1,
  persist: true,
  timeout: 30,
  maximumAge: 30000,
  desiredAccuracy: 1000
});

if (location.coords.accuracy > 50) {
  // decide in app code: accept, warn, or re-request
}

I'm going to run some tests on this behaviour with the latest SDK. It seems to me that if a cached location exists, the SDK should never 408, regardless if the fix doesn't fit the windows (maximumAge, desiredAccuracy).

[PolizerBruno]

We checked that exact setting.

“Improve Location Accuracy” was enabled during the test where a recent 400 m fix was rejected and getCurrentPosition returned 408.

We then disabled it, and the same request immediately accepted a 2000 m fix.

Improve Location Accuracy ON
gps=true
network=false
onLocation accuracy=400m
getCurrentPosition ERROR 408

Improve Location Accuracy OFF
gps=true
network=false
getCurrentPosition OK accuracy=2000m

Both tests used exactly:

{
  samples: 1,
  persist: true,
  timeout: 20,
  maximumAge: 30000,
  desiredAccuracy: 50
}

Therefore, disabling Google Location Accuracy did not produce the 408 in this test.

It caused the much coarser 2000 m fix to be accepted, while the 400 m fix obtained with it enabled was rejected.

[christocracy]

It caused the much coarser 2000 m fix to be accepted, while the 400 m fix obtained with it enabled was rejected.

What were the timestamp of the 400 vs 2000 meter fixes?

[PolizerBruno]

I need to clarify one misleading implication in my previous comment: these were not controlled before/after tests performed at the same location.

The direct answer regarding the timestamps is:

• The recorded 2000 m fixes have internal location timestamps ranging from 19:33:40.710Z to 19:39:58.720Z.
• The 400 m fix has location.timestamp=20:27:57.392Z and was delivered to our JavaScript listeners at 20:27:57.677Z and 20:27:57.683Z.

Both test sessions were performed using the same Android device and the same getCurrentPosition configuration. However, they occurred at different malls and in separate sessions, so this was not a controlled A/B test where only Google Location Accuracy was changed.

These two separate test sessions at different shopping malls, approximately 2.63 km apart, as part of a simulated courier route. This represents our actual use case: a courier may enter a mall to collect or deliver orders, or may launch the app and start tracking while already inside the building, where GNSS reception is poor.

All timestamps below are UTC on August 21, 2026.

Both tests used the same getCurrentPosition configuration:

{
  samples: 1,
  persist: true,
  timeout: 20,
  maximumAge: 30000,
  desiredAccuracy: 50
}

2000 m scenario — Google Location Accuracy disabled

For this test, the app was launched and tracking was started from inside the first mall.

Our JavaScript diagnostic logger recorded the following 12 onLocation callbacks with coords.accuracy=2000. The table contains both the callback timestamp and the location’s internal timestamp:

callback timestamp        location.timestamp       activity  isMoving  event
19:33:40.752Z             19:33:40.710Z            still     true      motionchange
19:33:40.841Z             19:33:40.733Z            still     true      -
19:33:57.562Z             19:33:57.539Z            still     true      motionchange
19:39:41.217Z             19:39:41.155Z            still     false     motionchange
19:39:42.261Z             19:39:42.222Z            still     false     motionchange
19:39:42.383Z             19:39:42.254Z            still     false     -
19:39:46.211Z             19:39:46.167Z            still     false     motionchange
19:39:46.276Z             19:39:46.189Z            still     false     -
19:39:58.764Z             19:39:58.720Z            still     false     providerchange
19:40:06.601Z             19:39:58.720Z            walking   true      motionchange
19:40:08.225Z             19:39:58.720Z            walking   true      motionchange
19:40:08.283Z             19:39:58.720Z            walking   true      -

All 12 callbacks reported the same coordinates and accuracy=2000. The final four callback records share the same internal location timestamp, 19:39:58.720Z, and therefore appear to reference the same fix.

The corresponding provider-change entry was:

19:39:58.712Z  onProviderChange
accuracyAuthorization=1
gps=false
network=false
enabled=false

The provider became enabled again shortly afterward:

19:40:07.038Z  onProviderChange
accuracyAuthorization=1
gps=true
network=false
enabled=true

During this period, getCurrentPosition repeatedly resolved with 2000 m results:

19:39:42.075Z  getCurrentPosition started
19:39:42.440Z  getCurrentPosition OK
accuracy=2000m

19:39:45.944Z  getCurrentPosition started
19:39:46.321Z  getCurrentPosition OK
accuracy=2000m

19:40:08.103Z  getCurrentPosition started
19:40:08.336Z  getCurrentPosition OK
accuracy=2000m

Later, after tracking was started again and changePace(true) completed:

19:44:10.907Z  tracking started
enabled=true
gps=true
network=false
authorization=3

19:45:06.629Z  changePace(true) completed
enabled=true
gps=true
network=false
isMoving=true

19:45:17.259Z  getCurrentPosition started
19:45:17.588Z  getCurrentPosition OK
accuracy=2000m
isMoving=true

Unfortunately, our getCurrentPosition OK diagnostic entry preserved the promise-resolution timestamp, accuracy and UUID, but not the returned location’s own location.timestamp.

Therefore, I cannot determine from the JavaScript diagnostics whether the result returned at 19:45:17.588Z was a previously recorded fix or a newly acquired 2000 m fix.

400 m scenario — Google Location Accuracy enabled

This was a separate test session at the second mall. A new diagnostic session started at 20:27:34.285Z.

Google Location Accuracy was enabled in the Android settings for this test, although the SDK provider state still reported network=false.

One location fix was delivered twice to our JavaScript listeners:

callback timestamp        location.timestamp       accuracy  activity  isMoving  event
20:27:57.677Z             20:27:57.392Z            400m      still     false     providerchange
20:27:57.683Z             20:27:57.392Z            400m      still     false     motionchange

The provider state included in the first callback was:

enabled=true
gps=true
network=false
authorization=3
accuracyAuthorization=0

The subsequent getCurrentPosition request produced the following result:

20:28:02.379Z  getCurrentPosition started

20:28:22.530Z  getCurrentPosition rejected
Error: 408

20:28:22.581Z  onLocation error callback
408

The 400 m fix was approximately five seconds old when getCurrentPosition started and was within our maximumAge: 30000 window. However, getCurrentPosition did not resolve with that fix and eventually timed out with 408.

Our JavaScript diagnostic logger recorded no better fix during the request.

[christocracy]

could you provide LogLevel.verbose logs from .emailLog from these tests?

[PolizerBruno]

Unfortunately, we did not capture LogLevel.verbose logs through .emailLog() during those tests, so we cannot provide them now.

We can prepare another test build and try to reproduce both scenarios with verbose logging enabled, but we will likely only be able to send those logs sometime next week.

[christocracy]

That would be super helpful.