Very weird result. If you wanna take a look at it lemme know. I'll post the prop script alone.
Sent from my LG Optimus L9 running PenberRom5 using Tapatalk 2
Sent from my LG Optimus L9 running PenberRom5 using Tapatalk 2
[TWEAKS][CWM+AROMA] Codename LightingBolt [2013DEC21]
- Thread starter leolawliet
- Start date
Oops, my mistake, you're right (that is the proper opener when running a shell from recovery...the line I used is for running a shell when the system is online)...was not thinking (what's new right?)...the opening line should be as you noted: #!/sbin/sh
Not totally sure, but maybe my bad opener is why you got such odd results (dunno if ya noticed, but it looks the the build.prop files are different formats for some reason). Did you use my bad opening line or your correct opening line?
Not totally sure, but it looks like you ran the script in ScriptManager, right? Maybe this explains the odd results.
Post your updater and prop scripts, maybe there are some typos or something given you got a syntax error...I am curious because, aside from that bad opener, I am quite certain the method I outlined should work...maybe the method I described is flawed I will do some testing.
===EDIT===
Okay did some first hand testing and made a zip with the correct opening line
...the method I described worked...not sure where your test went wrong, unless you used the bad opening line.Attached a screenshot as proof and attached the test zip I made so you can copy and paste from it if you want
.Also I was thinking, it might not be a bad idea to add something like this to the buildprop_additions script (before the part where you start making the actual additions, obviously):
Code:
if [ ! -f /system/build.prop.bak ]; then
cp /system/build.prop /system/build.prop.untweaked
fiEDIT#2 - Or you could get rid of the if statement and just use the cp command...this may actually be a better idea since the presence of build.prop.bak would imply that the build.prop currently in use has been modified.
Attachments
Last edited:
I'll try yours now, I'll post my prop script & updater script here.Oops, my mistake, you're right (that is the proper opener when running a shell from recovery...the line I used is for running a shell when the system is online)...was not thinking (what's new right?)...the opening line should be as you noted: #!/sbin/sh
Not totally sure, but maybe my bad opener is why you got such odd results (dunno if ya noticed, but it looks the the build.prop files are different formats for some reason). Did you use my bad opening line or your correct opening line?
Not totally sure, but it looks like you ran the script in ScriptManager, right? Maybe this explains the odd results.
Post your updater and prop scripts, maybe there are some typos or something given you got a syntax error...I am curious because, aside from that bad opener, I am quite certain the method I outlined should work...maybe the method I described is flawed I will do some testing.
===EDIT===
Okay did some first hand testing and made a zip with the correct opening line
Attached a screenshot as proof and attached the test zip I made so you can copy and paste from it if you want
Also I was thinking, it might not be a bad idea to add something like this to the buildprop_additions script (before the part where you start making the actual additions, obviously):that way it will make a backup for the user (if they don't already have one) just in case something goes wrong...it would also be good for you should you ever want to make an uninstaller zip.Code:if [ ! -f /system/build.prop.bak ]; then cp /system/build.prop /system/build.prop.untweaked fi
EDIT#2 - Or you could get rid of the if statement and just use the cp command...this may actually be a better idea since the presence of build.prop.bak would imply that the build.prop currently in use has been modified.
prop.sh
Your updater script looks good.
Guess the major problem, which I think explains the two build.props, was that bad opening line in the prop script...change it to: #!/sbin/sh
Also found one typo in the prop scrip, which I am pretty sure was the cause of that syntax error you got...change this:
Code:
busybox echo "# Rapid Boot Technology 1.1 (Reduces bootup time[B][U][COLOR="Red"])>>[/COLOR][/U][/B] /system/build.prop
Code:
busybox echo "# Rapid Boot Technology 1.1 (Reduces bootup time)[B][COLOR="Red"]" [/COLOR][/B]>> /system/build.propThanks for spotting that out, I'll try it out now.
Edit: I have no idea what I'm doing wrong, it's still a no-go
Edit2: I got a good feeling about the next update. I still can't apply the build.prop tweaks so that stays on the OP for now till I figure out what I'm doing wrong.
Last edited:
OP updated, please delete the older scripts from your init.d folder before applying the new ones to avoid any issues with conflicting scripts. Also updated the description a bit, and the list of terminal scripts. Check first page for details.
- Removed bootanimation
- Removed no-frills CPU
- Deleted 34dalvikcalc & 05fsyncdisable & 08IO
- Added RNGD & Cache_Cleaner & 01_darky_zipalign & 03sqlite_optimize
- Also added a renice script that helps open some common system apps faster, but it consumes a bit more ram
- Added tweaked ramscript
That's pretty much it for now, I'm still trying to figure out what went wrong with the prop script.
Thanx & i appreciate your work. Keep on to make this mod balanced..
---------- Post added at 11:44 PM ---------- Previous post was at 11:41 PM ----------
And plz tell how to copy paste build.prop settings properly? Bcoz i tried but my device had stuck on boot. Where to paste the build.prop lines & how?
You need a file explorer like root explorer that grants root access. Open your build.prop as a text file and add the prop lines at the very bottom of your build.prop and save and reboot.
I'll show you.
Sent from my LG-P769 running PACrom JB 4.3 using Tapatalk 2
Attachments
Did you try my test zip? Did it work on your device? If it did maybe the issue is the updater binary because if you made those two changes from my previous post it should work.
Without more information there is no way I can help you determine the problem...post the actual zip you tested, I'll take a look at it.
I attached a zip, which should do two things: (1) it will make a backup of the the user's current build.prop named "build.prop.PrePemberEngine" located in /system; and (2) it will add all the tweaks from the prop script you posted. Note: I did NOT test this zip, but all I did was modify the BP_TEST zip, which I did test.
Feel free to use this as you see fit...no credits necessary...I was thinking you could offer it as a separate option, that way users who only want the scripts or who only want the build.prop tweaks can flash the desired zip and users who want both can just as easily flash both zips. IMO keeping them separate would be more user friendly.
No promises nor guarantees, but if you want, try flashing the attached zip it should add all the build.prop tweaks and make a backup of your current build.prop named "build.prop.PrePemberEngine" located in /system. Report your result.
Last edited:
How to uninstall??
Thanks for the Mod Bro
I have downloaded your MOD & will flash it in a flash but before that would you be able to provide a script/zip to uninstall the MOD??
Thanks for the Mod Bro
I have downloaded your MOD & will flash it in a flash but before that would you be able to provide a script/zip to uninstall the MOD??
I'll check it out when I get home, I'll post the zip I used too. I'm thinking it is the updater binary at this point, Pizza_Dox had the same problem.
Edit: here's the link.
http://d-h.st/9ol
I'll look it up and try to figure it out but for now make a backup and try the zip defiant07 posted, he beat me to it
Sent from my LG Optimus L9 running PenberRom5 using Tapatalk 2
Last edited:
Nice script but there are some different values for the same tweaks for example in S97ramscript there is:
echo "500" > /proc/sys/vm/dirty_writeback_centisecs
And in 20vmlt there is:
echo "200" > /proc/sys/vm/dirty_writeback_centisecs
Sent from Belgium using XDA premium app.
echo "500" > /proc/sys/vm/dirty_writeback_centisecs
And in 20vmlt there is:
echo "200" > /proc/sys/vm/dirty_writeback_centisecs
Sent from Belgium using XDA premium app.
Ah thanks for spotting that out, I'll just make the value on 97ramscript match on the next update so it doesn't make a difference.
And I think you have to add a zipalign file to xbin otherwise zipalign script doesn't works.
http://db.tt/2tR7z1MP
Sent from Belgium using XDA premium app.
---------- Post added at 01:57 AM ---------- Previous post was at 01:53 AM ----------
Sent from Belgium using XDA premium app.
http://db.tt/2tR7z1MP
Sent from Belgium using XDA premium app.
---------- Post added at 01:57 AM ---------- Previous post was at 01:53 AM ----------
I think 500 is the best value it's in almost every tweaks script 500 or 1000.
Sent from Belgium using XDA premium app.
The build.prop tweak you posted works as stated, I'll take your suggestion of keeping it separate from the engine tweaks. Thanks again
Oh. You thought my script was bull****?:sly:At least you are responsive and responsible in that you acknowledge and try to fix your problems
Regarding the build.prop stuff your OP states it's included (and I quote: "The tweaks included are listed below:")??? If you don't have the time to make a half decent, informative, and accurate OP, IMO you should wait and release the product when you do have the time...there's no rush, XDA will still be here tomorrow.
As @Pizza_Dox said 34dalvikcalc is totally flawed...it does nothing in Pizza Box too (which I looked at last night as well since you credited him). Do you know anything about bash/shell scripting??? Busybox version is irrelevant, I did not run any of your scripts (nor will I ever)...as I stated all I did was a 5 min skim, but just by looking at the code I can tell it is bad. If you cannot tell this code:is bad, you have no business releasing mod packages. What in this script leads you to believe it does anything productive??? Again try using debug.Code:#!/system/xbin/sh # The Dalvik Optimizer 1.0 by Pizza_Dox mem=785624; heapsize=0; dalvik_heapsize=0; dalvik_vm_heapsize="m"; setprop dalvik.vm.heapsize ; # XDA: http://goo.gl/xEdOa # Blog: http://androidpizza.blogspot.com/ # Email: [email protected]
As for cpuramcheck, you can really run that script??? I smell BS (unless maybe you have a magic rom of some sort???)...as previously stated, try actually testing before releasing. The major issue with this script is it is missing that good ole fashion required opening line - #!/system/bin/sh. So there is no way it will do anything for anybody (you included), lol. FAIL.EDIT - I was wrong...this script DOES function as intended...EPIC FAIL on my part.
Try actually learning some code instead of "borrowing" it all and you may avoid such issues :silly:.
Sent from my crappy ass phone
Yep must be binary...both the relevant scripts looked good in that zip...if you wanted to offer a third option and merge everything into one zip you should only have to replace the binary from your zip with the one from my zip...although flashing two zips ain't too much of a pita.
Nice, np manThe build.prop tweak you posted works as stated, I'll take your suggestion of keeping it separate from the engine tweaks. Thanks again
and sorry again :angel:Yep, although I never thought it was your mistake being that I never bothered to tracked down the original made by you; I was thinking he probably copied it wrong and missed the first line...ignorance is bliss, until it bites you in the ass and makes ya look like a fool, lol
. Guess I indirectly owe you an apology too...sorry man.I did a little bit of searching and found no answer, but maybe you can enlighten me - why do bin scripts not need to call a shell with the standard opening line (#!/system/bin/sh)?
Last edited:
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone