-1

I have developed a Android hybrid app that amongst other activities tracks the users location and displays it to the user showing where they have been recently. This works by invoking LocationServices.FusedLocationApi.requestLocationUpdates at a 10 second update rate.

Obviously this requires location permission and for ANDROID Marshmallow and above I check and request the necessary location privileges from the user before requesting location updates.

I have read many other StackOverflow question about the same topic but I have not found a satisfactory answer about preventing Android from terminating the app if location permission is revoked for the app by the user after initially granting it.

I would be more than happy for the app to stop displaying the user's location and track, after all the user has asked for it to be stopped, but I am far less happy for the app to be terminated, as I said earlier the app does many other things for the user whilst running in the background.

As far as I understand there is no callback that can be used to allow me to remove the location updates as soon as the location permission is revoked. How could I change my strategy to avoid the app crashing?

It is not that I am expecting users to do this very often, but I think it good practice to make the app as bulletproof as possible. Please do not remind me that Android can terminate any app in the background as that is not my question here.

Do I need to adopt a singular rather than a periodic approach to requesting the location so that I can re-check the permission exists each time.

Or is it better to try and catch the error. If so where do I do this? Would it be inside onLocationChanged?

Nimantha
  • 6,405
  • 6
  • 28
  • 69
Steve Brooker
  • 1,043
  • 11
  • 28
  • "How could I change my strategy to avoid the app crashing? " -- it's unclear where you think that your app would crash. Your process will be terminated when the user revokes the runtime permission. When the user runs your app again, you check the runtime permission and take appropriate steps. What exactly is the crashing scenario? "By the way someone just downvoted this question faster than they could have read it." -- if I had to guess, it was the all-caps title that you had originally. But, that's just a guess. – CommonsWare Apr 01 '18 at 17:55
  • Thanks. I wondered if that was too, but I didn;t spot it and it took me several seconds to correct it. – Steve Brooker Apr 01 '18 at 21:03
  • What I mean by app crash is that the process is terminated (I have checked and this actually happens). Now this causes problems for the user that I wish to avoid. Firstly they will have to log back in as the web app data is encrypted and requires a password to decrypt it. Secondly this will stop all comms traffic to/from my server. And thirdly the user will not know why the app has stopped working. What I would like to do is prevent the process terminating if there is any way I can do this. – Steve Brooker Apr 01 '18 at 21:09

2 Answers2

1

What I mean by app crash is that the process is terminated (I have checked and this actually happens)

That's perfectly normal, when the user revokes a runtime permission.

What I would like to do is prevent the process terminating if there is any way I can do this.

Sorry, that is not possible.

Since I suspect that few users even know that they can revoke runtime permissions, this is not going to be a common occurrence, IMHO.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thanks for the thoughts. I expect you are correct in that few users will do this, however why did the Android developers not just cause a callback to be generated to allow the app code base to react, and at the same time stop issuing any more location updates. It seems to me that almost every other user action can be trapped. This is surely a big omission. – Steve Brooker Apr 01 '18 at 21:26
  • @SteveBrooker: "It seems to me that almost every other user action can be trapped" -- you cannot trap when Android terminates your process in general, such as when the user presses "Force Stop" on your app's screen in Settings. "This is surely a big omission" -- I expect that this is done for security reasons. – CommonsWare Apr 01 '18 at 21:29
  • Do you know off hand whether I it would be practical to set up a process to get a single location fix and set a timer to redo this in say 60 seconds time checking the permission each time, all whilst in the background? – Steve Brooker Apr 01 '18 at 21:30
  • At least with force stop, the user will know the app is to stop. It would be all to easy for a user to scroll down the list of apps with location rights in the settings menus and switch the wrong one off by mistake. – Steve Brooker Apr 01 '18 at 21:32
  • @SteveBrooker: Doing anything in the background in modern versions of Android is troublesome, unless it is a continuously-running foreground service. I assume that's what you're using now, and that service goes away when the process dies. You could use `AlarmManager` or `JobScheduler` for a "watchdog", to invoke your service in case it had stopped running. However, you won't get every-minute operation when the device is in Doze mode. – CommonsWare Apr 01 '18 at 21:41
  • Thanks. I expect I need to separate out the web app process from the location update process, so that only one gets stopped. It seems that the ability to market a simple automated location tracking and reporting device using a cheap Android phone is vanishing fast. – Steve Brooker Apr 01 '18 at 21:47
  • @SteveBrooker: "I expect I need to separate out the web app process from the location update process, so that only one gets stopped" -- I haven't played with revoking runtime permissions with a multi-process app. However, since the permissions are an app thing, not a process thing, my gut says that they will both be stopped. – CommonsWare Apr 01 '18 at 21:50
0

Blockquote however why did the Android developers not just cause a callback to be generated to allow the app code base to react

You could register for the LocationManager.PROVIDERS_CHANGED_ACTION in the BroadcastReceiver. When it is hit, you can check if the provider is still enabled and use that accordingly to prevent your app from crashing when someone revokes the location permission.

LocationManager locationManager = (LocationManager) getApplicationContext().getSystemService(Context.LOCATION_SERVICE);
    boolean enabled = locationManager != null && locationManager.isProviderEnabled(LocationManager.GPS_PROVIDER);
Lars
  • 371
  • 3
  • 8