No continuous position updating for OwnTracks 2.5 #1759
Comments
|
Can you please verify and confirm the app is set to report significant changes? |
|
Also, does it still behave like this in move mode? |
|
My smartphone has been operating in “move” mode for ages, with position updates issued every few seconds (parameter set at 10 seconds). I have not touched the parameter settings. |
|
My wife’s smartphone (Samsung A34, Android 14) has the same problem. Equivalent parameter set. Can’t be that we are the only ones suffering from this... |
|
Do you have access to a device that isn't a Samsung to test this on? |
|
Also, literally any logs would be helpful here. It's not clear if the locations are still being collected and queued, but just failing to send, or if something else is going on. |
|
Some problem here. Pixel 6, all battery-optimizations that I know of are diabled for owntracks. The previous version was running fine. I've attached a debug log, I hope it helps. If you need more help debugging this, just let me know. |
|
Thanks for the log. I see the location callback just stops being triggered, which hints that the device is no longer receiving location updates from the OS. Some questions:
For what it's worth, this was my day today - I'm not seeing (and haven't seen the entire 2.5 cycle) any issues with locations suddenly not arriving in the app. I'm not saying there's no issue, but if I can't replicate it then this might take a little while troubleshooting.
@fabianonline would you be willing to temporarily join our unstable track? That'll get you a new build on each commit, so should help us iterate a little faster. If so, shoot me your play store email address and I'll add you in. |
growse
added
bug
and removed
needs-more-info
|
Hi. Thanks for looking at this. I'll test if there's a difference depending on connection / charging tomorrow. Should I collect logs as well or would a simple "works / doesn't work" be enough?
The notification is present. It was disabled before, but trying to fix my problems I re-enabled it. Didn't make a difference.
Battery saver mode is not active.
"Battery optimization whitelisted" should be "Batterieoptimierung ermöglicht" in German, which is "Nein", so "No".
"Location permission granted" ("Standortberechtigung gewährt") is "Genau" ("Exact" in English, I think).
Unstable track would be fine for me. I'm fabian354@ that Google email thing.
|
|
Works or not should be good enough for the moment. Can you try clicking on those fields in the status page? It should take you through to the android settings that let you also (maybe) disable battery optimization for the app, and allow permission for location (background) access. Some more dimensions to try! edit I just clicked around on my phone to check the battery optimisation setting. They've made it a little more confusing on Android 14, where to set between "Optimized" and "Unrestricted" you have to actually click on the "Allow background usage" text next to the simple on-off toggle. That then takes you to a different screen to give you radio buttons. Just in case you can't find it :p |
|
That might have been the problem: Location access was set to "Allow access while using the app", not "Always allow". Apparently it got changed when Google updated the app?! After all it was set correctly earlier... Anyway, in the status screen it now shows "Exact (background enabled)".
Also, the battery optimization setting is now "Yes" after I realized that you can reach just another menu by not tapping the toggle but the label of the toggle in the system settings...
I'll test it later and report back if anything changed...
Am 20. Juli 2024 01:59:53 MESZ schrieb Andrew Rowson ***@***.***>:
…Works or not should be good enough for the moment.
Can you try clicking on those fields in the status page? It should take you through to the android settings that let you also (maybe) disabled battery optimization fot the app, I allow location (background) access. Some more dimensions to try!
--
Reply to this email directly or view it on GitHub:
#1759 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
I'm happy to report that it's now working fine. User error. XD The changed settings mentioned in the previous comment made all the difference. But I think the wording in the status screen could be better (based on the german translation, but I'd hope it is close enough to the english wording to bring my point across): "Location permission granted: Exact" sound just like the thing I'd want - but what I actually want is "Exact (background enabled)". Maybe you could change "Exact" to be something like "Exact, but only when in foreground"? Maybe you could also color those values? The "bad" value being red and the correct one green would probably have helped me notice these errors by myself without having to waste your time... ;-) But anyway: Thanks a lot for your help! |
|
I can confirm that the problem has been solved by changing the location setting to be “always on”. Shame on Google? Anyway, many thanks for the speedy response and all the good work! I’m impressed! |
|
"Always On" option is unavailable for OwnTracks app on Samsung S24+. Only "Allowed while using app" is available. This was also true for version 2.4.12. However, location was still updated in the background. Version 2.5.0 doesn't work with this setting. |
Can you share a screenshot? This is what I see on the emulator under location permission for the app:
|
|
Please see attached. Note that I am currently running V2.4.12, but V2.5.0 also has the same options.
Thanks.
Get TypeApp for Android
…On Jul 22, 2024, 6:56 AM, at 6:56 AM, Andrew Rowson ***@***.***> wrote:
> "Always On" option is unavailable for OwnTracks app on Samsung S24+.
Only "Allowed while using app" is available. This was also true for
version 2.4.12. However, location was still updated in the background.
Version 2.5.0 doesn't work with this setting.
Can you share a screenshot?
This is what I see on the emulator under location permission for the
app:
--
Reply to this email directly or view it on GitHub:
#1759 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
|
|
@anthonycle67 screenshots are not attached when replying by email |
|
|
|
|
Can you double-check on 2.5.0? It explicitly added an extra permission capability, which changes that menu. |
|
@fabianonline This is super-useful data, thank you! So, a couple of things. Background Location permissionThis is a new option in 2.5.0. Historically, it's not been requested by OT because it hasn't been necessary. An application with an active foreground service doesn't need The other factor here is that if you want to publish an app on the play store that asks for There was a fair bit of pressure from users to add this in. I'm not sure where it came from. I suspect that people put the pieces together of "OwnTracks needs locations", "locations should be collected when my phone is in my pocket, when OT is running in the background" and "OT doesn't ask for background location permission" and concluding "Ah, I know why it's not working quite how I want". This is not an unreasonable conclusion! I resisted for a bit because (a) I wasn't convinced that it would actually solve any issues and (b) paperwork + poking Google often doesn't go well - worst case we get banned from the play store! Eventually, I added it in for 2.5.0, mostly because it might actually solve some problems (especially around geofence detection), but partly to make the GH issues go away. It seems that something, somewhere though has changed. I don't know if it's
The irony is that if the last one is true, then people who upgraded from <2.5.0 will now have a worse experience, because the permission state carried across the upgrade will be for Battery OptimizationBattery Optimization is a murky, mystery world. There's no hard-and-fast list of behaviours that change between "Unrestricted / Optimised (default) / Restricted" modes, or what changes between different battery saver modes. Apps are left in this sort of "Be Lucky!" limbo, where the docs talk about things that "may" become throttled, or unreliable. So if an app requests location updates every 30 seconds, and Android suddenly decides that the battery drain is too high, the location callback just stops getting called. The OS just stops delivering locations. There's no intent (as far as I can tell) that's fired at the app to let it know that locations are being disabled, or throttled, or in any way going to start behaving differently. The app _can_subscribe to Worse, it seems that different device vendors vary the rules on what gets disabled / throttled under different battery conditions. https://dontkillmyapp.com/ exists entirely to highlight how badly behaved different vendors are when it comes to restricting perfectly useful Android APIs under arbitrary conditions. I get why they do it - battery life sells phones. Samsung get to market their 24-hour battery life (or whatever), which is only achievable because they force-kill every app the moment the screen goes off. UI/UXThe reality is that OT is used by a fair few people on a wide range of devices, and behaviour is inevitably different from one to the next. The thing I could use the most help with is working out how best to provide a user-experience that guides the user towards enabling / disabling whatever setting is needed. There's two main ways here:
In short, any help here would be hugely useful. |
|
Hi Andrew,
I found the permission for "Always On" now. I remembered that I didn't have it before with V2.5.0 so had to downgrade. Let me test this later today to see if everything returns to normal with the "Always On" selected. I will keep you posted.
Thank you so much for your help.
Get TypeApp for Android
…On Jul 22, 2024, 10:20 AM, at 10:20 AM, Andrew Rowson ***@***.***> wrote:
@fabianonline This is super-useful data, thank you!
So, a couple of things.
Background Location permission
===
This is a new option in 2.5.0. Historically, it's not been requested by
OT because it hasn't been necessary. An application with an active
foreground service doesn't _need_ `ACCESS_BACKGROUND_LOCATION`
permission, because the component receiving the location (the service)
is a foreground component! This is how it worked <2.5.0.
The other factor here is that if you want to publish an app on the play
store that asks for `ACCESS_BACKGROUND_LOCATION`, there's a _bunch_ of
hoops you have to jump through, including (but not limited to) sending
Google a youtube video showing how your app works.
There was a fair bit of pressure from users to add this in. I'm not
sure where it came from. I suspect that people put the pieces together
of "OwnTracks needs locations", "locations should be collected when my
phone is in my pocket, when OT is running in the background" and "OT
doesn't ask for background location permission" and concluding "Ah, I
know why it's not working quite how I want". This is not an
unreasonable conclusion!
I resisted for a bit because (a) I wasn't convinced that it would
actually solve any issues and (b) paperwork + poking Google often
doesn't go well - worst case we get banned from the play store!
Eventually, I added it in for 2.5.0, mostly because it might actually
solve some problems (especially around geofence detection), but partly
to make the GH issues go away.
It seems that something, somewhere though has changed. I don't know if
it's
- later versions of Android now behave differently for foreground
services that request locations without `ACCESS_BACKGROUND_LOCATION`,
or
- it's a bug in Android, or
- if Android treats the _app_ differently for having
`ACCESS_BACKGROUND_LOCATION` available in the manifest but not granted.
The irony is that if the last one is true, then people who upgraded
from <2.5.0 will now have a _worse_ experience, because the permission
state carried across the upgrade will be for `ACCESS_FINE_LOCATION` to
be granted, but `ACCESS_BACKGROUND_LOCATION` to be not granted (because
they've not explicitly granted before). This seems to be what you're
finding!
Battery Optimization
===
Battery Optimization is a murky, mystery world. There's no
hard-and-fast list of behaviours that change between "Unrestricted /
Optimised (default) / Restricted" modes, or what changes between
different battery saver modes.
Apps are left in this sort of "Be Lucky!" limbo, where the docs talk
about things that "may" become throttled, or unreliable. So if an app
requests location updates every 30 seconds, and Android suddenly
decides that the battery drain is too high, the location callback just
stops getting called. The OS just stops delivering locations. There's
no intent (as far as I can tell) that's fired at the app to let it know
that locations are being disabled, or throttled, or in any way going to
start behaving differently.
The app _can_subscribe to `DEVICE_IDLE_MODE_CHANGED` and other intents,
but these don't work on all OS versions, and (as far as I can tell) not
particularly reliable.
Worse, it seems that different device vendors vary the rules on what
gets disabled / throttled under different battery conditions.
https://dontkillmyapp.com/ exists entirely to highlight how badly
behaved different vendors are when it comes to restricting perfectly
useful Android APIs under arbitrary conditions. I get why they do it -
battery life sells phones. Samsung get to market their 24-hour battery
life (or whatever), which is only achievable because they force-kill
every app the moment the screen goes off.
UI/UX
===
The reality is that OT is used by a fair few people on a wide range of
devices, and behaviour is inevitably different from one to the next.
The thing I could use the most help with is working out how best to
provide a user-experience that guides the user towards enabling /
disabling whatever setting is needed. There's two main ways here:
1. Better text/i18n - if you think the wording could be changed /
improved in whatever language you consume the app in, please head over
to our translation site to submit a change:
https://poeditor.com/projects/view?id=419041. If you want to propose a
change to the base English labels, you can do this either on POEditor
or (preferably) via a PR here.
2. Better layout to guide the user towards the right settings. I'm not
convinced that it's sufficient to just display the settings in the
status activity. Something on the main Map activity that alerts the
user that they've not got background location enabled might be a good
idea. The trick here is balancing letting the user know vs annoying
them if they _don't_ want to enable it.
In short, any help here would be hugely useful.
--
Reply to this email directly or view it on GitHub:
#1759 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
It's starting to smell like we need to be more proactive with users in nudging them towards allowing background location permission. |
|
Seems similar with my wife's phone (OnePlus 9, Android 14). Hasn't sent anything apart from |
|
Confirmed that selecting "Always on" on Samsung S24 solved issue. |
|
I'm not having issues with sending location positions. Owntracks for Android 2.5 doesn't show current positions for anyone consistently. The recorder app does get the tracks. This might be a separate issue from this one.. Edit: I do have location set to always on. So that's not the issue. |
|
If you use Move mode you may see the problem we found in #1768. A fix will be available shortly |
|
At the risk of posting a technically unnecessary message, I want to give thanks to everyone active in this conversation, from the OP to @growse. I realised yesterday my tracking wasn't working anymore and was worried I'd find no helpful solution, especially if that was in part due to my phone's Android "flavour", as sometimes happens. But look at this, a healthy community had already reported the issue and a responsive and helpful dev explained what was happening. In a second I had confirmed that my phone was now also set to "only while using the app", which I quickly changed, so hopefully the issue is fixed for me as well, now. |
|
Currently proposing this dialog if no background location permissions. This should catch those upgrading (and therefore won't have otherwise be prompted to enable background permission).
|
App build number: 2.5.0
Android version: Android 10
Device: Samsung A6
Installation source: Google Play
Previous OwnTracks versions allowed continuous position updating (and MQTT data exchange) while the phone was tucked away in my pocket. The latest version seems to have lost that capability: the position gets updated only when the app is activated manually. For me that is an OwnTracks killer. Or have I missed something?
The text was updated successfully, but these errors were encountered: