I work on Android professionally both in building our own apps as well as reverse engineering existing ones alongside Android system processes, the Android kernel, and device firmware. There’s a lot of FUD here and not a lot of actual information in the comments. Perhaps I can provide some perspective.

In the beginning, Android was everything that Apple was not. Liberal and open, app developers were given almost complete freedom. The young OS needed a thriving ecosystem yesterday to challenge the App Store. This is reflected in other choices that still live with us today, like the choice of the Java programming language and its garbage collection to keep the ecosystem familiar and easy to learn for developers. This has led to chronic memory struggles, but that’s a discussion for another time.

Today, there is no need for explosive development. The Play Store is overflowing. We have the quantity. Now, the problem is app quality. It turns out that developers are selfish and cannot be trusted to be good stewards of shared, limited system resources. It’s easy to understand why. Developing an app is no small feat, and it’s natural to become attached when in reality your app might not mean the world to every user. Other developers wish to collect your data, and are happy to expend resources in ways that don’t benefit you. Permissions were added, sandboxing, and eventually Android decided to tie user interaction to system resources.

The idea is that if an app is important to the user, they ought to actually be using it, no? Whenever you use an app or interact with a notification, you’re telling Android that this program is important. Timers and events can fire more frequently, and the OS is more willing to perform background work. Apps you don’t use much are throttled, but they can still show a notification immediately if designed properly to respond to external events. More on this later. Remember: Android must decide where to spend your limited resources because apps cannot be trusted to do this amongst themselves.

The App Freezer takes this principal to the extreme. If you’re not actively interacting with an app, it gets zero resources. Nothing! It cannot run. The app is stopped. If you want to run, you need some external push to trigger access to resources. For example, the user could tap the app icon. A server might push a notification which will cause Android to unfreeze the app to handle it. You can also set timers or schedule the app to run on other conditions, but whether or not those things actually happen is up to the OS assessment for how important you are to the user, and app functionality must be driven through these events.

Many methods to trigger running are frequently abused by applications that don’t want to remodel. For example, a lazy developer could set a timer to trigger running an app every five minutes to check email. This is a really bad design because we have to keep the app in memory all the time and able to run which waste the battery. An app shouldn’t check for anything by polling. Rather, the email provider should tell Android to trigger the app to run on your phone whenever an email arrives, even if the app isn’t running! Push. Don’t pull the data. no useless spinning. It runs only when the email arrives and at no other time.

Android is taking a firm stand with the Freezer. You must redesign your app to respond to new data as it arrives or your app simply won’t work correctly. This is a complete reversal of responsibilities where your app is driven from the outside instead of the app doing the driving. A correctly written, well-behaved app will look almost inside out because it’s called upon to handle events rather than performing actions to check for events. This is a better design because keeping applications running all the time is not sustainable as users install more apps. iOS had the right idea of being extremely conservative with background services in the beginning. Android is still trying to bend apps to submit to the OS rather than the other way around.

If a party is at fault here, it’s Google. It’s irresponsible to allow apps to simply malfunction because this is a poor user experience. Notifications are delayed, and users don’t understand what’s wrong. It is my opinion that this problem occurs because Google did not provide sufficient developer support to redesign applications. To make matters worse, the behavior is highly inconsistent because every handset developer has slightly different rules for what constitutes important and exactly how resources are assigned. Sometimes, a badly designed app will work just fine until one day the OS decides it’s not important right now and you miss an update. to the user, the app looks flaky and to the developer sometimes it’s working so is there really a bug?

I’m not proposing a solution. I’m only here to explain the problem. App developers are not respecting Google’s intent, and Google is not providing adequate support for these apps when they inevitably fail. This is a decade old problem that resurfaces yet again as Google continues to build on this idea that apps only run based on external events while many apps continue to rely on polling.

Damn. The other day I received a notification from my local post app about something very important that has landed in my PO box when I had just arrived at home from work. I was curious and checked my emails for the exact time stamp of the delivery, turns out it was not "just now" like my Android notification implied but 12 minutes ago. Incidentally, 12 minutes ago was pretty much exactly when I cycled past my PO box being really disappointed that my package hasn't been delivered yet, or so I thought at the time. Had to go back when I could've just picked it up on the original trip.

Stupid me thought it was the "optimised" per-app battery setting vs "unrestricted" that would control this.

Thanks for pointing this out OP!

Can Android please just stop trying to figure this shit out by itsself and just give me the tools to manually configure this shit.

Is this why Waze would sometimes just terminate by itself when not at as the active window? It's annoying when it happens when I'm driving and have an audiobook or Spotify up and my GPS app decides to suddenly stop without even saying it terminated.

The 21st century version of a DOS TSR program?