[Xperia SP General] mrhnet:
B) Tips for better RAM management.

Following is an account of which i benefitted from, sharing for others who may not be aware of these. Your milage may vary... Desired "RAM Management" differs depending on whether expecting more multitasking or a snappy phone with lot of free RAM. Nowadays, phones with better specs generally won't show any lag even if tuned for multi-tasking , although "free RAM" stays little lower. I prefer towards more multi-tasking ;)

1.

Change the minfree values to suit your needs.

[highlight](Need Root access)[/highlight].

LMK Minfree values can be changed on the fly. Use lower values if you want more multitasking. Higher values if need more "free ram" for gaming etc.. . I use 8,12,45,65,95,165 for more multitasking and for foreground apps to stay until ram becomes much lower. Asphalt8 never crashed with this! If we use values like 15,25,95,145,195,245 "free ram" would be more but background apps (e.g. Hidden apps) would shutdown earlier. However, make sure NOT to increase the first 2 slots too high, so that the Foreground and Visible apps would stay even if RAM goes lower.

How to set/change them:

a) You can set those values with the above Memory Manager app and press Apply. (and tick 'apply at boot' for those values to be applied at every boot).

** There are many preset values you can experiment with.

b) Or can do the manual way.. Give the following command in a terminal/ADB shell:

echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree

(That's after "su" command to get root prompt). ** Need to 'echo' them in pages; not in MBs. See first post how to convert them.

Note

: This won't survive reboot. You can run this command as a script with init.d every boot. (For init.d support, check this). The script would look like this:

#!/system/bin/sh
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree ;

c) Can use Minfree Manager app. To set the minfrees, press Apply after entering the values. If we press 'Apply at Boot', it saves a script under init.d. No hassle.

** There are many apps that can do these kind of changes. Eg: Auto Memory Manager, Ram Manager(Free/Pro)-with other options. The above described ones are very easy to use.

2.

Use 'App Settings' xposed module to make any app "stay" in memory (make it "Resident")

. [highlight](Need Root access)[/highlight]

It would definitely help multitasking by keeping the needed apps in the background without getting killed, even if RAM becomes low. It possibly works by reduces the app's oom_adj value. That's why you can see Opera Mini in the 'Foreground app' list in my screenshot above (1st post). It's oom_adj value is 0. You can do this for your home launcher and any app you wan't to stay un-killed in the background.

Caution:

Making apps to stay in memory would make them stay without being killed, even when e.g. a heavy game is starving for RAM. Therefore, indiscriminate use of this option is not advised. I think it's better to..

(i) Apply only to the apps which have an 'Exit' button/menu, so we can shut it down when needed.

(ii) If no exit button, Add to the 'Greenify' list to be hibernated when the app is not needed. But it asks for confirmation before hibernating these kind of apps with 'High Priority' oom_adj status.

How-to:

1. Get Xposed installer from here. Install it. Install the Xposed framework through it. Refer to the respective thread for more details.

2. Then download the 'App Settings' module through Xposed installer..

3. Open 'App Settings'.. App list will load.

4. Select the app you wan't to tweak.. It will lead to a page as seen in the screenshot above.

5. Select 'Resident' and save (upper right corner button). Can change any other setting if needed.

3.

Use zeppelinrox's jar patcher tools to patch services.jar

. [highlight](Need Root access)[/highlight].

It changes Home Launcher priority and many other LMK related tweaks. This is why you see my home launcher is under visible apps (oom_adj 1). No launcher redraws even after asphalt8! See the particular thread for details. In summary, patching services.jar results in (quoted from the thread):

** From ICS up, Android doesn't read ADJ values from build.prop or local.prop - they are hardcoded into services.jar! That is the reason for needing to patch services.jar to change OOM priorities. More details in the respective threads.

How-to (quoted):

Get Jar patcher tools from the thread. I used 'Ultimatic_Jar_Patcher_Tools_RC7_TEST6_ALL_DEX_ALL_OSes_NO_FLASH.zip'. Extract it in the PC. Make sure ADB drivers installed.

** Always keep a cwm backup before attempting this; might not get it correct in the first attempt..

4. With the above jar patching, can use zeppelinrox's supercharger script. [highlight](Need Root access)[/highlight].

It can be used to change the minfrees and it re-groups the OOM categories. It also has tons of other cool tweaks. If we check "cat /sys/module/lowmemorykiller/parameters/adj" after applying the SuperCharger scripts to our phone, it returns.. "0,176,352,588,705,1000". Converting to oom_adj values (see 1st post) it becomes "0,3,6,10,12,15". Comparing with stock values (0,1,2,4,9,15), we can see that the above described six OOM slots are re-arranged, sort-of categorising more processes towards higher priority. Can test those settings by echoing those values (this won't survive reboot):

echo "0,176,352,588,705,1000" > /sys/module/lowmemorykiller/parameters/adj

** Not advisable to meddle with this if no clear idea about what is being done. Use the SuperCharger script instead. Checkout the respective thread for more info.

[For me, this OOM regrouping made some task killings more difficult and it didn't relese RAM readily when needed for heavy games..(may not be same for others ;)). So I'm not using it at the moment. I'm setting up minfrees as described previously.]

How-to (briefly):

1) Get the latest SuperCharger script from the thread.

2) Make sure requirements are met. Eg: Rooted, Busybox installed.

3) Run the script through 'Script Manager-Smanager' app (with root access granted).

4) Read the output of the screen and reply to the prompts accordingly.

** Keep a cwm backup before attempting this, just in case..

5. Override the "Hidden app limit" of Android. [highlight](Need Root access)[/highlight].

In addition to the LMK driver mechanism described above, this is another parameter that leads to killing of Hidden and Empty apps. Apps are killed when the number of those apps go beyond the specified limits. (Traditionally it was 15, so no more than 15 hidden apps would stay in the background even if there's plenty of RAM). There's a build.prop setting which can control this in our SP. (Btw, services.jar patching mentioned above makes that limit to 70). With the build.prop setting mentioned, we could make it to even 150 :D! (This way, we can maximize multitasking and app killing is fully handed over to LMK minfrees, which we can control).

How-to

:

ro.sys.fw.bg_apps_limit=70

Add this line to end of build.prop file (in /system) and leave another blank line below that, and save the file. Then reboot.

Tip:

Build Prop Editor is an easy way to edit the build.prop.

** Always keep cwm backups before doing these kind of things.

How to test:

a) Install CatLog app (need root) [This is for reading Logcat]

b) Run it and enter "longer" (without quotes) in the filter bar. Might get a filtered output like this:

It means that the 24th Empty app had got killed, because of exceeding the hidden app limit. This is after services.jar patching making the Hidden app limit to 70. Before it was #17 if I remember correctly.

c) Check the same output after applying the build.prop setting. Should get a little increase. (When I made Hidden app limit to 100, output was #34th empty app gets killed. So, I wen't upto 150 until that kind of output disappeared :D).

## Credits to [MENTION=3357461]zeppelinrox[/MENTION] for finding that build.prop setting. You can read what happened here in his thread.

How it works:

By [MENTION=3357461]zeppelinrox[/MENTION]

That's why my 24th Empty app was getting killed with app limit of 70. You might get a totally different value if this build.prop setting is applied without services.jar patching. Appreciate your feedback ;)

[highlight]** Please Note: I'm no dev. I wrote this according to what i understood by reading around in the net. I'd be more than glad if anyone points out any shortcomings/improvements. Thanks.[/highlight]

Credits/Sources

[MENTION=3357461]zeppelinrox[/MENTION] for his supercharger thread with overwhelming info, for finding out the build.prop setting in our SP, for explaining things and many more!

[MENTION=2199154]androcheck[/MENTION] for his thread

Took more info from here, here, here, and here.