Mapbox-gl-native: 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: https://github.com/mapbox/mapbox-android-demo/issues/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 https://github.com/mapbox/mapbox-gl-native/pull/8667 and we expect to release this fix with the next 5.1 version.

Finally, something related that you might be interested in is https://github.com/mapbox/mapbox-gl-native/pull/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.

[mpuchala]

Would new snapshot contains fix? If not, are you able to estimate when it will be available?

[zugaldia]

@mpuchala Yes. Once https://github.com/mapbox/mapbox-gl-native/pull/8825 lands, the fix will be available in the next nightly SNAPSHOT.

[lidkxx]

So, what should I use with the 'mapbox-android-sdk:5.1.0-beta.4' instead of
private LocationEngine locationEngine = LocationSource.getLocationEngine(myAppContext);
? When I am trying to upgrade from 5.0.2. it says that it cannot resolve getLocationEngine() method.

[tobrun]

@lidkxx you can use the constructor instead since beta.4, no need for a singleton

[lidkxx]

@tobrun Great, it works, thanks! Note: I also had to include compile com.mapzen.android:lost:3.0.1 in my build.gradle which was not required before.

[tobrun]

The reason for this is that the beta.4 version includes a SNAPSHOT of the LOST dependency, for this to work you would have to add

    maven { url "http://oss.sonatype.org/content/repositories/snapshots/" }

to your build.gradle.

FWIW since LOST released a new stable version, we are planning to do a new beta release.

[Petrulak]

What is the proper way to receive location updates and then remove location updates once the app gets to the background? Do you have some sample code (for 5.0.2)?
Thanks

[tobrun]

@Petrulak
First of all the good news, we are aiming for a final 5.1.0 release this week/early next. This will solve this specific issue.

I fear we don't have a proper workaround for you now as the code used is an external dependency. We have been waiting for proper solution but some time has passed an we are opting to revert the LOST dependency to v1.1.1. This version shipped as part of our 4.x series and afaik didn't show major issues as with 2.x or 3.x. Reverting LOST is the final blocker for a release.