yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] zeppelinrox:
You're probably using SuperSU... don't worry about it.

Post the output... is there any spaces in any folder name in the path? That shouldn't matter tho...

That looks interesting.

I'll look into it. Thanks.

Apex has a keep home in memory feature but having that enabled should report hard to kill and not die-hard as it gives the launcher ADJ 2 - not 1.

So disable that feature anyway and check out the boom stick.

Well check before and after.

Probably because I only put the best stuff in there that don't conflict with each other (ie. apply a setting only once unlike some butcher packs that apply the same thing many times with different values :p). There's only a couple of tweaks that I haven't put in that a user can still use without overlap such as swap file control and cpu control stuff.

Like a super bunny or somethin?
[Android Software/Hacking General [Developers Only]] renoob:
Yea, but ya gotta flash it to Cricket first. :banghead:

Sent from beyond the Droid
[Android Software/Hacking General [Developers Only]] BlackArtsInc:
I disabled Apex Launcher "Keep in memory" setting,re run V6 (selected 13 for Bulletproof) but the launcher still remains Die Hard even after rebooting.

Maybe I need to Superclean?

N.

Sent Using One Of My 5 iPads.
[Android Software/Hacking General [Developers Only]] .:Crack:.:
Any new insights today? :p
[Android Software/Hacking General [Developers Only]] zeppelinrox:
or tonight :p
[Android Software/Hacking General [Developers Only]] OmegaBlaze:
Hey Zep or anyone else that could help, I have a Epic 4g Touch (Galaxy S2 Sprint)

I'm using the Ultimatic Jar Patcher Tools to supercharge a Jelly Bean rom.

However, when i get to the part where i have to push the smali files i get this:

"sh: /storage/sdcard0/ALL: No such file or directory"

Any help would be great. Thanks.

EDIT: I forgot to put the "*" after ALL*. [=
[Android Software/Hacking General [Developers Only]] whitesox311:
Dude, holy **** does this make a difference. Ive always noticed that some ROMs are super smooth and fluid and just seem "right", whereas others are stuttery and just ****ty feeling. Ive come to realize that its the roms that use the v6 supercharger that feel smooth. Its a definite difference you can feel. Like others have said, its like a whole new rom. Im not sure what this script changes, but I feel like a lot of phone manufacturers need to think about employing the dude that wrote it. Best mod ive come across on XDA period.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Right so here we go... http://xdaforums.com/showthread.php?p=35589103#post35589103
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Ah yeah... was gonna suggest you borrow a * from the next guy... :)

Thanks man. That kinda feedback never gets old :D

Ok looked at it... too sure about it yet.

The overhead seems high with the entropy_avail being refilled pretty much non-stop and the binary is quite large at 950 KB.

Have you tried it?

Even if it worked, not sure how much effect it has if you're already supercharged.

BUT... me being the way that I am... found this: timer entropy daemon

And since I've been getting my feet wet compiling busybox n stuff... I figured I'd try and make that sucker run on android... and I did it :D

I actually installed ubuntu (finally!) but I couldnt get it to compile with linaro or the android ndk but it did work with the gcc cross compiler that you get in ubuntu - but it was still pretty big.

So... I ended up compiling it with android ndk on windows using cygwin!

Linaro worked flawlessly too but the ndk one was smaller at 475 KB so I attached that one.

Weird how linaro and the ndk spat out errors in linux but ran fine in CygWindows XP lol

btw I used the older timer_entropyd-0.1 version - 0.2 didn't do anything (it waits till entropy gets so low that it don't do anything lol)

So the attchment is NOT zipped.

Just remove the .zip exention.

To use:

1. copy it to /data

2. cd data

3. chown 0.0 timer*

4. chmod 755 timer*

5. mount -o remount,rw /system

6. cp -f timer* /system/xbin/

Then to run it just type timer_entropyd

To see if it's in memory you can do, pgrep -l timer_

To see it is's working, do watch -n 2 cat /proc/sys/kernel/random/entropy_avail

However, that command doesn't show anything for me when messing with it via adb so I do this:

while :; do cat /proc/sys/kernel/random/entropy_avail; sleep 2; done

Then you see the entropy_avail number show up every 2 seconds.

Without the daemon my phone was always between 200 and 300

With the daemon it usually between 1500 and 3500

If you like it, just put that bold command in any init.d script so it runs on each boot.

If you don't like it, too bad :p

Edit: Oh wow... I dunno how it happend I did a search and this entropy_watch. c came up as a download... so I compiled it!

Monitors the entropy all nice nice.

Same deal as above. Not zipped. Do the permission thing and install to /xbin
[Android Software/Hacking General [Developers Only]] noradoor:
Zep,thanks for your explanations.

I'm afraid I am out of my depth about this,so what I could do was to give it a shot.

I mean I tried using Seeder entropy generator (and without Supercharging my phone.)

On my phone with CM10,it did boost the speed when I was opening or browsing some apps,such as Titanium Backup and ES file Explorer.

And it seemed the apps were always running because I didn't see the loading message while opening TB each time.

However,it apparently slowed down when I opened Dolphin Browser,and of course I had tested it couples of times.Weird.:confused:

Now I get supercharged and I feel that Supercharger is the dominant one.

Because the above-mentioned phenomena no longer exist after Supercharging.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Of course nothing beats Super'Charger (read the OP!)... you can only add to it.. LOL

Yeah I felt that the rngd binary was way too active so that's what may cause the jerkyness that people report.

But that timer_entropyd daemon that I found and compiled seems to be smoother and is less hyperactive and more balanced.

So is your final happy result with both in effect or only SuperCharger?

I'd be curious if that timer_entropyd would make it better for you since you're already testing and all LOL
[Android Software/Hacking General [Developers Only]] pikachu01:
Replied to you here:

http://xdaforums.com/showpost.php?p=35592203&postcount=8133
[Android Software/Hacking General [Developers Only]] jr_718:
Supercharger for me..
[Android Software/Hacking General [Developers Only]] firstknightfirst:
Nova Redraw

the whole thing rocks.. but my nova launcher redraws frequently in drawer.... pls advise.
[Android Software/Hacking General [Developers Only]] pikachu01:
The ADJ is compared in the ActivityManagerService.java. The ActivityManager merely calculates the app, memory, app type and determines the threshold each app (that is calculated on the fly by the ProcessList.java).

If you remove the iput commands, the memory threshold can't be assigned to newly created apps, which might result in a bootloop.

An aside though. You mentioned it yourself that only tweaking the Linux LMK and not changing the Android OOM/LMK is half-baked. I wonder why you're backtracking yourself now and saying it isn't half baked when one of the OOMs aren't configured in sync. It ain't cool to change your stand whenever it suits the situation. (What I mean is, it ain't cool to mislead end users out of things that aren't the truth. As experts ourselves, we should strive to get and provide only the best to users)

The best thing to do now is to just let Android do its memory management. If you want to prevent something from being killed, just change its OOM value in the /proc/*/oom_adj.

One more thing about Samsung Galaxy SII stock ICS LMK/OOM. The one thing I'm sure that Samsung is still using the old OOM/LMK method by using build.prop is due to the /sys/module/lowmemorykiller is not some funky calculated value and with Samsung still using the init.rc to set prop values.

I've also tested using only build.prop values at a very high value ~ 150MB with the Linux LMK set to a very low value ~ 30MB. Repeatedly using high/low memory apps while still keeping it to less than 15 (which is the limit), I'm still getting ~ 100-150MB which means the Android OOM at least is working to keep the memory above 100MB.

Using a complete low OOM of like 40MB in both Android and Linux LMK/OOM, I do get the intended free memory of around 40-50MB after opening around 15 of high and low memory apps.
[Android Software/Hacking General [Developers Only]] .:Crack:.:
Thanks, I'm using the 'high overhead and too big file size' entropy binary. I feel a decent amount of speed increase.

How is your version different? As far as I can see it fills entropy by 500bits per second.?

Edit/ I tested your binary but I felt more lag than with the bigger binary. The other, watching binary also showed values from 100-300 sometimes.

Edit 2/ same behavior with big binary. Does feel smoother though (placebo??)
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Back tracking and learning someting new are 2 different things.

There aren't any *MEM values and there isn't any backtracking.

Indeed I hadn't noticed that ActivityManager using the 4 threshholds before but

neither does that mean that it is having any great effect either

.

And neither does it mean that you knew about it - because you

didn't know about it

-

I dug that up

, remember?

(Although you do get props for making me dig further - just by trying to find what you're talking about :p)

You can put anything you want in init.rc just like you can put anythinng in build.prop - it don't mean that ActivityManagerService will read it.

If that calculation is in ProcessList and there isn't any "getint blah blah" commands then it's you doing the misleading.

The reason your free ram would stay high despite low minfrees is because of the app limits.

Do the aLogcat test and you'll see lots of "no longer want hidden #" - apps get killed before minfree levels are reached and not because of some non-existent *MEM values in services.jar that you keep talking about - who's doing the misleading again?

And indeed, make no mistake, not do I only strive - I

do

provide only the best to users.

As for letting Android do what it wants to do - I don't think so.

You're not the first or last to say that I should leave it alone - as many elitists tend to do.

You may like launcher redraws and you're in the minority.

How many people say "hey cool! my launcher died so the OS can do stuff I don't care about even though I still have lots of free ram!"?

And if Android's memory management is so great, why do they keep changing it?

For all anybody knows,

they could have gotten the calculated minfree idea from me

.

Before me,

nobody

calculated minfrees based on ram.

You're welcome and glad the wait was worth it.

I'm good with teachers but not so good with preachers.

What's not cool is to ask my opinion on something just so you can pounce on my answer - even though you're wrong about non-existent *MEMs.

It's ironic and weird that you'd use the code that I just dug up in order to preach against me.

If I did want to mislead anybody, I wouldn't have even brought up what I found.

So you used what I found as an excuse to preach and saying that I backtrack?

Please...

Not too sure - may be or may not be placebo :P
[Android Software/Hacking General [Developers Only]] skezza:
This might sound like a silly question, but what would happen if I hide root or uninstalled busybox while this script was installed? Would it cause any major issues, or simply not run the script?
[Android Software/Hacking General [Developers Only]] m1trand1r:
No root/busybox/>>>No V6 SuperBeast for you:p:D...soo...:what:...lol...

Sent fom my S-II with CM-10 by mcm811(12/06/2012] powered by [url="http://dorimanx.shine.sk/kernels-jb/Kernel_Dorimanx-V7.29-ICS-JB-22-51--06-12-12-SG2-PWR-CORE.zip]DorimanX kernel v 7.29[/url]
[Android Software/Hacking General [Developers Only]] bjoswald:
Why would you do that?
[Android Software/Hacking General [Developers Only]] zeppelinrox:
If you mean the busybox binary that runs all the command then no.

If you mean the installer app that you get from market - then yeah you can uninstall that.

Just make sure that when you type "busybox" in terminal, you don't get an error
[Android Software/Hacking General [Developers Only]] OmegaBlaze:
Hey Zep, My busybox NEVER sticks. Does this affect the supercharge?

No matter which busybox version i select I have to use the busybox installer every time i reboot...
[Android Software/Hacking General [Developers Only]] zeppelinrox:
AWK error... so that's some peristent, old ass broken busybox :)

Why don't the rom dev use the latest?

Anyway, just use the boot re-installer version that's in the OP -it reinstalls bb on each boot with an init.d script

Tho I'll be updating soon with my own build of 1.21.0 ;)
[Android Software/Hacking General [Developers Only]] OmegaBlaze:
Thanks alot. We'll be waiting for it!
[Android Software/Hacking General [Developers Only]] OmegaBlaze:
Is this something I should be worried about??
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Only if you didn't update busybox.

Are you still using the FAIL edition?
[Android Software/Hacking General [Developers Only]] orbital_71:
Hey Zepp any new update for the ultimate tools? The test 6 offline doesn't work for me after the 1st enter key, it just stuck at daemon start. :confused::(
[Android Software/Hacking General [Developers Only]] zeppelinrox:
I'm actually tweaking it now.

Post a screen shot or the log if they both look the same
[Android Software/Hacking General [Developers Only]] noradoor:
Actually,I still have timer_entropy enabled even after Supercharging my phone.

And as I said,the Entropy's upsides disappeared after that.

Then,seen in this light,I think Supercharger beats it indeed.LOL.

But admittedly,I was amazed that timer_entropy streamlined my phone to a certain extent,or maybe at some apps.:p

Monitoring from the entropy-watching,I got around 3800+ and even 4000 some times.

just for your information.:)
[Android Software/Hacking General [Developers Only]] jgcaap:
Oh my... Dev wars :p
[Android Software/Hacking General [Developers Only]] pikachu01:
More like Dev disappointment. Disappointed that zep's original values that he holds true before this no longer holds true now. :(
[Android Software/Hacking General [Developers Only]] clay101eve:
Zepp ur a boss.

Clay

Team Pirate

Sent from my PINK GSwagger2
[Android Software/Hacking General [Developers Only]] pikachu01:
I think you're failing to see what the code does.

:/

As I've said, the values are there for the apps to use. Each of the object is passed to the app when it is created. It is up to the app creator to allocate memory according to the thresholds.

What you were doing, by removing the memory from passing to the app is just preventing the app to properly allocate memory, thereby disabling the Android LMK.

I sincerely hope that you understand the code first before attempting to make a quick fix for it.

Edit: This code:

private static boolean canSatisfyMemoryAllocation(long bytesRequested) {
checkInitialized();
ActivityManager manager = (ActivityManager) sContext.getSystemService(
Context.ACTIVITY_SERVICE);
ActivityManager.MemoryInfo memInfo = new ActivityManager.MemoryInfo();
manager.getMemoryInfo(memInfo);
long leftToAllocate = memInfo.availMem - memInfo.threshold;
return !memInfo.lowMemory && bytesRequested < leftToAllocate;
}

Is an example of the implementation done by the browser (one of the apps in Android).

How the other thresholds are used by other apps depends on how they use it.

As always the theory is:

1. Android gets the total available memory from the system, the screen size then calculates the minfrees and echoes it to the /sys/module/lowmemorykiller

2. Android passes the Home threshold (MEM), the low memory threshold, hiddenApp, secondaryServer, visibleApp and foregroundApp MEM to the Parcel API.

Note, the low memory calculation is here:

outInfo.availMem < (homeAppMem + ((hiddenAppMem-homeAppMem)/2));

3. The app itself accesses this API to successfully allocate memory on foreground/background and will trigger it to kill itself when in lowmemory. This helps a lot as some apps may choose to kill itself faster (for games) or slower (for widgets/services).

By removing this, you're effectively removing the option of the app controlling when it gets to be killed.

The Android LMK first and foremost was developed to give apps themselves controllability from being forcefully subjected to the Linux LMK. <- This is the core understanding that you need to grasp.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
heh... well if you wanna test... post your services.jar lol

Theoretically, I can get all fancy and change the values contained in the array in ProcessList.smali since the MB values in there are quite big.
[Android Software/Hacking General [Developers Only]] pikachu01:
You can easily try this:

If your edits was successful, and if you run games and browsers together, the browsers would be killed first. (actually depending on the games that actually actively managing the thresholds).
[Android Software/Hacking General [Developers Only]] zeppelinrox:
heh... still messing with a snappy Milestone which can't quite do miracles yet :p

Will be messing with an S3 soon methinks.

I just figure it would be faster if you could test and see if it's the disaster that you expect :p
[Android Software/Hacking General [Developers Only]] Kitschki:
...I skipped pikachus post just to see another brain-breaking post by zep ㅠ.ㅠ
[Android Software/Hacking General [Developers Only]] pikachu01:
You can try this in the ADT Eclipse as well.

Just try to print out the lowMemory/*threshold values. It would be 0 (I think). And with it being 0, apps that specifically use the getMemory API will be limited in making choices of whether to be killed/ releasing memory etc.

Bad choice.

Edit: To do that, you have to do readFromParcel.
[Android Software/Hacking General [Developers Only]] zeppelinrox:
hah... I can put all the in the OP... make it cleaner :p

Ah interesting idea.

I finally installed ubuntu on this laptop and don't have all that installed at the moment.

What do you get when you run those commands?

btw I don't think preventing AMS from putting those 4 new *thresholds to AcitivityManager is too big a deal - since those don't exist in previous OSes.

Doing only that may be actually be enough.

Always reporting free ram available is a bit drastic tho but I tend to see how far I can push things :p

But there's always different ways to achieve a wanted result and the first one isn't always the right one lol

The guys in the evo 4g lte like testing this services.jar stuff tho so gonna run it by them too and see what it takes for them to get below 150 mb free ram :)
[Android Software/Hacking General [Developers Only]] pikachu01:
You don't need to use Ubuntu.

You can download and use ADT for Windows.

I haven't had the time to run. If I get the chance, I'll report it ASAP.

I do have a day job!! >.<
[Android Software/Hacking General [Developers Only]] orbital_71:
Both of u like husband and wife bickering over house work. :D
[Android Software/Hacking General [Developers Only]] noradoor:
I'm inclined to think pikachu01 is also trying to provide his knowledge to better our phones' performance.

An argument is normal and kind of healthy for this community,so I'd rather take it as a brainstorming.;)
[Android Software/Hacking General [Developers Only]] clay101eve:
Best part is... I see a bromance forming... Step brothers style!

Clay

Team Pirate

Sent from my PINK GSwagger2
[Android Software/Hacking General [Developers Only]] OmegaBlaze:
It still does it with the boot busybox:

Not sure what to do..
[Android Software/Hacking General [Developers Only]] zeppelinrox:
Ah okay well at least the boot bb works :)

If it's 100% supercharged don't worry about it.

It's doing a routine to find the laucner but you shouldn't see the left over garbage like that

Ok cool. I do some testing tomorrow as I gotta hit the sack.

btw... I have a weird feeling now that I'm digging over source and smalis...

So... I'm thinking that the values in the minfree file are actually being read as KB and not pages in ICS and JB.

I'm following the hexadecimal / math in ProcessList.smali (just to be sure of everything) and it looks like KB?

// 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
};

Yes it does say KB but naturally I figured that it would get converted to pages when applied to the minfree file... and further down it does show the values in pages:

// GB: 2048,3072,4096,6144,7168,8192
// HC: 8192,10240,12288,14336,16384,20480

The first low end value in the source is 8192 KB which translates to 2048 pages. (Shortcut math 8*256 or 8*1024/4)

In the array in ProcessList.smali it shows up as 0x20 in hex which means 32 - which really makes no sense.

Then this happens:

memString.append((mOomMinFree*1024)/PAGE_SIZE)

So essentially that 32 is divided by 4 (32*1024/4096) which gives an 8

Then finally this happens:

return mOomMinFree * 1024

Multiply that 8 by 1024 and it is indeed 8192

And that's about it. I don't see in ProcessList.smali any additional math to convert that 8192 into pages so that's what must get put into the minfree flle.

Either that or I'm going blind all of a sudden.

What were those weird minfrees that you mentioned earlier?

Well I've always respected pikachu so I wondered about this whole "zep sucks at baking" deal lol

Anyway, he does have one of the best quotes in the thread ;)
[Android Software/Hacking General [Developers Only]] pikachu01:
You have no idea what you're talking about.

lowMemory is only affected by the available Memory/homeAppMem and hiddenAppMem.

Unless your hacking of services.jar can directly affect this, please provide a more concrete argument. I have never eyerolled more than I did in my life when I read the comment above.

outInfo.lowMemory = outInfo.availMem < (homeAppMem + ((hiddenAppMem-homeAppMem)/2));

The homeAppMem is calculated on the fly by ProcessList. Changing the *_ADJ only affects the priority it gets evaluated. When the homeAppMem threshold is reached, and if other victims have higher ADJ, it will be killed first. It still doesn't fix the problem of when the threshold gets evaluated. As there is a mismatch of Linux LMK and Android LMK, the Linux LMK will always fire first, searching for victims to release its memory disregarding the fact that the app itself can control memory release or whether some apps can get killed first rather than later.

Thus hacking services.jar will never be the correct method to get a good OOM/LMK fix.
[Android Software/Hacking General [Developers Only]] pikachu01:
The smali values are obviously constants that will be calculated and factored in once the actual available memory values are put in.

You can't do a 1-to-1 direct substitution like that.

Firstly, it'll scale:

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

scale is calculated by a ratio between screen size and total available memory:

// Scale buckets from avail memory: at 300MB we use the lowest values to
// 700MB or more for the top values.
float scaleMem = ((float)(mTotalMemMb-300))/(700-300);

// Scale buckets from screen size.
int minSize = 320*480; // 153600
int maxSize = 1280*800; // 1024000 230400 870400 .264
float scaleDisp = ((float)(displayWidth*displayHeight)-minSize)/(maxSize-minSize);
//Slog.i("XXXXXX", "scaleDisp=" + scaleDisp + " dw=" + displayWidth + " dh=" + displayHeight);

StringBuilder adjString = new StringBuilder();
StringBuilder memString = new StringBuilder();

float scale = scaleMem > scaleDisp ? scaleMem : scaleDisp;

Then it'll be converted to pages. Formula is:

n bytes / PAGE_SIZE

8192 KB is 8192 * 1024 bytes.

It does provide the correct calculation for page size.