Skip to content
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

Closed
BillCarsonFr opened this issue Sep 4, 2020 · 4 comments · Fixed by #2080
Closed

[META] Improve F-Droid Notification #2055

BillCarsonFr opened this issue Sep 4, 2020 · 4 comments · Fixed by #2080

Comments

@BillCarsonFr
Copy link
Member

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:

  1. When the App enters Background, an Alarm is scheduled, using setAndAllowWhileIdle. This should allow the alarm to be scheduled even if the app is in doze mode. When fired the Alarm will send a broadcast to the SyncBroadcastReceiver

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 🙃

  1. Upon wake-up the SyncBroadcastReceiver will:

    • Aquire an additional PARTIAL_WAKE_LOCK to give the app more time
    • Starts a foreground service (SyncService), that is required to display a notification to the user in order to be allowed to run (the listening for eventsnotification)
    • Then reschedule an Alarm in 30s (hard coded for now)
  2. 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:

  • Optimized for battery
  • Optimized for real-time
  • No background sync

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-timewas 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

@BillCarsonFr
Copy link
Member Author

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.
So given on your account structure it could sync a good amount of data, for example if you are in a lot of active public rooms, you will get all those messages that would have not triggered a notification.
In comparison, in this case, the push version would have not synced at all during all this period

@AUSITStuff
Copy link

AUSITStuff commented Sep 6, 2020

Solves/better explained version than my issue
Removed function: ability to set custom sync/check frequency #1815https://github.com/vector-im/element-android/issues/1815

@DoM1niC
Copy link

DoM1niC commented Sep 7, 2020

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...

@Be-ing
Copy link

Be-ing commented Nov 12, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants