Zepp, I manage to supercharge my One X but the settings back to original every time after reboot (50% Supercharged). I have to manually execute 99Supercharger.sh to get back 100% Supercharged, any other methods to avoid this??
You've to click on the script in SManager and choose "Run on boot" and "Run as root" (little symbols in the second row). Then click "Save" and "Close". I hope I didn't forgot anything. Restart your phone. I hope I could help.
Sony Xperia Arc S (BL unlocked) - My Custom ROM - Stock Kernel / LuPuS
obviously I'm talking about last version which is v6 RC8.2
In your script you have both options for novice users and for skilled ones, for example : one should select one of supercharge presets if he/she doesn't know how exactly slots work, or could customize each single slot if you know what you're doing with "customize".
Some of processes I'm talking about are almost always running in background in all phones : for example com.android.phone , com.android.mms, com.android.systemui. There should be also an option to include a preset to auto bulletproof mission critical well-known apps like phone or mms (we don't have to forget that an android phone is basicly a PHONE ) or some other presets which includes vending/finsky processes to have a more reactive marketplace/play store.
Another thing : it happened me to wrongly un-bulletproof all, I remember most of processes I want to bulletproof but the only way to add them back was to list all running processes (which in my phone takes a long time).
Well bulletproofing a set of apps for all users automatically wouldn't go over well... some low ram devices may gag if 2 or 3 apps get bulletproofed and prefer that it be stricly user choice though I do put a couple of suggestions.
Why did it take so long to list all processes... they get listed once and you can add however many apps without having to get it re-listed.
Re-SuperCharger does have the automatic restore of BPApps and all the files are backed up in /sdcard/V6*
The idea to add a Re-BulletProof_Apps is a nice idea so it's not a "hidden" feature of re-supercharger and I'll see about adding the deletion of apps one at a time from the hitlist.
It may need another menu tho
Quote:
Originally Posted by ferotakis
I'm finally Supercharget
Its somehow amazing and fix lot of batt drain on my mini . I explain this to myself with this memory things coz when phone use RAM in right way its drain less battery rather than Android itself RAM manager.
I notice when incoming call phone apk popup amazingly fast than before no delay at all.
I'm using kernel tweaks too result of which is instant sleep when screen of 0.o which is somehow amazing coz when I was not supercharged I have lots of kernel wakelok from apps who just sit on background and not let phone go into deep sleep.
And so on and soo on .... smooth , fast AMAZING!
I HAVE Q not for script , I got all the point of this coz last night I'm read all stuf inside of files and got what they are do on phone
My Q is how can I make shedule on fast engine flush ?
When I add it on script manager there is :
When ? - set time
How long? - set again time for when end
How may times? - there I'm lost what I must set there coz its like time setings not count i.e. 1 2 3 times o.O
For example :
I want engine flush run on weekly SAT on 01:00AM one time ! What I must enter for this to work ?
Ah.. I think it will do that by default if you only set the day and time.
It runs once and doesn't repeat unless you fiddle with the repeat options
Quote:
Originally Posted by paranoid2007
Does the bulletproof apps script take a hit on battery, as it checks OOM values every 30 seconds? If so, how can I disable the script, after I started it?
Do a test and let me know
To disable within the script you can goto option 17 and it will ask if you want to unbulletproof first.
Quote:
Originally Posted by Azwraith7788
Zepp, I manage to supercharge my One X but the settings back to original every time after reboot (50% Supercharged). I have to manually execute 99Supercharger.sh to get back 100% Supercharged, any other methods to avoid this??
Stock kernel? Then you're SOL or flash a custom rom/kernel. I assume you know about having script manager just run it automatically on boot tho.
There may be a guide in your device's forum as well.
Quote:
Originally Posted by Daniel D.
First of all: Thanks for this great tool! I thought ICS will lag and stutter on my Arc S and it'll be no fun to use it, but it's running fast even with 50% charged. I'll get the other 50% in the near future...
Criticism? Just a little bit: The first post is a hell of a mess. Please look at this tutorial, it's formatted for normal eyes . Don't use so many different types of font-sizes and colors - only for important things and use the same styles. It has so many interjections and links among some steps that you can loose the golden thread.
Keep up the good work and thanks for all this!
Yes I like that tutorial.
You see how I have the "saving as attachement" instructions big, red and underlined?
I ran the v6U9RC8.2 with the local.prop option, everything went fine and I'm 100% charged, but today I checked my local.prop and I noticed that the MEM and ADJ options weren't replaced correctly. To be more precise, the ADJ ones were (default ones disappeared and there were only the ones in the #charger# space), but at the beginning of the file there are still the default MEM ones uncommented, while below there in the #charger# space there are the new values. Doesn't this duplication cause a conflict by using certain values and ignoring others? Should I comment the default settings?
On a side note I noticed there are some tweaks in local.prop that are already in my buid.prop but with different values (such as the buffersize ones). Which ones are applied? Does the phone check local or build first?
And why did the buffersize values change, are they better than the old "4096,87380,256960,4096,16384,256960" ones?
The old MEM entries only get deleted if you select an option from 2-10.
If you only do grouping fixes and a launcher (11 - 13), it doesn't effect memory/minfree settings so it is left alone.
The other settings like buffersizes can be changed so the last ones that run are the ones that stick - the ones in local.prop since local.prop runs after build.prop.
MEM and ADJ settings cannot be changed so that's why supercharging works more reliably when using build.prop
The old MEM entries only get deleted if you select an option from 2-10.
If you only do grouping fixes and a launcher (11 - 13), it doesn't effect memory/minfree settings so it is left alone.
The other settings like buffersizes can be changed so the last ones that run are the ones that stick - the ones in local.prop since local.prop runs after build.prop.
MEM and ADJ settings cannot be changed so that's why supercharging works more reliably when using build.prop
But then why do you recommend using local.prop (that even gives a 25%) if build.prop is more reliable?
I didn't choose 2-10 because on my first run the script sort-of autodetected a possible setting for my ram (I have 512MB but only 300 available for the user) and I used the one suggested (and there WAS a minfree change unless I completely misunderstood the script) along with die-hard. Now in local.prop I have two different values for each MEM value and I don't know which ones are used, I thought if I deleted the default values with root explorer I could use the ones the script added below (which should be calibrated with my supercharge I guess).
But then why do you recommend using local.prop (that even gives a 25%) if build.prop is more reliable?
I dunno.
But it's the same reason why some devices bootloop when using build.prop
Quote:
Originally Posted by Mammt
I didn't choose 2-10 because on my first run the script sort-of autodetected a possible setting for my ram (I have 512MB but only 300 available for the user) and I used the one suggested (and there WAS a minfree change unless I completely misunderstood the script) along with die-hard. Now in local.prop I have two different values for each MEM value and I don't know which ones are used, I thought if I deleted the default values with root explorer I could use the ones the script added below (which should be calibrated with my supercharge I guess).
Oh ok so you did use a minfree setting.
Well run a minfree setting, immediately check local.prop to see if it gets cleaned. If so, reboot and check local.prop again.
Manually deleting the old ones is fine but obviously I'd like it to be automatic.
Ok I think the problem was because I had run the old update8 a week ago and I didn't clean before using the 9, because I checked the local.prop.unsuper (with default stuff) and in the "super" ones there were some duplicate entries even in the first section outside the script territory (the one enclosed in all the ###comments### stuff is the update9 not 8 right?). Anyway I manually removed the crap and no problems, so I'll just stick with this . Are there other "global" files to check along with the props?
Edit: Since I saw the unsuper version of the init.rc I checked it too and in the supercharger section I found again the usual MEMs and ADJs but with different values than the ones in local.prop! Waargh!
Edit2: and the "super" version of init.rc has again duplicates, default and supercharged (still with different values than prop), why do these settings have to be on every file? Please tell me this file is completely skipped by the phone because it's very huge to be modified manually
Edit3: and init.rc is also in "/" and not only in "/data/", there are too many D:
XDA Elite Recognized Developer AdamOutler is known … more
XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality. Are you a developer?