yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] zeppelinrox:
There is nothing effecting the ADJ there. I just made sure and there isn't even the string "adj" in core\java\android\app\ActivityManager.java

But there is something funky going on with those 4 memory thresholds.

hiddenAppThreshold

secondaryServerThreshold

visibleAppThreshold

foregroundAppThreshold

Using the visibleAppThreshold as an example, in AMS.java, it's

outInfo.visibleAppThreshold = mProcessList.getMemLevel(
ProcessList.VISIBLE_APP_ADJ);

In smali it looks like:

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

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

move-result-wide v4

iput-wide v4, p1, Landroid/app/ActivityManager$MemoryInfo;->visibleAppThreshold:J

So AMS gets a memory level for VISIBLE_APP_ADJ from ProcessList feeds the info to ActivityManager as a visibleAppThreshold memory level.

So, if I go with my initial gut feeling, I can comment out those iput commands so ActivityManager stays out of it and doesn't change anything and it will be fully baked! :)

OR... it will bootloop lol

Regardless, even if SuperCharging services.jar was half baked, which it isn't, that just means the oven isn't big enough to fit it all in ;)
[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.
[Android Software/Hacking General [Developers Only]] pikachu01:
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]] Kurre:
Thank you pika and zep! This discussion of yours is utterly interesting to read :D and so again I'm learning so much from you guys..;)

Sent from my slimbeaned GNex :)
[Android Software/Hacking General [Developers Only]] carniman78:
Good arternoon, pikachu01. I've using your script for a week in my I9000 with CM10.1 and it's amazing, but I have 2 questions for you:

a) When I've updated the CM to the last nightly, I've installed your script usin CWM and, after the system reboot, internal card wasn't detected. It was necessary to reboot the phone two times, making a wipe cache partition in both cases, and now it works well.

b) Do you know if it possible to use your scrip in a Galaxy SL I9003 with a rooted (with CWM) GB Stock rom?

Thank you for your work and help.
[Android Software/Hacking General [Developers Only]] pikachu01:
a) Never experienced that before. It might be a CM 10.1 instability that randomly happens?

b) Yes. It's compatible as mentioned in the first post.
[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...
[Android Software/Hacking General [Developers Only]] blackloaders:
Hello pikachu01

I have question

on step 4 i remount sgs4g, is it okay for my device (xperia mini pro)?

sorry for my bad English[/QUOTE]
[Android Software/Hacking General [Developers Only]] pikachu01:
Can I see the output of your

mount

in Terminal Emulator? I'll make a remount for your device if it can be remounted.
[Android Software/Hacking General [Developers Only]] blackloaders:
/local/bin:$PATH <
app_7@android:/ $ su
app_7@android:/ # mount
rootfs on / type rootfs (rw,nosuid,nodiratime,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,noatime,mode=755)
devpts on /dev/pts type devpts (rw,noatime,mode=600)
proc on /proc type proc (rw,noatime)
sysfs on /sys type sysfs (rw,noatime)
tmpfs on /mnt/asec type tmpfs (rw,noatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,noatime,mode=755,gid=1000)
/dev/block/mtdblock0 on /system type yaffs2 (ro,nodiratime,relatime)
/dev/block/mtdblock3 on /data type yaffs2 (rw,nosuid,nodev,nodiratime,relatime)
/dev/block/mtdblock2 on /cache type yaffs2 (rw,nosuid,nodev,nodiratime,relatime)
/dev/block/mtdblock1 on /data/idd type yaffs2 (rw,nosuid,nodev,noatime)
/dev/block/vold/179:2 on /data/sdext2 type ext2 (rw,noatime)
/dev/block/vold/179:1 on /mnt/sdcard type vfat (rw,dirsync,nosuid,nodev,noexec,noatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/block/vold/179:1 on /mnt/secure/asec type vfat (rw,dirsync,nosuid,nodev,noexec,noatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /mnt/sdcard/.android_secure type tmpfs (ro,noatime,size=0k,mode=000)
app_7@android:/ #

Thanks
[Android Software/Hacking General [Developers Only]] pikachu01:
All your partitions are yaffs2. Only Ext4 mounts supports remount :(
[Android Software/Hacking General [Developers Only]] blackloaders:
_:(

Okay, thanks anyway
[Android Software/Hacking General [Developers Only]] hoholee12:
Hi pikachu, 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.

Also wheres the sys device virtual bdi default used for?(edit idk anything!!)

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

thanks in advance!:)

This post was sent from my gaming rig.
[Android Software/Hacking General [Developers Only]] pikachu01:
I'll answer it a bit later. It was late yesterday and I had the time to only check what was posted.
[Android Software/Hacking General [Developers Only]] pikachu01:
Advantage of using LMK - You can control how much free memory (which governs responsiveness) as well as the degree of multitasking in Android.

Difference between Linux ADJ and Android ADJ - Linux ADJ and Android ADJ basically means the same thing. Only difference is that it is evaluated by different mechanisms. Linux ADJ is evaluated by the OOM killer while Android ADJ will be assigned to apps and then the apps will evaluate itself whether or not it should release memory/be killed when in background/the ADJ that the apps are assigned to.

The default BDI is not used for anything I think. Maybe if you mount another virtual BDI at runtime, it'll follow whatever's in the default. (Not sure as I need to check the source).

One comment I can give about your tweaks, Lazeroid, you're using a whole bunch of unorthodox values that will either sacrifice battery life or performance. Each of the VM values have their own uses. Disabling them will actually be detrimental to your phone.

You should at least learn about the architecture of what you're tweaking first before assigning randomly thought out values to it. More testing should be done as the impact from values you assigned at the time you're running it won't be seen just a few minutes from whence you've tested it.
[Android Software/Hacking General [Developers Only]] hoholee12:
Thanks for the answer:)

btw i was trying to find some lines that could automatically switch to orthodox values realtime

so that i can save battery when not needed.

Op Sounds like you got sth that i needed in your script. Could u tell me how to do it? Please:)

"Therefore I am the one doctor to demolish all the lags."
[Android Software/Hacking General [Developers Only]] zerorated24:
what about 120 MB and 150MB LMK?

Hi pikachu, is it okay for you to add 120MB and 150MB LMK? I think it will be better for gamers to have more free RAM
[Android Software/Hacking General [Developers Only]] pikachu01:
I think you're misled that more free RAM at the EMPTY_APP side will lead to higher performance.

Yes, it can scale better if your free RAM is generally around the region of 40-50MB. This is because apps that need RAM (generally apps can allocate the memory they need according to the Dalvik heap size). Very rarely (except for certain games) that they need to use the full 64MB heap size that is set.

Oh wait, I can see now that ICS and JB has a Dalvik heap size of 128MB by default. Yes, I think I should create a 120MB LMK just for that. However, 80MB and 100MB LMK should work just fine though. This is because, as long as RAM stays above the region of 40-50MB (which most apps reside, except games which naturally you would only run 1 game at a time), you won't face much problems.

Beyond the 120MB, it's just wasted RAM. Free RAM is wasted RAM in Linux and you should remember that well ;)

I will create a 120MB LMK a bit later. However, your RAM should be 1GB or more to use it efficiently. Using a 100MB/120MB LMK on a 512MB phone is just killing your multitasking. Imagine your CPU time busily working on recovering RAM from killing apps rather than crunching your app data.

There is another thing though. The LMK doesn't work for AOSP ICS and JB as they are using a calculated-on-the-fly LMK which should give you a range of 80MB LMK if you have enough RAM and this fine by any means.
[Android Software/Hacking General [Developers Only]] zerorated24:
thank you for that. I really learned something from you and zep. BTW, you said there that using 100mb LMK on 512MB ram phone will not give me effecient RAM management right? So, you mean 80MB LMK is already enough for RAM hungry games like Nova?
[Android Software/Hacking General [Developers Only]] pikachu01:
Should be effective enough. If it isn't I would like to know the RAM consumption of Nova. I would need to lower the Perceptible/Heavy_weight (rather than the Empty_app) MEM values to accommodate it.
[Android Software/Hacking General [Developers Only]] Ganesh A:
Good

My Greatest Work:

Xperia NxT MoD v1.2 For All GB

http://xdaforums.com/showthread.php?t=1967172

Sent from my GT-5360 with Xperia NxT MoD
[Android Software/Hacking General [Developers Only]] pikachu01:
I don't understand :/
[Android Software/Hacking General [Developers Only]] pikachu01:
Guys, expect a major update to the LMK soonish. Reading the Android LMK in depth gave me this:

http://xdaforums.com/showpost.php?p=35676889&postcount=16824
[Android Software/Hacking General [Developers Only]] Starsream88:
Hi pika,

Is bigger vm heapsize important for better performance ?

And what is the best value for a phone with 404Mb Ram ?

Thank you
[Android Software/Hacking General [Developers Only]] zerorated24:
LOL! why post here? anyway nice mod from you!
[Android Software/Hacking General [Developers Only]] pikachu01:
Bigger VM heapsize is not better actually. A low VM heapsize enables more applications to run on a device which has limited RAM.

VM heapsize means the maximum physical memory that an app can occupy. Some apps might make their VM heapsize to be maximum by default. That means, if your VM heapsize is 128MB and the app sets it's allocated heap size equals to the maximum heap size, your phone can only support 3 apps.

Thus, it is better to realistically set the heap size accordingly. Yes, with new OSes, they actually increased the heap size as I think they put in place a few rules before an app can allocate that much physical memory.

My advice: Just follow whatever default heap size the OS chose. If you want, you should scale down the VM heap size, not scale up. This will allow more apps to run at the cost of a lot of garbage collection running (the point where the apps need to write back to disk all the memory they are storing in the RAM).

Did you use zipalign? I've encountered quite a few problems with zipalign lately. I'm not sure what triggers it. :/
[Android Software/Hacking General [Developers Only]] spambayes:
Yes, I've enabled Zipalign, Remount and CFS98 in Thunderbolt. Funny thing is, some apps encountered no problems at all while others disappear after a few hours or after the next reboot.

Do you think the Permission denied error has anything to do with the problem? I'm wondering if this is in any way related to the "Fix permissions at boot" in the Rom's startup tweaks or in Recovery Console.

I'll disable Zipalign in Script Manager and retry.

Thanks.
[Android Software/Hacking General [Developers Only]] pikachu01:
If after the 1st reboot and it all worked fine after zipalign, it's fine.

If subsequent reboots produced this, then I'm not sure what could be wrong. It can be that you used init.d to perform zipalign and while in the middle of zipalign, something interrupted it (caused race condition?) . Hence it's imperative that you run zipalign using Script Manager, so that everything is loaded first before zipaligning.
[Android Software/Hacking General [Developers Only]] spambayes:
Just reinstalled missing apps and disabled S70darky_zipalign as root and boot in /bolt_scripts. Apps stuck around after multiple reboots. Upon reenabling Zipalign, apps disappeared after 1st subsequent reboot. So it appears that the S70darky_zipalign is part of the problem?

As I've reported a few posts back, I do have a 01zipalign script in my init.d directory which was put in there by the Slim Bean Rom as part of startup tweaks. I have NOT enabled this script.

Any ideas how I can proceed from here?

Thanks.
[Android Software/Hacking General [Developers Only]] pikachu01:
Did you enable zipalign as part of the init.d or Script Manager?

If you've restored the apps and zipalign causes it to get corrupted, I'd advise you to not use zipalign until I can figure out why there're differences in experience in using it.
[Android Software/Hacking General [Developers Only]] zulusik:
The issue might be with the cache partition size - zipalign probably uses it to store temp files, and if cache size is not enough, the app gets deleted. If my assumption is true, then most probably big apps are lost after reboot, and small ones not.
[Android Software/Hacking General [Developers Only]] pikachu01:
I'm using the /data to zipalign. Our phones should have at least 10 percent left before it says low memory I. E. 200mb for a Galaxy phone. That 200MB should be enough for most apps.
[Android Software/Hacking General [Developers Only]] mixednuts:
As a heads up for whoever ends up reading this - there are a few app2sd type scripts that implement zipaligning via INIT.d... CronMod being one of them.
[Android Software/Hacking General [Developers Only]] spambayes:
Pika,

I always used Script Manager to enable Zipalign, never init.d.

To clarify, there are 2 zipalign scripts. One named 01zipalign which came with Slim Bean is in /init.d and the other named S70darky_zipalign which was installed by Thunderbolt is in /bolt_scripts. The 01zipalign script has

always

been inactive. So the current problem is only with Thunderbolt's zipalign, S70darky_zipalign which I have been enabling and now disabling via Script Manager.

I've taken your advice and disabled zipalign for the time being. Hope you'll find out what's causing this problem.

UPDATE: I came across http://xdaforums.com/showthread.php?t=1252813. Do you think this has any relevance?

So far the apps which exhibit this disappearing behaviour are Titanium Backup and a few Office suites. I haven't installed any games or such yet so I wouldn't know if larger apps will see the same behaviour. I don't think Ti Backup is excessively large and the Office suites are in the region of around 10 Mb each. Interestingly, I have 15.20 MB free of /cache, as seen here:

[/IMG]

I do not use Apps2sd at all.

Thanks.
[Android Software/Hacking General [Developers Only]] spambayes:
Plenty of space here.

---------- Post added at 03:28 AM ---------- Previous post was at 02:49 AM ----------

Hi zulusik,

Found one of your earlier posts on this problem http://xdaforums.com/showpost.php?p=30898527&postcount=2550

Was a fix ever released?

Thanks.
[Android Software/Hacking General [Developers Only]] pikachu01:
Yeah, that's why if you have a ROM that comes with zipalign, and you enable zipalign from ThunderBolt! itself, you'll run a risk of a race condition.

Using /data would prevent the disk from getting full. Hence I don't think that's the issue. However, the idea of getting the return code is good to prevent failed zipalign APKs. I'll implement this in ThunderBolt! in the next update.

Yeah, there's plenty of space, hence I'm not sure what triggers the error. :/
[Android Software/Hacking General [Developers Only]] spambayes:
I understand. FYI, I tried removing the ROM's zipalign script from init.d and then using only Thunderbolt's script in /bolt_scripts to test for this problem. As expected, even without any zipalign in init.d, the problem persisted when I enabled zipalign in /bolt_scripts via Script Manager and disappeared when I disabled zipalign.

Let me know if there's any thing I can do to help.

Thanks.

UPDATE: Shortly after writing the above, I had a thought to try the inverse scenario -- keeping TB's zipalign disabled in Script Manager but enabling Rom's zipalign in init.d. After multiple reboots, all apps are still in place. So does it mean that somehow the Rom's zipalign does not cause the problem which TB's zipalign does? Any way I can help debug this?
[Android Software/Hacking General [Developers Only]] pikachu01:
Yeah. Thanks! I'll take a look into the problem deeper in the weekends.
[Android Software/Hacking General [Developers Only]] KMino:
This rocks on ELL5! Going to forget about custom kernels for a while now :D

Happy Christmas to all!
[Android Software/Hacking General [Developers Only]] roshan2989:
im on CM10.1 (galaxy s 19000)..does this script support cm10.1...?

Edit:which one should i install (signed_ThunderBolt-CWM v2.9.0.zip) or (Stock i9000 Restore CWM v1.2.0.zip)
[Android Software/Hacking General [Developers Only]] pikachu01:
Yes. It does support CM10.1. The Stock I9000 Restore CWM is the restore pack (to remove ThunderBolt! from a stock I9000 Gingerbread). You should install the main CWM (ThunderBolt! 2.9.0).
[Android Software/Hacking General [Developers Only]] roshan2989:
thnks for the info bro...
[Android Software/Hacking General [Developers Only]] roshan2989:
is this correct or error...?

View attachment 1585757
[Android Software/Hacking General [Developers Only]] pikachu01:
It's an error. You're probably using slimbean or some custom Jelly Bean AOSP ROM right? It's supposed to extract the JellyBean sqlite3 but it extracted the Gingerbread ones instead.

What you can do is copy the sqlite3 file from the zip (system_jb folder) to the /system/xbin using Root Explorer. Still can't find out what's causing it to not evaluate the correct OS version. Sorry about that.
[Android Software/Hacking General [Developers Only]] gaz41:
And what about if I'm on a I9000 JB ROM? How can I restore stock JB settings? Is it enough to reflesh the ROM without wipe? ty

Inviato dal mio Galaxy S
[Android Software/Hacking General [Developers Only]] roshan2989:
no,im on cm10.1...

i just copied from the zip (system_jb folder) to the /system/xbin,and its replace the sqlite(which alreday in it)
[Android Software/Hacking General [Developers Only]] pikachu01:
Yes, apparently so. Reflashing a ROM wipes ThunderBolt! as well.
[Android Software/Hacking General [Developers Only]] bigfau:
Does 2.9 work on ICS? Im a little confused by OP and lack of sleep.

ThE UnknowN
[Android Software/Hacking General [Developers Only]] akira888:
Sorry for the noob questions.:eek: I am a bit confused after reading a very long OP lol

I am using an AOKP ROM. Does it mean I cannot use this script?

Because my understanding is that the main script has the screenstate tweak which is not compatible with the AOKP ROM as per the OP?
[Android Software/Hacking General [Developers Only]] pikachu01:
It's already taken off into a separate addon called screenstate_scaling. Hence, main CWM is compatible with AOKP/AOSP/CM etc.