[FIX] Bulletproof Background Apps!

UPDATE: Try BulletProofing Apps with my latest V6 SuperCharger Script! Use the following link OR use the link in my signature

I didn't want to risk making the SuperCharge & Bulletproof thread too confusing so I figured it best to make a "sister" thread.

This is a work in progress.

But if this information is helpful, please click the thanks button

HUGE thanks to Feeyo and Bear in NM for helping me figure out a workable solution on locking a background app in memory on boot up.

Feeyo gave me the gist of it but it wouldn't work on boot.
After posting in this thread at Droid Forums, things got rolling - with alot of help from Bear in NM.

Create a Unix script file with no extension (I named it 97oom) with Notepad++ and put it in your i/system/etc/init.d/ folder and put this inside: Permissions: chmod 755 /system/etc/init.d/97oom (same as 10overclock)

You can also do it on the phone itself:
1. Make a copy of 10overclock
2. Renamed it to 97oom (I have a 98governor and a 99complete so...)
3. Deleted the text and put the text you see above
4. Set permissions

Then reboot to test!
You can check to see if it worked with either Auto Memory Manager (AMM) or AutoKiller Memory Optimizer (AKMO).

The bold text in the above code is the process name of the app that you want to protect!
Note: You can get the process name from most process monitors or with AKMO or AMM.

That command "as is" will give ES Security Manager the highest priority of -17.
AKMO shows it as being ignored by the OOM killer
At first it wasn't working on boot because ES Security was not yet loaded in memory.
The "sleep 60 "command fixes that by waiting 60 seconds to execute the command

You can also do this in GScript Lite with this: This comes in handy for apps that don't load on bootup - just run a GScript for those apps

I suggest you get Busybox Installer and have it install the latest BusyBox (v1.19).
This ensures GScript doesn't spit out ugly stderr: messages.

GScript Tip: 1. Make a file (with any text editor) with the commands
................. 2. Rename it with an .sh extension (example 97oom.sh)
................. 3. Put it in sdcard/gscript folder
................. 4. Run GScript, Menu key, Add script, and click Load file, select a script and Save (leave SU checked)

Even better, you can make shortcut for any GScript.
Long press desktop > Shortcuts > GScript Lite > Select... BOOYA!

As I said, this is a work in progress.
Taming the OOM Killer explains that an app will be ignored by the OOM killer if it has the -17 priority.
The problem is that Android will still shuffle it's priority downwards like it does with any inactive app.
If that happens, then the app reverts to it's usual priority.
This is why ESS will lose it's -17 after a couple of hours. It just sleeps ALL the time.

My thinking that if a more active background app, such as an SMS app or a music app is given the -17, it won't lose it's priority at all.

Feedback with results is more than welcome!

That's pretty cool.
I figure most people would copy/paste the whole thing and replace the process name.
So maybe the back ticks wouldn't be a big deal.

No need to set a variable, just use back-ticks:
Although that may be a little too complicated for some people to type in. Best to keep it simple I suppose...

Persistent bulletproof apps/ bulletproof service

I may be wrong, but the bulletproof apps script only runs once at boot, then calls /data/97BulletproofApps.sh, so it seems you get two shots at bulletproofing an app.

The problem, as I see it is that if your app isn't running at boot or in a few minutes after boot, it won't get bulletproofed.

If you want the script to stay persistent so that your chosen apps get bulletproofed whenever you decide to launch them, you can do something like:

---------------
#!/system/bin/sh

while true; do

for i in com.waze com.myrt.andrevocadjuster com.google.android.apps.maps com.android.music com.mixzing.basic mobi.mgeek.TunnyBrowser com.android.browser ;

do
j=`pidof $i`
echo "-17" > /proc/$j/oom_adj
renice -10 $j
done

sleep 60

done
-------------

On the "for i in" line just place a space-separated list of the processes you want to bulletproof.

I've used a nice value of -10, as I've always understood from my Unix days that it's good to let the system processes exist at a lower nice level than user processes (so that swap, I/O and other system processes get priority and keep the system running smoothly). I may be wrong.

The only problem would arise if android decided to kill the 97oom shell process. Having looked into this, you could instead move 97oom into /system/xbin (or another location if you prefer) and add these lines to your /init.rc

----------
# bulletproof as a service by evilj, with thanks to zeppelinrox for bulletproof and SuperCharger
service bulletproof /system/xbin/97oom
user root
critical
# bulletproof end
----------

The "critical" line makes the android system restart the service if it gets killed.

However, I noticed that 97oom is running at an oom level of -17 anyway, so it's unlikely to get killed unless you do it yourself, so maybe it's a case of overkill (pun intended!)

Hope this helps. Please give me a thanks if it does.

J

I don't know.

But try this:
1. uncheck lock messaging app so it's disabled.
2. run messaging
3. lock messaging in memory again.

It has to work if it's working on my phone.
But if not, keep in mind that I installed RC4 clean.

I had a stock rom that I was testing with and I wiped everything clean before installing RC4.
The only thing that was kept were the apps that were sleeping on the ext2 partion that were installed on CM6