yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Q. How does it determine homeAppMem in order to use it in the calculation?

A. It grabs home's ADJ and uses the corresponding minfree value for that ADJ.

See:

final long homeAppMem = mProcessList.getMemLevel(ProcessList.HOME_APP_ADJ);

What do you think that means?

It's not that complicated.

So... if home's ADJ is 6, it will use a much higher number in the calculation than if home's ADJ is 1.

And if I wanted to, I delay a lowMemory situation (so more apps can be loaded in memory) simply by changing the 2 and dividing by 3 or 4 instead.

And yes, I enjoy driving linux purists crazy :D
[Android Software/Hacking General [Developers Only]] zeppelinrox:
That's nice an all.

Let's pretend it's algebra.

It don't matter what x is.

The point is that x seems to not get converted to pages and remains a KB value which is forwarded to the minfree file and the only way to check it is by looking at ProcessList.smali directly or remove any LMK tweaks and see what numbers show up in the minfree file.
[Android Software/Hacking General [Developers Only]] pikachu01:
Ah, didn't notice that homeAppAdj wasn't in the original mOomAdj list.

private final int[] mOomAdj = new int[] {
FOREGROUND_APP_ADJ, VISIBLE_APP_ADJ, PERCEPTIBLE_APP_ADJ,
BACKUP_APP_ADJ, HIDDEN_APP_MIN_ADJ, HIDDEN_APP_MAX_ADJ
};

Yup. You're right. homeAppAdj should do fine with an ADJ change, that is if you mean fine as in you cripple the Android LMK/OOM.

The crux of the problem is that. Changing the homeAppMem like that, you'll trigger the Linux LMK faster than the Android LMK.

Yeah, sure what you mean by delaying the lowMemory boolean situation, you're actually just saying you're making sure that Apps don't realize themselves are in a lowMemory situation. See how this is a problem?

In the end, the Linux LMK will activate first (as the homeAppAdj becomes too small a value), start killing apps indiscriminately. Sure, your launcher becomes very hard to kill. But you just made every other app easier to kill, even if they should have their own memory management techniques which you've just overridden.
[Android Software/Hacking General [Developers Only]] pikachu01:
It is converted to pages. Please re-read.

To make it easier for non-math inclined individuals. Let's say X is 8192. It's in KB.

The code is doing:

8192KB -> bytes

8192 * 1024 = 8388608 bytes

8388608 bytes -> Pages

8388608 / 4096 = 2048 pages.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
I read what you wrote and I know how the conversion works.

I think I mention it on page one somewhere :p

Question is:

Where

is the conversion in the code? Seems to remain KB.
[Android Software/Hacking General [Developers Only]] pikachu01:
I actually have the output of the calculation for the minfree. It's in pages. EMPTY_APP_MEM being 11344 for my Galaxy S ~ 45MB.

The code, for non-Java inclined people is here:

mOomMinFree[i] = (long)(low + ((high-low)*scale));

The high/low code is here:

// These are the low-end OOM level limits. This is appropriate for an
// HVGA or smaller phone with less than 512MB. Values are in KB.
private final long[] mOomMinFreeLow = new long[] {
8192, 12288, 16384,
24576, 28672, 32768
};
// These are the high-end OOM level limits. This is appropriate for a
// 1280x800 or larger screen with around 1GB RAM. Values are in KB.
private final long[] mOomMinFreeHigh = new long[] {
32768, 40960, 49152,
57344, 65536, 81920
};

Plugging in the first value, you'll have:

mOomMinFree[0] = (long)(8192 + ((32768-8192)*scale));

Let's say scale equals to 0.2 (some random value).

mOomMinFree[0] = 13107.2

memString.append((mOomMinFree[i]*1024)/PAGE_SIZE);

It is then converted to pages.

13107.2 * 1024 (this converts it to bytes).

= 13421772.8 bytes

PAGE_SIZE is 4096 for standard Android/Linux.

13421772.8 / 4096 (this converts it to pages)

= 3276.8 pages.

You seriously need to brush up your Java skills zep.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Weird how I don't get flooded with feedback saying all their apps are dying... most report better multitasking well before Maximum Overdrive even came along :p
[Android Software/Hacking General [Developers Only]] TheLastSidekick:
Zep you are highly appreciated. Don't let someone run you. Talk to the admin. I don't think they want to scare a good developer back to some other place like Rootz. Keep it up you're phenomenal!
[Android Software/Hacking General [Developers Only]] pikachu01:
Let's go back to the beginning. What's the use of Android LMK/OOM? Why do apps need a way to manage their memory allocation and know when there is a low memory situation?

That is because Linux LMK is indiscriminate in it's killing. It sees an OOM_ADJ that fits the victim at its minfree, it kills.

With Android, the memory management is standardized to the Linux LMK so that apps can realistically release memory when low memory situations happen, or when they are in the background, they can either be made much more harder to kill, or easier to kill.

With games, they will opt to save their states when they detect low memory situations when they are in the background, then kill itself. Angry Birds have this mechanism if I'm not mistaken.

With apps that have monitoring purposes, it will either stop monitoring or kill itself if it's in the background.

When you deliberately cripple the Android OOM/LMK, the Android apps thought that low memory = 2048 KB (example) as opposed to the original 8192 KB (example). You configure the Linux LMK to kill OOM_ADJ of 4 at 8192 KB, which incidentally an app is running on that OOM_ADJ. Without the warning of low memory, the app itself didn't have a chance to release memory or do any save states of its app. Linux will directly kill it.

And there goes the Android LMK. Crippled.
[Android Software/Hacking General [Developers Only]] pikachu01:
I'm not attacking Zep or anything.

I'm actually helping you guys. The people that aren't familiar with the system altogether. If zep realizes this sooner, he can at least improve the system with the knowledge I'm sharing.

You, defending Zep would mean that you would want to live in the dark, forever mislead by Zep's false assumptions. You won't get the best out of your phone.

Would you like that?

In the world of developers, there are good developers and ignorant developers. Would you rather Zep be one or the other?
[Android Software/Hacking General [Developers Only]] orbital_71:
Don't attack pikachiu he mean good so do zepp. Easy ppl cheer up for a better supercharge :)
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Ah nevermind.

It wasnt the java skills.

I misread how the array data is initially stored in ProcessList.smali.

The initial 8192 kb is indeed stored as 0x20 in the array but doesn't quite translate the way that I thought... as that 0x20 is really 0x2000 which is really 8192 lol

Yeah I was only half serious about crippling stuff... just to see if I can do it :)

My style is more to massage and bend things instead of crippling them ;)

Of course any testing/further hacking to services.jar will be frowned upon but what the heck - that's nothing new and that's what testers are for lol

I'll figure something out.

For example. Instead of having the lowMem being crippled, I can feed it a fixed value based on how much ram the device has... ;)

After all, I already created a hex/decimal converter I may as well use it lol
[Android Software/Hacking General [Developers Only]] pikachu01:
lowMemory is a boolean that is calculated on the fly based on the free memory.

Can I get a smali output for ActivityManagerService? The full one. I might be able to pinpoint what values can or cannot be changed that can cripple the Android LMK.

Please attach it here.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
oh yeah... hell it's late... well... early... 5:30am... almost time to wake up :p

I meant the calculation involved ie. homeAppMem + ((hiddenAppMem-homeAppMem)/2

Well I attached the complete package.

The source matches the smali so if you're unsure of what something does in the smali file, you can use the debug info ie. look at the .line ### and go to that line in the java file.

The dex2jar file you can view it with jd-gui and see what the classes look like.

After making a changes in smali and do up a dex2jar to see how it looks and if things get bypassed properly :)

edit: looks like I get no sleep tonight... time for Tim Hortons :p
[Android Software/Hacking General [Developers Only]] Globespy:
Good to see smart minds collaborating to improve a fantastic phone mod.

I'm waiting on the delivery of my nexus 4 and plan on using supercharger to make it fly out of my hands because its so fast!

Supercharger has my current Samsung Vibrant running JB like a dream, with (for the most part) almost zero lag or issues....pretty dang impressive for an aging device.

I plan on keeping it for my dedicated music player, just disable mobile data etc.

Love voodoo sound playing flax music files, way better than my crap iPod.

Go supercharger!
[Android Software/Hacking General [Developers Only]] kaluoshi:
@pickachu01 and @zeppelinrox, you're really on the way to fix Android JB big bugs :D hope updates will come soon :fingers-crossed: keep up the good work guys :good:
[Android Software/Hacking General [Developers Only]] G1032:
When you say long boot how long is that? I'm on Stock 4.1.2 Galaxy S 3 ROM. Is 10 minutes too long? Pulled battery 3 times yesterday as suggested by Zep but still wouldn't boot. Trying again at the moment but I'm just wondering how long is 'LONG'??!!!:)
[Android Software/Hacking General [Developers Only]] gaz41:
When "SUPERTHUNDERBOLTCHARGER"??? ;)

Inviato dal mio Galaxy S
[Android Software/Hacking General [Developers Only]] jgcaap:
Wanna try with Jelly Bean leak for s2 also.. Anyone successful?
[Android Software/Hacking General [Developers Only]] Kitschki:
Zeppelin u werent in akinator so i had to create u... ㅠ.ㅠ
[Android Software/Hacking General [Developers Only]] skezza:
Several apps I use require un-rooted devices. Yes, this is the fault of the app developer but it's something I can't help. It also means I use a special app I developed to disable su, the SuperSU apk, and BusyBox.

So, if I hide busybox, su and superSu temporarily, the script obviously won't function but it won't cause any catastrophic damage to my ROM or whatever? As soon as I put SuperSU, busybox and su back, the script will work OK?
[Android Software/Hacking General [Developers Only]] hoholee12:
Pikachu didnt respond to my question so i ended up here.

Hi zeppelinrox, may i ask u a question?

what advantages do i get from tuning linux lmk parameters?whats the difference between linux adj and android adj? I never thought kernels lmk parameters were related to android app management. or is it not?

Just asking because im a beginner and want to learn more about android tweaks.I think you would know everything.

thanks in advance!:)

This post was sent from my gaming rig.
[Android Software/Hacking General [Developers Only]] clay101eve:
He definitely doesn't know everything... Like my middle name for instance. But he's pretty damn close!

Clay

Team Pirate

Sent from my Galaxy SHOwagger2
[Android Software/Hacking General [Developers Only]] gokart2:
Having issues getting the supercharger on my evo 3d running ICS. I tried running the script and I get the AWK error. I then run the supercharger install and it fails with the binary update. I try doing the binary update by itself and it aborts without description to why. I assume it aborts because all is well. But no matter what I do, it fails with the AWK error. And if I try running the script anyway....it doesn't load/run all the way through. Just hangs. Any input would be appreciated, been reading like crazy, but getting nowhere.

Also, the process seems to be a tad confusing (I'm sorry, but it is). I would assume you get the busybox, binary, and sqlite/zipalign crap done before trying the script. But.....also doing the jar edit/fix before the script as well. Is that my issue? Because it says run script, then install kit/binary crap, then jar edit in the OP....?
[Android Software/Hacking General [Developers Only]] da__beast:
I think you don't have the steps correct - why don't you reply with a quote on the steps as you found them. I would post the quote but they are already in post #1.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Well does the animation stay on the whole time?

Most of the waiting is on the "optimizing apps" message.

Oh never heard of that before... I googled it... that genie thing?

As long as it boots up you're good lol

ah I'm kinda tired.... later if pika don't answer.

erm...

If you find that confusing, it's time for some meds, troll boy.

Don't like? Tough.

The only confusing thing is that you "assume it aborts because all is well".

So yeah... maybe you should get a dictionary too.
[Android Software/Hacking General [Developers Only]] leolawliet:
I wonder if supercharging will make a difference with my N7, I'm willing to give it a shot.
[Android Software/Hacking General [Developers Only]] gokart2:
Whoa.......not trolling or trying to cause any issue :good:. I've managed to do quite a bit of modding (kernels and roms) without any issues....this isn't one of them. Just trying to get this to work. And it says somewhere if something is already kosher, then it won't install. Hench the assume it was good by not installing. What is the AWK error? Is it generic? Why would the binary install abort the process? Also, if I try the Script Manager to run the Supercharger install package, it keeps saying file isn't found. Works by terminal though.

Edit: Nevermind dude. No need to be a douche. If you want help making the OP understandable.....let me know.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
AWK error is bad.

Nah, I'm satified with the OP being understandable by those that want to understand it.

Or consider it a test.

And no specific error = no specific help
[Android Software/Hacking General [Developers Only]] gokart2:
Again, I apologize for coming off the wrong way. The way you took it the first time around, isn't how I meant it. And the dumb "OP help" comment was totally in anger. Again I apologise. Truth of the matter is I'm lost as to why I keep getting the AWK error, and am trying to understand why. I understand how to do this process according to your OP, but want to understand how to do it....properly. I can't get it to work.

I run the Supercharger Startup Kit, busybox loads fine. "su binary Installation ABORTED" comes up after "This is only for ICS!". I already have sqlite3 and zipalign, but still reinstall them without issue.

I then run try and run "U9RC11T9" with Script Manager, SU and "Is script" enabled. Fails with AWK error.

Current busybox is the one supplied, v1.19.4-wraithdu. I'm currently running "SuperSU" v0.99.

If I try to run the Supercharger Startup Kit through Script Manager, click the StartMeUp.sh file, "open as" script/executable, run with SU and "Is script" enabled. I get "Error resolving interpreter : Empty script

-and-

/SuperCharger_Starter_Kit/StartMeUp.sh: No such file or directory

^^^^That doesn't really matter since it somewhat works through the terminal.

So....could you please point me in the right direction. I figure if the binary aborts, then it is an issue related to my SU. Is one recommended more then the other? Or a specific version number?
[Android Software/Hacking General [Developers Only]] zeppelinrox:
The only problem is busybox.

Are you sure wraithdu's bb got installed properly?

SuperCharger will report which busybox build/version that's in effect.

And if it's wraithdu's bb that's in effect and you get an AWK error - that definitely makes no sense and a screen shot would help.
[Android Software/Hacking General [Developers Only]] pikachu01:
More like pikachu01 pointing out that Supercharger was crippling Android LMK rather than helping it.

Rest assured though. I'm sure that Zep will fix this in a jiffy.

I replied to you on the other thread:

http://xdaforums.com/showpost.php?p=35670671&postcount=8149
[Android Software/Hacking General [Developers Only]] UpInTheAir:
Can't remember exactly, but I had an error a while back testing V6SuperCharger for my ROM development.

I switched to the superuser app rather than SuperSU and it "fixed" the error. Can't remember which version of SuperSU at the time, and haven't tested since either.

I use wraithdu bb and binary.

The superuser app might be worth a try....
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Depends on how you look at it ie. depends on how one thinks the memory management should behave.

You don't like the strong launcher idea at all and want stuff to get killed and you're cool with the idea that it may get killed even if it's not necessary.

So in that sense, I've always crippled it :p

But I've hardly broke it with the services.jar hacking since making the launcher strong indeed made multitasking better because of how Android calculates the lowMem boolean. Though I admit it was somewhat of a fluke because of this code:

public void getMemoryInfo(ActivityManager.MemoryInfo outInfo) {
[B][COLOR=Red]final long homeAppMem = mProcessList.getMemLevel(ProcessList.HOME_APP_ADJ);[/COLOR][/B]
final long hiddenAppMem = mProcessList.getMemLevel(ProcessList.HIDDEN_APP_MIN_ADJ);
outInfo.availMem = Process.getFreeMemory();
outInfo.totalMem = Process.getTotalMemory();
outInfo.threshold = homeAppMem;
[B][COLOR=Red]outInfo.lowMemory = outInfo.availMem < (homeAppMem + ((hiddenAppMem-homeAppMem)/2));[/COLOR][/B]
outInfo.hiddenAppThreshold = hiddenAppMem;
outInfo.secondaryServerThreshold = mProcessList.getMemLevel(
ProcessList.SERVICE_ADJ);
outInfo.visibleAppThreshold = mProcessList.getMemLevel(
ProcessList.VISIBLE_APP_ADJ);
outInfo.foregroundAppThreshold = mProcessList.getMemLevel(
ProcessList.FOREGROUND_APP_ADJ);

As noted yesterday, multitasking improves because it uses home's memory as a huge part in deciding if memory is low.

By giving home a much lower memory kill level, Android waits much longer to decide whether there is a low memory condition.

In the calculation above, instead of using the memory level corresponding to ADJ 6 (home's ADJ by default), it uses the memory level corresponding to ADJ 1 when using the Die-Hard Launcher.

You rolled your eyes at that, remember lol

And not everyone would think that its "crippled" when they're getting the multitasking that they want - without breaking anything :p

So... it's no wonder the launcher, by default, is the first thing killed after background apps - even before the apps you used awhile ago (server apps - normally ADJ 5) since the launcher is less important than those.

The code above makes it so.

But SuperCharging the launcher totally reverses that so Android is in a lowMemory condition less often :)

It's not perfect - but it makes alot of users happy.

What would be perfect is to feed the desired minfrees into the services.jar by changing the array in ProcessList.smali and it's actually easy to disable the scaling part by commenting out a single line :p

heh... anyway... still toying with ideas lol
[Android Software/Hacking General [Developers Only]] pikachu01:
Let me reiterate it one more time.

Hacking the services.jar and changing the HOME_APP_ADJ to 1 basically disables the Android LMK.

This is akin to not even tweaking the Android LMK.

This manifesto was the one you took back in Gingerbread days with you saying that only tweaking the Linux LMK was half-baked.

Now you go around and say it is not. What logic is that?
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Wow I can't go over all that right now but just wanted to post that I just had the idea to just skip that one edit in the lowMem calculation.

In the smali files you don't change the home value in one place and it gets applied everywhere. It involves serveral edits for all the ADJs.

So for that calculation, I can simply skip that particular edit.

While the launcher is still supercharged.

Who knows, it may end up even smoother. heh.

edit: okay read your long post. Not gonna get much sleep again :P

So yeah, skipping that one edit will cover all those bases :)
[Android Software/Hacking General [Developers Only]] pikachu01:
I have no clue on what you're talking about. Post some codes to back up your words please.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
From the AMS.smali I posted yesterday.

.method public getMemoryInfo(Landroid/app/ActivityManager$MemoryInfo;)V
.registers 15
.parameter "outInfo"

.prologue
const/4 v5, 0x1

const/4 v6, 0x0

.line 5603
iget-object v4, p0, Lcom/android/server/am/ActivityManagerService;->mProcessList:Lcom/android/server/am/ProcessList;

[B][COLOR=Red]const/4 v7, 0x6[/COLOR][/B]

invoke-virtual {v4, v7}, Lcom/android/server/am/ProcessList;->getMemLevel(I)J

move-result-wide v2

.line 5604
.local v2, homeAppMem:J
iget-object v4, p0, Lcom/android/server/am/ActivityManagerService;->mProcessList:Lcom/android/server/am/ProcessList;

sget v7, Lcom/android/server/am/ProcessList;->HIDDEN_APP_MIN_ADJ:I

invoke-virtual {v4, v7}, Lcom/android/server/am/ProcessList;->getMemLevel(I)J

move-result-wide v0

That's where it's getting the memory levels for home and hidden app ADJs.

The part for HIDDEN_APP_MIN_ADJ is more obvious (near the bottom).

It grabs that value directly from ProcessList (which would be it's ADJ value of 9)

That 9 gets stored in that v7 variable

Then the corresponding memory level gets stored in the v0 variable.

But the code is different at the top for getting home app's memory level.

See that red 0x6? That's the ADJ for home.

It

isn't fetched from ProcessList

. (which is why figuring out how to SuperCharge services.jar was a pain in the ass)

The 0x6 is stored in the v7 variable directly.

Then the corresponding memory level gets stored in the v2 variable.

Currently that 0x6 is changed to 0x1 when SuperCharged.

I can just skip that edit and the pandas will be happy.
[Android Software/Hacking General [Developers Only]] kbraiza:
Boy, this is going to be a long headsploding night (or day, who knows, sun's rising here).

Tried the Windows patcher yesterday and it does pretty much everything, if only it would cut my lawn...

Xperia Pro mk16 @ Tapatalk