How to keep HTTP requests running in background? - Android

[JuanDeLeon]

First of all, awesome plugin. Now, I understand this is not exactly a plugin's issue, but probably a very common scenario for it.
I'm trying to watch and send the location via HTTP Post request to server as in the following code:

BackgroundGeolocation.addWatcher(
      {
        backgroundMessage:
          "Location is still tracked in background.",
        requestPermissions: true,
        stale: true,
        distanceFilter: 200,
      },
      async function (location) {
        if (location) {
          let formData = new FormData();
          formData.append("location", JSON.stringify(location));
          await ApiService.sendLocation(formData); // Does a simple HTTP post request using Axios.
        }
      }
    );

This is working fine in iOS indefinitely (as long as I grant the 'Always' location permission).

However for Android, this is not the case. I granted all battery/data usage permissions for my app in particular.
After 5 minutes in background, the server will stop receiving locations.
As soon as I enter the app again (it is not being killed btw, I can tell because it does not reload the splash screen) it will start sending all the buffered requests to server.
So the location is being tracked correctly, but it seems like the HTTP requests get blocked and start to pile up.

Does this mean that I should actually do the HTTP request inside the native callback code?
public void onLocationResult(LocationResult locationResult)

I would appreciate any insight, but as I said, I understand this is not precisely this plugin's issue.

[diachedelic]

May I ask what device(s) you are experiencing this issue with?

As a starting point, could you please insert console.log(new Date()); at the start of your watcher callback, and then connect your device via USB and attach a debugger via chrome://inspect. After reproducing the problem, look for a large gap in the logged timestamps. This would indicate that the WebView stopped receiving updates from the plugin at some point.

[JuanDeLeon]

Samsung Galaxy Tab A SM-T510 on Android 10.

I made a quick test editing the Android plugin code, and put an additional HTTP POST call inside the onLocationResult() callback method.
It's interesting because after 5 minutes, both calls start to throttle down. But it seems like the native HTTP is able to "push" the Axios one. (The records with 0.0000 are native, the others are axios).

Then after 5-10 more minutes, I stop getting the Axios call, but keep getting the native one, which is what I want to achieve anyway. So I guess I'll just fork this.

[diachedelic]

There looks to be some throttling going on. The plugin seems to receive location updates every ~10s initially, slowing to one per minute or less. So the operating system might be throttling updates from the location provider to the plugin. But it also looks like the operating system is throttling execution of the WebView, which is disturbing (however I can't tell from your logs whether the watcher callback ceased being called or was just unable to send off HTTP requests).

[diachedelic]

Where do the timestamps in the rightmost column come from? Are they from the location object, or generated by the server?

[JuanDeLeon]

That's the timestamp from server, when it receives the request.
I'll try to test it out as you mentioned, just to confirm if it's throttling the callback or the HTTP requests.
Since entering into the App again immediately starts sending out all "buffered" HTTP requests, I would think it's throttling those, and not the callback.

[diachedelic]

Thanks. It might be illuminating to see the difference between the time the location was generated and the time it was received by the server.

[JuanDeLeon]

So this is what I got in Android Studio console (couldn't use Chrome devtools).
After 5-6 minutes I stopped receiving the Axios calls, that's exactly when console shows "A resource failed to call end" and "FinalizerDaemon".
At this point, the callback keeps being called opportunely, but not the Axios HTTP. (Native HTTP keeps working fine).
*Notice the "mutating IsBusy" log, which is triggered by my API/Axios services.

Finally, when I open the App again, it starts to fire off all queued requests, and logs the following to make it clear:
2021-03-10 23:09:56.183 1124-1124/com.corvustrack.ionic I/Capacitor/Console: File: http://localhost/home - Line 0 - Msg: Some resource load requests were throttled while the tab was in background, and no request was sent from the queue in the last 1 minute. This means previously requested in-flight requests haven't received any response from servers. See https://www.chromestatus.com/feature/5527160148197376 for more details

In conclusion, seems like this is intended by Chrome and I don't pretend my users having to turn this off, so I guess native HTTP is the way to go 👍🏻

[diachedelic]

WebSockets, WebRTC's data channel, Fetch API, XMLHttpRequest, EventSource, Video and Audio are excluded today to allow keep-alive connections.

From the link you pasted above, it appears your Axios requests should not be throttled.

This means previously requested in-flight requests haven't received any response from servers.

The error message seems to indicate that your requests are not receiving responses. Are you sure your server is responding to your requests correctly?

[JuanDeLeon]

Oh I totally missed that. You're right.
However, I cannot think of why my server would just start rejecting axios requests after a few minutes... while actually accepting the "native" requests.
Both have pretty much the same headers and even the same authorization credentials.
Not to mention this all just worked on iOS, with Axios only 🤔

[diachedelic]

Is it possible your server is accepting & processing the requests, but is not sending out any response?

[JuanDeLeon]

Just tested this by putting a log server-side, right before returning the 200 response. It definitely sent the response back.

[diachedelic]

Well I am bamboozled then.

[JuanDeLeon]

Yeah, thanks for keeping in touch.
I'll just use the http plugin for this specifically.
Hopefully someone else will find this useful.

[gbrits]

I am experiencing this issue on Android only exactly as described in the opening post of this thread, I implemented an enqueueing process which I initially thought helped, but then on Android the problem (as described above) persisted. I considered setting up job queueing on my Laravel backend, but that doesn't rectify the fact that after some time Android appears to start spamming GPS locations after adding them up -- it's almost as if backgrounding works temporarily, then stalls, collects GPS to send but doesn't use the callback to send them until the app is foregrounded - then it spams all of the GPS points into your database all at once, causing throttling to occur. @JuanDeLeon did you solve this somehow?