As far as I know, the only truly 100% reliable way to never be killed is to run as an accessibility service. I haven't implemented this in Red Moon but will likely add it as an option. I believe it has a large impact on bettery life.
You can also set alarms using AlarmManager to restart the service if it has been killed, and optionally wake up the device. This is what DNS66 does.
I'd look into that before starting that implementation.
[1] https://blog.lastpass.com/2017/11/lastpass-android-accessibi...
https://github.com/LibreShift/red-moon/issues/253#issuecomme...
Just bought a Xiaomi Redmi Note 7 and it kills everything including foreground services with a notification.
A simple user still can allow it but it will require some tech knowledge to follow instruction that are described here: https://www.reddit.com/r/Xiaomi/comments/amcck5/miui_10_keep...
If a OS is actively sabotaging you, then yes, the only real solution is to replace it with something else. That's the simple and obvious solution.
The simplest way to do this is to not buy a phone with shitty OS in the first place. As in "Don't buy a phone from Xiaomi".
And when users complain about it you tell them that the problem is their phone manufacturer. If you can, of course, give them a work around so the app will work. But eventually they'll plug all the holes that allow for a functional phone. So it may not always be a option.
Despite this being true many will see is as an excuse, or worse just a plain lie, and leave you a 1* (or 0* if possible) review ranting about your attitude and bad coding. How dare you criticize their choice of device?!
You don't always have that luxury.
Should you simply drop support for IE and punish people relying on it and hope it dies quickly?
Or should you maintain legacy code, and actually helping IE to survive by supporting it?
I find that issue to be quite complicated and I'm still unsure if there is a right answer to that.
I wish this was more obvious to people. Had to use my retire parent's phone to long into Netflix for them and it was overflowing with of persistent notifications.
The solution to the background limitations for now is running as a foreground service. This shows a persistent notification (which can be hidden by the user) but can then run indefinitely. The other option is to integrate this at the system level (via a custom rom, root, magisk, etc.).
> I'm curious to know if anyone is using this framework in the wild.
The client side implementation of this is still WiP, so it's not used yet in the wild. I hope to be at a point where I can work with some apps on integrating it there in the next few months.