LineageOS 18.1 / Android 11 Only move mode is working?

[vsatmydynipnet]

I am using LineageOS 18.1 without gapps and the Owntracks 2.4.2 oss version on my phone.

Battery exception is set

If I change to move mode things works as expected, but uses kinda much battery,

Significant changes mode (set to 300) does not update the location for whatever reason.

Maybe this is related to: #1005 but unsure.

I tried to at least implement changing move mode to manual and back to move mode when leaving my home WLAN, but failed to create a fitting am command line based on this infos:

This would be the detail:

"Service Start"
Package: org.owntracks.android
Service Class: org.owntracks.android.services.BackgroundService
Action: org.owntracks.android.CHANGE_MONITORING
Extras: { "monitoring" as Int: 2 }

The old version to stop and start Owntracks based on the home WLAN does not work anymore because if Easer starts Owntracks without unlocking the phone, it does not work either.

Would appreciate help to alt least change mode using command line till a full solutions is found.

Thank you very much for this cool peace of software.

[growse]

Ah! The first issue of the OSS flavour! :)

I've got a spare pixel phone here, let me put LineageOS on it and do some testing to see if I can reproduce and find out what's going on.

[vsatmydynipnet]

I had it in the past in the way when coming home (HOME WLAN), easer has done a am force stop of the app and when leaving home Easer started the app again. This saved Battery at home. Maybe if significant changes mode works again, this will work again too.

Sending the intent to change mode manual/move on command line would be fine too, but i was unable to create a am ..... command for this one.

And my phone is rooted using Magisk + running AFWall+

Thank you for looking into it

[growse]

Ok, I did some testing.

I think what's going on is this:

• Significant changes monitoring mode uses PRIORITY_BALANCED_POWER_ACCURACY in the location request. At the moment, I've got that just relying on the network and passive location sources (ie not gps), because my perception is that this closest matches the behaviour of Google's provider. Google's is much more complex than this, and can maybe take a GPS location very infrequently, or when its not had an update in a while.
• Relying on network and passive requires there to be an actual ability for something on the device to provide locations based on the network context, or another app that's asked for GPS location to be open at the same time.
• By default, there's nothing on the base LineageOS that can provide network location.

I tried a number of things (on a Pixel 2). First, I installed UnifiedNlp and added the Mozilla Wifi database. After a few reboots, I managed to get OwnTracks OSS to pick up a location on significant changes mode whilst indoors (no GPS signal). I could see it bouncing around in terms of accuracy and location, which is consistent with my experience of how netowrk-provided location works.

Second, to test the passive location provider, I factory reset LineageOS to remove UnifiedNlp, and then installed both OT and OsmAnd. Putting OT into significant changes mode, then loading OsmAnd and then taking the device outside, I saw OsmAnd locate the device correctly through GPS, and then switching back to OT I saw that it had also picked up on the same location. So passive seems to be working correctly.

I think therefore the issue is that on stock Lineage (with no network location provider), OT in significant monitoring mode will not receive location updates unless there's something else on the device that's also asked for GPS updates.

So, I'd be interested in looking at what we can do. I'd be concerned about asking for GPS as a location source, because that's essentially no different to a PRIORITY_HIGH_ACCURACY request (which will drain the battery). Another option is to just say "Hey, use UnifiedNlp to get network locations", but that feels a bit of a cop-out.

[vsatmydynipnet]

Pretty interesting. I used Owntracks in the past, then changed to Nexttrack because of some Problems with missing Google Libs longer time ago. This worked great with LIneageOS 16 and 17,.1 (Android 9 and 10). Even stop/start with Easer worked fine. As I saw Owntracks oss version i moved on to this one, which I was missing the time i changed to Nexttracks.

Starting with LOS 18.1 / Android 11 the Problems startet.

One thing i found was that if you install Easer it has "ALWAYS" Access to Location Permission and OwnTracks "While using the App" and it is not possible to assign "always" to Owntracks.

Is it possible that Owntracks needs additional Permissions because of changes in Android 11?

[growse]

One thing i found was that if you install Easer it has "ALWAYS" Access to Location Permission and OwnTracks "While using the App" and it is not possible to assign "always" to Owntracks.

Is it possible that Owntracks needs additional Permissions because of changes in Android 11?

See my reply on this thread.

In short, background location permission sounds like a thing we'd need, but is actually something different. OT maintains a constant foreground service to receive accurate and timely locations, so having "background location" permissions won't necessarily help with anything in this case. (As per that thread, it's possible it may help with resuming location logging post-reboot or upgrade, but that's a separate thing).

I'll try and repeat the test on LineageOS 17. I'll also grab easer and see if I can see what's going on. I know your original question asked about sending intents to the service to change the monitoring mode - this should absolutely work.

[vsatmydynipnet]

I am no dev, but found this, which has IMHO some long explaination:

https://www.kajda.com/2020/09/21/restrictions-to-background-location-and-foreground-services-in-android-11/

https://stackoverflow.com/questions/64246883/android-11-users-can-t-grant-background-location-permission

https://medium.com/swlh/request-location-permission-correctly-in-android-11-61afe95a11ad

This is to deep into App'S for me, but I think this reads like explainations and ways to go.

[growse]

So I can't seem to find a build for Lineage 17 for the pixel 2. Looks like it was never supported. Not going to be easy to test without being able to actually run Lineage 17.

This would be the detail:

"Service Start"
Package: org.owntracks.android
Service Class: org.owntracks.android.services.BackgroundService
Action: org.owntracks.android.CHANGE_MONITORING
Extras: { "monitoring" as Int: 2 }

I'm looking at Easer and can't find how you're configuring this. I've tried creating a profile to "Start Service", but it only gives me the option of "Action", "Category", "Type", "Data" and "Extras", with no place to populate the actual package name. It seems from this issue that this isn't supported yet...? Macrodroid (and others) seem to allow you to create an explicit startService intent which works just fine.

https://www.kajda.com/2020/09/21/restrictions-to-background-location-and-foreground-services-in-android-11/

https://stackoverflow.com/questions/64246883/android-11-users-can-t-grant-background-location-permission

https://medium.com/swlh/request-location-permission-correctly-in-android-11-61afe95a11ad

Yeah, these are reasonable overviews. It's a complex area. Ultimately, without background location, we're going to rely on the user explicitly opening OT once post-boot or post-upgrade in order to start getting accurate and timely location data. In the future, we may get background location, but it's a lot of work to jump through the policy hoops on the play store, there's no guarantee that it's approved, and even with that permission, the frequency and accuracy of locations isn't what the user might expect.

[vsatmydynipnet]

I am on Samsung and Fairphone here, both 18.1 meanwhile.

I used the run command way to stop / start OwnTracks using Easer till LOS 17.1/ Android 10.

am start -n org.owntracks.android/.ui.map.MapActivity
am force-stop org.owntracks.android

But I was not able to find the corresponding am command for the intent to send the change from significant to move , or other modes .

IMHO the oss version would be ok, with additional permissions for background location, because this one will be installed using the apk and Google has no way to disapprove.

[growse]

I used the run command way to stop / start OwnTracks using Easer till LOS 17.1/ Android 10.

Ah I see - let me test what the right am command is to send an explicit service intent. I'll try document that in the booklet as well.

IMHO the oss version would be ok, with additional permissions for background location, because this one will be installed using the apk and Google has no way to disapprove.

Fair - I do plan to add background location to the OSS flavour first. There's a bit of work that needs to happen to take advantage of it, so hopefully will try and get it into the 2.5 release.

[growse]

am start-service -a org.owntracks.android.CHANGE_MONITORING --ei monitoring 2 should work.

[vsatmydynipnet]

Wow, thank you so much. This one works great. This way it is far better now, because i switch to manual mode when entering home WLAN and to move mode when leaving. Battery is not drained while beeing at home or sleeping.

Docs:

Start

am start -n org.owntracks.android/.ui.map.MapActivity

Stop

am force-stop org.owntracks.android

Change Mode

am start-service -a org.owntracks.android.CHANGE_MONITORING --ei monitoring 2

Links

https://owntracks.org/booklet/features/android/

Modes

Quiet monitoring:-1
Manual monitoring:0
Significant Changes monitoring:1
Move monitoring:2

[vsatmydynipnet]

Feedback: I tested things now in real life and the solution now works fine. There is no battery draining at home and while away its recorded fine. So if one day significant changes will work too it would be really cool.

[growse]

Sounds good.

So we just need to figure out what the right approach for Significant mode on OSS is. Do we ask users to get a network location database implementation (like UnifiedNlp), or do we request GPS updates in significant mode and risk the battery?

[vsatmydynipnet]

I think we should not ask the user to install, setup, get something. Lot of users will fail with it. Currently Battery drainage with 10sec update is less then I expected, but still to much for always on.

I assume requesting GPS update, e.g. every 300s should not drain the battery to much. If somebody is angry about the battery, one can set to 900s.

[growse]

I think I agree. Let me make some changes for the next version and you can test that once it's done (hopefully in the next few days).

[vsatmydynipnet]

Whenever you have a new version, just let me know and I will test it in real life. Thank you very much for your work!

[growse]

Can you try the OSS apk on v2.4.3-beta1 release? https://github.com/owntracks/android/releases/tag/v2.4.3-beta1

[vsatmydynipnet]

wow, cool. for sure yes. will put it on today and use it real life tomorrow. will report back.

[vsatmydynipnet]

Good Morning! Had it with me for testing things yesterday. Works really great now. Thank you for your work! Love it.