It only uses GPS in the background if you have a journey open. Once you've closed the journey (by pressing the stop/speedometer control), and there's no blue line showing on the screen, then it won't use GPS in the background – it expressly shuts it off when you move away from the app.

Thanks. I have Stopped, cleared the route and exited. The notification remains. However having added an additional 'gps in use' indicator to my phone I now see that the cycle.travel apps 'using location to navigate' is not, in fact, correct at this point. 

Perhaps you could clear the notification on exit?

This is happening to me too. Only fix I found was to restart phone.

Perhaps turning off automatic routing in settings stopped it

Chris,

If route planning is all you want, then it would be better to use the C.T website, which has better functionality especially if used on a desktop computer where you can click and drag a possible route with the mouse.

The website can also be used on your smartphone, but makes no use of GPS.

chris

The only way I've found around this is to revoke cycle.travel's notification permissions from the Android Settings app. The notification can't even be dismissed otherwise.

As mentioned above, the app does not use your location in the background if you’re not navigating along a route. The notification says “cycle.travel uses your location when you are navigating along a route”. If you’re not navigating along a route it doesn’t use your location.

The notification remains because the service is still running (but not asking for location or indeed doing anything else). Android requires that a foreground service with the ability to use location shows a notification at all times (“When a foreground service is running, the system raises user awareness by showing a persistent notification” – link).

In theory it may be possible to halt the service when the app goes into the background and you’re not navigating the route, and this may remove the notification. However, a lot of the trauma over the past month has been getting Android to reliably start the location service at all. Right now I honestly do not have the hours in the day to rework this again, and to do the testing on a bunch of devices to see if the delight that is Android will reliably restart a foreground service when the app is resumed, given that the main learning from the past month is that many phones don’t reliably start one when the app is started in the first place. If this is a deal-breaker for you I can only suggest you might be happier with an app with a bigger development team – sorry.

I'm sorry to be a pain about this. C.T is my favourite app (it's why I support it), and I recommend it to every other cyclist I know, which is why it pains me for to see it take such a sharp right turn.

May I ask, candidly, what the impetus was for moving the navigation logic onto a background(foreground?) service in the first place?

I've ridden 100s of miles using C.T to navigate, when there was no background service, and the app only accessed my location while it was in use. This caused no annoying notifications, no invasive permission requests, and no confusion about whether the app was "really" open or not. Directions, distance tracking, ETAs etc all seemingly functioned without it.

(I don’t know why Android calls something that runs in the background a “foreground service”, but that’s fairly typical of the Android developer experience!)

It’s because a lot of people have asked for turn-by-turn directions to continue when the app isn’t on-screen – maybe they’ve got a music app open, or maybe they’ve hit the power button to turn the screen off. And I can see the appeal – turning the screen off greatly reduces the battery draw, so you can keep going for longer. Foreground services are the Android way of doing this.

Teething issues aside, the only other resulting difference in functionality is the notification. Everything else should work the same. 

The notification is enough to stop be recommending the app to people tbh. I trust you're not doing anything nefarious, but a constantly present, undissmissable "we are tracking your location" notification would be a massive red flag for me for a unfamilar app, and would have led me to uninstall it in 5 minutes were I a new user.

I also don't know if  the text is accurate: I granted C.T permission to access my location "Only while using the app" (As opposed to "all the time". As of the very latest update the app at least does not prompt me to upgrade this permissions on every run anymore, thank you for making that change), but the notification says it "uses your location when you are navigation" (actually "uses your location when you are n..." on my display). Does Android count running as a background/foreground service as "using the app"? I honestly don't know if my location is being accessed or not anymore.

I also just noticed while writing this post that C.T "App Settings" page has a toggle to turn off "Background navigation". Does *this* restore the "only use my location while I'm looking at the app" behaviour?

Like I say, I can only do what I can do in the hours available. Getting rid of that notification is going to be a lot of work for what is, ultimately, just two lines of text on a screen.

I understand for some users those two lines of text are important, and when I have the time I will try and see what I can do about it, but given how pernickety (and unpredictable) Android is, I’m not going to just drop a ‘stop the foreground service’ call into onStop and ‘start the foreground service again’ into onResume, deploy the app and hope for the best – this area of Android has been the absolute pain point over the last month so I’m very very wary of touching it without a lot of testing.

The ‘Background navigation’ toggle says “Continue navigating when the app is in the background”. If you turn it off then the app will not continue navigating when it’s in the background (i.e. not on-screen). The exact logic is that when the app goes off-screen, then the foreground service will only continue accessing location if you have both (a) a route open and (b) ‘Background navigation’ set to ‘on’.

The solution isn't "keep wrestling with the foreground service API until you can wrangle it into stopping and starting the service exactly when you need it", the solution is "don't request a foreground service at all when it's not necessary". If the user hasn't granted the app "all the time" location permissions, doesn't have "background navigation" turned on, or doesn't have spoken directions enabled, then the navigation logic should remain on the main process.

(The Android Settings app also lets you disable foreground-processes on an app-by-app basis, as do certain low power modes, so this needs to exist as a fallback anyway)

It's also not just "two lines of text", it's the knowledge that the app can (and to a less trusting user, WILL) track their location 24/7 *even after the app has been closed*. As this thread points out, this notification (and we can only assume pressure: the location access) persists even after the app itself has been closed in the task drawer, and the only way to make it go away is to restart your phone or force-kill the app from the settings menu.

At which point it needs twice the application logic to be aware of location updates, which is not an issue for apps with bigger development teams (Komoot has apparently laid off 75% of their staff, which by my reckoning means they still employ about 70 people) but more of a challenge where the same person writes the code for Android, iOS, website backend, website frontend, routing engine, map tile generation and map tile serving.

Using indie apps made by solo developers means that there are inevitably compromises – not everything can happen all at once. That doesn't mean it won't happen, but not immediately.

I don’t think this conversation is going anywhere I’m afraid, and it’s impacting my ability to actually spend time improving the apps. If you would like a refund then let me know at info@cycle.travel and I can try and process that through Patreon.