[Motorola Droid 4] Septfox:
Hijacking the thread again.

So I'm 90% sure I figured out the problem with slow/laggy wakes whilst extra_free_kbytes is set high, and fixed it. Well, did last weekend, but I wanted to make sure and ended up getting busy with work.

It hadn't occurred to me when I started screwing around that the keyguard is a service, and a non-persistent one at that. The minfree settings usually set a comparatively gentle limit for services (Secondary Server), but under heavy enough use it'll still be killed off eventually.

This isn't a problem so much for when you go to put the phone to bed, because - whether by mistake or by design - having Ambient Display on disables the screen-off animation and flashes the keyguard for a moment. Since the keyguard has to be reloaded before this can happen, the phone can take up to several seconds to get its ass to sleep. In a perfect world this means the keyguard is loaded and ready for when the phone wakes up.

But we're not in a perfect world, and the keyguard isn`t a persistent service. minfree continues making sure there's memory free, even when the phone is asleep. For some reason it goes kind of nuts if extra_free_kbytes has been enabled lately, and is more aggressive than usual.

so minfree is all

"Oh look, the keyguard is an idle service and doesn't have a UI that's currently being drawn. <snip>"

and the phone is like

"zzzzzsnrkWha? Ok sure, I'll wake up, just let me flash up the OH GOD MY KEYGUARD WHERE IS IT hold on let me spawn another one I'm so sorry ;_;"

...and does that while simultaneously trying to juggle all the other crap it needs to do at wake.

The thing of it all is, this is mostly pointless behavior; shutting down services to clear memory is nearly always a losing strategy because most of them are persistent and will immediately try to restart, wasting disk I/O and CPU time as they do so. Seeing as we lack both of those to begin with for work we actually want the phone to do...well.

By the looks of it the setting wasn't originally provided as a way to keep the memory flowing, but instead as a way to clean up after lazy app developers who start services for temporary use (looking at you and your media service, BBC News) and never end them.

Then we have Content Providers. Providers are apps that have externally-invokable APIs and widgets and whatnot that other apps can load up and use; it seems most apps have at least a couple components they can provide to others. I'm reasonably certain that because of what it is, the Clock is a content provider. The keyguard has a clock. Yea.

Larger apps also suffer from a high Content Provider setting; something I'd forgotten I had experimented with back when I was getting Ingress running. It uses Google's location stuff, which is both a persistent service and a content provider or three.

With this minfree setting up too high, Ingress would stutter a lot, probably because it would be

Initially loading the content it needed to get location

LMK removes the content from memory

Refreshing location, reload the content

LMK removes the content from memory

Rinse and repeat forever.

Even stock minfree is very aggressive when it comes to content providers, which would probably be ok if it weren't for their being no way to insist on some of them being marked as important and unkillable.

I suggest changing Secondary Server to 100mb, and Content Provider to 100-125mb. The latter especially smooths some large apps out if set 20+mb under Hidden Applications, but considering there's little need to kill off content providers anyway (unless you're not a typical user and don't always use only a small typical set of apps), there should be nothing but good from setting it lower, especially if zram is enabled.

This might also help people like [MENTION=1070688]joojoobee666[/MENTION] who have the incall UI getting constantly killed off and needing to take approximately forever to come back up. I'm not sure if it's a Service or a Content Provider, might be part of the main app.

Attached are a couple of Automate flows; one is for people like me and [MENTION=5711114]Bobcus Leper[/MENTION] who use large extra_kbytes_free to get by, one omits this (but still sets Swappiness to 0 to avoid paging things out while sleeping). Both set very low limits on services and content providers and higher on background apps while asleep, strongly encouraging the phone to only kill background and exited apps if it needs memory for something.

Screen off: 60/60/60/180/60/180

Screen on: 60/75/100/160/100/200

You can of course tweak these amounts in Automate; the flow goes top-right to bottom left, then loops. They're probably a bit aggressive to be honest, but they've been working ok for me.

This is about all I'm going to do with it. After much comparing and deliberation the past couple evenings, I bought a like-new Droid Turbo (xt1254) yesterday, which ought to be here Monday or Tuesday, and it's going to take over as my everything-phone. I've come to realize how silly it is to hold myself back from upgrading and better running the big, clunky apps I want to just for the sake of having a physical keyboard; the only thing I'm doing is wasting time and frustrating myself. Originally I was going to go big and get a Blackberry Priv, but Verizon's refusal to distribute the Marshmallow OTA combined with its locked bootloader make it a no-go.

While I don't like typing on glass, Swiftkey is...adequate, and the substantially-better everything else makes up for it.

This isn't necessarily farewell, since I'm not going to sell off or destroy my D4 (there is still potential for more SCIENCE! to be performed), but I'm not going to be constantly messing with and tweaking it anymore.