[Android Software/Hacking General [Developers Only]] osm0sis:
Nope, I've just been working on it. :p

I discovered the lmk whitelist wasn't working correctly on f.K r382 for the GN (even though the exact same script works flawlessly on the recent f.K builds on the N7). So I've just been doing some testing with trying to figure out why it also requires a delay and how to set it as soon as possible, which has been driving me CRAZY. Basically it all has to do with the creation of the "/proc/<process id>/oom_adj" file and dir, and then, like the lmk minfree test above, there being other oom_adj values it starts out with that get overridden later, making us wait until then to set our desired value of -17 (to make it "unkillable").

Most launchers start out at a oom_adj of 0, then I've found at least stock (com.android.launcher), Apex, Nova and Zeam all then get an oom_adj of 2, and THEN finally 6. And we can't set -17 at any time before it becomes 6. So I accommodated that pretty well, but then found some other launchers don't follow this pattern; ADW, for example, just stays at oom_adj 0, which is a huge pain in the ass since that's a value I had to set it to avoid for most other launchers I tested. I've also seen a value of 1 pop up instead of 2 which is rare and makes no sense to me considering I hadn't changed anything from when it was 2 on the boot before.

I also learned I needed to use pgrep instead of pidof for a number of launchers to get their process id correctly, since once they're running they take on a different class name, like org.zeam.core instead of just org.zeam, and others may have an activity on the end like com.lx.launcher8:lock. (I also had to take Launcher 8 back out of the list since it doesn't even show up in a pgrep at all under most circumstances. Not sure how or why, but for now it just can't be supported.)

Here's what I've come up with:

# lmk whitelist for common launchers and increase launcher priority
list="com.android.launcher org.adw.launcher org.adwfreak.launcher com.anddoes.launcher com.android.lmt com.chrislacy.actionlauncher.pro com.cyanogenmod.trebuchet com.gau.go.launcherex com.mobint.hololauncher com.mobint.hololauncher.hd com.teslacoilsw.launcher com.tsf.shell org.zeam";
safety=0;
while sleep 1; do
for class in $list; do
if [ `pgrep $class` -o $safety -gt 120 ]; then
launcher=`pgrep $class`;
oomadj=`cat /proc/$launcher/oom_adj`;
if [ $oomadj -gt 2 -o $safety -gt 60 ]; then
echo -17 > /proc/$launcher/oom_adj;
chmod 100 /proc/$launcher/oom_adj;
renice -18 $launcher;
exit;
fi;
fi;
done;
safety=$(( $safety + 1 ));
done&

So, what that should do is sleep until it gets a pgrep hit from the list, then if the oom_adj is 0, 1 or 2 it continues to wait. Once oom_adj is greater than 2 (so 6 for most launchers) it's safe to go ahead and set it to -17, lock the oom_adj file then exit the loop. To accommodate those launchers that just stay at 0, once the loop counter gets to 60 seconds it'll allow it to go through even if oom_adj isn't above 2. And if it never gets a hit at all (ie. you're using a launcher that isn't in the list), then at 120 seconds it will just let it through so it can exit the loop.

So all in all, it should work, but it's not very clean due to accommodating so much weird variability in how oom_adj appears to work with various launchers. It has me feeling that it might not be worth the effort to set it as soon as possible, and we should just go back to using the sleep 60 to bypass all that bull****:

# lmk whitelist for common launchers and increase launcher priority
list="com.android.launcher org.adw.launcher org.adwfreak.launcher com.anddoes.launcher com.android.lmt com.chrislacy.actionlauncher.pro com.cyanogenmod.trebuchet com.gau.go.launcherex com.mobint.hololauncher com.mobint.hololauncher.hd com.teslacoilsw.launcher com.tsf.shell org.zeam";
while sleep 60; do
for class in $list; do
if [ `pgrep $class` ]; then
launcher=`pgrep $class`;
echo -17 > /proc/$launcher/oom_adj;
chmod 100 /proc/$launcher/oom_adj;
renice -18 $launcher;
fi;
done;
exit;
done&

Still toying with the notion for a bit, then I'll upload the new 975experimental with the changes, one way or the other. ;)

Edit: Going with the sleep 60 version with the pgrep fixes. The other way is too complicated and finicky. :( Uploaded now. :good: :)