Wanted to share this with fellow amaze users. It's a collection of scripts/binaries that will seamlessly reodex your /system/app and /system/framework folders. This will give you a noticeable increased in overall speed/fluidity, boot times, ram usage... I generally prefer to re-odex anything I use. Major downside to re-odexing is that you can't easily modify the APK. But honestly, it's not that difficult to simply deodex the APK in question, mod/theme it, then reodex it. I find the benefits are well worth it.
The original script was created by tommytomatoe. All credit goes to him for the actual creation of this script. I simply made a windows batch file to ease the setup and execution of said script.
Please PLEASE PLEASE make a NANDROID backup before you run this. I've never had it mess anything up, but who knows... just back up and be safe!..
ZIP is attached below. Unzip into any directory (make sure the files stay together) and run Dexo.bat - You MUST HAVE BUSYBOX, WORKING ADB (Wireless ADB support is built into the batch file), and ROOT!
I originally had a quick batch file made for just myself.. but I changed things around and made it a bit more user friendly and other things.... I've only tested it ONCE on my own device once (the modified one).. so just be warned.. and make a backup first!
The batch file will not close on its own, when it's done the device will reboot on its own. You can simply just close the window.
Hope this helps some people! Good luck.
--------------------
[What is Odex?]
During the build process, Android can be built with the flag “WITH_DEXPREOPT=true”. This means that the dex files are preoptimized in the build environment using a dalvikVM on the host, as opposed to optimized during boot on the device. The dex-preopt process results in two files per apk or jar – the jar/apk file and its accompanying .odex file.
----------------------
[What is so tricky about reodexing?]
Due to the nature of the dalvik VM (according to documentation in AOSP), the VM expects the optimization process to follow the strict BOOTCLASSPATH.
/* There are some fragile aspects around bootclasspath entries, owing
* largely to the VM's history of working on whenever it thought it needed
* instead of strictly doing what it was told. If optimizing bootclasspath
* entries, always do them in the order in which they appear in the path.
*/
So that is the dex-preopt during the build time. All the vendors ship devices with Odex, ie, stock ROMs are odex. What about ROMs that have been deodexed? Or how do you go about editing the smali code from the odex files? Thank goodness for JesusFreke, we have baksmali and smali. Using the two in sequence, one can successfully convert the optimized dalvik executable (odex) and dissemble it into a human readable (sorta) language called “smali”, created by JesusFreke and resembles the Jasmin language. Anyways, carrying on. Using the dexopt-wrapper binary, you can re-odex your ROM after it has been deodexed. This sounds pretty simple but as stated above, the VM expects the optimization to follow the BOOTCLASSPATH. You cannot silly nilly deodex android.policy.jar and then re-odex it. Your device will not boot. You must transfer the original “signature” from the original odex file to the newly created (Hint, dd if=original.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc). This can be done on a Linux machine or with the busybox binary.
OK. So what is this tool? I just wanted to give a brief (or not so brief) overview of the process. This tool doesn’t deal with partially odexed ROMs. This tool is for odexing a ROM that is completely DEODEX.
The benefits? Faster boot, smaller imprint on /data/ partition, overall faster feeling. The phone will generally just run a little bit faster, system apps will launch quicker..
The myths? I can’t theme ODEX! WRONG! You can theme odex just fine! Just use baksmali and smali.
This requires BUSYBOX.
This requires ADB.
Again HUGE THANKS to tommytomatoe for the original script and his original efforts.
THIS ZIP FILE IS NOT FLASHED IN RECOVERY! You simply extract it to a folder on your hard drive. Then run Dexo.bat, follow on screen instructions. Make sure to nandroid as well as having phone plugged in VIA USB with debugging enabled, or have wireless ADB ready to go.. batch file supports wireless. Just have to follow prompts and enter IP.
ericdjobs said:
Wanted to share this with fellow amaze users. It's a collection of scripts/binaries that will seamlessly reodex your /system/app and /system/framework folders. This will give you a noticeable increased in overall speed/fluidity, boot times, ram usage... I generally prefer to re-odex anything I use. [/B][/SIZE]
Click to expand...
Click to collapse
Tried this on my ICS ROM and it works fine.
Thanks!
Doesn't work for me :/
Sent from my HTC Ruby using xda app-developers app
avenged_sevenfold27 said:
Doesn't work for me :/
Sent from my HTC Ruby using xda app-developers app
Click to expand...
Click to collapse
Oh! It's not supposed to be flashed in recovery!
Sorry if I wasn't clear on that.
It's a script and a batch file. The batch file will make uploading the script, changing permissions, etc etc etc, a lot more intuitive and easier.
You simply need to extract the ZIP anywhere on your harddrive (Have to be using windows for the batch file to work.. if you're running Linux i'm sure you can figure out how to do it manually anyways) Make sure to keep all the files in the same folder.
Then simply execure dexo.bat and follow the prompts. Make sure you have the phone plugged in via USB and USB debugging enabled.. or have Wireless ADB running (batch has built in support for wireless ADB)
You can run it while the phone is on. The phone will reboot itself when the script is finished.
ericdjobs said:
Oh! It's not supposed to be flashed in recovery!
Sorry if I wasn't clear on that.
It's a script and a batch file. The batch file will make uploading the script, changing permissions, etc etc etc, a lot more intuitive and easier.
You simply need to extract the ZIP anywhere on your harddrive (Have to be using windows for the batch file to work.. if you're running Linux i'm sure you can figure out how to do it manually anyways) Make sure to keep all the files in the same folder.
Then simply execure dexo.bat and follow the prompts. Make sure you have the phone plugged in via USB and USB debugging enabled.. or have Wireless ADB running (batch has built in support for wireless ADB)
You can run it while the phone is on. The phone will reboot itself when the script is finished.
Click to expand...
Click to collapse
It goes through all the prompts for me, but then on the final "Press any key to continue" when I press any key, the batch file just closes with nothing being done to my phone.
Guess I should add, I'm using windows xp, and yes, usb debugging is enabled
masondoctorjt said:
It goes through all the prompts for me, but then on the final "Press any key to continue" when I press any key, the batch file just closes with nothing being done to my phone.
Guess I should add, I'm using windows xp, and yes, usb debugging is enabled
Click to expand...
Click to collapse
Hmm strange. I guess I should add instructions to do it manually, just in case something like this happens
Basically just open a command prompt, navigate to wherever you unzipped everything...
adb root
adb remount
(adb connect again here if using wireless)
adb push dexo /system/bin
adb push dexopt-wrapper /system/bin
adb push zip /system/xbin
adb push zipalign /system/xbin
adb shell chmod 755 /system/bin/dexo /system/bin/dexopt-wrapper /system/xbin/zip /system/xbin/zipalign
then the final command
adb shell dexo
let me know where at in this process it's getting snagged if that doesn't work.
ericdjobs said:
Hmm strange. I guess I should add instructions to do it manually, just in case something like this happens
Basically just open a command prompt, navigate to wherever you unzipped everything...
adb root
adb remount
(adb connect again here if using wireless)
adb push dexo /system/bin
adb push dexopt-wrapper /system/bin
adb push zip /system/xbin
adb push zipalign /system/xbin
adb shell chmod 755 /system/bin/dexo /system/bin/dexopt-wrapper /system/xbin/zip /system/xbin/zipalign
then the final command
adb shell dexo
let me know where at in this process it's getting snagged if that doesn't work.
Click to expand...
Click to collapse
Thanks... It might be a couple of days before I have a chance to try this again, but I'll let you know if this way works.
Sent from my HTC_Amaze_4G using xda app-developers app
Just ran the manual instructions since I had the same error noted above and all goes well until after the last adb shell dexo command; I get a message saying everything is installed but I also see this: Please install these binaries to continue: sed cp unzip. What does that mean?
Edit: I went ahead and rebooted anyway and nothing happened, still deodexed.
How can you tell if the custom rom you're on is dedoxed or redoxed? I'm on the ViperA
Sent from my HTC_Amaze_4G using xda app-developers app
kevinrubio1 said:
How can you tell if the custom rom you're on is dedoxed or redoxed? I'm on the ViperA
Sent from my HTC_Amaze_4G using xda app-developers app
Click to expand...
Click to collapse
Use root explorer or some similar app and go into system/apps and if you see any files right next to the app files that say .odex then you are not deodexed.
Also most custom ROM's state right in the OP if the are deodexed or not.
Sent from my HTC_Amaze_4G using Tapatalk 2
I don't have access to computer so can I run commands through terminal emulator?
Sent from my gt-1900 using xda premium
Doesn't work as of yet...
Followed the instructions
BusyBox Rooted S-off on ViperAmaze 1.7.1 ran the script as Admin and phone restarted after completion of script and stuck on bootscreen.
running fix permission and wiping dalvik+cache just in case if it works will report back EDIT: doesn't work had to recover nandroid
Can anyone dumb this thread down to what deodex/odex means to a person with no dev skills or
What can I do with deodex apks?
Is this a significant boost in speed etc?
Dumb and Dumber (remember the movie?)
blindskater39 said:
Can anyone dumb this thread down to what deodex/odex means to a person with no dev skills or
What can I do with deodex apks?
Is this a significant boost in speed etc?
Click to expand...
Click to collapse
When a Carrier releases a version of software it is ODEXED meaning you have an app like camera.apk, and you have a camera.odex
It's a file that contains the libraries and other things to support the apk.
When you DE-ODEX you build all of the stuff into the apk file so you don't need the .odex files.
it reduces the nuber of files in the rom. Meaning you now only have a camera.apk with no .odex file.
RE-ODEXING the apps and files makes it run faster.
That is taking the files back out of the apk file so you have two files again.
It seems easier to take DE-ODEXED files from one rom and use them in another rom, but you cannot just copy an apk that hasn't been DE-ODEXED into another rom without its' associated odex file.
How's that?! Hope it helps!
Looks like.... IT WORKS on Super Sense 3.2 (coming very soon)! This will speed it up big time!
chevycowboyusa said:
When a Carrier releases a version of software it is ODEXED meaning you have an app like camera.apk, and you have a camera.odex
It's a file that contains the libraries and other things to support the apk.
When you DE-ODEX you build all of the stuff into the apk file so you don't need the .odex files.
it reduces the nuber of files in the rom. Meaning you now only have a camera.apk with no .odex file.
RE-ODEXING the apps and files makes it run faster.
That is taking the files back out of the apk file so you have two files again.
It seems easier to take DE-ODEXED files from one rom and use them in another rom, but you cannot just copy an apk that hasn't been DE-ODEXED into another rom without its' associated odex file.
How's that?! Hope it helps!
Click to expand...
Click to collapse
For the most part its much easier to comprehend, thanks! But why can't you copy a de-odexed apk to another rom if it doesnt which doesnt need the .odex files anymore?
blindskater39 said:
For the most part its much easier to comprehend, thanks! But why can't you copy a de-odexed apk to another rom if it doesnt which doesnt need the .odex files anymore?
Click to expand...
Click to collapse
You can. I'm sorry if I complicated that part..
Sent from my HTC_Amaze_4G using xda app-developers app
this may be a stupid question but will this work on cm11?
dtr145r said:
this may be a stupid question but will this work on cm11?
Click to expand...
Click to collapse
No, CM11 is already deodexed.
SuperAfnan said:
No, CM11 is already deodexed.
Click to expand...
Click to collapse
well yea,
i know that.
thats the point, to 'RE-Odex' it....
Related
NOTE: DO NOT DO THIS UNLESS YOU KNOW WHAT YOU ARE DOING, YOU CAN EASILY SCREW UP YOUR SYSTEM, AND THIS WON'T HELP YOU.
BACKUP FIRST, AND MAKE SURE YOU HAVE A SETUID SH AS ROOT SO YOU CAN RECOVER FROM BACKUPS IF NECESSARY.
First you have to re-sign framework-res.apk using testkeys. This will allow you to use testkeys for system uid packages.
Next step is to re-sign all other apks that use shared uid system.
That is: bootinfo, Fota, GoogleCheckin, GoogleSubscribedFeedsProvider, NetworkLocation, ServiceMenu, Settings, SettingsProvider, VpnServices
Next you have to re-sign all apks that use the platform key, which turns out to be the shared uid phone - these require implicit permissions from the platform like DEVICE_POWER:
TelephonyProvider, Stk, semc-backup-rachael, Phone
Finally, I think GoogleEnhancedSearch also needs it or something otherwise a settings menu will fc.
The nice part about re-signing is that you don't actually need to deodex the files.
One important thing is that in the new versions, the fota.action.DEBUG_ENTRY is actually disabled, and moreover, requires special permissions that aren't granted. This is where re-signing comes in.
Now, you need to deodex fota.apk, modify the manifest to remove permissions required for DEBUG_ENTRY, and finally, force enable the debug menu:
In com/sonyericsson/android/fota/common/fotaview/FotaDebugEntry.smali,
find "debug UI is not available!"
a few lines above, there is if-nez v0 :cond_0
change it to if-eqz v0 :cond_0
This forces it to enable the debug menu.
Now we re-smali the Fota.apk, re-sign, then push it on to the phone along with the rest of the modified packages.
Repush all the files to the phone and it's done
problem !
baksmali gives an error at fota.apk
can you post your deodex scrypt
Why is this required?
TechGuru_x10 said:
Why is this required?
Click to expand...
Click to collapse
So that you won't have to keep re-flashing the older firmware to root (and keep re-installing stuff afterwards), and it should save time in repairing your firmware if you mess system files up.
It should also allow us to upgrade to newer firmwares from the current one, so we don't have to lose all of our apps/settings when rooting our phones again with a newer firmware.
Is this right guys? Anyway, thanks and good luck!
jerpelea said:
problem !
baksmali gives an error at fota.apk
can you post your deodex scrypt
Click to expand...
Click to collapse
You need to add the classpath by deodexing everything in the framework folder and including it.
zephyrix said:
You need to add the classpath by deodexing everything in the framework folder and including it.
Click to expand...
Click to collapse
oki
will try
thanks
found my error
i was using smali1.2.2 tested with 1.2.3 and is working
jerpelea said:
oki
will try
thanks
found my error
i was using smali1.2.2 tested with 1.2.3 and is working
Click to expand...
Click to collapse
Could these steps be made into a script, to run everything at once? Or at least in sections?
Daneshm90's autodeodexer 2.3 modified by me for X10
http://hotfile.com/dl/53736770/16a1bc8/Deodexer_2_3_SE.rar.html
So eventually (with this) we can take a newer build and run this script thus allowing us to then run the files necessary for root?
what do you mean by newer builds like R2BA020
Sorry if Im being a noob but lets say I mess up a framework file and get stuck at the bootscreen. When I try to use adb to push my backup it says permission denied. Will this allow me to make the changes?
Well what I've done is use a modified adb which runs as root and replaces on boot. However, I believe you could use a setuid sh and achieve the same result.
i.e. cp /system/bin/sh /system/bin/rootsh
chmod 6755 /system/bin/rootsh
then you can push to a folder where you can normally write, and use rootsh and move it.
Great thanks, I'm going to wait until I have to try it...
Can we flash rom using PC ?? Its not that big a deal but sounds cool to me.. i cudnt find any such option in nandroid-mobile.sh.. I mean after i reboot into recovery i dont want to press any buttons on my phone..Juts hook up the phone to pc and flash the new rom using say adb
It should be possible. When flashing zips, the recovery checks the update-script file found in the META-INF folder. Mimicking the steps there and inputting the correct adb commands and copying the files on the appropriate folders and partitions on your phone should yield the same results.
But as you may have guessed, this isn't practical.
so u mean to say that i unzip the contents of the zip archive and just execute the script from terminal ???That shud be it??? I know its impractical but wat the hell i love doing things from my debian terminal
Update: that script is just a set of messages to be shown during actual update process..it isnt the script ..
instead the script apparently "update-binary" is a binary executable and not a shell script..DO you think that unzip and calling this binary might work??
I'm not entirely sure. I think adb has it's limitations. Check other's replies xD
Hi all
I have created for my first java program a update.zip creator for the nexus one.
This will create a flashable update.zip for updating the system apps on your choice.
I created it for my self to save me time making them every time I wanted to save memory on my phone by moving apps from /data to /system partition (could just of written a script), so thought I would share it.
This is a console tool written in java and only for linux, it will only work on a rooted nexus one running clockwork mod recovery (have not tried any other recovery).
Tested on: nexus one, clockwork mod, CM 7
Programs you can choose to add to the update.zip:
Amazon mp3
Maps
Facebook
Gmail
Rom manager
Android market
Twitter
Youtube
Voice search
Super user
Read the README on how to use it.
Don't forget to run the adb server as root!
Download: http://www.mediafire.com/?pekm9ehswe49x
Any questions,problems,suggestions let me know.
README
Code:
This is a tool I have created for my self to speed up making update.zips for my nexus one and am now sharing.
It is my first java program so it's not perfect but it will improve over time as I learn.
This program will create and sign an update.zip file that will move apps you choose from the /data/app patition to the /system/app partition
It has only been designed to work with the nexus one using Cyanogen mod.
How it works
First it pulls all apps from the /data/app partition on your phone into a created directory with in the PWD
it then scans all the apps for key names of the apps
then if it finds certain apps, it will then ask you if you would like to add it to the update.zip
it then creates the update-script with the commands to delete the apps from the /data/app and copy them to the /system/partition
then it zips the contents and finaly uses the testsign.jar to sign the package.
In the PWD the following programs are needed to run updater-creator:
adb
testsign.jar
update-binary
**** RUNNING THE PROGRAM *****
You must download the apps from the market that you want to update
Leave updater-creator.jar in the directory with ADB and other programs, moving it will prevent the program from finding the programs it needs to run.
You must enable USB debugging on your phone as this program uses ADB.
To run updater creator:
*unzip the file and contents into a directory .
*cd to the dir you unzipped the files to.
*Plug phone in
*Run 'sudo ./adb kill-server' then 'sudo ./adb start-server'
*run the updater-creator.jar file using the following command: java -jar updater-creator.jar
This will create folders and files needed with in the PWD.
Each time you run updater-creator it will over write all previously created files.
I'll give it a try, thank you for sharing your hard work any chance of adding the "read me instructions" to your first post?
Thanks again
Gr8 work,definitely will try it once I get back home
Sent from my Nexus One using XDA App
tina333 said:
I'll give it a try, thank you for sharing your hard work any chance of adding the "read me instructions" to your first post?
Thanks again
Click to expand...
Click to collapse
README now added. Let me know if it works ok or if there are any problems with it, I have tested it my self and had a friend test it with out any problems
If there are any more common apps or features you would like me to add let me know and I will see what I can do.
thank you!! I think this would be pretty useful for myself
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Binary100100 said:
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Click to expand...
Click to collapse
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Keep me posted will ya?
I believe that Faux and other developers would have to use the zImage kernel flashing technique to get it to work with his existing app but I'm sure he can simplify it to accept .img files and the .ko files in the /system/lib directory of a zip file. It actually should be very easy. It took me about ten mintues with testing included to create the script for my method. I just can't code for apps else it would be done by now.
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
I contacted pershoot, no answer lol!!!
Joeykrim is willing to support the Amaze, he just needs testers, this would be a great backup incase the new script failed to push the kernel. I'll keep everyone posted with updates
Sent from my HTC Amaze 4G using XDA App
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Binary100100 said:
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Click to expand...
Click to collapse
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
seansk said:
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
Click to expand...
Click to collapse
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Binary100100 said:
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Click to expand...
Click to collapse
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
seansk said:
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
Click to expand...
Click to collapse
I'm sure there's a way to add a delay timer of some sort. I'm just not that savvy. Easiest way would be through an app like Tasker.
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
The short answer is yes!
I've setup the application to support the HTC Amaze 4G, but before I release it publically and officially, I want to have a few testers confirm everything is working properly for them.
Posted all the information in a new thread as this one seems to be covering a few different topics so I didn't want to "hijack".
http://forum.xda-developers.com/showthread.php?p=21574722
Thanks for the request and for reaching out to me DEFINITIONOFREAL.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
joeykrim said:
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
Click to expand...
Click to collapse
I look forward to tryin out your app.
It was basically what this thread was all about in the first place.
The clockwork method that you mentioned is the only workaround that I was able to come up with for custom kernels (like Faux123) because a kernel cannot be flashed through recovery without s-off. Really stupid. So I started thinking "How can we flash a boot.img file from recovery without the typical means?" Then came up with the solution to flash_image the boot.img file automatically IF the file is detected. But how to start a script automatically upon boot? init.d is the only way I could think of. Okay... so where to put the boot? I tried the sdcard but it failed to mount until it was way too late. So... data. Nope... still didn't mount in time. Cache? Well... how many developers will include a cache file into their roms? So the only other option was /system and it seemed convenient since /system mounts BEFORE the script can run (obviously) so that's why it is as it is. I also figured "If someone wants to flash a new kernel all they need to do is push the boot.img to /system and reboot." Must easier than using the EKF method (requiring PC access) and I don't know about you but I'm not around a computer 24/7.
I saw a post in this thread about getting the promotional space on AT&T S4 without flashing TMobile roms. I gave it a try, and it worked just fine. So I thought of sharing the files with you. I pulled them out of a deodexed TMobile rom.
Download the attached file. You need to push Dropbox.apk and DropboxOOBE.apk into system/app and fix permission. Then you need to push com.dropboxpartner into system/framework and again fix permission.
Then, you need to modify the build.prop using a root explorer. Find the following lines and modify them as follow:
ro.product.model=SGH-M919
ro.product.name=jfltetmo
ro.product.device=jfltetmo
Reboot your device, open the Dropbox app, and log in with your existing account, or create a new account. You will receive an email, and after fulfilling 5 of the 7 tasks, you will receive the 48 GB promotional space. After fulfilling the tasks, you can restore your build.prop to its original state.
Attached Files:
http://d-h.st/fZJ
smnfriend said:
I saw a post in this thread about getting the promotional space on AT&T S4 without flashing TMobile roms. I gave it a try, and it worked just fine. So I thought of sharing the files with you. I pulled them out of a deodexed TMobile rom.
Download the attached file. You need to push Dropbox.apk and DropboxOOBE.apk into system/app and fix permission. Then you need to push com.dropboxpartner into system/framework and again fix permission.
Then, you need to modify the build.prop using a root explorer. Find the following lines and modify them as follow:
ro.product.model=SGH-M919
ro.product.name=jfltetmo
ro.product.device=jfltetmo
Reboot your device, open the Dropbox app, and log in with your existing account, or create a new account. You will receive an email, and after fulfilling 5 of the 7 tasks, you will receive the 48 GB promotional space. After fulfilling the tasks, you can restore your build.prop to its original state.
Attached Files:
http://d-h.st/fZJ
Click to expand...
Click to collapse
Worked great for me, thanks! I already had 12GB and had completed the 5 Getting Started steps long ago. When I signed into the DropBox app and got it setup, I suddenly had 60GB for 24months and an email from DropBox.
Here's the instructions I followed:
Cleared cache of, cleared data of, and uninstalled the DropBox app I already had.
Reminder: backup your build.prop
I ended up using this build.prop Editor. When you open it, use the menu key to make a backup before touching anything. Then scroll through and make the changes prescribed in the OP.
Downloaded the file attached in OP.
Extracted files using my computer to my internal sdcard. Possible to do this with apps on your phone (various file explorers or unzip programs), but I found it easier to just do it over USB/MTP.
Fired up ADB Shell - could also use a terminal emulator from the device, but do not use the "stop" command below if you are using an emulator on the device.
Performed the following commands (after running "adb shell" from a command line on the computer):
Code:
$ su
# mount -o rw,remount /system
# stop
# cp /sdcard/Dropbox.apk /system/app
# cp /sdcard/DropboxOOBE.apk /system/app
# cp /sdcard/com.dropboxpartner.jar /system/framework
# reboot recovery
Device rebooted into TWRP, where I used the Advanced menu to Fix Permissions.
Rebooted back into the System like normal.
Opened the DropBox app and signed in. Setup the camera sync again of course (awesome feature).
Checked my mail - Woot.
Used the build.prop editor to restore my build.prop
Closed the build.prop editor and re-opened. For some reason after restoring the backup, the restored changes were not reflected until I restarted the editor. Whatever, but it worked.
Worked for me:thumbup: Thanks! Now what to do after the two year promo period ends...
Sent from my SAMSUNG-SGH-I337 using xda app-developers app
I'm already up to 50GB on doing something like this before. I'm not sure if it'll work again but I'll give it a whirl sometime today. Will report back if I find myself up to 98GB.
Perfectly working.
Followed general instructions (used FX root explorer instead of Android Terminal for dropping apks in designated locations) and this worked just fine without a hitch. I appreciate the straightforward and simple instructions.
All I did was flash Wicked (T-Mobile ROM) then KTOONSEZ touchjizz kernel. After getting my free dropbox space, I flashed back.
Sent from my SGH-I337 using xda premium
lol same here with GOLD3N3Y3 rom; any non-ATT rom works if you DL and activate it. i have my own server so im letting everyone in my family use it for our stuff.
Slade8525 said:
lol same here with GOLD3N3Y3 rom; any non-ATT rom works if you DL and activate it. i have my own server so im letting everyone in my family use it for our stuff.
Click to expand...
Click to collapse
i can confirm that this works on vzw.
Thanks, worked great on my VZW S4.
Aou said:
Worked great for me, thanks! I already had 12GB and had completed the 5 Getting Started steps long ago. When I signed into the DropBox app and got it setup, I suddenly had 60GB for 24months and an email from DropBox.
Here's the instructions I followed:
Cleared cache of, cleared data of, and uninstalled the DropBox app I already had.
Reminder: backup your build.prop
I ended up using this build.prop Editor. When you open it, use the menu key to make a backup before touching anything. Then scroll through and make the changes prescribed in the OP.
Downloaded the file attached in OP.
Extracted files using my computer to my internal sdcard. Possible to do this with apps on your phone (various file explorers or unzip programs), but I found it easier to just do it over USB/MTP.
Fired up ADB Shell - could also use a terminal emulator from the device...
Performed the following commands:
Code:
$ su
# mount -o rw,remount /system
# stop
# cp /sdcard/Dropbox.apk /system/app
# cp /sdcard/DropboxOOBE.apk /system/app
# cp /sdcard/com.dropboxpartner.jar /system/framework
# reboot recovery
Device rebooted into TWRP, where I used the Advanced menu to Fix Permissions.
Rebooted back into the System like normal.
Opened the DropBox app and signed in. Setup the camera sync again of course (awesome feature).
Checked my mail - Woot.
Used the build.prop editor to restore my build.prop
Closed the build.prop editor and re-opened. For some reason after restoring the backup, the restored changes were not reflected until I restarted the editor. Whatever, but it worked.
Click to expand...
Click to collapse
Using terminal emulator, after using #stop, device screen goes black... what do I do, just wait?
Cinosinu said:
Using terminal emulator, after using #stop, device screen goes black... what do I do, just wait?
Click to expand...
Click to collapse
You need to do it from your computer terminal/shell using adb shell command through the USB, not using a terminal emulator on the device. Stop does exactly what it says, it stops the device from running I think , or maybe just pauses.
You should be able to copy the files without stop though, it's probably riskier, and then you need to use reboot. You just need to copy the files into the right locations and then fix the permissions.
Cinosinu said:
Using terminal emulator, after using #stop, device screen goes black... what do I do, just wait?
Click to expand...
Click to collapse
These are linux commands. Stop, stops your device, and you cannot use it unless you reboot it. You can punch in the commands through your computer (this way, you need to install android sdk. Then, open the installed folder, and go to sdk\platform-tools. Here, you should hold shift, right click and select "open command window here", and punch the commands). Also, you can simply use a root explorer, and manually move the files to their folders and fix permissions
Just pull the battery and reboot. It happened to me also.
Sent from my SGH-M919 using xda premium
smnfriend said:
Also, you can simply use a root explorer, and manually move the files to their folders and fix permissions
Click to expand...
Click to collapse
What does this mean? I have ES fie explorer, trying to move the files I get a rewrite error. Do i need to fix the permissions first? What is the adb command?
thanks
I got it!!! :victory:
Why didn't someone tell me you must use the command 'ADB Shell' to start?
I'm no expert with ADB obviously. Knew it was something trivial. Hope someone else finds my comment helpful. :highfive:
Thank you OP and all! XDA rocks!
Thanks for pointing these things out. Yes, "stop" should only be used if doing this from an ADB shell. I've updated my instructions a tad bit to reflect this.
How can i do this for multiple accounts? I logged out and in and no luck.
Sent from my SGH-M919 using xda premium
kalparker said:
How can i do this for multiple accounts? I logged out and in and no luck.
Sent from my SGH-M919 using xda premium
Click to expand...
Click to collapse
did you do a factory reset, re-install of your ROM, then the steps again? that may help by giving you a different device ID (you may have had this warning before in TiBU), which i'm guessing DB is looking for to limit 1 upgrade per device ID.
-rf
xrabbitfootx said:
did you do a factory reset, re-install of your ROM, then the steps again? that may help by giving you a different device ID (you may have had this warning before in TiBU), which i'm guessing DB is looking for to limit 1 upgrade per device ID.
-rf
Click to expand...
Click to collapse
That might work. In TiBu, I have the option to create a new, random device ID - might be a Pro feature only. Check your menu key, and near the bottom you can Manager your Device ID...
I would advise a nandroid backup first - this may screw up some of your other accounts, including Google. I've personally never tried it, but I would imagine it could cause some amount of chaos.
thanks!