App cannot detect current network when in background due to missing ACCESS_BACKGROUND_LOCATION permission

[wertziop]

Syncthing app is configuered to start only on connection of a specific wifi ssid: config options are: "Bei WLAN-Verbindung ausführen" AND "In festgelegtem WLAN-Netzwerk ausführen" (sorry, app is in german)

that means: use only wifi connectivity, don't use metered wifi, use only a specified ssid (which is displayed correctly) other options: respect energy saving mode

[edit]

the real issue here

detecting the type and properties of connectivity (wifi, ssid of wifi, mobile data, metered, unmetered) depends on the global device discovery. this should be an independent task.

what I've observed

1. connect to specified wifi
2. start app
3. permanent android notification comes up saying "syncthing is activated"
4. disconnect wifi
5. permanent android notification says "syncthing is deactivated"
6. reconnect to specified wifi
7. permanent android notification still says "syncthing is deactivated"
8. tab on notification brings app in foreground with error popup saying something like "syncthing is disabled, reason: the ssid is not in white list."
9. after reopen settings page and close it without changing anything, it reactivates.

what I've expected

• after 6.) it should reactivate automatically without any user interaction.
• change of network type should be independent from use of network, e.g local/global discovery

nice to have

• no permanent notifications, that means: only notfications on status changes, otherwise silent background operation

the app has all rights, the battery management is "unlimited" and the "stop app when idle" is disabled the app is configured to only do local discoveries

Version Information

App Version: 1.23.6.3
Syncthing Version: v1.23.6
Android Version: Android 13 / CalyxOS-Version 4.11.3

[tomasz1986]

Is location enabled in the Android settings? If not, then you need to enable it, as otherwise Wi-Fi connectivity detection in the Syncthing app won't work.

the app is configured to only do local discoveries

This is unrelated to the issue at hand, but local discovery is broken in newer versions of Android, so if you disable global discovery (and relays), you will effectively have no discovery at all.

[wertziop]

the dependency of ssid and location service is android bullshit, that's clear. But why does the check of connectivity depends on the discovery? that's a completely different functionality, imho. connectivity: which network I'm using at the moment? is it cheap, what's the name, dows it changed lately, etc. discovery: use the network and do some magic.

i'll edit the issue, to clarify that point.

[tomasz1986]

But why does the check of connectivity depends on the discovery? that's a completely different functionality, imho.

It does not. That's why I said it was an unrelated comment 🙃. The only thing that should have an impact here is whether you've got location services enabled in the Android settings and whether the app is allowed to access location. If both of those are true but the problem still persists, then it may also be something related to CalyxOS which is supposed to harden privacy, security, etc. which could possibly result in apps being unable to determine whether Wi-Fi is connected or not. This is just a speculation on my part though.

[wertziop]

it has all necessary rights and location service works properly. I've tested it just now: global discover AND nat traversal is on: wifi ssid detection works one or the other is off: wifi ssid detection does not work.

if you think i've done something wrong, or messed my config up, you're free to close this issue. I will not continue to test it.

[RalfWW]

I can confirm the issue - still - with Syncthing Version 1.273.7 under Android 12 at a Poco X3 pro.

A configured, right SSID, will not be detected after "coming home"... Without a configured SSID, a "now/new" available Wifi-Connection is detected, syncthing starts working...

[zauberervonOZ]

Allow access to location all the time I think, worked for me

[bt90]

I think we need to request the ACCESS_BACKGROUND_LOCATION permission.

We declare it in the manifest but don't request it in the startup wizard.

https://developer.android.com/training/location/permissions#request-background-location

[Catfriend1]

@bt90 Here's the two function that are needed to request it: https://github.com/Catfriend1/syncthing-android/blob/d8e007d1f8b758ba87f99dc6cce18903515fc63e/app/src/main/java/com/nutomic/syncthingandroid/activities/FirstStartActivity.java#L530

https://github.com/Catfriend1/syncthing-android/blob/d8e007d1f8b758ba87f99dc6cce18903515fc63e/app/src/main/java/com/nutomic/syncthingandroid/activities/FirstStartActivity.java#L541

[user-elly]

I can also confirm the problem about automatically recognise the allowed ssid. Once configured it works as expected. But some hours later the app pretend to have wrong working conditions. Then i can only help myself with two options

• switch off the ssid dependency and allow all wlan networks
• or force android to stop the app and open it again. Then the ssid is again evaluated once as expected. But this trick was always needed to get another sync run started.

Using a "realme 7 (5G)" with Android 12.

[xarx00]

I was about to create an bug about this, and found this issue.

The app can detect that Syncthing battery settings are not set to Unrestricted, and notifies the user to change it. On the other hand, it does not detect that location privilege is not set to "Allow all the time". Instead, upon start, it says something like "syncthing is disabled, reason: the ssid is not in white list".

The check should be performed only when the location services are really needed, i.e. when conditional run ("Run on wifi") is checked.

It took me several hours to figure out the problem. This simple check would have helped to solve the problem immediately.

[LinuxOnTheDesktop]

    I take it from this page that the following obtains.

1. syncthing android needs a code-change in order to enable it reliably to identify white-listed wifi networks and even any wifi at all.
2. There is a workaround, viz., the user granting Syncthing the permission to access location 'all the time'.

Yes? Re 1: I lack the knowledge to make the pull-request myself, but I look forward to someone doing so.

    To this problem (/these problems), cf. (at least):

• 1304 (open);
• 1775 (open);
• 2068 (closed as duplicate of this issue, viz., 1960, but also, seemingly, closed as 'not planned').

    I reiterate the point (made by me, and another, on #1304) that living with the current situation - at least until one discovers the workaround (a workaround that I am about to test) - hammers one's phone's battery.

    Finally: ah, the workaround does not seem to work for me, in that Syncthing, when set to run on any wifi network, fails to detect when I am connected to my home network (or rather - I use dual-band wifi - to both of my wifi networks).

[tomasz1986]

• 2068 (closed as duplicate of this issue, viz., 1960, but also, seemingly, closed as 'not planned').

This one is due to GitHub's confusing wording, i.e. when closing an issue as duplicate, you are supposed to use the right button, which then results in the "not planned" thing.

I also do think that most if not all of these issues are likely related though.

[LinuxOnTheDesktop]

@tomasz1986 : you mean the rightmost button (i.e. the button on the right, as against a button that is by some criterion correct), I think!

[tomasz1986]

There are basically two options - close as completed (i.e. implemented) or close as not planned (which includes "won't fix", "can't repro", "duplicate", "stale", etc.). The problem is that this is only shown when actually closing the issue. Once closed using the latter, everyone sees it as "closed as not planned" regardless of the real reason for closing it.

[LinuxOnTheDesktop]

@tomasz1986 : right; thanks.

I find: (1) granting full location permissions does not fix the problem whereby Syncthing fails to detect a wifi network (at least when using dual-band wifi); (2) even when one tells Syncthing to ignore 'run conditions', it will fail to start until it (Syncthing) is restarted.