[Galaxy S III Android Development] agusdallalba:
Why are you all messing with the OOM killer settings anyway? That's a Linux thing, it's different to the Android task killer even though Android does store the stat of every app in the oom_adj tunable.

First a disclamer, I'm a Linux guy, not that familiar with Android. But from what I gather:

The OOM condition is triggered when the ram and swap space depletes. This will only happen if the Android task killer fails to suspend an idle app. Then the kernel (which knows next to nothing about Android and its internal consistency) does one of this three things:

If /proc/sys/vm/panic_on_oom is 1, it just writes to the log and hangs/reboots. Fortunately this is set to 0 by default.

If /proc/sys/vm/oom_kill_allocating_task is 1 it kills the last process to request memory to the kernel (which is very likely wither the app the user is using atm, which of course shouldn't be killed, or a vital process like surfaceflinger). This is clearly a terrible thing to do, so it's set to 0 by default. But you have set it to 1 in your script, this means that when memory is completely full the task that's going to be killed first (by the kernel, in a very untidy way), is the app that the user is interacting with. Or worse, it'll will kill something important and hang or reboot the phone.

Otherwise, it scans all running processes, identifies the most memory-hungry, and kills it. With fire. The big, hot, yellow and flaming kind of fire that burns everything. The only way to avoid being killed by the OOM in this situation is having a lower OOM priority that everyone else. The 99lockapp script just sets the same really low OOM killer priority (that should be reserved for critical system processes) to everything. The Android task killer will hardly ever kill something with such a low OOM priority. So let's say that the Facebook app decides to take a big bunch of memory very fast (so fast that Dalvik can't catch it and force-close it), then init, or the core Android UI service surfaceflinger have the same chances to be killed than Facebook. Not that good huh?

So changing the OOM killer priorities in a global manner is a really bad idea, and not only it won't keep the apps from being suspended by Dalvik, but it will make the system unstable and unreliable. On the other hand, I think that the original idea of keeping the phone, camera, conacts and SMS apps in memory at all times was very good.

This is not the only /proc tunable that does more harm that good, for example:

chmod 777 /sys/block/mmcblk0/queue/read_ahead_kb
echo "2048" > /sys/block/mmcblk0/queue/read_ahead_kb

What this does is:

It gives read-write permissions to every non-root app running to change a kernel tunable (!). Completely unnecesary since you are root already.

Sets readahead to 2kB. This means that for every read request, 2kB of memory will be allocated, being that necessary or not, and if an app wants to read, say, a few bytes from it's settings file, a whole 2kB chunk (slow!) will be read, again, even if it's not necessary.

echo "0" > /proc/sys/kernel/panic

If something goes wrong with the hardware, a kernel module, stuff like that, the phone will hang instead of rebooting. The default of 1 makes it reboot after one second.

echo "0" > /proc/sys/kernel/panic_on_oops

If something goes really wrong, but it's not something that would keep the cpu from running, the kernel will try to continue anyway. This means that, for example, if the kernel finds a corrupt memory page, instead of rebooting for safety it will go on, potentially corrupting more things on the way. Dangerous.

echo "100" > /proc/sys/vm/swappiness

The kernel will much rather place running processes in swap than in RAM. In fact, any read operation will force a memory page out of ram and into the swap. The result? A unresponsive system when several RAM-hungry apps, like games, are run concurrently.

echo "2" > /proc/sys/vm/drop_caches

This flushes the read cache from ram once. Problem? Flushing the read cache while the phone is booting will only make it boot slower. Afterward it has no effect whatsoever, since Android does not keep that big of a read cache.

The list is long, so I'm probably missing something. And even tough I tried and did the research, things might be completely different in Android than what I'm used to in Linux. Take this with a grain of salt.

And to finish up, I like the way you've set up tha low memory killer, but if I were you I think I would lower the fourth parameter, (that's for apps running in the background) to ~8000 or so. It might help fit one or two extra apps.