tl;dr The author would like to run his app in the background without notifying the user about it, because otherwise the author would just add add an ongoing notification, which would allow the app to run in the background forever on all platforms.
If this were the solution, I'd have to have a notification that I can't swipe away for email, Telegram, Wire, navigation while navigating, music player while playing, alarm clock when an alarm is set... So say I'm driving with music, that's five useless notifications. The app can ask me on first launch if I want it to do this or not, rather than being permanently in my face about it.
The notification area is becoming increasingly useless (for actual notifications). Since upgrading from 4.4 to 7.0 last year, this has been bugging me quite a bit and I haven't yet found a solution. I was much happier with the old OS, but security updates...
But then it hides all notifications. I still want to know when I received a new email or message.
Again, Cyanogenmod based on Android 4.4 was better here: I could selectively hide notifications with certain contents. In Android 7, I can only choose not to display notifications from a certain app. I still have to write something that reads notifications and kill them selectively, but then I guess such a service would get killed as well without its own annoying notification... (The "you must update google play services to use this app" notification (which is a falsehood) is also annoying the crap out of me, another issue I didn't have on 4.4.)
I didn't actually know the wake lock would still work if you hide an app's notifications, I thought the notification was the prerequisite for not getting killed.
Not really no. It's more problematic, a good amount of vendors doesn't allow applications to run in the background and it's not a matter of notifications.
It's a big issue with IM apps like Conversations or calendars and contacts synchronisation apps like DAVx5
I wouldn't necessarily ascribe anything shady here (which I got a bit of from your comment, if that was intended).
I found this helpful in debugging an issue I've had with my OnePlus - namely, many apps that I'd like to get notifications from abruptly stop getting them after a while, and I have to reopen them to get notifications. Today alone I had to manually open Facebook Messenger and Venmo in order to get notifications from them - this seriously degrades the functionality of those apps since opening Messenger multiple times a day still isn't apparently sufficient to exempt it from being "optimized".
There is much scope for abuse if things are relaxed, but all kinds of very serious use cases become somewhere in between “very difficult and/or unreliable” and “impossible” due to these techniques. For example: email clients, chat clients, calendars, even alarms sometimes.
The first affected things tend to be synchronisation jobs, but it’s distressingly common for these systems to break things so that notifications just mysteriously stop working outright—with no diagnostics of any form for user or developer.
Or how about emergency notifications? I live out in a rural area and it’s bushfire season; I want the VicEmergency app’s notifications pronto so that, if a threatening fire starts nearby I can get out quick.
Your TL;DR is wrong and it completely misses the core issue the website is describing. It's about OEMs breaking core Android API guarantees in cases where the OS (by documentation) allows you to run in the background for short bursts during so-called Doze maintenance interval.
I'm not sure this is the case, the website talks about propietary "battery savers", not about the standard Android one. I find it completely possible that they kill apps regardless of ongoing notifications.
