Plugin doesn't send location updates when the screen goes off

[colenso]

Your Environment

• Plugin version: 4.11.4
• Platform: Android
• Device OS version: 11
• Device manufacturer / model: Realme X2
• Android Studio version: Chipmunk | 2021.2.1 Patch 1
• Capacitor info (npx cap doctor)

  @capacitor/core: 4.6.1
  @capacitor/android: 4.6.1
  @capacitor/cli: 4.6.3
  @capacitor/ios: 4.6.1

• Plugin config provided to #ready:

  {
  stopOnTerminate: false,
  foregroundService: true,
  url,
  headers,
  debug: true,
  xhrFields,
  httpRootProperty: '.',
  locationTemplate,
  distanceFilter: 30,
  elasticityMultiplier: 1.5,
  heartbeatInterval: 60,
  showsBackgroundLocationIndicator: true,
  notification: {
  title: 'Background Tracking Enabled',
  text: 'Your location is being sent to XBE.'
  },
  locationAuthorizationRequest: 'Always',
  backgroundPermissionRationale: {
  title: "Allow App to access to this device's location in the background?",
  message: "In order to track your activity in the background, please enable {backgroundPermissionOptionLabel} location permission\n",
  positiveAction: "Change to {backgroundPermissionOptionLabel}",
  negativeAction: "Cancel"
  }
  }

Expected Behavior

Location updates should continue to be sent to our server even when the phone's screen is off.

Actual Behavior

Location updates stop when the phone's screen is turned off.

Steps to Reproduce

I turned on debug mode and am trying to figure out what's happening based on the sound. https://transistorsoft.github.io/capacitor-background-geolocation/interfaces/config.html#debug Here's what's happening: In the list I can't seem to find the first sound notification that is played when it begins. In the foreground, I get the notification sound location_sample and then location_recorded. After I put it in the background and turned off my screen, it would stay silent and when I turned back the screen on, it picked up again started with the initial notification sound, then the location_sample, then location_recorded. Tried it a few times, it did the same way every time.

Context

I was trying to check if location updates are being sent in the background.

Debug logs

Since the logs were too big to be pasted directly here on github, here's a link to the logs: https://sharetext.me/9ovumqyann

[colenso]

@christocracy Can you please help find what the issue could be? If there's any info I can provide to help with this, let me know.

[christocracy]

• See https://dontkillmyapp.com

How are you testing? The device needs to move at least 200 meters before tracking automatically engages.

[colenso]

Sorry for the delay in the response. But yes. We tested with movement > 200 meters as well.

[christocracy]

See https://dontkillmyapp.com

[jingdaradal]

so this is something that we can't prevent even if we bought the plugin? We should really ask the user to exclude the app from battery optimization?

[christocracy]

That’s right. It’s well known that various Android manufacturers are violating the Android api to preserve battery drain at the expense of functioning apps. There is no software solution to manufacture violations.

Also see this: https://issuetracker.google.com/issues/122098785?pli=1

[jingdaradal]

am i correct that the onMotionChange "ismoving" is your workaround on this? since it detects after 200m that the mobile has moved it will wakeup the app again?

[christocracy]

is your workaround on this?

No. There are no “workarounds” to this plug-in. That’s part of the core philosophy of operation, to conserve energy by turning off location-services when the device is detected to be stationary (what’s the point wasting energy when the device is setting at the same place?).

[jingdaradal]

What i mean is that. even if my screen is off and the app has turned to sleep, the onMotionChange event can make it possible to wake and record and send data to my server again?

[christocracy]

The plug-in monitors the Activity recognition api as well as a geofence around the last known location. Both of these APIs are publicly documented in the Android api of operating even of the app is terminated, in addition to merely having the screen off.

[jingdaradal]

I tried to go out on a bicycle. I stopped to add air to my tire for probably 15mins. the travel took me 45mins without looking at my phone. when i arrived home and check the coordinates i got in my server. i noticed that the sending of data stopped where i fixed the tire. Is this normal? should it resume after 200m? by the way, i brought 2 phones with me. Samsung s22 and huawei. both have the same coordinates where i stopped.

[christocracy]

See api docs Config.stopTimeout.

yes, it’s normal. Read the wiki “Philosophy of Operation”.

[CraigMcloughlin]

@christocracy - In @jingdaradal's case, I can see why it would stop sending where the tire was fixed. But after he was back moving again, shouldn't the phone Activity recognition have changed state from stationary to moving again after 200m or so? (Providing battery optimisation is switched off for the app and the other hoops that the phone manufacturer may need to not kill it off?)

[christocracy]

But after he was back moving again, shouldn't the phone Activity recognition

In a perfect world, yes. He should provide logs showing what the plugin was doing during that time after stopping.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.