Closing Element closes background services

[keleset]

Hello,

I'm using Android 10 with Element from F-Droid store. When I'm closing the app from "Recent apps" menu, this also stops any background activity, such as listening for events.
This was not the case for Android 8 + RiotX.
Also, for example, Telegram FOSS (which also has custom push notifications mechanism and not firebase) doesn't cancel event listening in this case.

Also Element does not appear in Developer options -> Running services unlike mentioned Telegram FOSS.

[olymk2]

Just looking into this myself have you found this screen and run the troubleshooter ?

[BillCarsonFr]

I don't think it's necessary to enable the notification to have it running. But you have to enable 'Enable notification for this session'

Regarding the 'running service', element will periodically start a sync as a foreground service; That means that periodically you will see a 'listening for event' notif, and depending on your sync size it might be fast.

So it's permanenlty checking periodically

[keleset]

Oh, nevermind, it's broken again, even with "Listening for events" turned on. Sync just never appears again after the app was closed through "Recent apps" menu. I'm unable to find out what causes this problem. Could this be related to presence/updating of Google Services or turning off/on VPN on the system?

[BillCarsonFr]

If you used the 'force stop' option in running apps, some android version will block it from running in background until you explicitly relaunch it

[keleset]

I have a "close everything" button in "recent apps" menu, pushing it while Element is in the list almost always stops sync from appearing. The thing is: sometimes it doesn't stop it and sometimes syncs die with Element still in the list.
This is too random to catch. I guess the easiest option would be to make a new setting in notification settings that would switch on "permanent" service mode (Element would be a service that runs 24/7 and always appear in "Running services" list) like it works for Telegram FOSS (https://github.com/Telegram-FOSS-Team/Telegram-FOSS).
I would be really glad to provide a PR, but I simply don't have enough skill with kotlin for this.

[kojid0]

Having the same problem, also with F-Droid version. I only get notifications when Element listens ('listening for event' notif).
Why can't there be a setting to show this notif forever? There are lots of apps showing a constant notification in order to be able to receive notifications immediately. You can disable this constant notification in Android settings though.

[53c70r]

FDroid version does not give me any background con either on /e/ OS - FP3.
Don't getting any messages until i explicitly open the app again.

[elerch]

Same issue with F-Droid version on Android 9. It might be worth investigating how other apps do this. I know F-Droid version of Tutanota has a similar use case. For that app I periodically see a brief notification while it checks for mail. While that app still has some issues, that app has less problems than element, which at least for me very consistently closes when not in foreground. An advantage of that brief notification is that if it fails to appear, it reminds me that the app is not running. IIRC that notification is an option I can turn off if I don't like it.

Syncthing has a different use case, but is delivered through F-Droid and is rock-solid for me. I believe its secret sauce is a persistent notification.

[andrewaylett]

My current understanding of this issue is that Element schedules synchronisation using a Worker or an Alarm, has a notification active while actually syncing, then schedules the next synchronisation. But if the system declines to run your worker, there's no mechanism for restarting. I've had a play about with trying to add one (in #2921) but I'm not entirely clear that's the direction to go in.

Also, we currently run the SyncService as a background service which runs a thread doing long-polling only while the application is in the foreground. From https://developer.android.com/guide/components/foreground-services?hl=en#start I think that it should be possible to run the SyncService as a foreground service even when not actively running the application. This would result in a persistent notification (which can be hidden) and an ongoing sync. As we're long-polling, this wouldn't use (much) more battery than FCM, even, and should help avoid the delay of restarting synchronisation when returning to the app.

[benjmarshall]

I also have the same problem, and have had as long as I can remember running Element.

I'm on LineageOS/MircroG with no google services so rely on the Fdroid versions' polling mechanism. In it's current state Element on Android isn't usable as a real-time messaging application for me which is a shame as I would really like it to see wide adoption!

Has the PR is #2921 been tested? I'm not experienced enough to build myself but would happily test if someone can build that version?

Has anyone found a workaround to reliably restart Element in the background, perhaps using Tasker or similar? This is something I have considered trying to mess with. but fixing the issue at source always seemed like the better option.

[immanuelfodor]

Gotify Android (https://github.com/gotify/android), the self-hosted notification system, uses a websocket connection with its server + recommends disabling battery optimizations + utilizes a foreground notification for keepalive. In my experience, it uses minuscule battery over the day, doesn't even show up on the battery stats page in Settings. However, I always receive every notification instantaneously.

Two takeaways:

• Maybe an optional minimized notification can keep Element running (could be turned on in app settings)
• A websocket-based notification method could be tudned on if Synapse or another used Matrix homeserver supported it. It could be a viable alternative to FCM notifications for users without Play services. It could also provide an alternative to privacy minded self-hosters even when they have Play services and even if they know that the notifications are also E2E encrypted but want to go for the all-selfhosted way.

[ouchadam]

Addressed by #4298, is in 1.3.7