Hello!
So, some guys tested my bat-script and they reported that it works! So i create a new thread..
All you need is a java installation (i think jdk, becuase you need the jar binary) and adb! You have to edit the bat file and
set the 2 variables to the directory.
The other variables (sed, smali, baksmali, dexopt-wrapper) are in the package, so you shouldnt change it.
If anything necessary is not found, the script will not start!!
Attention: If you run the bat file, be sure your mobile is NOT IN STANDBY!! You have to be in normal mode (not recovery or sth) and the screen turned on!
So not in lockscreen/standby mode, because otherwhise SuperUser does not popup and ask for root-rights.
When you dont allow root-rights you will see a permission error during the script and this is bad (it will ask you 2-3 times for root rights).
I made this script, so everyone can look at the commands (not hiding inside an exe file which could do anything).
Here is the link: http://rapidshare.com/files/420586328/install_lockscreen.zip
Windows verion needs to be on rapidshare/filehoster, because i have put the sed binary + dll into it (you need it for windows and autopatching the .smali file)
Just download the bat script and edit it with an editor (notepad++ or jedit or just notepad) and set the ADB variable to adb.exe and JAVA_DIR to the JDK-directory (not including \bin - just the main-directory).
Tested successfully on my JM5 and some other user with JM8 and someone with JH2!
4 things todo (not for running the script, just for the future ):
1. create script for linux/mac os usage (shouldnt be so hard, but i have not so much time currently..)
2. auto-create an update.zip with the original android.policy.odex/.jar file for errors (because you cannot change this file if the phone cannot boot - su segmentation fault)
3. if /system/xbin/dd is not here or if it is missing the "conv=notrunc" option, the script should abort
4. create a version for deodexed mobiles/firmwares.
I dont have a clue, how to create an update.zip, so if anyone of you could give me a little help, i would be very happy
And i dont have a deodexed mobile, so someone should tell me the difference, so i can make a different script or the script should autodetect it.
Big thanx to Ateisti for found this solution: http://forum.xda-developers.com/showthread.php?t=779803
If you like my work you can buy me a beer (but you dont have to ): Beer via paypal
menu button fix included or not?
When someone would tell me what this is, then i can insert it in the script
Ateisti talk about it at the end of the first post of his thread
Found it
- By default, the menu button will also unlock the screen. To disable this behavior, you have to modify /res/values-hdpi-v4/bools.xml in /system/framework/framework-res.apk, and change the value of <bool name="config_disableMenuKeyInLockScreen">false</bool> to true. Can also be done by modifying code.
But, i have disabled WidgetLocker and just the AndroidLockscreen now..
I can hit so many times i want the menu button, the lockscreen will never be released..
I have JM5 (2.1). Maybe this is there different?
I will make on the weekend a linux version of the script and then i will also enable this feature..
thE_29 said:
When someone would tell me what this is, then i can insert it in the script
Click to expand...
Click to collapse
There is also a way to do this from the android.policy smali files. I did it on my UGJH2.
go into "android.policy\com\android\internal\policy\impl\LockScreen.smali"...
Do a search for "return v4" and change it to "return v6" (this should be within the method ".method private shouldEnableMenuKey()Z", closer to the ".end method" line.)
To add it to your script, have it change this at the same time as the other file you edit and bingo, no more menu button unlock....
didn't work here.
thank god you made a backup folder
JHJP8, not de-odexed.
Related
I was wondering if anyone thought about integrating a theme switcher with modified firmwares. I wonder if its possible without having to reboot to install a different skin.
possible!!
i wud thnk its possible bcuz its the same concept as the jf updater!! it wud just bring up a list of themes to choose from and u pic 1 thn it just does the auto reboot and the name change!! in theory it makes since but im not tht good of a dev. so i cud b wrong!! just gotta wait n c i guess!!
acejoker25000 said:
i wud thnk its possible bcuz its the same concept as the jf updater!! it wud just bring up a list of themes to choose from and u pic 1 thn it just does the auto reboot and the name change!! in theory it makes since but im not tht good of a dev. so i cud b wrong!! just gotta wait n c i guess!!
Click to expand...
Click to collapse
Ouch...my head. Your keyboard seems to be missing some letters.
For the OP, you would need to reboot to apply the update.zip, I don't believe it can be applied without the phone rebooting, even if an application was to do the "switching" for you.
it would be like winterboard in the iphone/ipod touch restart every time you change themes. But i dont mind if an app could do the hole process for me
why not?!?
why is it not possible without a reboot?
as far as i know the themes are only images overwriting the original images...
now only some one has to try it ^^
i found the "framework-res.apk" on my phone (ADP1) in /system/framework
now just cp "NEW-Themed-framework-res.apk" to /system/framework
and restart the home app...
or the app that uses these images .. i dont know when there are loaded ... if they are loaded already on boot we need a reboot!
is anyone brave enough to just force cp the theme file
shouldn't do any harm its linux so what ....
lad
ps probably i will -.-
sounds great in theory, and i like the last post about it being linux so who cares, we can always fix it. but personally i would prefer an app similar to the JFupdater app. the main problem with that is that someone (not me) would have to make sure that the server the app reads from always has the most updated themes, and with our devs posting 10 new themes a day and only getting more since RandumAccess has posted 10 himself in the last two days it would get to be quite a headache. i like both ideas, the app seems like the better one, but please let up know if you get the force cp to work, it might get us on our way
ok
dont try it !!!!!
i did it thru the terminal app and after copying i pressed the home button to see i f anything happend...
well yes ... it rebooted ... and it stuck at booting ...
fixing my phone now ....
JUST DONT TRY IT! ....
Doesent it work like openHome and Bettercut ?
just relink the icons with an app?
I liked a themes icons here but hated what they did with the bars so I just copied the /system/app/ apks to mine and it worked without a reboot. I guess you could just make a program that copies apks around but I'm thinking having themes stored in /data/themes and symlinking the apks would work better. What do you guys think?
DeadBody79 said:
Doesent it work like openHome and Bettercut ?
just relink the icons with an app?
Click to expand...
Click to collapse
i thought so...too
thats why i tried to overwrite them ... but it seems that ii's more complex...
but mabye if we place symlink / hardlinks into the theme package..
and link to a location with the new image (so we can change this image)
something like /data/framework/framework-res.apk/res/drawable
ok i played a little with symlinks and hardlinks
what we need are symlinks with an absolute path
we can copy (with cp -d ) these into the package...
i'll try that ...but it may take a while since i never singed a package...
lad
What if you used scripts to rewrite the data and auto save apply the theme then forclose or cause a light reset? I'm assuming the system would have to be completely rebooted for the textures to take effect!?
ok
i have a problem with signing ...(i am runing linux!)
i did everything according to http://developer.android.com/guide/publishing/app-signing.html
signing on the computer works and even the verification says "jar verified" on every apk that is in my package..
just when i want to update on my dream it says :
verifying update package...
E: No signature (58 files)
E: Verification failed
....
how can i find these unsigned files...?
edit:
ohh and you have to compress the zip via : zip -yr newZip.zip dir
to keep the symlinks
lad
The auto sign programs wont work on linux because that makes it much easier to sign the .apk files and the update.zip. I used to do it manually and it takes way more time than using the sign.bat.
ok
signing problem solved ...
i tried to sign with my private key and not with the "public-update.zip-key"
so i managed to update with the symlink .... and it didn't boot
i checked everything again ... the symlink is now a text file (no wonder android didn't like that....)
... but why?
first i thought that th proses of unzip is destroying the symlink ... but on my com the symlink are always kept
then i noticed when signing a new zip is made and that broke the symlink ....
for signing the update.zip and framework.apk i'm using :
java -jar signapk.jar publickey.x509.pem privatekey.pk8 <themeDir>update.zip <themeDir>newUpdate.zip
(well sort of...)
i will now try to "hack" the signing into my own zip
or does anyone know how to sign it without destroying the symlink?
lad
-.-.....
what i did ...
i copied the symlink into the drawable folder of framework...
i made a zip of framework ... i signed that zip
then i unziped it to copy the symlink again (this time into the just unziped folder)
then i touched (with touch) the symlink and made the timestamp the same as the signed zip
then i ziped that folder .... (it is now signed and has the symlink)
now i only needed to zip and sign the whole update.zip ....
(i unpacked both to see if the symlink was still there... it was!)
i copyed it on he android ... and updated succesful
...but then it didn't boot ..... -.-
now what...?
any ideas?
lad
ps i will try to symlink the whole framework-res.apk .....
edit: pps use at own risk
script for Resigning(use it as a nautilus script):
Code:
#!/bin/bash
#
#use as nautilus script
##########################################
#change to the dir where u have the "signapk.jar", "testkey.x509.pem" and t"estkey.pk8"
##########################################
androidModDir=/home/lad/projekt/android/AndroidMod
java -jar $androidModDir/signapk.jar $androidModDir/testkey.x509.pem $androidModDir/testkey.pk8 "$*" "$*".signed
exit 0
script for Verifying"dirty" (use it as a nautilus script):
Code:
#!/bin/bash
#
#use as nautilus script
export i=`jarsigner -verify "$*"`
zenity --info --title "JarVerifier" --text "Well the outcome is:\n $i"
exit 0
I understand every bit of what you're trying to do. As of right now its obvious that a complete reboot to install the update.zip may be needed to install each skin, but I wonder if you can just do a reboot without an update to rewrite over the previous files then the new files would load a different skin. It shouldn't be so hard since the G1 is like any other cpu or OS platform right!? Keep trying you're getting close to it "Lad!" I'm sure there are more people out there in the world that are willing to give you a helping hand in the process of making this all work out. =)
Idea
What if you just created something that asks which theme you want to use. It then opens something like a file manager with a theme directory list
/themes
-->/theme1
-->/theme2
-->/etc
you choose the theme you want. It asks if you want to backup your current update.zip and then copies the update.zip from the theme folder selected to /sdcard and then reboots and applies the update.
Is that possible. Or even if it just reboots and then you press the power + home key when it restarts and then !!! you have applied the new theme. This would allow you to add/remove themes as you see fit.
OK, here you go
Here is a script for gscript to automate theme switching!
http://forum.xda-developers.com/showthread.php?t=486486
Code:
echo "boot-recovery
--update_package=SDCARD:themes/aero/update.zip" > /cache/recovery/command
reboot recovery
I have all my themes located in /sdcard/themes and a folder with the name. So all you have to do is write scripts for each theme and just place a shortcut on the desktop. With bettercut you could make the icon very representative of the theme.
beagz said:
Here is a script for gscript to automate theme switching!
http://forum.xda-developers.com/showthread.php?t=486486
Code:
echo "boot-recovery
--update_package=SDCARD:themes/aero/update.zip" > /cache/recovery/command
reboot recovery
I have all my themes located in /sdcard/themes and a folder with the name. So all you have to do is write scripts for each theme and just place a shortcut on the desktop. With bettercut you could make the icon very representative of the theme.
Click to expand...
Click to collapse
Here is the original post to this thread.
flip0406 said:
I was wondering if anyone thought about integrating a theme switcher with modified firmwares. I wonder if its possible without having to reboot to install a different skin.
Click to expand...
Click to collapse
I guess we'll have to keep searching and testing things until we can get it all together...........
well, I thought this would help until someone can find a way without doing a reboot.
Until then, this was the easiest method I could find.
Hi guys,
Since there seems to be some demand for this kind of thing, I decided to post instructions on a mod I made a while back. This gives you the option of choosing between Samsung's GlassLock (i.e. the default TW lockscreen) or the stock keyguard of Android 2.1.
The method involves de- and re-compiling /system/framework/android.policy.odex, and you should have some basic knowledge of the tools involved (i'm not gonna spell out every step). Before beginning, take a backup of android.policy.jar and android.policy.odex (or preferably the whole framework folder). You should issue the commands in recovery mode.
Required tools: rooted SGS (I've done this only with JM2, and the code *might* need modifying for other roms, though I doubt it), adb, smali/baksmali, dexopt-wrapper, text & hex editor, winrar (or any jar editor).
Here we go:
1. Use adb to pull out /system/framework/android.policy.odex and other framework .odexes (required for de-odexing). Might be wise to backup the whole /system/framework/ directory at this point.
2. Use baksmali to deodex the file (java -jar baksmali.jar -x android.policy.odex -o android.policy). Baksmali will let you know if you are missing any of the framework .odexes.
3. Open LockPatternKeyguardView.smali and find the method getLockScreenMode()Lcom/android/internal/policy/impl/LockPatternKeyguardView$LockScreenMode;
4. Replace the contents of this method with the attached file getLockScreenMode.txt.
5. Save LockPatternKeyguardView.smali.
6. Use smali to compile the files back to classes.dex (java -jar smali.jar android.policy -o classes.dex)
7. Pull /system/framework/android.policy.jar, add the newly created classes.dex to it, and push it back to the device.
8. On your phone, do:
# cd /system/framework
# dexopt-wrapper android.policy.jar patched.odex /system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
Ouput should be:
--- BEGIN 'android.policy.jar' (bootstrap=0) ---
--- would reduce privs here
--- waiting for verify+opt, pid=3105
--- END 'android.policy.jar' (success) ---
9. You now have odexed the file into patched.odex. However, the signature of the file is not compatible with the other framework files, so you need to fix it. I think the proper way should be to re-odex all the framework files, but I haven't encountered any issues with just patching the signature.
10. Open the original android.policy.odex in a hex editor, and copy signature bytes from offsets 0x34-0x47 to the new patched.odex, and save it. Optionally, you can also do this on your device by issuing the command:
# dd if=original.android.policy.odex of=patched.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
Where if="..." is the original file, and of="..." is the file you want to patch.
11. Push the patched and hex-edited file to /system/framework/android.policy.odex and restore the original /system/framework/android.policy.jar.
12. Reboot and enjoy your good ol' keyguard
Some notes:
- If you want to revert back to Samsung's lock screen, just create a file called /data/local/enable_glass_lock ("adb touch /data/local/enable_glass_lock").
- By default, the menu button will also unlock the screen. To disable this behavior, you have to modify /res/values-hdpi-v4/bools.xml in /system/framework/framework-res.apk, and change the value of <bool name="config_disableMenuKeyInLockScreen">false</bool> to true. Can also be done by modifying code.
On a side note, the code for Smart Unlock (present in some Samsung phones) seems to be in there... it would be an interesting project to get that working
Great stuff, i've been waiting for someone to find out how to get rid of the glass screeen since first day.
Sadly i'm a real noob so it is useless for me.
Maybe someone can create an apk or a win program out of this.
thank you !
but could you explain it better ?
toca79 said:
Maybe someone can create an apk or a win program out of this.
Click to expand...
Click to collapse
+1 for an automated solution, provided method seems too hard for me.
Excellent post Ateisti! We need more of these advanced mods for SGS.
Ateisti said:
adb, smali/baksmali, dexopt-wrapper,
Click to expand...
Click to collapse
Could you provide links to this?
Or are those sw included in the Android SDK?
I want to do 6-step but I see:
Code:
C:\Users\Konrad>"C:\Program Files (x86)\Java\jre6\bin\java.exe" -jar "C
:\Users\Konrad\Desktop\smali.jar" android.policy -o classes.dex
android.policy\com\android\internal\policy\impl\LockPatternKeyguardView$LockScre
enMode.smali[0,-1] The file must contain a .class directive
What's wrong?
EDIT:
I've changed a wrong smali.
In step 10, how do i copy the signature bytes with my hex editor? I dont understand what offsets 0x34-0x57 is...
10. Open the original android.policy.odex and copy signature bytes from offsets 0x34-0x47 to the new patched.odex, and save it.
Click to expand...
Click to collapse
Can anyone who successfully coped with getting this done following the instructions above please do a video showing us how to do it, I think that might help us a lot... thanks a lot on behalf of us noobs
Stefanauss said:
Could you provide links to this?
Or are those sw included in the Android SDK?
Click to expand...
Click to collapse
ADB is included in the SDK, Smali and Baksmali can be downloaded here and dexopt-wrapper for example here.
qwas00 said:
In step 10, how do i copy the signature bytes with my hex editor? I dont understand what offsets 0x34-0x57 is...
Click to expand...
Click to collapse
It means to seek to the 52nd byte (or 0x34 in hex) of the file, and then copy and replace the following 20 bytes to the second file. But you can also do it on the device by issuing this command (I think busybox is required):
dd if=original.android.policy.odex of=patched.android.policy.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
...where "if=..." is the original file and "of=..." is the file you want to patch.
Ateisti said:
Hi guys,
Since there seems to be some demand for this kind of thing, I decided to post instructions on a mod I made a while back. This gives you the option of choosing between Samsung's GlassLock (i.e. the default TW lockscreen) or the stock keyguard of Android 2.1.
The method involves de- and re-compiling /system/framework/android.policy.odex, and you should have some basic knowledge of the tools involved (i'm not gonna spell out every step). Before beginning, take a backup of android.policy.jar and android.policy.odex (or preferably the whole framework folder). You should issue the commands in recovery mode.
Required tools: rooted SGS (I've done this only with JM2, and the code *might* need modifying for other roms, though I doubt it), adb, smali/baksmali, dexopt-wrapper, text & hex editor, winrar (or any jar editor).
Here we go:
1. Use adb to pull out /system/framework/android.policy.odex and other framework .odexes (required for de-odexing). Might be wise to backup the whole /system/framework/ directory at this point.
2. Use baksmali to deodex the file (java -jar baksmali.jar -x android.policy.odex -o android.policy). Baksmali will let you know if you are missing any of the framework .odexes.
3. Open LockPatternKeyguardView.smali and find the method getLockScreenMode()Lcom/android/internal/policy/impl/LockPatternKeyguardView$LockScreenMode;
4. Replace the contents of this method with the attached file getLockScreenMode.txt.
5. Save LockPatternKeyguardView.smali.
6. Use smali to compile the files back to classes.dex (java -jar smali.jar android.policy -o classes.dex)
7. Pull /system/framework/android.policy.jar, add the newly created classes.dex to it, and push it back to the device.
8. On your phone, do:
# cd /system/framework
# dexopt-wrapper android.policy.jar patched.odex /system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
Ouput should be:
--- BEGIN 'android.policy.jar' (bootstrap=0) ---
--- would reduce privs here
--- waiting for verify+opt, pid=3105
--- END 'android.policy.jar' (success) ---
9. You now have odexed the file into patched.odex. However, the signature of the file is not compatible with the other framework files, so you need to fix it. I think the proper way should be to re-odex all the framework files, but I haven't encountered any issues with just patching the signature.
10. Open the original android.policy.odex and copy signature bytes from offsets 0x34-0x47 to the new patched.odex, and save it.
11. Push the patched and hex-edited file to /system/framework/android.policy.odex and restore the original /system/framework/android.policy.jar.
12. Reboot and enjoy your good ol' keyguard
Some notes:
- If you want to revert back to Samsung's lock screen, just create a file called /data/local/enable_glass_lock ("adb touch /data/local/enable_glass_lock").
- By default, the menu button will also unlock the screen. To disable this behavior, you have to modify /res/values-hdpi-v4/bools.xml in /system/framework/framework-res.apk, and change the value of <bool name="config_disableMenuKeyInLockScreen">false</bool> to true. Can also be done by modifying code.
On a side note, the code for Smart Unlock (present in some Samsung phones) seems to be in there... it would be an interesting project to get that working
Click to expand...
Click to collapse
THANX TO ALL YOUR EFFORTS........ can you please attach a screen shot of the lock what you are talking about.. and does it work flawlessly without any sort of a lag.. and is it 100% bugs free?????
Could you also choose any other lockscreen, like WidgetLocker or SimplyLockscreen?
That would be great
Ateisti said:
It means to seek to the 52nd byte (or 0x34 in hex) of the file, and then copy and replace the following 20 bytes to the second file. But you can also do it on the device by issuing this command (I think busybox is required):
dd if=original.android.policy.odex of=patched.android.policy.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
...where "if=..." is the original file and "of=..." is the file you want to patch.
Click to expand...
Click to collapse
Thanks, that worked fine
Thanks! This method worked like a charm. I hated that glass unlock thingy.
However my /system/framework/framework-res.apk doesn't have a value folder, so I can't remove the possibility to unlock with the menu button.
Couldn't find any bools.xml in there at all.
This is replacing the music player controls when the screen is locked, right? It's a nice functionality and would be a pity to loose it.
Otherwise its a great mod and it would be cool if someone can make the One Click LockScreen Changer ;-)
Sent from my GT-I9000 using Tapatalk
thE_29 said:
Could you also choose any other lockscreen, like WidgetLocker or SimplyLockscreen?
That would be great
Click to expand...
Click to collapse
Not as such, but technically it should be possible with some additional coding. I however don't have the time to undertake such a task.
Tharfrin said:
Thanks! This method worked like a charm. I hated that glass unlock thingy.
However my /system/framework/framework-res.apk doesn't have a value folder, so I can't remove the possibility to unlock with the menu button.
Couldn't find any bools.xml in there at all.
Click to expand...
Click to collapse
This might be a ROM version thingy. On my system there are actually two XML files with that same setting, but only one of them works (the one I mentioned in my original post). Just search all your framework-res xml files for "config_disableMenuKeyInLockScreen", and change every instance to true. Should do the trick.
Or if all else fails, just edit the file LockScreen.smali, method "shouldEnableMenuKey()", and make it always return 0 ("return v4" -> "return v6").
mobilx said:
This is replacing the music player controls when the screen is locked, right? It's a nice functionality and would be a pity to loose it.
Otherwise its a great mod and it would be cool if someone can make the One Click LockScreen Changer ;-)
Click to expand...
Click to collapse
That is unfortunately the case. The music controls (as well as the puzzle pieces) are coded into the GlassLock class, so it would required some additional reverse engineering to implement those in the stock keyguard.
4 hours working and it works (jm2).
I'm going to test on the jpc.
EDIT:
I put it on the jpc and it doesn't work.
Did not work with JPC I really want to use the stock lockscreen!
Sent from my GT-I9000 using XDA App
hi guy thanks for your instruction. However I'm using samset's 1.9f which has the ROM deodexed and i found no .odex files but .jar files. Is there a way to workaround this? I'd really love to revert back to stock eclair lockscreen~!
billytcf said:
hi guy thanks for your instruction. However I'm using samset's 1.9f which has the ROM deodexed and i found no .odex files but .jar files. Is there a way to workaround this? I'd really love to revert back to stock eclair lockscreen~!
Click to expand...
Click to collapse
same here no odex files...
Hi,
I search a way to run some terminal command at startup so that i can apply persistant tweak to the internal memory manager. ( how to here)
Is there an apps or something to do to achieve this?
Solved :
theboostman said:
I finaly found how to do the job. We can run script at boot even with Su permissions!
Using tasker to launch script at device boot.(I wanted to be able to set it directly in android like in windows anyway)
how to launch the script at boot :
Prerequisite (available in market):
- Tasker by Crafty Apps
- Locale Execute Plugin by Michael Mauch (no need for the main locale apps)
Create a "loadable" script:
Use script file in UNIX format with no extension in the name and use a key like "on" in your script to be able to start the script on tasker, if not it will not work.
I use NotePad ++ to create my script starting from a . txt and select Edit , EOL Conversion, Unix Format. Then save as "filename.txt" and rename to delete ".txt".
Copy the script on your sdcard (see samples in .zip attached)
In tasker, Create a new profile and select |System| , |Device Boot|.
Then select |New task| and |Add an action| , |Plugin| , |Execute|.
Then |Edit| and tip @! sh /sdcard/filename key
For example for file name "bofstask" that contain a script tweaking internal memory manager settings and vdd level of kamma's 1.4 kernel.
The script run when the key "on" is used, so tip @! sh /sdcard/bofstask on
Done.
Mod: Do you think this thread has to be moved on a more "developement" thread since it allow to run basic developpement script?
Click to expand...
Click to collapse
I've search a bit and found how to create the script than can be run to apply the settings I want but i still don't find where to put this file on the android system so that it will run at each boot...
It was very easy to do this in windows, I'm sure there is a way to do it in android!
please skilled guys point me to the right thread...
Run script at boot with SU permissions!
I finaly found how to do the job. We can run script at boot even with Su permissions!
Using tasker to launch script at device boot.(I wanted to be able to set it directly in android like in windows anyway)
how to launch the script at boot :
Prerequisite (available in market):
- Tasker by Crafty Apps
- Locale Execute Plugin by Michael Mauch (no need for the main locale apps)
Create a "loadable" script:
Use script file in UNIX format with no extension in the name and use a key like "on" in your script to be able to start the script on tasker, if not it will not work.
I use NotePad ++ to create my script starting from a . txt and select Edit , EOL Conversion, Unix Format. Then save as "filename.txt" and rename to delete ".txt".
Copy the script on your sdcard (see samples in .zip attached)
In tasker, Create a new profile and select |System| , |Device Boot|.
Then select |New task| and |Add an action| , |Plugin| , |Execute|.
Then |Edit| and tip @! sh /sdcard/filename key
For example for file name "bofstask" that contain a script tweaking internal memory manager settings and vdd level of kamma's 1.4 kernel.
The script run when the key "on" is used, so tip @! sh /sdcard/bofstask on
Done.
Mod: Do you think this thread has to be moved on a more "developement" thread since it allow to run basic developpement script?
Edit: Maybe should I just create a new thread and keep this one as it is...??
Ended up using SManager from the play store - working great!
most roms for dhd i have used also support init.d scripts. all you have to do is to put your script with no file extension in /system/etc/init.d folder and that is it
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
Hi. I just finished installing CyanogenMod 11 on my Galaxy Nexus. I also put the DirtyV-SR kernel on as well. Everything seems to be working fine. I then learned about a custom edit of the DirtyV kernel by Nephilim that seems to be popular. I have no idea how to change the settings manually though. Luckily in the DirtyV post there is a link to a script by the user "buscher" that supposedly does the changes for you. I followed the instructions and put the script in the System/etc/init.d folder, removed the .txt extension on the script, and changed it's permission settings (I think I changed the permissions correctly). I'm using an app called SManager to do this BTW. When I try to launch the script I get a syntax error. Here is a screen shot of said error...
i.imgur. com/ b5jAVe3. jpg
(Added spaces so I could post the link)
Link to DirtyV thread: http://forum.xda-developers.com/galaxy-nexus/development/kernel-dirtyv-t2613655
Link to buscher's post with the script: http://forum.xda-developers.com/gal...nel-dirtyv-t2613655/post50202995#post50202995
Does anyone have any idea what im doing wrong? Or perhapsna different way to use Nephilims version of DirtyV?
Thx
I've never used any of the scripts you're talking about, but normally that syntax error means that there's a coding error in the script file that the interpreter doesn't know how to handle. I looked at the script in that thread and I can't see anything that would jump out as being problematic, so there's a chance something may have happened when you downloaded the script or copied it to the device.
I'd say you should try downloading the script again directly on your device, and make sure you're clicking the "Download" button on the Mediafire page with the script instead of doing a "save link as" or anything similar from the forum thread. You may even want to open it up in a text editor app and compare it to the version online to make sure that the file matches.
Alright so I redownloaded it and got it to run this time. My problem now is that it seems some of the required directories for the script don't exist on my phone for some reason.
Here's a new screenshot of the errors
http:// i.imgur. com /mjBjQ88. jpg (again had to add spaces)
It's probably safe to ignore those errors, they probably come from that script being older than the latest kernel version you're running it against. Basically, Linux kernels create a whole bunch of files and folders in /sys that control certain kernel settings. By writing a value to specific files, you can change those settings. Those two errors are the result of the script trying to change two settings files that don't exist anymore, possibly because they were removed in a newer version of the kernel. The rest of the script should run without problems and make the rest of the changes.
just wanted to say, there is no need for script manager to run that script.
remove the .txt
put it in /etc/init.d folder/dir
set all perms(i.e rwxrwxrwx)
then just reboot
it will automatically run and set everything in the script when the device boots.
also
if you want to set those things from nephilim thread, use the app called trickster mod(or Synapse, though trickster might be less overwhelming for someone new to setting these things)
enjoy
any questions feel free to ask