[Android Software/Hacking General [Developers Only]] zeppelinrox:
Funny then how nobody has done what I've done with it ;)

Nowhere is there the string _MEM anywhere - hence they don't exisit anymore.

As I stated previously, in ProcessList.smali, it's just a big song and dance to come up with values to put into the minfree file.

In the old days, it was done in init.rc like this:

# Define the memory thresholds at which the above process classes will
# be killed. These numbers are in pages (4k).
setprop ro.FOREGROUND_APP_MEM 1536
setprop ro.VISIBLE_APP_MEM 3072
setprop ro.SECONDARY_SERVER_MEM 6144
setprop ro.BACKUP_APP_MEM 6144
setprop ro.HOME_APP_MEM 6144
setprop ro.HIDDEN_APP_MEM 6656
setprop ro.CONTENT_PROVIDER_MEM 7168
setprop ro.EMPTY_APP_MEM 8192

# Write value must be consistent with the above properties.
# Note that the driver only supports 6 slots, so we have HOME_APP at the
# same memory level as services.
write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15

write /proc/sys/vm/overcommit_memory 1
write /proc/sys/vm/min_free_order_shift 4
write /sys/module/lowmemorykiller/parameters/minfree 1536,3072,6144,6656,7168,8192

The

only

reason that the minfrees correlate with the now non-existent _MEM values is because it was done manually and were static.

No other routine writes to the minfree file. Whatever is written there, stays there without further interference by the OS.

But keep reading... there's a twist coming up...

Yes that's the code that I came across last night upon further digging.

It used to be alot simpler, like this:

public void getMemoryInfo(ActivityManager.MemoryInfo outInfo) {
outInfo.availMem = Process.getFreeMemory();
outInfo.threshold = HOME_APP_MEM;
outInfo.lowMemory = outInfo.availMem <
(HOME_APP_MEM + ((HIDDEN_APP_MEM-HOME_APP_MEM)/2));
}

Which merely does a simple calculation to determine a low memory situation and applies HOME_APP_MEM to quite simply "threshold"

The new code does the same and adds 4 more thresholds:

threshold (which is actually home's threshold)

hiddenAppThreshold

secondaryServerThreshold

visibleAppThreshold

foregroundAppThreshold

Now this is what is actually new to me: Those 5 thresholds are what actually replaces the 8 or 9 (depending on OS) _MEM values.

And it is effected by the ProcessList calculation with ActivityManagerServices acting as the go between.

So here's the funny part:

By changing the ADJs all over the place,

I have already effected those memory thresholds to improve multitasking

;)

Without even knowing it lol

How so? home used to be ADJ 6 but I made it 1 with Die-Hard Launcher.

So... the "outInfo.lowMemory" (which is actually a boolean value) is "true" much less often than before patching services.jar - because the memory limit of ADJ 1 is used in the calculation instead of the much higher memory limit belonging to ADJ 6

Not only because of that, but also because of this in ActivityManager:

/**
* The threshold of {@link #availMem} at which we consider memory to be
* low and start killing background services and other non-extraneous
* processes.
*/
public long [B][COLOR=Red]threshold[/COLOR][/B];

That red part is the same value as homeAppMem - again, which is much lower than before patching.

Therefore, the OS automatically waits much longer before considering memory to be low - simply by making the launcher more important than it was ;)

Yeah I already fixed that. I have prevented AMS from putting the 4 *Threshold values to AcitivityManager - and I also have it always report lowMemory to be false... no bootloop...

works mint

:D

This way, the LMK values will play a bigger role in the bigger scheme of things :cool:

I was only talking about the code pertaining to the new *Thresholds

That I did indeed miss - probably due to digging for java sources and smalis at whatever time it was (Nobody's perfect? That's my excuse and sticking to it :p)

But I like to look at the services.jar... just something I'm in the habit of doing for some weird reason.

Look again. If I didn't strive to be the best - I wouldn't have already fixed it in record time.

If I didn't strive to be the best, I would have been all arrogant, thinking that I knew everything already, and not even bother do any additional digging let alone post something that I had missed in the past ie. the *Threshold stuff

Die-Hard or Hard to Kill launchers would get killed if need be - that's why the SuperCharger is so great.

I created different strengths because bulletproof launcher actually broke Tasker and a user wanted me to find a way to make the launcher really strong but not too strong - which required moving a whole lot of ADJs around.

Plus, I understood that it should be killed - but

only

if it needed to be killed.

The problem is the launcher, by default ADJ 6, gets killed before the servers apps (stock ADJ 5) that you were using 20 minutes ago. You can believe what you want about how it should be killed and I've never preached to you that you should think otherwise.

Hence, I don't listen to such sermons.

As stated above, *_MEM is no longer in the code. And I didn't believe there to be a replacement for it.

So... if it's no longer there, I wasn't worried about it. Does that not make sense?

Now I see that the

*MEMs did indeed get replaced

in a very subtle manner with those *Thresholds.

And now that I know about it, I have addressed it - I think in a satisfactory and timely fashion.

Yes, and if you understand my stand, you may resume idolizing :p

Just don't tell me I shouldn't block the *Thresholds from being put into ActivityManager lol

As somebody once said not too long ago: Au contraire :cool:

And it's kinda nice that somebody noticed that I have some integrity lol

OK so... this is actually

great news

.

In the EVO 4g LTE Sense Multitasking thread there have been cases where these Sense roms would not go below 150 mb free no matter if the minfrees were all down to 10 or 20mb and with Maximum Overdrive 70 apps in effect.

I just couldn't find the reason why that was the case - but now I know why it would never go below 150 mb free :D

So it looks like there is

even better

multitasking on the way... heh.

Now... if nobody clicks thanks, I'm gonna *SNAP*