| We are running a (very niche) platform + app for people with special needs, where accurate and offline alarms are necessary: this is a big problem for us. I think about 1/3 of all our support requests are about the app being killed in the background on specific phones. The part of the app that does the actual scheduling of the alarms is a big mess with lots of device & API level exceptions. Debugging alarm problems is a nightmare. We often advice users on what phone to buy and tell them to avoid specific brands. Sometimes users even need to buy a new phone to be able to have reliable alarm signals. I understand why manufactures are doing this. But it really degrades the user experiences for our users quite a bit and is a significant cost (in terms of support load + extra development) for us as an app vendor. Really hope that Android 8+ incentive manufactures to just use the standard Android mechanisms: they seems to work quite well in my experience. You can run things in the background, but only if it has a user interaction as a result: i.e an alarm notification. The user can then determine if this is wanted or not directly from the notification itself. Unfortunately it is not much better on the Apple side of things with local push notifications limits. |
I really don't. User has power to uninstall or replace app that is in his opinion using too much power. There is no need for manufacturers to intervene. They should only display warning about app using too much power. But it seems killing app is so much easier for them.