-
Notifications
You must be signed in to change notification settings - Fork 741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
F-Droid background syncing #4298
Comments
The FairEmail dev had to create an entire FAQ entry just for this: https://github.com/M66B/FairEmail/blob/master/FAQ.md#user-content-faq39 |
For content, what about "We're listening for notifications..." |
It might be just me but it somehow feels invasive when including "we're", compared to "Listening for notifications" Like element is personally listening to my notifications 😅 |
Haha, fair point @ouchadam. Cut to "Listening for notifications" then 👍 |
Is part of 1.3.7 |
Finally (FINALLY) got the 1.3.7 update on F-Droid. But now I'm confused as to what the default configuration is supposed to be. I was expecting just a single toggle for a permanent sync notification to be created, like Telegram-FOSS has. Maybe Element should also do the same. Anyway, should I choose If only the There is also no check mark or something similar next to the currently selected option in the |
I have not had any notification issue (including late or not arrived notifications, background process auto-closed) on a Samsung phone with Android 7.1.1, Element from F-droid, setting Is it possible to disable the persistent notification for this case? |
Just delete anything in the input field and save. Then the default will be used and shown. |
This only applies to if the device is left unattended and the screen is turned off, right? I'm assuming if the phone is being actively used there is no "waking" to be done, since there is a permanent foreground notification.
Maybe this could be retained for Developer mode. |
I am running Element-FDroid on /e/OS 0.18-o in an "always online" mode (= "optimized for real time", 0 seconds delay, 179 seconds timeout; notifications working perfectly). I can report that version 1.3.7 is using 25 to 30% less energy when idling. Thanks! Element is now down to using ~8 times as much battery as Conversations. |
Centralising the fdroid specific background notification issues - #3263 #3159 #2827 #2669 #2143 #1419 #2519
Context
The fdroid variant of element does not use Google play services which means we cannot receive push notifications (FCM). Instead we must manually poll the server for new events at a scheduled rate whilst the app is in the background to achieve a similar messaging experience.
Element currently provides 2 mechanisms for polling in the background
WorkManager
workersForegroundService
triggered byAlarmManager.setAndAllowWhileIdle
AlarmManager
usage allows some system battery optimisations to be skipped like executing during Doze however they're limited to once per 9 minutes.but...
Both mechanisms suffer from OEMs being able to ignore our background scheduled tasks and the system applying restrictions to how often we can schedule.
#3844 approaches the problem by using a long running
ForegroundService
along with an explicit timer to manually trigger and reapply the background scheduling. We have reports that this resolves the notification issue.#2921 is similar in approach by using
PeriodicWorkManager
workers as a way to ensure the polling workers are being scheduled, there's a 15 minute minimum interval. This approach still suffers from the system being able to ignore the scheduling.Through my local testing simply the existence of a foreground service allows the Element process to avoid being killed early (especially in combination with disabling battery optimisations)
*Pocofone F1 MIUI android 10 & Nexus 6P android 8.1.0
*Unplugged on WIFI
*Battery optimised background sync set to 60 seconds
*Noop foreground service
*Writing a timestamp to disk each time the sync worker is triggered
We can see the
WorkManager
quickly starts to ignore our 60 second rescheduling requests on the Pocofone, but it takes a few hours for the Nexus 6P to start scaling back.The foreground service also protects against #2143 (closing the app through recents, only some OEMs ignore WorkManager/AlarmManager jobs when doing this)
Proposed solution
ForegroundService
with a persistent notification, including when the app is in the foreground. This will stop the system from ignoring our scheduled work when the app is in the background/has been stopped.An example notification...
1.
may not be enough for some OEMs, this is where we provide another background sync option in which we manually reschedule events instead of relying on the system, this will use more battery than the other mechanisms. I would argue for only doing this once we confirm 1. doesn't fix the issue.The text was updated successfully, but these errors were encountered: