[LG Optimus 2x] tonyp:
Okay, as writing about the memory management yesterday got me too interested to not dig into it deeper, I just finished my little ActivityManagerService rework and compiled a flashable zip, it's in the addon folder (works for both bls):

http://goo.im/devs/tonyp/ParanoidAndroid-P990/addons/

Flash it + wipe cache / dalvik!

I adjusted a couple adj (priority) values.

The V6 SuperCharger does this as well, but it is only hardcoding new values into the ProcessList, without reflecting that this totally screws up the lowmemorykiller (lmk) of android.

You can read more about that flaw of V6 here.

It worked great with GB, but it messed up the default LMK of android in ICS+.

I customized some values as well, but adjusted the ActivityManagerService for the lmk accordingly, which keeps it fully intact.

It works pretty great in my tests - the launcher won't get killed constantly anymore :)

You should see better multitasking capabilities.

But I'd love to hear your feedback. I know it's difficult to tell, but you can just check it out and see if it works out good for you.

You will still get launcher redraws occasionally - see, it's more important that the game you're playing runs fluid than preventing the launcher from redrawing - at least in my opinion.

As I said in my last post, the default lmk isn't bad per se, but it's targeted at devices with more memory.

This is what made the V6 SuperCharger that popular in the first place.

----

What I did:

These are the stock values. The lower the value the higher the priority:

System -16
Persistent Process -12
ForeGround app 0
Visible app 1
Perceptible app 2
Heavyweight app 3
Backup app 4
Service 5
Home Launcher 6
Previous app 7
Service_b 8
Hidden app min 9
Hidden app max 15

If you want to read explanations about what these values are for exactly, see the comments here:

// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption.
static final int HIDDEN_APP_MAX_ADJ = 15;
static int HIDDEN_APP_MIN_ADJ = 9;

// The B list of SERVICE_ADJ -- these are the old and decrepit
// services that aren't as shiny and interesting as the ones in the A list.
static final int SERVICE_B_ADJ = 8;

// This is the process of the previous application that the user was in.
// This process is kept above other things, because it is very common to
// switch back to the previous app. This is important both for recent
// task switch (toggling between the two top recent apps) as well as normal
// UI flow such as clicking on a URI in the e-mail app to view in the
// browser, and then pressing back to return to e-mail.
static final int PREVIOUS_APP_ADJ = 5;

// This is a process holding the home application -- we want to try
// avoiding killing it, even if it would normally be in the background,
// because the user interacts with it so much.
static final int HOME_APP_ADJ = 3;

// This is a process holding an application service -- killing it will not
// have much of an impact as far as the user is concerned.
static final int SERVICE_ADJ = 7;

// This is a process currently hosting a backup operation. Killing it
// is not entirely fatal but is generally a bad idea.
static final int BACKUP_APP_ADJ = 6;

// This is a process with a heavy-weight application. It is in the
// background, but we want to try to avoid killing it. Value set in
// system/rootdir/init.rc on startup.
static final int HEAVY_WEIGHT_APP_ADJ = 4;

// This is a process only hosting components that are perceptible to the
// user, and we really want to avoid killing them, but they are not
// immediately visible. An example is background music playback.
static final int PERCEPTIBLE_APP_ADJ = 2;

// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear.
static final int VISIBLE_APP_ADJ = 1;

// This is the process running the current foreground app. We'd really
// rather not kill it!
static final int FOREGROUND_APP_ADJ = 0;

// This is a system persistent process, such as telephony. Definitely
// don't want to kill it, but doing so is not completely fatal.
static final int PERSISTENT_PROC_ADJ = -12;

// The system process runs at the default adjustment.
static final int SYSTEM_ADJ = -16;

The V6 Supercharger does the following (but screws up the LMK by applying it) - in blue the parts zeppelinrox moved out of the previous order:

System -16
Persistent Process -12
ForeGround app 0
[COLOR="RoyalBlue"]Home Launcher 1[/COLOR]
Perceptible app 2
[COLOR="RoyalBlue"]Visible app 3[/COLOR]
Heavyweight app 4
[COLOR="RoyalBlue"]Previous app 5[/COLOR]
Service 6
[COLOR="RoyalBlue"]Backup app 7[/COLOR]
Service_b 8
Hidden app min 9
Hidden app max 15

I did a choose a slightly different priorization:

System -16
Persistent Process -12
ForeGround app 0
Visible app 1
Perceptible app 2
[COLOR="RoyalBlue"]Home Launcher 3[/COLOR]
Heavyweight app 4
[COLOR="RoyalBlue"]Previous app 5[/COLOR]
Backup app 6
Service 7
Service_b 8
Hidden app min 9
Hidden app max 15

Why did I choose this?

V6 prioritizes the launcher above perceptible apps - which are background services like the music player.

I'd rather have the launcher killed than my music player service... :eek:

Then it doesn't make any sense in my opinion to move the "visible app" and the "backup app" priorities, this is more likely to cause problems.

Visible apps (like dialogs) seem more important than the launcher - and while it is not "fatal" to kill an app doing a backup process, it seems more important than a standard background service.

What I basically did: I gave the launcher (home app) and the previous app a higher priority.

Both are apps I'm likely to switch to, which makes them e.g. more important to the user than background services.

Google writes the following for the services adj:

"This is a process holding an application service -- killing it will not have much of an impact as far as the user is concerned."

So if it doesn't have "much of an impact", why shouldn't we move the launcher & previous app ahead of it.

Note that what I described here, the adj adjustments, has been the easy part ;)

I had to ensure that these values, which are used directly for the lmk, won't break androids default memory handling.

Phew long post, back to work :)