Develop Bugs

*OUTDATED* ROM porting for kaiser/vogue [Linux] NOOB friendly!

THIS IS NOW OUTDATED!!
It uses the old sqsh method WITH a rootfs. So if you're using the NoMoRootfs method, this won't work. Please use the already complete builds in the Kaiser/Vogue threads as they are working the best at this moment.
DISCLAIMER:
I take no responsibility for anything that may happen to your phone/computer. Use at your own risk.
PURPOSE:
This is for informational/testing purposes. And for people to stop asking, "can somebody port X rom!!! PLZ!!!"
PREFACE:
I made this as a quick tool to port ROMs from the Dream/Sapphire forums to work with our phones. It's a very quick and dirty script I threw together using bash, so there's probably some problems with it. This tool is simply designed to make a copy of the Dream/Sapphire ROM. Once you get the setup, it's really easy and you'll be porting like crazy.
I did this all on Ubuntu 9.10 so things might not work properly if you're using another distro.
THANKS:
All credit goes to the people that made this possible, in no particular order...
dzo, vilord, mssmison, zen, enatefox, pmos, jamezelle, craig0r, cyanogen, and so many more. If I forgot you, I'm sorry, but you know if you helped in some way.
THE SETUP:
1) Download this file
2) Extract the folder to your desktop. Then copy and paste the following code into the terminal:
Code:
sudo mv -f $HOME/Desktop/Android/genext2fs /bin/genext2fs; sudo chmod 755 /bin/genext2fs; sudo dpkg -P squashfs-tools; sudo dpkg -i $HOME/Desktop/Android/squashfs-tools_3.3-7_i386.deb; sudo rm -r $HOME/Desktop/Android/squashfs-tools_3.3-7_i386.deb; sudo chmod 777 $HOME/Desktop/Android/*.build.script
3) Now go into synaptic package manager, search for squashfs-tools, select it and under Package, check Lock Version so that way it won't try to update.
4) Now cruise over to the Dream android development forum or the Sapphire android development forum and download the ROM you would like to port. Place the zip file in the Android folder. (no need to rename)
5) Place any .apk's you would like built into the system in the Apps folder.
ADVANCED SETUP:
If you would like to tweak the system before building, open the script in a text editor and you'll find a line to uncomment that will halt the script until you are ready.
HOW TO RUN:
Either run the script from a terminal
Code:
./$HOME/Desktop/Android/HERO.build.script
or
./$HOME/Desktop/Android/Donut.Build.script
Or double click and Run in Terminal
You will get a prompt for your password to use the sudo command. THIS IS NOT SAVED ANYWHERE OR MAGICALLY SENT TO ME. It is just to get the system.sqsh setup for you to use.
You will now see a Donut/Hero folder inside the Android folder. Inside that will be a nice little system.sqsh with the date ready to boot!
*Rename to system.sqsh when you put on your SD card*
Grab the latest basefiles from vogue-android and you're good to go.
~~~~~~ To get an output of what's happening run in a terminal as described above but add " > build.txt" and you'll see a txt file in the Android folder. ~~~~~~~
CHANGING SYSTEMS:
If you want to port a new rom, replace the .zip.
UPDATES:
1) Download the updates from HERE
2) Extract to the Android folder overwriting if necessary.
3) Copy and paste the following code into a terminal:
Code:
sudo chmod 777 $HOME/Desktop/Android/*.script
CLEANUP:
If you follow the advanced setup and/or accidentally closed the terminal before the build finishes, run the cleanup script. This will unmount everything that might be mounted and delete all folders that are made during the process.
DOWNLOADS:
If you're too lazy or just want a quick link:
Main "Android porting" folder
Updates

Input, testers, bugs, and tweaks to the scripts are appreciated!
FAQ:
Why does my system.sqsh not work?
Most likely cause is that you're not using the correct version of squashfs-tools. You'll have to find version 3.X for the distro you're using. Version 4.X will NOT work!!!
When I try to boot a system.sqsh I just made I keep getting something about android power wake locks. WTF?
You're probably trying to port an eclair or cyan ROM. These don't work at the current state. Hopefully soon I'll get these working.
Will update more when they arise.
CHANGELOG:
11-27-09:
-Created a cleanup script in case the terminal is closed during the build process.
-Bug fixes in Donut and Hero scripts
11-24-09:
-Added an Apps folder for apk's you want built into the system.
-Bug fixes in scripts
11-22-09:
-Combined everything needed into a zip file
-WAY easier to setup
11-20-09:
-Added feedback to make more user friendly
-Append time to system.sqsh

loserskater said:
Input, testers, bugs, and tweaks to the scripts are appreciated!
Click to expand...
Click to collapse
Will try today... Downloading
Tried and working. Had to change the script for it work with ubuntu version that i use. Thanks this is really great

garynsa said:
Will try today... Downloading
Tried and working. Had to change the script for it work with ubuntu version that i use. Thanks this is really great
Click to expand...
Click to collapse
What did you change?
Glad to see it's working.

loserskater said:
What did you change?
Glad to see it's working.
Click to expand...
Click to collapse
hI
For some reason I cannot use -a in the genext2fs command. Had to remove that..
One of the Donut is working. Couldnt get the Cyanogen build working . Struggling with hero build also.
Will try again in the next couple of days and post results.
Thanks

garynsa said:
hI
For some reason I cannot use -a in the genext2fs command. Had to remove that..
One of the Donut is working. Couldnt get the Cyanogen build working . Struggling with hero build also.
Will try again in the next couple of days and post results.
Thanks
Click to expand...
Click to collapse
Make sure you use the genext2fs that I referenced.
That one works with -a and might take care of some issues. try that and see if it works.

Updated script to now move system to a Hero or Donut folder.
Working on the cyanogen build now...
EDIT: Here's a cyanogen script that gets it to boot, but sits at a black screen. I haven't had much time to test it so it might boot further than that if you leave it. If somebody wants to test this out or tweak it in some way go for it.
It uses the donut.sqsh in the Android folder so you shouldn't have to do anything with it except make it executable.
EDIT 2: Still working on cyan builds... that script didn't work.

great job i like to see stuff like this to motivate people!!! also note this will work with any donut or hero build from the sapphire forum

jamezelle said:
great job i like to see stuff like this to motivate people!!! also note this will work with any donut or hero build from the sapphire forum
Click to expand...
Click to collapse
Good point, forgot to mention that. Updated first post.
I'm hoping it will help people start to learn to tweak system's. But I have a slight feeling wer're going to start seeing a lot of "MLIGN/DWANG/etc's Android Rom" threads from random people.

Hi
Was able to port the DWANGs build using your script. Thanks a lot for making life this simple. Howev3er, hero build is still not working. Tried your genesxt2fs. Is it possible to get the links to correct base hero version to use? I tried magic and normal version. It keeps giving me black screen and doesnt completely boot. I think the base hero version is not the right one i am using
Thanks

OK, I think I figured out the problem. The apps folders weren't copying over from the data folder to the system folder correctly. Testing now, and will update first post with new scripts.
EDIT: Finally got the Hero builds working correctly. You should still be able to use any hero.sqsh.

loserskater said:
OK, I think I figured out the problem. The apps folders weren't copying over from the data folder to the system folder correctly. Testing now, and will update first post with new scripts.
EDIT: Finally got the Hero builds working correctly. You should still be able to use any hero.sqsh.
Click to expand...
Click to collapse
Hi
The new script is great.. I was able to get the hero to boot I still have 2 check a few thing willl post later in the night with more
Thanks a lot

garynsa said:
Hi
The new script is great.. I was able to get the hero to boot I still have 2 check a few thing willl post later in the night with more
Thanks a lot
Click to expand...
Click to collapse
Glad to see its working. Thanks for the feedback!

Most things working
Hi
was able to get the hero ported and a few things worked
1. Calls
2. SMS
3. Wifi (getting ips)
4. Working with partition rootfs (speed quite great with this)
Not working
1. Camera
2. GPS
I am using he ION build to build the hero roms (based on the inputs of Zen). May be I need to use another hero rom for the camera to work? I recommend that the links to the recommended build to be used as template (donut, hero...) be updated on the first thread to make it easy for others to have a single starting platform

garynsa said:
Hi
was able to get the hero ported and a few things worked
1. Calls
2. SMS
3. Wifi (getting ips)
4. Working with partition rootfs (speed quite great with this)
using u
Not working
1. Camera
2. GPS
I am using he ION build to build the hero roms (based on the inputs of Zen). May be I need to use another hero rom for the camera to work? I recommend that the links to the recommended build to be used as template (donut, hero...) be updated on the first thread to make it easy for others to have a single starting platform
Click to expand...
Click to collapse
If using a hero.sqsh doesnt fix the problem it sounds like it might be the rootfs (probably not copying over correctly). Ill take a look at it when I get home and update the first post with hero/donut.sqsh's.
Im also thinking about combing the 2 into just one script and youll be able to just type which build you want when you run it. What do you think? Or is the 2 seperate scripts more convenient?

loserskater said:
If using a hero.sqsh doesnt fix the problem it sounds like it might be the rootfs (probably not copying over correctly). Ill take a look at it when I get home and update the first post with hero/donut.sqsh's.
Im also thinking about combing the 2 into just one script and youll be able to just type which build you want when you run it. What do you think? Or is the 2 seperate scripts more convenient?
Click to expand...
Click to collapse
Personally i prefer the separate scripts mainly because each requires a different base templates. However if you prefer to combine them may be have sub-folders within the main so that the work happen for each port within the sub-folder.
Few suggestions if you like (please ignore if not correct.. being a non-programmer of linux I can be a bit off )
1. Let the folder names be requested at start and use them
2. If possible to put in a log of the run to check if there were issue or not (because i use double-click to run the script sometimes there is a problem that i face if i dont watch the window. for now i have put some waits to check the errors. Had this issue while testing to port one)
If I can help (except on coding as I dont know it.. generally change the script just enough to work... )
Queries/questions
1. Is there a way to test the build on the comp itslef rather than to keep booting on the phone (takes a lot of time and the phone is not usable all that time...)
Thanks for all the work

garynsa said:
Personally i prefer the separate scripts mainly because each requires a different base templates. However if you prefer to combine them may be have sub-folders within the main so that the work happen for each port within the sub-folder.
Few suggestions if you like (please ignore if not correct.. being a non-programmer of linux I can be a bit off )
1. Let the folder names be requested at start and use them
2. If possible to put in a log of the run to check if there were issue or not (because i use double-click to run the script sometimes there is a problem that i face if i dont watch the window. for now i have put some waits to check the errors. Had this issue while testing to port one)
If I can help (except on coding as I dont know it.. generally change the script just enough to work... )
Queries/questions
1. Is there a way to test the build on the comp itslef rather than to keep booting on the phone (takes a lot of time and the phone is not usable all that time...)
Thanks for all the work
Click to expand...
Click to collapse
I'll try to make the script more user friendly with prompts if something doesn't happen correctly. And also work on naming folders.
But first I want to figure out the camera/gps issues...
There isn't a way to boot it on the comp that I know of. I'll upload blank data.img's for each build so that they'll boot faster but other than that I think moving to SD Card and booting is the only way. But once all these bugs get sorted out, you won't have to do it as often!
EDIT: Which folders would you like to name? Just where the system.sqsh gets stored?

loserskater said:
I'll try to make the script more user friendly with prompts if something doesn't happen correctly. And also work on naming folders.
But first I want to figure out the camera/gps issues...
There isn't a way to boot it on the comp that I know of. I'll upload blank data.img's for each build so that they'll boot faster but other than that I think moving to SD Card and booting is the only way. But once all these bugs get sorted out, you won't have to do it as often!
EDIT: Which folders would you like to name? Just where the system.sqsh gets stored?
Click to expand...
Click to collapse
Hi
Thanks for the answers. For me it should be both (but the starting folder is main. Other can be a sub-folder like u have now to be renamed as choice)

garynsa said:
Hi
Thanks for the answers. For me it should be both (but the starting folder is main. Other can be a sub-folder like u have now to be renamed as choice)
Click to expand...
Click to collapse
Are you referring to the Android folder? Or just a folder where everything is kept when it runs?

loserskater said:
Are you referring to the Android folder? Or just a folder where everything is kept when it runs?
Click to expand...
Click to collapse
Android folder... but its not a big deal as one can easily change it while startign the script

Howto make a permanent change to $PATH?

Is there a way to make a permanent change to the $PATH variable to place /system/xbin ahead of /system/bin? I found /init.rc when the phone is booted, but obviously I can't make changes to that yet. When booted into recovery, I can't find the same file to edit it. The /init.rc file is specific to the recovery image at that point.
Basically, I have busybox installed in /system/xbin and want it to override the /system/bin apps. I do not want to install busybox in /system/bin.
Any help would be appreciated. Thanks!

are you trying to export a path? if so it would go something like
export PATH=$PATH /system/bin
or you can
PATH=$PATH /system/bin
export PATH

B-dub25 said:
are you trying to export a path? if so it would go something like
export PATH=$PATH /system/bin
or you can
PATH=$PATH /system/bin
export PATH
Click to expand...
Click to collapse
He's trying to make it so he doesn't have to reset the $PATH variable every time. I'm assuming you are currently just using something like.
export PATH=/system/xbin:/sbin:/system/sbin:/system/bin
every time you enter shell. The way I would do it is by editing the init.rc as you stated, however it doesn't stick on the incredible, also as you stated.
The only thing I can recommend is making it a shorter PATH to type. You could just enter
export PATH=/system/xbin:$PATH
for example, and that would accomplish the same thing with less typing.
The only other way that I know of would be to make a start-up script, not sure how to accomplish this outside of init.rc however. In linux I would add it to the bash_profile or something similar. Not sure how to do it in android...

Not only for shell, but I'd like to be able to do it for installed apps as well, such as OpenVPN. Ah well, just have to wait for full root unlock.

This is done in the ramdisk. You can actually do this yourself. You need to extract the boot image, break it apart into the ramdisk and kernel, alter the init.rc file, package it back up and then flash it back to your phone in recovery.
Even if we get the nand unlocked, you will still need to do this since the init.rc recreates itself from the ramdisk during each boot.
If you are using a custom ROM, just request the dev to do this.

ihtfp69 said:
This is done in the ramdisk. You can actually do this yourself. You need to extract the boot image, break it apart into the ramdisk and kernel, alter the init.rc file, package it back up and then flash it back to your phone in recovery.
Even if we get the nand unlocked, you will still need to do this since the init.rc recreates itself from the ramdisk during each boot.
If you are using a custom ROM, just request the dev to do this.
Click to expand...
Click to collapse
Thank you kindly, didn't know where those files were kept. Interesting how that works, so basically the phone works like a hardware chip, where the main parts of the OS recreate themselves from ROM, similar to firmware... I like it... prevents corruption I suppose.
Out of curiosity (I've never made a ROM, and therefor never packaged the boot image), is it packaged as a tarball? Or do you require ADB to extract? If you don't want to answer, I can probably track it down somewhere.

It's a bit more complicated than that. Take a look at this link. I'm sure there are other ways, but I would recommend only doing this in some flavor of Linux like Ubuntu.
HOWTO: Unpack, Edit, and Re-Pack Boot Images

ihtfp69 said:
It's a bit more complicated than that. Take a look at this link. I'm sure there are other ways, but I would recommend only doing this in some flavor of Linux like Ubuntu.
HOWTO: Unpack, Edit, and Re-Pack Boot Images
Click to expand...
Click to collapse
Cool link. Thanks.
But yea, pretty much seems to be that simple, Just a gzip (zip) and tarball (cpio). The only thing I wasn't expecting was stripping out the 2k header with a hex editor, but I think I'll try using the scripts found through that link to do that, not that I couldn't do it by hand... but I'm lazy...
Thanks again.

[Q] SU not working

I am just about to release my new barebones build with a lot of new features but one thing is killing me. I cannot get superuser to work anymore with the latest build and the latest kernel. Rogue tools won't overclock without SU working and that just totall kills the speed of my build =(. The build is based off scoot's release 5 and I am using the latest kernel with and without the module update SU is unaffected. Everything else works though.

What have you changed from the build i sent you that might effect it? Does it work for you with the original build? Things to check are the sysinit.rc, make sure it calls userinit.sh on startup, and also check your userinit.sh in the /bin directory and make sure the su fix is still present in the file Otherwise, try opening the super user app and downloading the latest su binary file, if it fails to install then you most likely have partition permission issues.

I did edit userinit to enable the odex script. I am gonna check that now.

Ok I am pretty sure that was it. how do I add this line to userinit to have it be proper then? /system/bin/odex.sh

aceoyame said:
Ok I am pretty sure that was it. how do I add this line to userinit to have it be proper then? /system/bin/odex.sh
Click to expand...
Click to collapse
You'd need to put it in sysinit.rc like this :
service odex /system/bin/odex.sh

So put that line right at the end then? Or is there a special format it has to go in. Sorry, I have just never had to edit this particular file before lol.

aceoyame said:
So put that line right at the end then? Or is there a special format it has to go in. Sorry, I have just never had to edit this particular file before lol.
Click to expand...
Click to collapse
At the end is fine, you will see some similar lines in there, you may want to add some options such as :
console
user root
oneshot
I don't know what the structure of the odex script is so i don't know which options you will need to get it to run properly but these are the most likely, just experiment and see

I've always put it at the end, after the su fix just as "/system/bin/odex.sh" and nothing else. What does service do? will it run it continuously or just with different permissions?
I would say its more likely that something's gone wrong while you edited userinit.sh, and now it can't be executed.
did you edit it in windows? you may have /n/r line endings now instead of /n
if you did it in linux it may be a permissions problem

fixed! I used the userinit from my old barebones. Something changed in the update. The two looked totally different.

[HOW TO][MOD] V6 SuperCharger Script

Hi all,
I own no credits to this mod/script, it's all put together by zeppelinrox, Thanks go out to him for this! Orginal thread can be found here.
http://forum.xda-developers.com/showthread.php?t=991276
This is the first post of this kind I have ever made, so it might not be that good, or any help at all, but for those who want to try this script for the first time, I shall try my very best to explain how to do so.
I had been running ROMS for my Nexus with the V6 SuperCharger built in, and decided to see if it'll run well on our humble little Tabs. And indeed it does, it could be a placebo of course, but I seem to notice a good difference.
First, there are a few requirements in order to use this script :-
You NEED to be Rooted, in order to do this (if you aren't already) you could try the excellent Quick and Easy Root Script by the genius Crossix http://forum.xda-developers.com/showthread.php?t=1472521
Download and Install Script Manager from the Market
https://market.android.com/details?id=os.tools.scriptmanager
You also need to have BusyBox installed for the script to be run, I suggest installing the Script attached to the above V6 SuperCharger thread (even if you already have BusyBox installed to avoid errors). Simply scroll to the bottom of the thread and download the file named "busybox_v1.19.3_installer_script_wraithdu.zip"
To install this version of BusyBox navigate to where you saved the ZIP file, if on the Tab it should have downloaded to "/mnt/sdcard/Download", extract it using your file manager, I use ES File Explorer. Then open Script Manager and navigate to the extracted folder, find the script that should be called "busybox_v1.19.3_installer_wraithdu.sh", open this and select the "su" icon, make sure it is selected as a script and not executable.
To Run the Script:-
Scroll to the bottom of the SuperCharger thread and Download the file named " V6_SuperCharger_for_Android-update8.sh.txt" Navigate to where this file is downloaded, if on the Tab it should have downloaded to "/mnt/sdcard/Download", rename it using your favourite file manager, usually via a long-press to "V6_SuperCharger_for_Android-update8.sh"
Then open Script Manager and navigate to the script, open it using script manager, again taking care to run it as "su" as a script not an executable. The script should Run and prompt you for an option numbered 1-17. I chose Option 2, which is Aggressive Level 2 and noticed a good improvement, you can of course opt for the balanced options of 3 or 4. To input a number touch the screen and the on screen keyboard should pop up, hit a number and enter it.
The Script Should run and then prompt you for another option, don't choose another one just yet.
If you are running the excellent build.prop by Crossix, Icewyng et al, it is recommended to disable the device keeping Launcher in memory for the script to run properly. To do this, open Root Explorer, navigate to the build.prop, in "/system", and open it in the text editor. Scroll to the part of the prop file that begins "store launcher in memory" and change the below string to "ro.HOME_APP_ADJ=0"
In order for this to be a persistent change to how RAM is managed on our Tabs, a script has to be set up to be run at boot. To do this, in Script Manager, navigate to "/data" and open the script named "99SuperCharger.sh", and check the boxes of "su" along with "boot" to run it at boot.
After you have followed these steps reboot your Tab and you *should* see a snappier Tab
Please be aware that this is the very first HOW TO I have ever written, and it will probably be inaccurate and crap. So, please, feel free to correct my errors and I will try to help running the script.
Yours,
Toyface

Awesome scripts. Im going to give it a try here in a bit and see if there is a difference in performance.

Could someone confirm if this really works?

I just did this and have notices an improvement but do follow instructions carefully
Sent from my A500 using xda premium

I can't download the update 8 sh.txt file it just opens it in my browser

I used taptalk to download it it worked great and is still working its magic
Sent from my A500 using xda premium

Super huge improvement. Thank you!

rando152 said:
I can't download the update 8 sh.txt file it just opens it in my browser
Click to expand...
Click to collapse
Which browser are you using? If chrome on the PC, try a right click and save as a txt file and rename it as a file ending .sh
Sent from my A500

Thanks for all the cool info. Using info I found in sin threads Skype seems to stay running for hours now instead of just 15 Minutes.
Sent from my modified A100 using Tapatalk and SlideIT keyboard.

so far so good.
Just had time to get this installed. So far it seems to be a bit snappier. Wish i had thought to benchmark first. Grrrr....

I think this should be in the dev section, I might ask to have it promoted... Good Work!

Frankly the whole you cant modify his script deal is a HUGE turn off. I understand him wanting credit for his hard work, BUT wth. I'll stick to safer things.
EDIT: Forget what I said I completely miss understood what he says in his post. He says
"Personal Use: You may tweak the V6 installation script (leaving credits intact) to your own personal liking as long as it is NOT redistributed in any way."
His autostart script script looks very handy. I was considering trying Gscript already here is a new reason hehe.

NoSudo said:
Frankly the whole you cant modify his script deal is a HUGE turn off. I understand him wanting credit for his hard work, BUT wth. I'll stick to safer things.
EDIT: Forget what I said I completely miss understood what he says in his post. He says
"Personal Use: You may tweak the V6 installation script (leaving credits intact) to your own personal liking as long as it is NOT redistributed in any way."
His autostart script script looks very handy. I was considering trying Gscript already here is a new reason hehe.
Click to expand...
Click to collapse
I can see why he doesn't want redistributables floating around, even with the open source (something I feel very strongly about) nature of the forum.
All I wanted to do was spread the word, maybe help along the way, if I've done this then I'm happy
Sent from my Nexus S using xda premium

NoSudo said:
His autostart script script looks very handy. I was considering trying Gscript already here is a new reason hehe.
Click to expand...
Click to collapse
You can also auto start scripts without having to use script manager or any other scripting program by calling them from within install-recovery.sh (see my sdswap mod).
For example if you had a script /data/app/supercharger.sh
in install_recovery.sh you'd add a line sh /data/app/supercharger.sh

crossix said:
You can also auto start scripts without having to use script manager or any other scripting program by calling them from within install-recovery.sh (see my sdswap mod).
For example if you had a script /data/app/supercharger.sh
in install_recovery.sh you'd add a line sh /data/app/supercharger.sh
Click to expand...
Click to collapse
Cool. I have re-written another version of my hulu script in .sh and set it up to be able to run in a normal verbose mode, or to accept "silent" as a command line argument to redirect output to a lhulu.log file instead to better allow for the option of running at startup like a cron entry or what ever our allowed methods are on android.(like the one you just referenced, thanks) I'm planning on playing with it a little to figure out the best and easiest method. Then repost the updated version that can be a semi permanent fix.

NoSudo said:
Cool. I have re-written another version of my hulu script in .sh and set it up to be able to run in a normal verbose mode, or to accept "silent" as a command line argument to redirect output to a lhulu.log file instead to better allow for the option of running at startup like a cron entry or what ever our allowed methods are on android.(like the one you just referenced, thanks) I'm planning on playing with it a little to figure out the best and easiest method. Then repost the updated version that can be a semi permanent fix.
Click to expand...
Click to collapse
install-recovery.sh won't work for the hulu lib, sometime after that script is loaded all the apks libs get extracted for whatever reason. Unless you put a wait in there for the prop sys.boot_complete or something like that. Might also need to use busybox run-parts for a seperate init.d script, not sure if the wait would actually stop the rest of the boot process.

It should be fine, install_recovery is called really late in the boot process you're right about putting the waits in, if you look at my swapscript you'll see the amount of time I used to get it to work (and it does not pause the other processes).
Sent from my MB860 using XDA App

crossix said:
It should be fine, install_recovery is called really late in the boot process you're right about putting the waits in, if you look at my swapscript you'll see the amount of time I used to get it to work (and it does not pause the other processes).
Sent from my MB860 using XDA App
Click to expand...
Click to collapse
It's not as late as I previously thought myself. dmesg won't work at that point and getting a logcat from there you'll see it's the start of the system log just when vold starts up. Which is why you need a few sleeps in your script. Using it was my second attempt at 2nd-init, which wasn't possible until after my first bootloop, the boot animation starts later but also before the libs are replaced.
For hulu I've just been running a gscript after a reboot because of this, at least until I find a different solution.
Anyway install-recovery is the perfect spot for any kind of kernel tweaks and also SuperCharger.
@toyface sorry for being off topic

Sorry a little confused with the last part how do I navigate to /data in script manager?
Edit.. never mind. ma bad noob moment, couldn't for the life of me figure out how to get out of the mnt part of the directory.
Sent from my A100 using Tapatalk

[Script] Hollyname CM7 Build.prop Tweaks

Basically what this does is add a bunch of properties commonly added or adjusted in the build.prop that just makes everything better. I put this together to serve two purposes. The first is that although there are a few custom CM7 build.prop files floating around I never liked the idea of continuously using an old build.prop over what is now a multitude up updates and variants. A, because it shows incorrect or outdated information and B, maybe something new has been added or has been found to work better that will be missed by just swapping the file out. Before putting this together I found myself spending more time then I would have liked in notepad++ adding and adjusting lines in the build.prop after an upgrade or anytime after a system wipe. Second is that I think my Kindle runs pretty dam smooth in comparison to friends and family members who often ask if I can make their Kindle perform more like mine so not only does a script at boot save the time of editing all their build.prop files I would like to think these values and additions work well. Had originally planned on adding these to an init.d script I’m working on but can’t figure out a way that by including a line already present in the build.prop does not result in me needing to boot into recovery and swap out the script by mounting system. I’m sure ill figure it out but until then this method works just fine. Also trying to figure a way of making this script trick the market into thinking the device is a Galaxy Tab. Not there yet but pretty sure it can be done. Anyhow enough with my justification for the need of yet another set of build.prop tweaks for CM7.
Almost forgot, This is of curse at your own risk and I am not responsible for any damage done to anything you own.
Instructions
Download Hollyname Script and place on SD-Card
http://www.mediafire.com/?z964ni67vuy2nea
Install Script Manager from the Market
Open Script Manager and Select Hollyname Script
Select SU, Boot & Save
Reboot
One of the other nice things about using this method to apply these tweaks is that they are not permanently added to the build.prop and can be removed by either deleting the script from the SD Card or UN-selecting Boot in script manager.
If not sure everything was done correctly run “getprop” in either ADB or a Terminal and all current properties will be displayed. The list should include the properties below.
List of Tweaks Include,
debug.sf.hw 1
wifi.supplicant_scan_interval 180
dalvik.vm.heapsize 64m
persist.sys.ui.hw 1
ro.max.fling_velocity 12000
ro.min.fling_velocity 8000
ro.ril.disable.power.collapse 1
pm.sleep_mode 2
windowsmgr.max_events_per_sec 150
ro.media.enc.jpeg.quality 90
media.stagefright.enable-player true
media.stagefright.enable-meta true
media.stagefright.enable-scan true
media.stagefright.enable-http true
net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
ro.kernel.android.checkjni 0
ro.kernel.checkjni 0
debug.performance.tuning 1
video.accelerate.hw 1
dalvik.vm.dexopt-flags m=v,o=y
persist.adb.notify 0

Some irrelevant entries
Thank you. Unless your Kindle Fire has a camera and GSM radio you might rethink the following four items, as their inclusion does not inspire confidence:
ro.media.enc.jpeg.quality 90
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
If you have such a device, can I have it?
Sent

chairshot215 said:
Had originally planned on adding these to an init.d script I’m working on but can’t figure out a way that by including a line already present in the build.prop does not result in me needing to boot into recovery and swap out the script by mounting system. I’m sure ill figure it out but until then this method works just fine.
Click to expand...
Click to collapse
Here's one way to do it in an init.d script:
busybox sed -i 's|windowsmgr.max_events_per_sec=.*|windowsmgr.max_events_per_sec=150|' /system/build.prop
busybox sed -i 's|wifi.supplicant_scan_interval = .*|wifi.supplicant_scan_interval = 300|' /system/build.prop
You might also find ease in making a .txt file with your edits ready to copy and paste into your build.prop file after a new flash. You might save yourself some hassle this way. Don't worry about doubling up on entries; the last instance of a value will override the previous instance. So, while your build.prop might have:
wifi.supplicant_scan_interval=60
something.use.situation.fun=7
wifi.supplicant_scan_interval=300
300 will win. Doesn't it always?
Sent from my mind using magic

manchucka said:
Thank you. Unless your Kindle Fire has a camera and GSM radio you might rethink the following four items, as their inclusion does not inspire confidence:
ro.media.enc.jpeg.quality 90
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
If you have such a device, can I have it?
Sent
Click to expand...
Click to collapse
Sorry, thought "ro.media.enc.jpeg.quality 90" was the value for displaying a Jpeg and not actually taking the image. Never mind, checked a few sites and this line does pertain to displaying images and not taking them. The other 3 I usually use with my phone and always see them together when looking at other scripts so figured the worst including them all could do is that they would just not do anything. Should probably just remove them anyhow if for no other reason than to avoid sarcastic alpha smart person in the room comments like "If you have such a device, can I have it?” It's a good one though as far as those kind of comments go, gave me a laugh anyway. Still don't understand why their inclusion would be any cause for concern?
Thanks for this though, I think I see what I may have been doing wrong.
manchucka said:
Here's one way to do it in an init.d script:
busybox sed -i 's|windowsmgr.max_events_per_sec=.*|windowsmgr.max_events_per_sec=150|' /system/build.prop
Click to expand...
Click to collapse
You might also find ease in making a .txt file with your edits ready to copy and paste into your build.prop file after a new flash.[/QUOTE said:
This is what I had been doing previously but then also had a few other Tweaks I have been using in an init.d script and had originally just planned on adding these to that script. Either way I just figured I could learn something new and at the same time avoid the need of having to paste in the lines as after each new flash the script would still be on the sd-card and script manager would apply the values with out needing to do anything extra after flashing. At least I had thought it was a good idea.
Click to expand...
Click to collapse