I'm in the same boat: I always have voice directions turned off (I find them annoying), and I just look at the map when I want to know where to go next, so I have no need for the app to access my location when it's not open (before even getting into the privacy and battery life concerns).

This used to work perfectly fine, but since the last update the app will now nag for permissions on every run if you don't give it "at all times" location access.

If I were a new user to the app, such an invasive request would have probably been enough for me to uninstall it and try something else, which would have been a shame as C.T is by *far* my favourite cycle router.

There’s a couple of associated things here. Two points first: one is that I’m actively working on it, and the other is that this part of Android is an absolute nightmare to develop for. (Lots of Android is hard work, but this bit is really hard work!)

Background navigation: it only accesses location in the background if you have a route open. The notification says ‘cycle.travel is using location in the background’ if you don’t have a route open, but it isn’t, this is just Android being Android. At some point in the future I will have a go at removing the notification in these circumstances, but right now I am loth to create a further source of instability by doing so.

(Technical explanation: the app uses a ‘foreground service’ to look up location. When the app goes into the background, if you don’t have a route open, this service stops looking for location. The service is still running, which is why the notification persists, but it isn’t doing anything. In theory it should be possible to stop the service at this point, at which point the notification would disappear. But there are enough issues with Android arbitrarily deciding not to start the service that, right now, I don’t trust that it will reliably restart it on reopening the app.)

The use case of wanting to keep a route open in the background, but not navigate, is not one I’d thought of but it shouldn’t be at all difficult to support. I’ll take a look. In the meantime, you can download planned routes for offline use which will get round the internet access issue – just find the route in the route list, and long-press to get a popup menu with a download option.

Permission nags: this isn’t the app intentionally being needy, this is just Android being Android again. I have (I think) come up with a workaround for the next version of the app that will stop them. (Technical explanation: Android doesn’t actually differentiate between “the user has just clicked ‘no permission’” and “the user clicked ‘no permission’ a week ago”.)

I know Android vs iPhone is a bit of a holy war and not one I’d want to wade in on, but it really is remarkable how much harder Android is to develop for!

Thanks, I appreciate you looking into this.

Some more information on my use case, I have granted location permissions "only while the app is running", like so (iirc, until this update, "all the time" wasn't even an option):

Whenever I open the app, I get these screens:

The text in the latter popup is misleading, because after I dismiss it I'm able to then "navigate" just fine, it just won't give directions when the app is minimized, which is exactly the behaviour that I want:

I think for me to be happy to app again, the only change that would need to be made would be for the app to treat the "Only while using the app" option as a valid user choice, and not to request permissions again once this has been obtained. I appreciate that the Android APIs may make this more complex than I've described it here though :)

Please feel free to reach out to me if you have any questions, I'm a dedicated user and supporter of this app and a software dev myself so I should be able to give detailed and useful answers!

Update: I also still get this un-dissmissable lock screen notification whenever the app is running, even with the "only while using the app" setting selected. I had forgotten about this because I muted all C.T notifications after the first few times it happened.

Suffice to say, none of this used to happen, I don't think I'd be a C.T user if it did!

Yep – that’s all as mentioned above. The nag should be addressed in the next version, but the notification will persist at present because I’m not confident that Android will reliably restart the service on re-entering the app.

Thank you, I will be patient.

In the mean time, I've found that unchecking "Allow Notifications", "Allow foreground activity" and "Allow background activity" in the Android App Management settings goes a long way to restoring the pre-update behaviour.

Thanks, Richard (and Dan, for useful expansion)