Syncthing-android: Android kills the syncthing process when activity is closed

[Unrud]

Android kills libsyncthing.so everytime when the activity is closed. It gets automatically restarted by SyncthingService, but syncing gets interrupted.

I ActivityManager: Killing 9422:com.nutomic.syncthingandroid.debug/u0a128 (adj 16): remove task
I libprocessgroup: Killing pid 9500 in uid 10128 as part of process group 9422

[Nutomic]

Can you tell me how to reproduce this? Because I can't see this output in the logs. Also, the binary is started by the background service, so I don't see why it would be stopped when an Activity is closed.

[Unrud]

Can you tell me how to reproduce this?

Start Syncthing and close the activity. It only happens when the activity gets closed, not just send to background.

[Nutomic]

I tried that, but didn't get this log output. Please post the exact steps to reproduce, and Android/app version you're using.

[licaon-kter]

@Unrud Even with background active?

Even with experimental foreground service active?

[capi]

Have you by chance enabled some development options? There are some settings that will do exactly this. Also certain "power saving options" may be doing this. The best-bet is to enable the "Run service in foreground" mode, that should be equivalent to having the activity in foreground.

[wweich]

If I remove Syncthing from the recent Apps, all other nodes show my phone disconnected for a short time and the notification disappears for a few seconds.
I have the experimental wake lock option enabled, no Android development options and no power saving options enabled.

If I enable the experimental foreground option, the notification stays, but when I go inside the App shortly after removing it from recent Apps, it shows loading for a short time, while the other nodes show is as connected.

---

BTW: Since activating the experimental foreground option, I keep getting the "device wants to share folder .." notification for all already shared folders. Even after disabling that option.

[capi]

@wweich Removing from "recent apps" force-stops the process, which is then re-started due to the auto-restart policy of the service. That's how Android works and nothing we can change about that.

Regarding the notifications, those are generated by the syncthing native binary, no influence from our side there. So unsure, how this is triggered.

[wweich]

I knew that those restarts probably cannot be avoided and I can live with it (don't clear recent Apps while important sync is running ;) ). But I suspected that this is what the OP meant.

Regarding the notifications. Turns out, that for some reason all folders were unshared, after I enabled the experimental foreground option.

[Unrud]

Android/app version you're using.

Android 6.0.1. It happens with the version from f-droid and with a version that I compiled form this repository.

Even with background active?

Yes

Even with experimental foreground service active?

No

That's how Android works and nothing we can change about that.

You can use the android:process attribute in the service definition. The service will run in a different process and should not be restarted when the activity is closed. But you have to use AIDL to communicate with the service.

[Nutomic]

Ah it only seems to happen if you swipe the app away in recents (I tried to use the back button).

@Unrud Would be cool if you can make a PR for this ;)

[Catfriend1]

@Unrud: I remember that this problem also affected me on an earlier syncthing app release but haven't stumbled on this for a while. Is this still an issue in 0.10.8 release?

[Catfriend1]

Is this still an issue in 0.10.10 release?

[Catfriend1]

I am explicitly testing this on Android 7.1.2 with lg-h815 device ... confirmed!

[Catfriend1]

I can confirm the problem @Unrud reported is still present on 0.10.10. SyncthingService restarts the binary but it takes time ...
Here's the log:

[Catfriend1]

Source for anyone wanting to help:

https://developer.android.com/guide/topics/manifest/service-element

android:process
The name of the process where the service is to run. Normally, all components of an application run in the default process created for the application. It has the same name as the application package. The element's process attribute can set a different default for all components. But component can override the default with its own process attribute, allowing you to spread your application across multiple processes.
If the name assigned to this attribute begins with a colon (':'), a new process, private to the application, is created when it's needed and the service runs in that process. If the process name begins with a lowercase character, the service will run in a global process of that name, provided that it has permission to do so. This allows components in different applications to share a process, reducing resource usage.

[Nutomic]

Multiprocess might cause other problems though, we might need a different API for inter process communication. And we might have to do some explicit synchronization between processes.

[capi]

The service should not be killed on swipe-close, if you are running with foreground priority. But I'll have to check that.

[Catfriend1]

@capi: Please note I did not check foreground priority when testing.