I'm curious to know if anyone is using this framework in the wild.
I'm curious to know if anyone is using this framework in the wild.
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.
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...
You don't always have that luxury.
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?!
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.
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...
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.
I'm happy that I'm using LineageOS. My phone is turning 7 years old, and it's running Android 9, and I've no reason to switch so far.
It is the only way I can get my K-9 mail app to stay alive to sync my email.
You can read more about it here in case you are curious: https://hackernoon.com/notifications-in-android-are-horribly...
If you're not whitelisted, there's very little you can do except for ask users to take various manual steps to change operating systems.
This site ranks Android OEMs that kill apps in the name of battery optimization: https://dontkillmyapp.com/
I believe this aggressive behaviour tends to come from user-feedback, given users care a lot about battery endurance and heat dissipation.
Absolutely. I don't want my phone to run hot or low on battery when I'm not using it. If there was a way to shut down all background tasks when the screen is off, I'd gladly do that (second device, no sim, WiFi only use case).
If I want my email app to download my emails as they come in because I'm on a slow network connection, I want it to do that even if I get a lot of emails. Especially then. Even if that means I have to charge my phone every day instead of every week.
What they should be doing is using a blacklist instead of a whitelist. Not because they're actually going to be able to blacklist every misbehaving app (though they could certainly catch the most popular offenders), but because that's how you get developers to change their behavior.
If everybody is restricted by default then there is no incentive for bad developers to do better. They get restricted, they weren't going to get whitelisted either way, so they go on making a wasteful app. By contrast, if making a wasteful app could get you blacklisted and restricted when you wouldn't have been otherwise, well now you've got a deterrent. Meanwhile they wouldn't be defaulting to breaking well-behaved apps that are designed to efficiently run all the time.