[Help Wanted]: Android app killed after inactivity – background tracking stops when app is reopened

[cesarmartinssjr]

Required Reading

• Confirmed

Plugin Version

4.18.2

Mobile operating-system(s)

• iOS
• Android

Device Manufacturer(s) and Model(s)

Samsung Galaxy S23+

Device operating-system(s)

Android 14

What do you require assistance about?

Hello Transistor Software team,

I'm using the Flutter Background Geolocation plugin on Android and would like confirmation that my current startup and configuration strategy is correct for continuous walking tracking, where the device may remain locked in the user's pocket for long periods.

Context / Use case

• User walks continuously for long periods (field work)
• Device stays locked in the pocket most of the time
• Tracking must never stop while the user is working
• Android may kill the Flutter process due to inactivity
• When the app is reopened, Flutter should reconnect to the existing native tracking service

Observed behavior

• After a long period with the screen locked, Android kills the Flutter process
• When the user opens the app again:
  • The app restarts from the initial screen (expected)
  • Flutter state is lost (expected)
  • There are no visible errors or crashes
• From the Flutter side, it looks like a clean cold start

Important note about logs

There is no relevant log output to attach, because:

• The app is not crashing
• No exception is thrown
• Android simply kills the Flutter process
• When reopened, the app just starts from the initial screen

Because of this, there are no error logs indicating a failure in the plugin itself.

Requirement

My requirement is that tracking must never stop, even if the Flutter process is killed and later relaunched.

If the native BackgroundGeolocation service is still running:

• Flutter should detect this on startup
• Flutter should reconnect to the existing tracking state
• Tracking should continue seamlessly

Questions

• Is it expected behavior on recent Android versions that the Flutter process is killed while the native service keeps running?
• Is checking BackgroundGeolocation.state on app startup the correct strategy?
• Is explicitly calling changePace(true) on app relaunch the correct way to force reconnection to the moving state?
• Are foregroundService, stopOnTerminate, enableHeadless, and heartbeat sufficient for this use case?
• Is startOnBoot unnecessary when tracking is always user-initiated?
• Are there any additional Android or OEM-specific considerations (e.g. Samsung)?

[Optional] Plugin Code and/or Config

// Plugin initialization (called once)
await bg.BackgroundGeolocation.ready(
  bg.Config(
    desiredAccuracy: bg.Config.DESIRED_ACCURACY_HIGH,

    // Distance-based tracking at approximately every 10 meters
    distanceFilter: 10,

    // Prevents automatic scaling of distanceFilter based on speed
    disableElasticity: true,

    // Fallback interval to avoid long gaps between updates
    locationUpdateInterval: 5000,

    // Prevents automatic transition to stationary mode
    stopOnStationary: false,

    // Disables auto-stop when the user slows down or pauses briefly
    stopTimeout: 0,

    activityType: bg.Config.ACTIVITY_TYPE_FITNESS,
    stopOnTerminate: false,
    startOnBoot: false,
    enableHeadless: true,
    heartbeatInterval: 30,
    preventSuspend: true,
    foregroundService: true,
    debug: false,
    logLevel: bg.Config.LOG_LEVEL_OFF,

    notification: bg.Notification(
      title: 'Sangria em andamento',
      text: 'Rastreando sua sangria',
      channelName: 'Localização',
      priority: bg.Config.NOTIFICATION_PRIORITY_HIGH,
      sticky: true,
    ),

    maxDaysToPersist: 7,
    maxRecordsToPersist: 10000,
    autoSync: false,
  ),
);

// On app startup / relaunch
final existingState = await bg.BackgroundGeolocation.state;

if (existingState.enabled) {
  // Forces the plugin back into "moving" state if tracking was already active
  await bg.BackgroundGeolocation.changePace(true);
} else {
  await bg.BackgroundGeolocation.start();
  await bg.BackgroundGeolocation.changePace(true);
}

[christocracy]

The plug-in doesn't care if the OS terminates the foreground Activity. Tracking is unaffected, as long as you configure stopOnTerminate: false.

[cesarmartinssjr]

I understand that the native tracking service continues running when stopOnTerminate: false, even if Android terminates the foreground Activity or the Flutter process.

What I’m actually looking for help with is configuration validation.

Based on my use case and the configuration I shared, I’d like to know if there is anything misconfigured or suboptimal that could explain tracking not behaving as expected after long periods with the screen locked.

Thanks for your help.

[christocracy]

stopTimeout: 0,

What are you hoping to achieve with that?

[christocracy]

The first thing I do when something unusual happens is test with debug: true and verbose logging (then analyze logs when I return from a field test using .emailLog)

Also see https://dontkillmyapp.com

[cesarmartinssjr]

stopTimeout: 0,

What are you hoping to achieve with that?

The intention with stopTimeout: 0 is to prevent the SDK from automatically transitioning to the stationary state during brief slowdowns or short pauses.

[christocracy]

The intention with stopTimeout: 0 is to

you've achieved the opposite of your intention, telling the plug-in to wait 0 seconds to transition to the stationary state when the motion api reports the device is not moving.

You want to increase stopTimeout to a higher number, not zero.

[cesarmartinssjr]

The intention with stopTimeout: 0 is to

you've achieved the opposite of your intention, telling the plug-in to wait 0 seconds to transition to the stationary state when the motion api reports the device is not moving.

You want to increase stopTimeout to a higher number, not zero.

Understood.

Given my use case, continuous walking sessions lasting roughly 1 to 4 hours, with the device locked and in the pocket most of the time, what stopTimeout value would you recommend in practice?

[christocracy]

Have you read the api dos for stopTimeout? Have you read the wiki here "Philosophy of Operation"?

I suggest you go outside for a walk with debug: true and learn what the debug sound FX mean. See api docs Config.debug to learn what they mean.

[cesarmartinssjr]

Yes, I’ve read both the API docs for stopTimeout and the Philosophy of Operation wiki.
I’ll increase stopTimeout to a higher value and validate the behavior empirically by testing in the field with debug: true and observing the debug sound FX during long walking sessions.
Thanks for the clarification.