oxen-io
force run as "foreground service" all the time
This is the bare minimum to run as a "foreground service". Ideally there would be an option in Settings->Notifications to enable this as a third option after Push & Polling.
I don't recommend this PR be merged into the mainline branch. But others may like to merge and compile themselves to activate foreground service.
This could be quite interesting, interested on how much this increases battery usage? and if the OS can interfere in any way with a foreground service? https://dontkillmyapp.com/
Also interested if we could modify code to only run minimal poller while app was backgrounded but foreground service was running
I should have clarified, "foreground service" is so music apps and the like can play music etc without the OS shutting it down. So we register a foreground service even though it does nothing. This allows session to run even if you swipe close the app or sleep the device and Android wont kill it.
My phone has been asleep for hours, new messages still show immediately.
Not sure about battery life. I also run Signal, Elements and a few others all with their own "foreground service", so running permanently. Phone still makes it through a day no problem.
After 12-24 hours of running with foreground service active I can verify that battery consumption is far too high. I guess it might be useful for someone who needs immediate notifications for a short period of time.
There might a good way to switch between the "active" polling and the polling via foreground service @andrewheadricke but that is useful information in terms of battery usage. I noticed we actually have a similar service in the app (I think from forking Signal) GenericForegroundService.java which we could probably look at merging some of these poller changes from this PR into, but might have to wait until we can do something about the battery issue (might be as simple as just polling less frequently)
Tracking this PR internally through https://optf.atlassian.net/browse/SES-660, which will look at various options for improving notifications for devices not using Google services
We are still tracking this internally via SES-660, but closing for now as the PR has some conflicts and isn't necessarily the approach we want to take here.