element-android: Element does not stay running in background

I have taken yesterday and today to take a look at the current sync implementation. I have only taken a look at the real time sync code. It is made using alarms. The sync process with the matrix server itself is called from within the service. Before the service ends an alarm is set into the future to retrigger the sync service. The alarm is captured by a broadcast receiver which then (re)starts the service and the whole thing starts again. As with all services since one of the android versions they must start in the foreground and display a notification within 10s if i remember right. This is happening and I can see the notification icon popping up and being removed again.

But I noticed that sometimes I get an application not responding error on the sync service classes when the service is started meaning it is not calling startForeground fast enough. This results in the sync service not being started hence not being able to set a new alarm for the next sync. The sync cycle stops. I did not investigate why.

I also noticed that on my old Moto G3 with only 2GB Ram acitivities and services are killed and restarted quite often. Especially when I use the browser or NewPipe. This is quite “normal” but might point in the direction of the problem that the situation we have here is one of those corner cases. Low powered old devices with not much Ram. Meaning the timing does not work as with newer phones. I know people using the fdroid version where the sync works without any problems. All of them have modern phones. There also might be a correlation with Lineage as it can be that this is used especially on older phones.

I have implemented a patch. Well quite literally as it is not fixing the cause but the symptom. The patch creates a new sticky guard service that is (re)starting the sync services (VectorSyncService) every 1min. No matter if it is still running or not. Android will not restart/start a 2nd service anyways. The guard service is persistent and shows a notification icon as android requests it. Even if the guard services crashes it will be restarted by android (and not an alarm that might not be there anymore). This works since a few hours. Longer than I have ever seen. I hope that with concentrating on the symptom also other crash reasons on other phones can be fixed. The brave can download the patched fdroid version here. It was made from the current development branch using the grade task assembleRelease. Feedback welcome.

As usual with bugfixing, once you fixed one issue, the next, formerly hidden one appears 😃 Sometimes the sessionId seems to get lost. The GuardService now stores the sessionId in the sharedPreference I updated the binaries here. Additonally I forked the repo and here the diff with my changes can be looked at.

I have read that there is a kill policy for services in Android. Depending on certain parameters it can take up to 30 minutes before a restart of that service is retried.

UPDATE: Works for me since over a day. I think this “fixes” it for now. I believe a rewrite of the sync architecture would be the best course of action. A lot of work though…

I really wish this issue would get some sort of developer response or at least prioritization. It’s quite literally preventing F-Droid users from using Element in its full capacity as a messenger on newer Android versions that impose heavy restrictions on background services. Other apps successfully circumvent this by using a persistent foreground notification. Perhaps WorkManager from Android Jetpack could work as well?

It seems we are moving forward to include this as a temporary patch until a more thorough rewrite has done. So patience you must have young padwans.

Edit 2: Despite no further log output or sync notifications appearing afterwards, Element actually received an incoming message this time and I can’t reproduce the issue now. Perhaps it’s only after a certain amount of time that Element is killed in a way that it can’t sync anymore? I’ll try to always close it from now on and see if I can discern a pattern.

I was able to reproduce the issue again by closing Element late at night and having a friend write to me at 11:00 in the morning - I did not get their message until I manually opened Element later. I also left a Logcat recording running for the entire night, and there are a few things in there that may be related to the problem.

I closed Element at 01:30 and right after that, it wrote the same things as it did in my previous log.

However, at 03:00, a few lines regarding im.vector.app were logged:

[01-16 03:00:03.950 1023:1067 I/PackageManager]
Un-granting permission android.permission.SYSTEM_ALERT_WINDOW from package im.vector.app (protectionLevel=1250 flags=0x30c83e44)
[01-16 03:47:00.711 1023:1067 I/PackageManager]
Un-granting permission android.permission.SYSTEM_ALERT_WINDOW from package im.vector.app (protectionLevel=1250 flags=0x30c83e44)

The following appeared starting at 04:53 and irregularly repeated a few times…

[01-16 04:53:37.875 16858:17014 W/im.vector.app]
Long monitor contention with owner pool-1-thread-13 (17032) at io.realm.Realm io.realm.Realm.getInstance(io.realm.RealmConfiguration)(Realm.java:6) waiters=0 in void io.realm.BaseRealm.close() for 187ms

…until 08:21, when the following was logged:

[01-16 08:21:01.877 1023:1055 I/ActivityManager]
Killing 16858:im.vector.app/u0a213 (adj 935): excessive cpu 37860 during 300176 dur=659207 limit=10

This was the last entry until I checked Element out of habit at 09:40, and no messages arrived yet. Thus, I’m not sure if Element got killed at this point or would have received a message as normal. I again closed it and continued waiting.

At 10:50, this appeared:

[01-16 10:50:11.978 1023:2261 I/ActivityManager]
Killing 17968:im.vector.app/u0a213 (adj 999): empty for 2626s

From this point onward, no further lines containing im.vector.app were logged and I did not receive the message sent to me at 11:00 until I manually opened Element a while later.

I see the same problem on two different phones with the f-droid variant. There seem to be a couple of related (identical) bugs floating around such as #2519 and #2669. That essentially renders the fdroid build unusable, unfortunately resulting in the perception that element doesn’t work even at a basic level. #2669 suggests this has actually worked in riotX, thus it might be possible to bisect the regression.

hoping for a first pass in 1.3.6 🤞

closing in favour of #4298

Same with me running on Lineage OS 17.1 on a still working Moto G3. For me it also never seemed to have worked. This is the only application on my phone that does not work in background. It makes no difference if I remove it from battery optimization. I see a lot of proactive help already. Any more we can provide to solve this issue that seems to be here already very long?

I’m having the issue as well. Someone sent me a phone call with Element and I didn’t get a notification. The notification was there only when I opened Element. This makes Element almost unusable.

Clarification: it stops running for me if I move focus to another activity, despite the RUN_IN_BACKGROUND permission granted.

Same here (on Android 10, though); after updating to 1.0.7+, Element does not appear to keep syncing once it’s closed or I simply switch to another activity. However, all notification tests succeed and battery optimizations are disabled (although it worked before even with them enabled). Settings are exactly as in @BillCarsonFr’s screenshot.

Edit: After some further testing, it seems like Element does keep running when I minimize it or switch to another activity. However, dismissing it from recents closes it completely and it stops listening for events.

Edit 2: Apparently, I was mistaken again; Element does, in fact, die even after simply switching to another activity. It only receives messages once it’s focused again, which makes it unusable as a messenger.