Location service doesn't stop after closing app

[mpuchala]

Platform: Android
Mapbox SDK version: 5.0.2

Steps to trigger behavior

1. Open app with map (in my situation fragment with map)
2. Request for tracking user location
3. Go back from app

Expected behavior

Location service stops after user closes app

Actual behavior

Location service is working in background

Hey guys,

I was using API 4.1, now I'm switching to API >5.0 (5.0.2) and there is an issue with location service I mentioned. After user closes an app it's still requesting for his location. Maybe I haven't found a method which I have to use in new API to avoid it, but it's pretty easy to see this problem in your "Mapbox Dev Preview" (Menu -> User location -> Track user location -> Back button -> Back button). App is closed (in background), but location service works, only killing the app stops it. It's not possible to release an app with that issue (battery).

If it's known issue, or there is something I should now I would appreciate a suggestion how to resolve it.

[mpuchala]

@tobrun

I found possible problem, would be great if you can take a look on it.

It looks like there are two LostApiClients. In onStop() method we call mapboxMap.onStop() then trackingSettings.onStop(), myLocationView.onStop() and then we toogleGps(false). Inside this method there is locationEngine.deactivate(); which seems to not work properly. LocationSource's method deactivate() is trying to disconnect lostApiClient but LostApiClientImpl's clientManager contains two clients (HashSet) which seems to be the same. One is being removed, but the other still exists, thats why (probably) LocationProvider isn't disconnected and Location Service is working in background.

That's only my guess, I don't know why there are two clients, but I hope it would be helpful for resolve this issue.

EDIT:
I see another interesting thing. In LocationSource class you have constructor which is used in Mapbox class and singleton instance. According to situation I described above, you remove singleton object from HashSet, but object created in Mapbox class isn't removed in onStop() method. I see it's used by MapboxTelemetry which isn't stopped probably.

[zugaldia]

@mpuchala Thank you for the report.

but it's pretty easy to see this problem in your "Mapbox Dev Preview" (Menu -> User location -> Track user location -> Back button -> Back button). App is closed (in background), but location service works, only killing the app stops it.

We're tracking an issue in the demo app where we're likely setting up an extra location engine unnecessarily: mapbox/mapbox-android-demo#248. By default, the SDK only sets up one location engine using the passive location provider so shouldn't see any active requests from the SDK by default.

I found possible problem, would be great if you can take a look on it. It looks like there are two LostApiClients.

There was an issue with the LOST library (which we use under the hood to handle our location updates) that had an incorrect behavior when more than one client was set up. We fixed this with #8667 and we expect to release this fix with the next 5.1 version.

Finally, something related that you might be interested in is #8710. Once this PR lands you'll be able to set your own LocationEngine (while still providing a default LocationSource). I hope this helps.

[mpuchala]

Hey,
Thanks for clarification.

[tobrun]

additional information on this issue can be found in #8787

[tobrun]

Been looking into this issue and was able to confirm that disabling telemetry (commenting out) resolves the issue. The underlying issue will be the set up of LocationEngine/Source.

[mpuchala]

I guess it works for new users, if you update app Telemetry Service works in background, so probably Location Service won't be closed until user kills app (for the first time).

[tobrun]

Found the issue in Mapbox.java:

LocationEngine locationEngine = new LocationSource(appContext);
// vs
LocationEngine locationEngine = LocationSource.getLocationEngine(appContext)

We are now creating two instances of the lost api client, while there should only be one.