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?
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.