Running background services in Android is tricky. Most device manufacturers put their own battery management software on devices, which makes it almost impossible to run long-running services in the background. And since this framework would either perpetually run in the background or run frequently to check for new messages, your app is guaranteed to be throttled(force-killed) by most devices. And being force killed means that your app cannot receive push notifications even from FCM.
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.
Maintainer of Red Moon, a screen filter app, here. I've struggled with similar problems as others describe for a long time.
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.
This might have changed since, but in 2017 LastPass had to work with Google to update how they run their app. Google introduced "a new policy restricting the use of Android Accessibility Services" [1]
I'd look into that before starting that implementation.
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.
> tell them that the problem is their phone manufacturer
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?!
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.
Under Nokia it says that its Android One phones are aggressively killing apps as well. Isn't Android One a phone with vanilla Android install without vendor crap by definition?
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.
They are (I own a Nokia), but you can go into Battery Optimization in the settings and tell it to not optimize an application. That, I find, tends to leave it alone much better.
It is the only way I can get my K-9 mail app to stay alive to sync my email.
My previous phone was Oneplus with such an extreme battery manager (rated by some resource in top 3 of most aggressive managers). There were messaging apps which worked just fine in background and send push notifications even after prolonged periods in background (e.g. Telegram and others) and some apps which were killed in minutes after being minimized (e.g. official Skype app). Point is - I suspect that there is a correct way to make inoffensive apps which will work in background, but certain minority of developers simply don't give a damn about battery usage and proper coding guidelines.
Oneplus incidentally maintains a whitelist of apps which are allowed to run in the background and only apps in that list can run for extended periods. While it is possible for users to add apps to that list, it comes with a set of apps already whitelisted ( like whatsapp). I found it out the hard way while working on Android.
> 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).
And by poorly written apps which actually DO drain the battery while doing nothing useful. So I don't feel like putting all the blame on the OEM manufacturers.
The problem is they're using bad heuristics. Just because a service runs 24 hours a day doesn't mean it's using a significant amount of battery. The harder problem is, just because a service uses a significant amount of battery doesn't mean it's doing nothing useful.
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.
The reason why some apps work is they've been whitelisted by the manufacturer, not a choice by the developers (except maybe a choice not to pay to be whitelisted?)
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.
I'm curious to know if anyone is using this framework in the wild.