[FIX] Bulletproof Background Apps!

Search This thread

zeppelinrox

Senior Member
Dec 21, 2010
9,374
21,590
IN THE FREAKIN' OP
UPDATE: Try BulletProofing Apps with my latest V6 SuperCharger Script! Use the following link OR use the link in my signature :D

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 :D

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:
Code:
#!/system/bin/sh

sleep 60

PPID=$(pidof [B]com.estrongs.android.safer[/B])
echo "-17" > /proc/$PPID/oom_adj
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 :D

You can also do this in GScript Lite with this:
Code:
PPID=$(pidof com.estrongs.android.safer)
echo "-17" > /proc/$PPID/oom_adj
This comes in handy for apps that don't load on bootup - just run a GScript for those apps :D

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!
 
Last edited:

Bear in NM

Member
Mar 13, 2010
9
0
That is why I try and avoid putting any code I use on forums. Someone who actually knows what they are doing will always come along and whack me ;^)

Seriously, good work Zep.

Craig
 

zeppelinrox

Senior Member
Dec 21, 2010
9,374
21,590
IN THE FREAKIN' OP
I don't mind.
That's all a part of learning so it's always good that there's somebody around that's "smarter" at something than me.

For example... this script I'm trying to get working for supercharging stock phones...

On custom roms, CM and FroyMod at least, I'd modify /system/etc/rootfs/init.mapphone_umts.rc

I flashed stock telus 2.2 and the path seems to be just /init.mapphone_umts.rc
I don't see rootfs anywhere
But there is a rootfs is mounted

To mount as rw, "mount -o remount,rw /system" doesn't work
In gscript, I'm getting "sed not found" errors too.

grrr...
 
  • Like
Reactions: Ricfil

milestonefail

Senior Member
Sep 10, 2010
134
21
Toronto
how well do you think this would work with handcent? it's a little laggy to load up on my phone, but i want to try it out more. will keeping handcent in memory eat up ram that i need otherwise? and do you think it will be active enough to keep it's -17 after a few hours? thanks

edit: i was trying it out, it disappeard from processes withing a few minutes. oh well, maybe it doesnt need to be running anyway
 
Last edited:

milestonefail

Senior Member
Sep 10, 2010
134
21
Toronto
ya, i checked. it was set to -17, then next time it refreshed it was gone. then i opened handcent, went back, and the process had a different pid, not oom level. oh well
 

mike-08

Member
Mar 17, 2011
34
2
damn
Maybe some apps are too prone to get killed off and the only way to keep them alive is with multitasking friendly minfree values
Yes, I've seen the same happening with the stock SMS app. I did not receive SMS anymore so I decided to look at it a bit closer (using adb logcat). I started the SMS app, noted down the PID and set the oom_adj value to -17 using adb shell. A few seconds later it was killed. Setting the minfree values back to system default allows me to receive SMS again. Also whatsapp, gtalk and push mail now work reliable. With high minfree values I could see in the logs that, when a message arrived the app is started and immediately killed afterwards. So, I was never notivied that a SMS or whatsapp message had arrived. With default minfree values it seems to work more reliable.
But it all depends on how you use your phone, I guess. I'm using it as my communication central and don't want to miss any message. If you use it more as your mobile gaming or surfing device you might still be better off with high minfree values.
 

zeppelinrox

Senior Member
Dec 21, 2010
9,374
21,590
IN THE FREAKIN' OP
I agree.
That's why I made 6 different profiles.
The multitasking and balanced 2 settings, for example, will leave you with more free ram but are actually more background app friendly than stock google/android values.
 

mike-08

Member
Mar 17, 2011
34
2
I agree.
That's why I made 6 different profiles.
The multitasking and balanced 2 settings, for example, will leave you with more free ram but are actually more background app friendly than stock google/android values.
I see. I did not realize that. It seems I've been reading your post too superficially.
I'll give those settings a try. I've just lost another SMS (this time with the default setting)
If I can't get this under control I might go back to CM6. I understand this is not as memory hungry as CM7 is.
 

zeppelinrox

Senior Member
Dec 21, 2010
9,374
21,590
IN THE FREAKIN' OP
Well, handcent is a giant pain in the ass.

I'm running stock telus froyo and the thing doesn't even stay loaded and I'm not even doing anything.
I run it.
Try and bulletproof it with a gscript (and sometimes handcent is even killed off if I take too long opening gscript lol)
The script won't even change the priority of hancent.
It stays at an 9 or 10 in the content provider grouping.

But the thing is a pig anyway.
20+ mb of ram used up and the app itself is close to 5 mb.

Maybe froyo has a reason to not like it? LOL
 

yosriz

Member
Nov 30, 2010
20
2
very very important and informative post!
thank you!
one question: any idea why "Auto Memory Manager" isn't avialable to
milestone according to market?
I can't install it from market site and wasn't able to find it in market application?
 

IFLPI

Senior Member
Sep 18, 2010
473
22
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:
Code:
#!/system/bin/sh

sleep 60

PPID=$(pidof [B]com.estrongs.android.safer[/B])
echo "-17" > /proc/$PPID/oom_adj
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
I did it, and after reboot stock sms app (com.android.mms) is killed, I cheched in AKMO, and that fix didn`t help, so I set default minfree values in AKMO (although the previous settings weren`t so strict)
 

jabberwocky127

Senior Member
Dec 25, 2010
55
9
West Lafayette, Indiana
Ok, first off, I am a UK Milestone, running Cyanogenmod 7 RC4. I am trying to raise the oom_adj of COM.ANDROID.MMS and I just used the method zeppelinrox posted instead of the proposed alternative (though I did try that too) and the startup command seems to do nothing. So I decided to try the GScript way and I get this:

Code:
stderr:
stderr:
stderr:
stderr:
stderr:
stderr: cannot create /proc//oom_adj: directory nonexistent
stderr:
stderr:
stderr:

I have never used GScript before and maybe I am doing something wrong here, but I am running it the script as superuser, I have exactly what zeppelinrox has (except a change for the messaging app process name) and I am at a total loss here. Other methods worked fine on my RC3 and keep Messaging as a "Foreground Group" app, but in RC4 it is an "Empty" and that means it will likely get killed a lot. I am using stock minfree values, just using AMM to check oom. I don't want to be missing texts, so any help would be greatly appreciated. Let me know if you need anything else.
 

zeppelinrox

Senior Member
Dec 21, 2010
9,374
21,590
IN THE FREAKIN' OP
You get that "directory nonexistent" error because the app was already killed so there is no PID anymore.

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.

I finally installed CM7 for the first time and RC4 at least does have the option to lock messaging app in memory.
It's sitting in the foreground with a 0 priority :D
 

jabberwocky127

Senior Member
Dec 25, 2010
55
9
West Lafayette, Indiana
I thought that maybe it was killed already also, but I opened Messaging -> checked System Panel to ensure it was running -> ran the GScript (which failed as noted before) -> and checked System Panel once more and it was still running. Maybe I am crazy here..

I am using the "Lock messaging in memory" but "Messaging" process is still killed by the stock manager, is it still alive in some separate process? It certainly is not 0 priority in Foreground, still sitting in "Empty" at something generally over 4 priority.

I will probably just switch back to the previous build as all was well there, though I would like to be able to keep up with the newest features.

Thank you for the Busybox link, I will try that.
 

zeppelinrox

Senior Member
Dec 21, 2010
9,374
21,590
IN THE FREAKIN' OP
That's strange.
Maybe that setting needs a reboot?
I remember seeing messaging in content provider earlier and then I was actually surprised to see it in the foreground.
I actually checked to see if I still had the 97oom file in the init.d folder but it's not there.

But it should be immediate because if I uncheck Lock messaging in memory, it gets instantly killed.
I run it, check lock messaging again, and AMM shows it in the foreground group again.

Stderrs... now I dunno what's going on with that

GScript was working perfectly in stock Telus rom without stderrs after installing busybox (to get certain commands to work).
But in CM7, after updating busybox, stderrs all over the place.

Now I have to figure this out.. those stderrs are annoying as hell
 

mike-08

Member
Mar 17, 2011
34
2
You get that "directory nonexistent" error because the app was already killed so there is no PID anymore.

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.

I finally installed CM7 for the first time and RC4 at least does have the option to lock messaging app in memory.
It's sitting in the foreground with a 0 priority :D

What am I missing here? I'm looking at my CM7 Milestone right now with the "lock messaging app in memory" selected. And the messaging app is sitting in "background". Then I set the oom_adj value to -17 and a few minutes later messaging is gone. I'm starting to become desperate.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 44
    UPDATE: Try BulletProofing Apps with my latest V6 SuperCharger Script! Use the following link OR use the link in my signature :D

    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 :D

    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:
    Code:
    #!/system/bin/sh
    
    sleep 60
    
    PPID=$(pidof [B]com.estrongs.android.safer[/B])
    echo "-17" > /proc/$PPID/oom_adj
    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 :D

    You can also do this in GScript Lite with this:
    Code:
    PPID=$(pidof com.estrongs.android.safer)
    echo "-17" > /proc/$PPID/oom_adj
    This comes in handy for apps that don't load on bootup - just run a GScript for those apps :D

    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!
    4
    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.
    3
    No need to set a variable, just use back-ticks:
    Code:
    echo -17 > /proc/`pidof [B]com.estrongs.android.safer[/B]`/oom_adj
    Although that may be a little too complicated for some people to type in. Best to keep it simple I suppose...
    3
    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
    3
    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