Location tracking is delayed after a period of inactivity

[chris-eaheart]

• Plugin version: 4.16.0
• Platform: Android
• OS version: 14
• Device manufacturer / model: Pixel 7a
• React Native version (react-native -v): 0.73.2
• Plugin config

BackgroundGeolocation.ready({
            desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_HIGH,
            distanceFilter: 10,
            stopTimeout: 5,           // Activity Recognition
            stopOnTerminate: false,   // Application config: Allow the background-service to continue tracking when user closes the app.
            startOnBoot: true,        // Application config: Auto start tracking when device is powered-up.

            // Debugging options
            debug: false,
        })
        .then((state) => {
            BackgroundGeolocation.start();
        })
        .catch(err => {
            console.error('Failed to start location services:', err);
            crashlytics().recordError(err);
        });

Expected Behavior

Tracking should start immediately after moving ~10 meters.

Actual Behavior

Tracking is delayed. I walk over 300 meters (over a ~5 minute period) before tracking is started.

I am using your sample app on a physical device, and have configured the code as indicated above. The below is a walk I took just this morning - the red line indicates that initial part of that walk that was not tracked.

[christocracy]

300 meters is not an unusual distance to travel for tracking to engage.

the plug-in monitors a geofence around the last known position, the exit of which signals that the device is moving.

geofences are monitored by the OS and depend upon the presence of wifi signals and distance and spacing of cell towers. They are also affected by the device and the manufacturer’s own version of the Android OS.

[chris-eaheart]

Ok, I'll have to find a way around this limitation - completely understand that this is not the module itself, but the OS and other external factors.

[christocracy]

Ok, I'll have to find a way around this limitation

I’ve been doing this for over 10 years. There’s no way around it. Particularly so today with targetSdkVersion 34 and increased restrictions on foreground-service launches in the background.