this post was submitted on 25 Apr 2024
75 points (94.1% liked)

Android

27896 readers
314 users here now

DROID DOES

Welcome to the droidymcdroidface-iest, Lemmyest (Lemmiest), test, bestest, phoniest, pluckiest, snarkiest, and spiciest Android community on Lemmy (Do not respond)! Here you can participate in amazing discussions and events relating to all things Android.

The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:

Rules

1. All posts must be relevant to Android devices/operating system.

2. Posts cannot be illegal or NSFW material.

3. No spam, self promotion, or upvote farming. Sources engaging in these behavior will be added to the Blacklist.

4. Non-whitelisted bots will be banned.

5. Engage respectfully: Harassment, flamebaiting, bad faith engagement, or agenda posting will result in your posts being removed. Excessive violations will result in temporary or permanent ban, depending on severity.

6. Memes are not allowed to be posts, but are allowed in the comments.

7. Posts from clickbait sources are heavily discouraged. Please de-clickbait titles if it needs to be submitted.

8. Submission statements of any length composed of your own thoughts inside the post text field are mandatory for any microblog posts, and are optional but recommended for article/image/video posts.

Community Resources:

We are Android girls*,

In our Lemmy.world.

The back is plastic,

It's fantastic.

*Well, not just girls: people of all gender identities are welcomed here.

Our Partner Communities:

[email protected]

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
75
Beware the "Cached Apps Freezer". It's the new Doze and may be delaying your notifications. (lemmy.world)
submitted 6 months ago by [email protected] to c/[email protected]
19 comments fedilink hide all child comments
 

Recently I got a new phone and immediately had trouble with my notifications coming in on time. Emails, calendar alerts, even alarms were being delayed up to 15 minutes.

This isn't the first time I've had problems like this. When Doze first came out back in Android 6 around 2017, it caused me a lot of grief, until I figured out how to whitelist apps and disable it. However, none of my well-known fixes and workarounds were effective.

A new sinister menace has arisen. It's the Cached Apps Freezer, and it must die.

Before I wrote this post, I did a lot of research and found very little information. It's clear that this feature and it's negative side effects is not well know to the Android user community. The one exception was the Termux community and it's dev agnostic-apollo, who had some excellent notes which I link to below.

The Cached Apps Freezer first appeared in Android 11 QPR3. It's a feature that still seems half baked, like it's in beta, but it's being enabled by default on some devices. Notably, all Google Pixel devices have it enabled by default, but I've read that some Samsung devices also have it enabled by default.

So what does it do? In basic English, it periodically pauses and unpauses any app that isn't in the foreground so that it can't run. The process isn't killed, but it can't do anything until it gets unfrozen. If you watch your logcat, you will regularly see ActivityManager messages with the word "freeze" and "frozen". It's a power saving feature and you will find a plenty of ignorant users praising how it makes their battery last longer, but you won't find any mention of the side effect of delaying notifications.

Note that you might have seen the term "frozen" and "freeze" before in relation to Android apps, where the app is still installed but disabled. This is not the same thing and is not related in any way.

If battery life is your primary concern, then feel free to turn this thing on. It definitely works, but don't expect your notifications to come in right away. They might come in instantly, but most of the time they are going to be delayed up to 15 minutes.

So, what can you do about it if you want it disabled?

Unfortunately this feature has no user-facing control. Google didn't create any kind of knobs or controls for the end-user. Maybe this is intentional, or maybe it's just a half-baked feature. Either way, your only option is to disable it completely.

There are two ways to disable it:

Option 1: Enable Developer Options and disable "Suspend execution for cached apps". You must reboot to apply the change.

Option 2: Run the following command on an adb shell, a terminal, or wherever, and then reboot: "device_config put activity_manager_native_boot use_freezer false".

Below are a bunch of links with reference info.

https://source.android.com/docs/core/perf/cached-apps-freezer

https://www.xda-developers.com/hidden-changes-android-11-source-code/

https://discuss.grapheneos.org/d/11574-cached-apps-freezer-breaking-foreground-services-pixel-7pro-qpr2

https://www.reddit.com/r/termux/comments/13z7cpg/prevent_termux_from_closing/

https://github.com/termux/termux-app/issues/2366

https://github.com/agnostic-apollo/Android-Docs/blob/master/en/docs/apps/processes/phantom-cached-and-empty-processes.md

top 19 comments
sorted by: hot top controversial new old
[–] [email protected] 18 points 6 months ago (1 children)

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.

[–] [email protected] 2 points 6 months ago* (last edited 6 months ago)

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.

Thank you for the detailed post. Something still doesn't compute here because one of the email apps that gets put in the freezer is Google's own Gmail app. If your explanation is correct, what does it say about the fact that Google can't convince their own developers to do the right thing. Overall pretty sad state of affairs as far as push notifications on Android go.

[–] [email protected] 11 points 6 months ago (1 children)

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!

[–] [email protected] 2 points 6 months ago

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

That controls Doze, which can also potentially delay notifications.

The Freezer works entirely separate and in addition to Doze. You would need to disable both.

The nice thing about Doze these days is that you can whitelist individual apps rather than turning the whole thing off. That's what setting the battery to "not optimized"/"unrestricted" does under the hood.

[–] [email protected] 4 points 6 months ago* (last edited 6 months ago)

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

[–] [email protected] 2 points 6 months ago (3 children)

The 21st century version of a DOS TSR program?

[–] [email protected] 3 points 6 months ago (1 children)

You are very confused. Not similar or related to in any way shape or form.

[–] [email protected] 1 points 6 months ago

Confused? No. Seeking an apt analogy for this situation? Yep. Can you provide one, please?

[–] [email protected] 3 points 6 months ago (1 children)

The opposite, programs that are supposed to stay in the background are being swapped to disk, not staying resident at all.

I imagine if a app properly uses push notifications (with all the privacy problems that entails) then this isn't a issue, android sees the push, reactivates the app, you see the notification. If your app does work itself, polls, etc, then this will mean you will miss any activity until the app runs again.

[–] [email protected] 2 points 6 months ago (1 children)

Ah. Thank you, that clarifies things; along with a cuppa java.

[–] [email protected] 3 points 6 months ago (1 children)

yeah if anything the problem is everything is a TSR program now. the generous explanation is because they want to offer the best experience possible and implement everything themselves.

.. but the real explanation is they want more telemetry data, not just when you are using the app. not just when you've recently used it. but no you launched it once we must indefinitely run in the background and install services to launch on startup

[–] [email protected] 1 points 6 months ago (1 children)

Tile would be a poster child for this.

It begs to run constantly and acts pissed when you don’t allow it.

[–] [email protected] 1 points 6 months ago

I like grapheneos .. I can disable apps so they don't run it all until I enable them again.

My only complaint is I wish to be able to keep the app icon in the menu when it's disabled, I just want the app to only run when I manually open it. There's no reason my hotel booking program needs to run in the background. It can just run at my convenience. It's just a web page anyway with a wrapper and authentication built into it.

But I do like the icon disappearing for my banking apps, I have to open them in the app list, and enable them, run the baking app, go back to the app list and disable them. But to me that's worth it, so that I don't have a banking app in my list of active apps, if I should ever get mugged. I won't have any indicator I've got banking on the phone

[–] [email protected] 2 points 6 months ago

Annoy and Stay Resident...like a lot of apps that can't be removed, where data can't be deleted, and the the app only disabled.

[–] [email protected] 2 points 6 months ago (1 children)

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.

[–] [email protected] 5 points 6 months ago

That's more likely to be another battery optimisation setting, or a low memory condition.

Each manufacturer is different in this regard, google 'don't kill my app' for more info.