Owntracks - Doesn't automatically start tracking after reboot

[austwhite]

Whenever the phone is rebooted, Owntracks will stop tracking location. This seems to be due to background location usage not being available.
I get the message "Location Tracking Paused. This version of Android restricts OwnTracks from receiving locations when started in background until the app is opened. Click this notification to open the app and start tracking location"
Once I open Owntracks and then send it back to the "background" it will work fine.
I do not have this issue with Life360 or the Home Assistant companion app, which also do real time location tracking.
The only difference I can see in permissions is that OwnTracks does not have the "Allow all the time" option in Location settings. All the other tracking apps that start properly when the phone reboots have this option, and successfully track real time.
It's a minor annoyance more than a real deal breaker, but I would like to know if there is a way to get OwnTracks to start tracking automatically when the phone boots like other apps can do. Not sure if the issue is my device or just something I am doing wrong :).
Thanks

• App build number: Version 2.4.2 (24208) - Google Play
• Android version: 11 build RP1A.200720.012.G970FXXSCFUH5 - One UI version 3.1
• Device: Samsung Galaxy S10E

[growse]

You're not doing anything wrong, this is an Android limitation. OwnTracks doesn't request background location permissions for a number of reasons:

1. It doesn't need them. Holding a foreground service and requesting location updates there allows OT to receive updates at the desired rate and accuracy as long as that foreground service is running.
2. The Google Play Store has a policy around allowing publishing of apps that request background locatoin (https://support.google.com/googleplay/android-developer/answer/9799150). In short, there's a lot of work required to convince Google that background location is "required".
3. Even if we did that and were allowed to use background location permission, we'd still be subject to the background location limits on devices > Android 8 (API 26). From the backgroudn limits article "If your app is running in the background, the location system service computes a new location for your app only a few times each hour. This is the case even when your app is requesting more frequent location updates." If we did this for OT, what you'd see is very infrequent location publishes after device boot, until you interacted with the app in some way, and then updates would suddenly become more frequent.

I'm not familiar with what Life360 or HA are doing (although HA seems to request background location) but they'd be subject to the same policies and restrictions as above.

That said, the current plan is to include background location permission in the OSS flavour build of the app, which will be distributed on F-Droid. Hopefully, we can get some user feedback about how background location behaves there on real-world devices (after reboots, upgrades etc.) and then take another look at jumping through the necessary hoops to add it to the Google Play Store version.

[ahmouse15]

Life360 seems to be able to request location without background permissions once or more per minute. Also unlike Owntracks, it can still run without requiring a constant notification, and swiping it away from the app list does not prevent it from reporting location. It does however send a temporary notification only while it's checking and sending location. I think it may be a technique where it somehow uses a background service to send a notification which (iirc) can be used to open a foreground service. From there, the app can send location as needed, because it avoids the limitations of background location.
P.S. I don't know much about Android and the different states apps can be in, so this may be wrong

[growse]

I'm not familiar with Life360 or how it works. I can't imagine that they're not subject to the limits set out in the documentation on how Android background location limits work.

I think it may be a technique where it somehow uses a background service to send a notification which (iirc) can be used to open a foreground service. From there, the app can send location as needed, because it avoids the limitations of background location.

Foreground services started from the background (ie without an express user interaction) are still considered "background" and therefore subject to the location restrictions (see https://developer.android.com/about/versions/oreo/background-location-limits#tuning-behavior). This is the exact problem that we have on OT, where the foreground service is started by a device boot broadcast, so its limited by what locations it receives. Hence the notification on newer devices that the user needs to interact with OT explicitly to start receiving locations.

[austwhite]

Well, not sure about all the technical stuff. All I know is Home Assistant and Life360 get real time updates from the background, and are accurate enough to do proper geofencing. The Philips Hue app seems to do that too.

[growse]

All three of those apps use BACKGROUND_LOCATION permission. You can grab the APKs from the play store and use a tool like apktool to check the AndroidManifest.xml yourself.

[Flightkick]

@growse thanks for elaborating, very much appreciated.
Great to hear that the osm version has background location implemented.

I'd like to respond to your points though (with all respect):

1. It doesn't need them. Holding a foreground service and requesting location updates there allows OT to receive updates at the desired rate and accuracy as long as that foreground service is running.

• Seems to me like you have a pretty decent case to be using background location. Given this issue and the restrictions of foreground location updates.

2. The Google Play Store has a policy around allowing publishing of apps that request background locatoin (https://support.google.com/googleplay/android-developer/answer/9799150). In short, there's a lot of work required to convince Google that background location is "required".

• Complexity of that process aside. The policy obviously aims to prevent unnecessary user tracking and data collection which certainly is a good thing. But I don't think that 'convincing Google that background location is required' would be much of an issue for an open source GPS tracking app. Continuous location tracking is the app's sole purpose.

3. Even if we did that and were allowed to use background location permission, we'd still be subject to the background location limits on devices > Android 8 (API 26). From the backgroudn limits article "If your app is running in the background, the location system service computes a new location for your app only a few times each hour. This is the case even when your app is requesting more frequent location updates." If we did this for OT, what you'd see is very infrequent location publishes after device boot, until you interacted with the app in some way, and then updates would suddenly become more frequent.

• The current behavior is that the app stops sending location updates on a reboot. At least for my use-case, a fall-back method to less frequent updates is much better than no information at all plus having to manually intervene to get location updates started again.

Hopefully the user feedback on the osm version will help you get the information you need to smoothly roll out to the Play Store version as well.

[austwhite]

@growse They do, but that is not the point of my comment.
It has been said that background does not update real time, and that's one argument used for OwnTracks not to use it.
I only highlighted those as they do use background and still manage to get real time data :)
It could be that they do an initial trigger in background and then transfer to foreground somewhow. All I know is that for whatever reason, they can do accurate geofencing without an user intervention. I am not technical though :)

[growse]

Ah, I see. At a guess, they're using the Google geofencing lib, which should give you the near-instant region detection but requires background permission.

[TundraTamer]

Hi, is there any progress with this. My installs all state that with my version of Android OT needs to be opened first after a reboot in order for it to work. This basically breaks my use of OT, as I have multiple users and automation routines that need to be triggered from their geofenced triggers.
It used to work fine.
Is there a workaround?
Can we send a command to OT to get it to activate?
Can we use something like Tasker or IFTTT etc to get it to open at reboot?

[growse]

I'm not sure what sort of progress you're anticipating.

It used to work fine.

Yes, and then Google changed the restrictions on what applications could do without explicit user actions. Grabbing high-precision location is one of them, which is why we can't get high-precision, timely location updates after device bootup without an explicit user interaction.

Can we send a command to OT to get it to activate?

The whole point is that Android requires an explicit user action. By definition, this is not something OT can just do, because then it wouldn't be an explicit user action.

Can we use something like Tasker or IFTTT etc to get it to open at reboot?

It might be worth experimenting to see if Tasker can open the app and then immediately mimimize it. With the right admin-shaped permissions for tasker, this may be enough to convince Android that a human has explicitly opened OT, and therefore start feeding it locations.

[TundraTamer]

Hi, Just tried Tasker (Tasker can be added to the family library too which I will explore later). I've managed to get tasker to open OT at reboot on a Samsung no less. I would class this as a great workaround. Not tried getting it to minimise OT yet, but for the most common use case for OT, this is a big step forward, at least for my purposes. Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Andrew Rowson ***@***.***> Sent: Monday, April 11, 2022 5:10:34 PM To: owntracks/android ***@***.***> Cc: TundraTamer ***@***.***>; Comment ***@***.***> Subject: Re: [owntracks/android] Owntracks - Doesn't automatically start tracking after reboot (Discussion #1095) I'm not sure what sort of progress you're anticipating. It used to work fine. Yes, and then Google changed the restrictions on what applications could do without explicit user actions. Grabbing high-precision location is one of them, which is why we can't get high-precision, timely location updates after device bootup without an explicit user interaction. Can we send a command to OT to get it to activate? The whole point is that Android requires an explicit user action. By definition, this is not something OT can just do, because then it wouldn't be an explicit user action. Can we use something like Tasker or IFTTT etc to get it to open at reboot? It might be worth experimenting to see if Tasker can open the app and then immediately mimimize it. With the right admin-shaped permissions for tasker, this may be enough to convince Android that a human has explicitly opened OT, and therefore start feeding it locations. — Reply to this email directly, view it on GitHub<#1095 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT2E77D5GLM23UN4WWZYCJDVERFHVANCNFSM5FLIQM4Q>. You are receiving this because you commented.Message ID: ***@***.***>

[growse]

Great news - if you do manage to get a reliable recipe together, it'd be worth us adding it to the OT booklet to help others out who need a similar thing.

[TundraTamer]

Hi, So far tasker is working. I have a number of devices that reboot daily. At boot tasker opens OT, waits 3 or 4 seconds then triggers 'Go Home'. This seems to work, although is noticeable by the user. Tasker needs to be able to draw over apps for this to work. It's not perfect, as the display must be on. So a short timeout on the display settings could cause OT not to work. It would be useful if there could be a reportLocation:true command in OT, similar to change_MONITORING, although I don't think this would resolve the display on requirement of getting OT to start. This does however appear to offer a reasonably good workaround to the Android 11 restrictions. Family sharing Tasker also helps in the cost overhead. This certainly helps with getting presence detection working again using OT. Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Andrew Rowson ***@***.***> Sent: Saturday, April 16, 2022 1:42:52 PM To: owntracks/android ***@***.***> Cc: TundraTamer ***@***.***>; Comment ***@***.***> Subject: Re: [owntracks/android] Owntracks - Doesn't automatically start tracking after reboot (Discussion #1095) Great news - if you do manage to get a reliable recipe together, it'd be worth us adding it to the OT booklet to help others out who need a similar thing. — Reply to this email directly, view it on GitHub<#1095 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT2E77FQMCNHOFGHRPZXB3LVFKYUZANCNFSM5FLIQM4Q>. You are receiving this because you commented.Message ID: ***@***.***>

[hevel86]

I apologize if this is considered necroposting, and I will start another thread if it is. Does the OSM version start on its own after a reboot? Or does this still require a workaround?

[growse]

I think the OSM version has background location permission, so should auto-start.

It's early and I've not had coffee yet, so let me fix that and peek at the code.

[cmaciasochoa]

Hello,

Any updates on the topic? I just installed the PlayStore version but it seems that the app doesn't autostart at boot. Any solution so far?

Thanks

[cmaciasochoa]

Seems that OSS v2.4.12 does the trick...

[Botched1]

I see that this looks like it is fixed in the upcoming 2.5 android app version (for those of us that can't sideload the oss version).

Any guesses on when the 2.5 app will be final?

[growse]

When it's ready.

[Botched1]

Hilarious. :eye roll:

I'll choose to translate the snark into the much friendlier "we don't publish or give estimates on future releases". Which is fine of course, I was just curious.

Thanks!

[TundraTamer]

Happy with whatever comes. I don't write it so I can't complain. I have a workaround using tasker which seems reliable. I am happy with whatever 2.5 brings when it arrives. Merry Christmas everyone. Especially the Devs that put in the time that I benefit from. Happy New Year. Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Botched1 ***@***.***> Sent: Friday, December 22, 2023 2:16:54 PM To: owntracks/android ***@***.***> Cc: TundraTamer ***@***.***>; Comment ***@***.***> Subject: Re: [owntracks/android] Owntracks - Doesn't automatically start tracking after reboot (Discussion #1095) Hilarious. :eye roll: I'll choose to translate the snark into the much friendlier "we don't publish or give estimates on future releases". Which is fine of course, I was just curious. Thanks! — Reply to this email directly, view it on GitHub<#1095 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AT2E77E4TTGISBL6B3QWRJLYKWI5NAVCNFSM5FLIQM42U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TOOJSHAZDENQ>. You are receiving this because you commented.Message ID: ***@***.***>