-
Notifications
You must be signed in to change notification settings - Fork 717
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
[META] Improve F-Droid Notification #2055
Comments
The main drawback of this solution is that the app will potentially perfoms periodic syncs even if there are no important events waiting for you. |
Solves/better explained version than my issue |
Yeah the Notification loops everytime if I swipe it unread away :( this is really frustrating and the App Takes like the other Issues a lot of Battery but this is not the Main Problem for me... |
Thank you for your work on improving this situation in #2080 @BillCarsonFr. However, I don't think the issue is really solved if there are any user settings for it. Requiring users to manually switch between settings for different scenarios is a usability problem. I am sure I will forget to switch between the better setting for my present usage which could change multiple times during a day. There should be no tradeoff between battery life and receiving timely notifications. I expect notifications to just work and not consume much battery at any time. If I understand correctly, doing this without FCM requires server sent events in the Matrix protocol. Another workaround could be providing Element APK builds with FCM separately from the Google Play store so they can be used with microG. This could be in an FDroid repository just for this purpose. Alternatively, Zulip attaches APK builds to each GitHub release and links them from their website. But ideally the official FDroid build should just work without any configuration from the user. |
TL;DR
The scope of this issue is to give F-Droid users more control on Background Syncs without needed any changes on other system (sygnal) and only using full syncs. So basically adding back the same options that were available in riot android
Problem
The F-Droid element app cannot rely on the Google Push solution (FCM/GCM) that is propriatery code and therefore cannot be used.
As a consequence F-Droid apps need to implement an alternative way of getting messages while the app is in background or killed. This is usually achieved by doing some long polling, or keeping alive a websocket connection while the app is not in foreground.
But recent android version introduced several battery saving features (aka doze), that drastically reduced the capacity for apps to perform any kind of work in background.
If you add to that additional vendors custom limitations, you get a fragmented environment making it hard to test and would force user to perform some specific manual step to make thing works.
Notice that when using Google FCM, you get a magic out of jail card, that allow your App to sync in background after receiving a push;
Current Polling Solution used by Element
Element Android implemented the following solution:
It is said that under normal operations alarms should not be allowed to run more than every minutes, in doze mode it is 15mn, white listing your app from battery optimization would relax those rules but you could have the joy to see your alarm executed but with network disabled 🙃
Upon wake-up the SyncBroadcastReceiver will:
listening for events
notification)The SyncService is then started, it will perform a complete sync with a 0s timeout, that will get all new events for all your rooms
Difference with the former riot-android app
The former riot-android app had 3 fdroid notification mode:
The
optimized for battery mode
was using Workers and was letting the system manage frequency of execution depending on system state (so syncs could be heavilly delayed or even stopped in doze mode)The
optimized for real-time
was using Alarms to force wake up, and required to be whitelisted from battery optimizations, ensuring users to get notifications even if the phone is in doze (e.g standing still on a table for sev 10's of minutes)Default delay between syncs is 60s, default timeout is 6s, and those are configurable by the user.
So Element Android way of working is the old
optimized for real-time
with 30s delay (instead of 60s), and 0s (instead of 6s) of timeout=> So yes Element android is by default lot more aggressive on battery than old Riot Android
The text was updated successfully, but these errors were encountered: