[Too]

#3 shouldn't break normal apps (excluding these chinese notification solutions), it's clearly documented restrictions apps should adhere to on https://developer.android.com/guide/components/services, and https://developer.android.com/about/versions/oreo/background, with WorkManager and JobScheduler examples one should use instead. Are you saying OEMs go even deeper and interfere with these APIs rather than just stopping the background service and the process as they are allowed to, and some times must due to memory shortage?

I wouldn't be surprised if OEMs had nasty tricks going on but the dontkillmyapp.com doesn't even mention the existence of these APIs and instead try to promote some auto-start apps on boot workaround believing that the service must be running? Giving me very little confidence in the rest of what they are saying. A lot of it has become more aggressive since each release lately so that could explain confusion for old app developers.

[gdeglin]

My understanding is that this Samsung device feature operates outside of Android's normal background execution limits.

Samsung's documentation on the feature is here: https://www.samsung.com/us/support/answer/ANS00088422/. Notably, the documentation fails to mention that this breaks notifications and timers (like Alarm Clock apps).

This is compounded with bugs on Samsung devices that prevent reliably notification delivery. Here's a thread on the Samsung forum about one of these bugs with 346 (!!) replies: https://eu.community.samsung.com/t5/galaxy-s9-series/delayed...

It seems hard to believe that Google and Samsung would allow such popular devices with these behaviors to be sold, but here we are.