[FEATURE] Manual location refresh?

[CodeCracker-oss]

Hello,

I've noticed that while locus is in background (swiped away from recent apps) it only updates once an hour which may be too long for many to wait for a location update (I thought it was supposed to be 15 minutes, if im not mistaken?)

Can you implement an option, that the user who creates the task must allow called "Manual location refresh" or something like it, where those who are viewing location can update their location, as that person may not be in same location anymore depending on when it was last updated.

Thats how Google maps works with location sharing feature. When user clicks to see friends location, google pings their device to get its location and sends it back. I believe its done this way to avoid further battery drain by constantly sending the location when its not needed.

[Myzel394]

Hey @dhammel,

Locus updates your location about every 15 minutes when you do not have battery saver mode enabled. As the sender, you can manually update the location by long pressing the home icon and then tapping on "Update location now".

As for the receiver to update the location, this is definitely I want to try implementing, but will probably take some while. Google has the advantage of acting as a middleman between the two parties, as Locus is completely decentralized, we do not have that option. However, I might be able to accomplish this using peer to peer connections, but it will take a while.

So this is a planned feature, but it won't be available in the near future unfortunately.

[CodeCracker-oss]

@Myzel394 Hm, well I don't ever even use battery saver mode but for me its updating every hour.

What I was originally looking for was real time tracking, similar to live GPS devices that constantly broadcast location to receiver every second. Although, this would consume way too much battery on a phone. So i thought a manual refresh able to be done by receiver might be better.

Is it possible you use locus.cfd as the middleman, until you can/do get it implemented decentralized?

I haven't readup on technical details of Nostr, but within locus does it use end to end encryption so not even the relays are aware of location? If so, can this preserved by using locus.cfd as a middleman?

[maximbaz]

I have experimented with this in the past, and I am pretty certain we need a persistent notification with foreground service in order to ensure a stable refresh rate for location update, otherwise it's marked as background activity by Android, and refresh rate is very unpredictable and depends on many factors. I think it's true for both Google and FOSS location services, but especially for the latter one. For an example of how to have foreground service with persistent notification, you can check OwnTracks. And by the way, the notification can be fully hidden by the user, and if it's the user who hides it, the service is still considered being a foreground service, and you still have all the benefits of stable refresh rate.

[Myzel394]

Thank you for the hint @maximbaz, but I'm not too sure whether implementing this ourself might be a good idea in terms of battery life and privacy. One would need to be connected to all the other devices retrieving the current position. This would probably drain the battery very much and would also be a leak of the ip address (for both the viewer and the receiver).

However, I have one question to you @maximbaz: Do you know Android accepts services as Foreground Services when the notification permission has NOT been granted yet on Android 13+ ?

[maximbaz]

One would need to be connected to all the other devices retrieving the current position

I don't think it's the case, or I didn't get what you mean, could you please try to explain it? I'll also try to explain on my end: basically we need to launch a foreground service that is active as long as location sharing is active (and stop it when we are no longer listening to the device location). In the simplified terms, you can think of a foreground service as nothing more than a simple instance of a special class, it doesn't have to do anything else. And a notification is just a side-effect of having a foreground service running.

We don't need to make any connections to anyone, it's simply a way to signal to Android, that the user actively knows that the app is working in "foreground" and collecting location, that it's not okay for Android to suspend this app.

Battery usage is increased - not because this process takes more battery, but because you are preventing Android from skipping those 15-minute intervals, so it now has to do what it promised.

Do you know Android accepts services as Foreground Services when the notification permission has NOT been granted yet on Android 13+ ?

I believe you don't even need to request notification permission when you launch a foreground service (as a reference, see the blue box in the top of this page) - you need to provide the notification, just as part of the contract, but then the user is free to remove it.

[Myzel394]

I don't think it's the case, or I didn't get what you mean, could you please try to explain it? I'll also try to explain on my end: basically we need to launch a foreground service that is active as long as location sharing is active (and stop it when we are no longer listening to the device location). In the simplified terms, you can think of a foreground service as nothing more than a simple instance of a special class, it doesn't have to do anything else. And a notification is just a side-effect of having a foreground service running.

Yes that's true, but I was more talking in context of Locus. If we want the user to be able to request an update of the location from someone else, they somehow need to transfer that "Give me your location" signal to them, so they need to be connected, which would mean we'd have to open a lot of connections.

[maximbaz]

Aah! That is true. Just to be completely on the same page, it's not really related to a foreground service, it's a separate feature that will be implemented in the same way with or without foreground service, the only difference being is that with foreground service there will be higher chance that the app will actually receive such a connection, and will be able to update the location and respond with it. So, foreground service is for stability and reliability when app is in background, to guarantee 15 min interval, and then "on-demand" is separately, when even 15 min is not fast enough. Does it sound correct? 🙂

[JFingerle]

The location updates are also very random on my devices. Often they don't update for hours.
The devices are running on Android 13 AOSP (Lineageos and Crdroid). I have turned off all notifications by Locus on both devices.

Is there anything I can do to improve this?

(I had the same issues with owntrack btw)