[Dev]Automatic Update Zip Generator - Android Software/Hacking General [Developers Only]

Everyone:
I've recently finished creation a program that will take an existing directory structure (i.e with /system and/or /data) in the root directory and generate a signed update zip from it. Let me know if there are any problems and I'll do my best to fix them in a day or so. Enjoy!
Features:
Generates the META-INF folder structure and update-script if the META-INF folder isn't present. If it is present, you folder structure and scripts will not be overwritten
Experiemental: Gives the option to run a script before copying the contents or /system or /data to your phone. I've tested this feature using a simple echo script with no ill-effects, but still use it at your own risk. If you want to verify the command to run a custom script is being written correctly, you can check the source at: (line 18)
code.google.com/p/android-customization-autotool/source/browse/trunk/src/standalones/UpdateZipWizard/CreateUpdateZip.py
Generates a signed update zip (named whatever you want) containing your files (including the META-INF folder) that can be flashed in Clockwork
Download:
code.google.com/p/android-customization-autotool/downloads/list
Report an Issue/Make a feature request/suggestion:
code.google.com/p/android-customization-autotool/issues/entry

Awesome!
Appreciated

No problem. I'm currently trying to finish out the all-in-one tool but if anyone has any feature requests, I'd rather contribute some more new programs to the community than making existing ones better. Any ideas can be submitted here:
code.google.com/p/android-customization-autotool/issues/entry?template=Feature%20Request
If they aren't phone specific, there's a higher chance I'll pursue it. If it is phone specific, I can code it to tutorial specs, but I only have a Droid X to test on so if it's not a Droid X, you'll have to do the testing (or assume it's right --> Bad idea)

Recently made an update to the tool... A user had a problem with the Java heap size so that has been decreased. Additionally, the command window would close before errors could be seen, and this has been fixed.
The updated version can be found at the original link. Let me know if there are any additional issues.

androidfan44 said:
Everyone:
I've recently finished creation a program that will take an existing directory structure (i.e with /system and/or /data) in the root directory and generate a signed update zip from it. Let me know if there are any problems and I'll do my best to fix them in a day or so. Enjoy!
Features:
Generates the META-INF folder structure and update-script if the META-INF folder isn't present. If it is present, you folder structure and scripts will not be overwritten
Experiemental: Gives the option to run a script before copying the contents or /system or /data to your phone. I've tested this feature using a simple echo script with no ill-effects, but still use it at your own risk. If you want to verify the command to run a custom script is being written correctly, you can check the source at: (line 18)
code.google.com/p/android-customization-autotool/source/browse/trunk/src/standalones/UpdateZipWizard/CreateUpdateZip.py
Generates a signed update zip (named whatever you want) containing your files (including the META-INF folder) that can be flashed in Clockwork
Download:
code.google.com/p/android-customization-autotool/downloads/list
Report an Issue/Make a feature request/suggestion:
code.google.com/p/android-customization-autotool/issues/entry
Click to expand...
Click to collapse
How to use this aplication ?

Related

[GUIDE] How to create a your own ROM

How to create your own ROM update.zip for the T-Mobile MyTouch 3G
Things you will need to perform this:
Java SE Dev Kit from Sun. java.sun.com
May need Cygwin with zlib0 package, from cygwin.com
This will give you Android 1.6 with all the Google applications, Root access.
I never found one place where all this information is all together, so that is why I compiled this together.
Now anyone can do this themselves.
Thanks to all the hard work others have done before this.
1.
First Root your phone and install a new Recovery image, either Amon Ra or Cyanogens Recovery image.
Instructions for one-click root: http://theunlockr.com/2009/08/22/how-to-root-the-mytouch-3g-or-g1-in-one-click/
2.
Download the Android 1.6 System image from
http://developer.htc.com/google-io-device.html
extract the contents of signed-google_ion-img-14721.zip.
3.
You now need to extract the contents of system.img using a tool called unyaffs. The source code is here:
http://code.google.com/p/unyaffs/downloads/list
Or download a prebuilt win32 version here.
http://jiggawatt.org/badc0de/android/index.html
Note you may also need cygwin1.dll and cygz.dll (zlib0 package). Found at cygwin.com
Of course if you already have Cygwin installed with the GCC packages, you can just compile it yourself. Then also
if you comment out the line 67 to "// symlink(oh->alias, full_path_name);"
then it will not create the copies of the symbolic link file, and you will not have to worry about deleting duplicate
symbolic link files later.
Now in the directory where system.img exists, create a new directory called "system"
go into the "system" directory.
type the following command:
unyaffs ..\system.img
That should extract all the files from the system.img file into the system directory.
4.
Now we just need to clean up some items. Since the system.img is a linux file system, it has symbolic
links built into it, but when we extracted it, it just created duplicate files, if you used the prebuilt unyaffs.exe.
So we can just delete the duplicates and have a script recreate the symlink on install.
So we need to delete some extra files from the system\bin directory.
Run the attached DeleteExtras.bat file from the same directory where system.img is in.
If you notice, all the files it deletes are 28 byte files, and if you open them in notepad only contain:
"!<symlink>toolbox..."
And we will remake the symbolic link when it is installed.
5.
Now from the directory where the system.img is, enter the following commands
mkdir META-INF
mkdir META-INF\com
mkdir META-INF\com\google
mkdir META-INF\com\google\android
Now copy the included file "update-script.txt" into the "META-INF\com\google\android" directory
and RENAME it to just "update-script".
This update-script gets run to recreate the symbolic links.
Not sure if these two are needed but they are in some custom ROMs here:
Copy the two files "fix_permissions" and "flash_image" to the "system\bin" directory.
6.
-- Optional --
These add root and Superuser access to the ROM, plus the Terminal Emulator application.
Copy the file "su" from Cyanogen's rom to the folder "system\bin"
Copy the file "Superuser.apk" to the folder "system\app"
Copy the file "Term.apk" to the folder "system\app"
You can also replace the "system\etc\apns-conf.xml" with a more complete one from here:
http://forum.xda-developers.com/showthread.php?t=547718
or here
http://docs.google.com/Doc?docid=0AZNbAmKkmakoZGZxZHNwMnpfMjJkaHg3ejN3eg&hl=en
Turn data roaming off by default by editing line in the build.prop file:
ro.com.android.dataroaming=false
Also to fix the Market program to show "Protected" applications change the ro.build.fingerprint line to the following:
ro.build.fingerprint=tmobile/opal/sapphire/sapphire:1.5/COC10/150449:user/ota-rel-keys,release-keys
Only phones with a fingerprint of a "released" device can access some market applications.
--------------
7.
Now we just need to create a ZIP file for the final ROM
Zip up the following file and two folders:
boot.img
META-INF
system
8.
Now sign the zip file.
See here how to sign a ZIP file for flashing it.
http://androidforums.com/developer-101/8665-how-signing-roms.html
9.
Copy it to your SD card, boot into recovery, wipe, apply the update, Reboot.
You are now running Android 1.6!
the finger print is found in build.prop is this correct and what app do you use to edit your build.prop
Yes the fingerprint is in build.prop
Make sure to use an advanced text editor like TextPad, UltraEdit, or EditPlus. It has to handle UNIX text files.
Also use this for the update_script.
how abt kernel parameters?
How would one go about customizing this with Hero? Or is that not possible at this point?
detox702 said:
How would one go about customizing this with Hero? Or is that not possible at this point?
Click to expand...
Click to collapse
Would like more info on hot to incorporate senseui
Thanks for sharing... Got nothing to do today, so I experimented on my phone... I gotta say, I'm pretty amazed w/ this feature. Was able to sort out and organize my files.
Kudos!
How does one create the system.img file once one has the system files...
What I want to do is use some of the custom roms here and put it on an AVD emulator system.
Can someone help with this please.
NOTE: I dont have linux. So if there is an alternative to mkbootimg, it will be excellent.
the ion is the 32b if I'm not mistaken?
Is there an image for the 32a or do we always have to use the ion and throw a patch over it?
Sorry if this is a stupid question
in step 5. it says
Not sure if these two are needed but they are in some custom ROMs here:
Copy the two files "fix_permissions" and "flash_image" to the "system\bin" directory.
Where do i copy the files from or download please?
thanks in advance
P.S. any tips on changing the splash screen would be much appreciated.
DeleteExtras.txt or DeleteExtras.bat doesn't work. I have to delete the extra files by myself - one by one.
codysoloman said:
DeleteExtras.txt or DeleteExtras.bat doesn't work. I have to delete the extra files by myself - one by one.
Click to expand...
Click to collapse
check this: http://forum.xda-developers.com/showthread.php?t=633246
Perhaps someone here knows or could point me to the right resources, but if the phone isn't supported by Cyanogen, how would a custom rom be made in that case?
How is a custom rom made from scratch? Since android is just linux, is it simply a matter of building it with the right drivers for the phone and installing it? How can an image be manually copied to the phone if it isn't supported by Clockwork recovery? How can it's steps be manually done?
ping pong...
Can i install my own rom on samsung ace?????
anybody knows how to make a ROM customized and make a "update.img" to run on a un-rootable device? I know when you backup a linux image for example ubuntu, this image will run on all other PCs, the image will automatically knows the new PC's drivers and adapt everything with that, is it what happening to an android too ?
---------- Post added at 08:36 AM ---------- Previous post was at 08:33 AM ----------
and pls let me know how to open/edit a "update.img" file, thnx
Question
androidcustomrom said:
How to create your own ROM update.zip for the T-Mobile MyTouch 3G
Things you will need to perform this:
Java SE Dev Kit from Sun. java.sun.com
May need Cygwin with zlib0 package, from cygwin.com
This will give you Android 1.6 with all the Google applications, Root access.
I never found one place where all this information is all together, so that is why I compiled this together.
Now anyone can do this themselves.
Thanks to all the hard work others have done before this.
1.
First Root your phone and install a new Recovery image, either Amon Ra or Cyanogens Recovery image.
Instructions for one-click root: http://theunlockr.com/2009/08/22/how-to-root-the-mytouch-3g-or-g1-in-one-click/
2.
Download the Android 1.6 System image from
http://developer.htc.com/google-io-device.html
extract the contents of signed-google_ion-img-14721.zip.
3.
You now need to extract the contents of system.img using a tool called unyaffs. The source code is here:
http://code.google.com/p/unyaffs/downloads/list
Or download a prebuilt win32 version here.
http://jiggawatt.org/badc0de/android/index.html
Note you may also need cygwin1.dll and cygz.dll (zlib0 package). Found at cygwin.com
Of course if you already have Cygwin installed with the GCC packages, you can just compile it yourself. Then also
if you comment out the line 67 to "// symlink(oh->alias, full_path_name);"
then it will not create the copies of the symbolic link file, and you will not have to worry about deleting duplicate
symbolic link files later.
Now in the directory where system.img exists, create a new directory called "system"
go into the "system" directory.
type the following command:
unyaffs ..\system.img
That should extract all the files from the system.img file into the system directory.
4.
Now we just need to clean up some items. Since the system.img is a linux file system, it has symbolic
links built into it, but when we extracted it, it just created duplicate files, if you used the prebuilt unyaffs.exe.
So we can just delete the duplicates and have a script recreate the symlink on install.
So we need to delete some extra files from the system\bin directory.
Run the attached DeleteExtras.bat file from the same directory where system.img is in.
If you notice, all the files it deletes are 28 byte files, and if you open them in notepad only contain:
"!<symlink>toolbox..."
And we will remake the symbolic link when it is installed.
5.
Now from the directory where the system.img is, enter the following commands
mkdir META-INF
mkdir META-INF\com
mkdir META-INF\com\google
mkdir META-INF\com\google\android
Now copy the included file "update-script.txt" into the "META-INF\com\google\android" directory
and RENAME it to just "update-script".
This update-script gets run to recreate the symbolic links.
Not sure if these two are needed but they are in some custom ROMs here:
Copy the two files "fix_permissions" and "flash_image" to the "system\bin" directory.
6.
-- Optional --
These add root and Superuser access to the ROM, plus the Terminal Emulator application.
Copy the file "su" from Cyanogen's rom to the folder "system\bin"
Copy the file "Superuser.apk" to the folder "system\app"
Copy the file "Term.apk" to the folder "system\app"
You can also replace the "system\etc\apns-conf.xml" with a more complete one from here:
http://forum.xda-developers.com/showthread.php?t=547718
or here
http://docs.google.com/Doc?docid=0AZNbAmKkmakoZGZxZHNwMnpfMjJkaHg3ejN3eg&hl=en
Turn data roaming off by default by editing line in the build.prop file:
ro.com.android.dataroaming=false
Also to fix the Market program to show "Protected" applications change the ro.build.fingerprint line to the following:
ro.build.fingerprint=tmobile/opal/sapphire/sapphire:1.5/COC10/150449:user/ota-rel-keys,release-keys
Only phones with a fingerprint of a "released" device can access some market applications.
--------------
7.
Now we just need to create a ZIP file for the final ROM
Zip up the following file and two folders:
boot.img
META-INF
system
8.
Now sign the zip file.
See here how to sign a ZIP file for flashing it.
http://androidforums.com/developer-101/8665-how-signing-roms.html
9.
Copy it to your SD card, boot into recovery, wipe, apply the update, Reboot.
You are now running Android 1.6!
Click to expand...
Click to collapse
Could you tell me where I can correct the fake data in the phone like the real RAM is 512 MB but it say 1GB ,can you tell me how to
correct it thanks in advance:good:

[TOOL] odexer

I made this shell script to automatize the odexing process and maybe it could be useful to someone else.
It should be universal, but I only tested it on my phone.
It's not to re-odex a deodexed rom, but to make stock roms compatible odexed files from deodexed files.
Some mods won't work (signature issues I think)
How to use it:
Extract the attached zip wherever you want on your phone.
In the same directory of the script 'odexer.sh' and the directory 'odextools', make a directory named 'deodexed' (actually, it's already there). Inside 'deodexed' create two directories: 'framework' and 'app'. Put there your modded files, each in the respective directory.
You need the original stock odexed files (apk and odex) and all the '$BOOTCLASSPATH' files (see the note below). The script was intended to be used on odexed rom, but I made it adaptable: in the script change the variable 'moddedpath' with the path to the directory with the original odexed files, each inside 'app' or 'framework (you can directly copy '/system/framework/' and '/system/app/' from a stock rom if you are too lazy).
(I only tested this script on my odexed stock rom using /system as 'moddedpath')
Here how the directory tree should look like:
Code:
/some/random/path/
|-[COLOR="BLUE"]deodexed[/COLOR]
|---[COLOR="BLUE"]app[/COLOR]
|-----[COLOR="RED"]SystemUI.apk[/COLOR]
|---[COLOR="BLUE"]framework[/COLOR]
|-----[COLOR="RED"]framework.jar[/COLOR]
|-[COLOR="GREEN"]odexer.sh[/COLOR]
|-[COLOR="BLUE"]odextools[/COLOR]
|---[COLOR="GREEN"]busybox[/COLOR]
|---[COLOR="GREEN"]dexopt-wrapper[/COLOR]
|---[COLOR="GREEN"]zip[/COLOR]
You need to run the script as root from 'adb shell' or 'Terminal emulator'.
If you put the script in your vfat formatted sdcard, you won't be able to change its permissions, so, in order to run it, you need to pass its path to 'sh' as argument:
Code:
sh /sdcard/somepath/odexer.sh
It will create in the same directory a directory named 'odexed-DD-MM-hh.mm.ss'.
The script will automatically skip files with no odex (framework-res.apk should be always skipped, I think).
It's important to keep everything in the same place, because I used relative paths in the script.
Enjoy
________
To see your $BOOTCLASSPATH files, run from 'adb shell' or 'Terminal emulator:
Code:
echo $BOOTCLASSPATH
or open your /init.rc
Thank you
Thank you for guide. But some points were gone over my head
I found this one. Its one of the simplest method.
forum.xda-developers.com/showthread.php?t=1348062
vishal24387 said:
Thank you for guide. But some points were gone over my head
Click to expand...
Click to collapse
Which point? This?
It's not to re-odex a deodexed rom, but to make stock roms compatible odexed files from deodexed files.
Click to expand...
Click to collapse
loSconosciuto said:
Which point? This?
Click to expand...
Click to collapse
actually I am noob in case of android's coding technical language. Its not ur fault

[TOOL/GUIDE]1by1_ReOdexer - Make a new ODEX file

WHAT IS THIS, AND WHAT IS IT FOR?
This is a guide for creating a new odex file from a deodexed file, one at a time – manually, or with the tool provided. There are tools/methods for doing the entire system at once, but I have not had any luck with those. Plus, typically, one does not need the entire system re-odexed. This is more for those who want to personally mod their stock odexed systems, or create an odexed ROM maybe.
For starters, you can get away with modding a lot on an odexed system, without needing to deodex. You really only need to deodex in order to edit the smali files within the classes.dex (which is required to achieve the cooler mods). See cogeary’s great guide for deodexing tips.
-------------------------
SCRIPT METHOD (using the 1by1_ReOdexer):
I made this script to speed up the process a little bit (thanks! to jimbridgman and cogeary for their input).
NOTE: This could hurt your phone if you don't place your original files (the ones that are currently running on your odexed system) in the 'orig-odexed' folder…
Requirements:
Windows OS (for now – Linux coming soon)
odexed system
root
busybox installed
DOWNLOAD the 1by1_ReOdexer_v2.0.zip for Windows
Unzip it on your desktop or other convenient place (with no spaces in the file path), and read the README.txt.
NOTES
-It will show a few failed processes right when the script starts - it's just trying to clean stuff that isn't there..
-This will not push the new modded files to your phone - but, the re-odex process needs to take place in the /system, so this script does a quick switcheroo by pushing the deodexed file to your running odexed system, then replaces the originals (that's why you must place copies of the odexed ones from your system to the 'orig-odexed' folder - I plan on automating that too eventually) - that's also why you may need to reboot afterwards to straighten things out
-It still needs A LOT of work... but it does the job
MAJOR NOTE: The script is currently set up based on Motorola’s ICS bootclasspath.
To change the file name/path and/or the bootclasspath, right-click on the .bat file and open with a text editor (preferably something like Notepad++) and edit accordingly. The bootclasspath was taken from /init.rc.
-------------
MANUAL METHOD:
I will use the services.jar in this example. Just change the file name and path to existing .odex accordingly for other files. (thanks! to jhotmann for helping me to nail down this method)
Requirements:
odexed system
root
adb
busybox installed
dexopt-wrapper
Put this dexopt-wrapper file in /system/bin with 775 permissions:
X X X
X....X
X....X
Put the deodexed services.jar (or other jar/apk file you want to make a new odex of) on the root your /sdcard (on some phones that means internal storage).
Make sure USB Debugging is enabled.
Put your USB connection to MTP or PTP mode.
The bootclasspath is located in the /init.rc file at the root of your phone. Just make sure that all jars listed in init.rc are actually in your /system/framework folder and only include those in your bootclasspath in the command below. The one from Moto A2/Razr/other ICS is used below (minus the extra jar paths). To replace it with that of a different device, change the word bootclasspath with yours, using the path style as shown in the example below: dexopt-wrapper services.jar new.odex bootclasspath...
Connect with adb (do a adb devices check to make sure you're all good).
To create the new odex, enter the following one line at a time:
Code:
adb shell
su
cd /sdcard/
dexopt-wrapper services.jar new.odex /system/framework/core.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/framework-ext.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/apache-xml.jar:/system/framework/filterfw.jar:/system/framework/com.motorola.android.frameworks.jar:/system/framework/com.motorola.android.widget.jar:/system/framework/com.motorola.frameworks.core.addon.jar
To copy the signature from the existing odex (change path to /system/app/.. if necessary):
Code:
busybox dd if=/system/framework/services.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
Done! Rename new.odex (created on your /sdcard) to services.odex since that is your new signed odex file... and move to your phone using the method of your choice.
---------------------
CHANGE LOG:
Code:
11/7/12 (v2.0)
-more automated
-changed the location where the new odex is made
-thanks to [URL="http://forums.acsyndicate.net/showthread.php?113-Re-Odexing-script&p=1369&viewfull=1#post1369"]tanimn[/URL] for the hint
-thanks to [URL="http://forum.xda-developers.com/showthread.php?t=1879128"]alkhafaf[/URL] for his bat files that I got ideas from (his script didn't work for me)
8/25/12 (v1.0)
-initial release
Thanks to the following for testing!:
-A2Trip (formerly DX2Trip) on the A2 ICS
-RETIEF on the RAZR Maxx ICS
-iwabashu on the RAZR ICS
(I tested it on GB - but I am not high-fiving myself :D)
-----------------
Some vague notes on what to do next:
Depending on what you are after by re-odexing, there are different routes. For example, if you only edited or copied smali files, then you only need the new.odex file. Meaning that all of the smali code was inside of that classes.dex of the deodexed file on your sdcard, and you just made that into a new odex file (and copied the signatures from the existing .odex in /system).
If you have a deodexed apk with more edits than just smali (you could really just copy those edits over to your existing odexed apk with 7-zip or similar), but – if you want to, you will need to remove the classes.dex from the deodexed apk, and make sure that the signatures (/META-INF folder) and AndroidManifest.xml are the same as your existing apk (check, and or copy with 7-zip or similar).
.
.
.
Good job on this!
Mods, am I crazy or are we in need of a separate "stickied" section here"?
Please stickify...
An Edit: I'm glad were seeing so many great guides here in this forum, before long, we'll have a directory that other forums will envy -if not already.
Sent from my SAMSUNG-SGH-I747 using xda premium
Updated the tool (not the guide).. eh, it's still a work-in-progress but gets the job done

[TOOL] Windows tool for patching services.jar for V6 SuperCharger (0.9.0.6)

temporarily "abandoned" .. please use Zep's ultimatic jar power tools instead.
----------------------------------------------------------------------------------------------------------------------------------------------
I hate that Zeppelinrox's thread is being cluttered with OT questions about this.. so opening a new thread. Please post any JellyScreamPatcher.exe questions here. Thanks.
----------------------------------------------------------------------------------------------------------------------------------------------
[experimental] Windows tool for patching services.jar for V6 SuperCharger
Opening note: When replying to this post, please do not quote it!!! Or quote selectively.
For each fully quoted reply a puppy will die somewhere in the world. If you love puppies as much as I do, you'll stop quoting long posts.. thank you
----------------------------------------------------------------------------------------------------------------------------------------------
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.. LOL I guess you knew it already.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because your phone bootloops. Please
* do some research if you have any concerns about features included in my utility
* before using it! YOU and only YOU are choosing to make these modifications.
* I'm providing no ETA's, though usually I'm responding PM's in a timely manner ;)
*
* While the tool provides some backup functionality, allowing you to roll back to
* a working system, feel free to create a nandroid backup trying this ;)
*
*/
For downloads and changelog, see Post #2
----------------------------------------------------------------------------------------------------------------------------------------------
Preface:
Many of us V6 Supercharger users have been flashing nightlies nightly and dailies daily, resulting in the need for a patched services.jar almost daily since the automatic web patcher no longer works for Android 4.1.1 Jellybean files, we had to stick with manually patching this files as described in Zep's guide here. Eventually Zep prepared several versions of the Jelly_Scream_Smali_Patcher_Test_x.sh script, which does the job perfectly, but the user still has to get his services.jar, extract the .smali files, put them to the phone, put the script to the phone, run it in the phone's terminal, copy the patched .smali files back to the PC etc. etc. and for many of us, this is time consuming (and difficult for others). Time is money, right?
Currently, this tool is using a ported version of the ALL_ROMS_Ultimate_Jar_Power_Tools-Jelly_ISCream+Maximum_MultiTasking_Mods-Smali_Patcher_Test_11.sh script for patching.
So... here an automated workflow, which assumes a few things:
you are running a MS Windows operating system (tested on Win7 x64)
you have Java installed. This was tested with Java7, should run fine on Java 6 as well. In the Q&A section below I provide a link to download Java. Make sure that java.exe is accessible from any folder (is in PATH). Some version of Java 7 installs the binaries into the windows/system32 folder, other versions use different folders (e.g. "C:\Program Files\Java\jre7\bin"), so you need to know where the binaries are. Make sure you have that folder in your PATH. If not, just google how to add a folder to the PATH, there are many tutorials on the web.
[optional] you know how to connect your phone to the PC via USB
[optional] you have ADB drivers installed (either via Android SDK or from your phone's manufacturer)
[optional] you know how to enable USB debugging in your phone and did that
[optional] the USB connection mode is NOT "mass storage" (for the online mode) - please set it to "Charge only" or "None" (varies from device to device)
Before you start:
The following needs to be done only once. Of course, when Zeppelinrox updates his shell script, I'll be updating my tool and this guide to provide a new download file.
download the 7zipped tool (single archive) to your PC . Make sure you always download the latest version (link in the changelog)
extract it to an empty folder (e.g. c:/super/ .. just like in the ICS Guide) so that you get a nice folder structure like this - see explanations for the folders as well:
Code:
C:.
│ JellyScreamPatcherV6_0.9.0.6.exe
│
├───adb
│ adb.exe
│ AdbWinApi.dll
│ AdbWinUsbApi.dll
│
├───backup
├───cwm
│ signapk.jar
│ testkey.pk8
│ testkey.x509.pem
│ update.odex.zip.empty
│ update.zip.empty
│
├───dist
├───framework
├───odex
│ dexopt-wrapper
│
├───scripts
│ deodex-pusher.sh
│ dexopt-wrapper.sh
│
└───smali
baksmali
baksmali.jar
smali
smali.jar
version.txt
Before we start, I'll explain the folder structure.
Code:
adb - support folder, includes google's adb tool
backup - this folder will include your old files
cwm - support folder, includes files for generating cwm compatible update.zips
dist - this folder will include the patched files for further processing
framework - this is the working folder, where files will be compiled/decompiled/patched
odex - support folder, includes the binary for odexed ROMs in-phone final patching
scripts - support folder, includes files for online mode
smali - support folder, includes the smali/baksmali tool
How to patch the services.jar file
The following assumes you have a "stock" (or unchanged) services.jar in your phone's ROM or in my tool's framework subfolder .
Note: The current version should still be considered as beta-release. While it works for me (most of the computer stuff works when I'm near it, my family has been puzzled about this since long ago.. LOL), it may not work for you. Please report any bugs you find (thread, PM) and I'll be happy to fix them. Although I inserted many "hit the Enter" prompts into the tool, it's always good to run the tool from a console so that you can keep the output in case you flash through the workflow too fast
Also, the tool maintains an activity.log file where it flushes messages about what's happening. If you encounter a bug, send me this file. Please do not copy/paste the log contents into the thread!!! Attach it. Or upload to any cloud service and send me the public URL.
Click to expand...
Click to collapse
Tip: When running the tool, feel free to enlarge the command prompt window vertically
Click to expand...
Click to collapse
After running the tool and passing the initial screen, you will be presented with a choice between online and offline mode.
Online mode
Online mode assumes that the phone is connected via USB. In this mode, the tool can pull all the information from the phone. Not only the files, but system variables, as well as some debug info (e.g. is the ROM odexed?)
Connect the phone via USB
Enable connection mode "Charge only" or "None". This won't work, if the phone is in "Mass Storage" mode!
Sit back and enjoy (and don't forget to answer the tool's questions!)
After patching there will be a warm reboot
Offline mode
Offline mode means, that there will be no interaction of the tool with the phone via USB. You need to do all the file transfers and in case of odexed ROMs, the final in-phone patching, manually. Also you will have to enter some other information into the tool manually.
make sure to copy your /system/framework/services.jar to the tool's framework folder. If you have an odexed ROM (e.g. stock), copy the whole /system/framework folder contents to the tool's framework folder.
make sure to know your system's version because the tool will ask for it
make sure to know your BOOTCLASSPATH variable. It can be pulled from the phone using the command
Code:
adb.exe set | grep BOOTCLASSPATH
make sure you know if the ROM is odexed or not
After patching, you will need to transfer the patched files to the phone and perform manual patching/replacement:
Odexed ROM:
For odexed ROMs, there is some more patching required that you can do in the phone.
copy services.jar from the 'dist' folder to the sdcard
copy 'dexopt-wrapper' from the 'odex' folder to the sdcard
copy 'dexopt-wrapper.sh' from the 'scripts' folder to the sdcard
Make sure they are in the card's root folder !!
In the phone, open Script Manager or any other app that can run shell scripts with superuser rights.
Open the app, run the dexopt-wrapper.sh script. A warm reboot may occur, since the script will restart the framework
Reboot to recovery, Clean Cache, Clean Dalvik Cache
That's it
Deodexed ROM:
update-signed.zip in the dist folder
Copy this file to your sdcard, then reboot to cwm recovery and install it from there. Then do a Dalvik Cache wipe, Cache wipe and reboot.
services.jar in the dist folder
You can copy this file to phone's /system/framework folder and replace the existing one. Make sure that the new file will have owner/group 'root' and permissions 644. Then reboot to recovery, clean Cache & Dalvik Cache.
Rollback
In case something goes wrong, there should be a message about that in the activity.log file.
Feel free to send this file to me - either attach (not paste!!!) the file to a post in this thread, or upload it to any of the cloud services and tell me the URL. I'll take a look.
Before patching, the tool creates backup of the files as a CWM recovery compatible update.zip file. It will sit in the backup folder. This is your way back to a working system. Of course, you can do a nandroid backup..
So what is the tool actually doing?
Very easy to explain.
it pulls the services.jar (and odex files if needed) from your phone to the working folder (or takes an existing one that you put into the folder)
it uses the baksmali.jar to decompile the services.jar/odex
creates a backup of the unchanged files
it runs a ported perl version (and compiled to exe) of Zeppelinrox's JellyScream patcher script (v6) to patch the .smali files
it uses smali.jar to compile the new classes.dex
inserts the new classes.dex back to the services.jar
[optionally] it pushes the new services.jar back to the phone
[optionally] for ODEXed ROMs, created services.odex from the patched services.jar
[optionally] for deODEXed ROMs, it creates and signs an update.zip that can be flashed in CWM recovery
collects the garbage and exits with a nice message .. LOL
Q&A
Q: It doesn't decompile the services.jar and complains that the .smali files don't exist !!!
A: Yeah, probably your Java is crap. Install Java JRE from Oracle's web (http://java.com/en/download/index.jsp), it will offer you the latest version. I tested with Java 7, but latest releases of Java 6 should work as well.
Q: Getting java errors "not recognized" "not found" and so !!!
A: You probably don't have the java executable in the system PATH. Search the web on how to do this. Example - Java7 installs its binaries to the <system>:\Windows\System32 folder, other versions may act differently and they may have the binaries in a different folder (e.g. "C:\Program Files\Java\jre7\bin") . That folder needs to be in the PATH.
Q: I'm getting bootloops after patching the services.jar with this tool!
A: Make sure to Wipe Cache, Wipe Dalvik Cache and Fix permissions in the CWM recovery. ALso, feel free to send me your original services.jar, I'll take a look. If you have an odexed ROM, send me the whole /system/framework folder and the activity.log file generated while using this tool in "online" mode.
Q: After reboot with the new services.jar file, it says "Android is upgrading" and optimizing apps, even though I did not wipe my dalvik cache.
A: Well, yes that is expected. It will take a while, depending on how many apps you have installed.
Q: Will my phone's memory be blazing fast and effective after this?
A: No, you still have to run the V6 Supercharger script.
Q: Does it run on Linux?
A: Not yet, but it will. I need some more internal testing to release a Linux version.
Q: Does it run on ODEXed ROMs?
A: Yes !!!
Q: Why is the executable so large???
A: Blame PAR long story short, I wrote my stuff in Perl and used Perl to port Zep's stuff as well. Then I compiled the script to exe using the PAR:acker package, resulting in the huge executable. I know, there is another way, to use Activestate's PDK (Perl Development Kit), but the license is approx. $250 and I just don't have that money for spending on a single tool. PDK creates much smaller files (approx. 1/3rd), but for now we have to stick with what we have
Q: Tool fails and in the log I see messages like "failed to copy 'C:/super/backup/services.jar' to '/mnt/sdcard/services.jar': Permission denied"
A: Make sure the USB connection mode is other than "Mass Storage". It can be "Charge Only" or "None", really this is depending on the device you own.
Q: Isn't there a virus included in the executable?
A: LOL.. No. This community gave me a lot since 2007 and I have no intention to harm it in any way. If you are using NOD32 and it starts complaining about the URL to my file I posted above, let me know. ESET support is pretty quick in identifying and fixing false warnings
Enjoy.. and feel free to PM me in case of any questions. I'll keep this post updated all the time.
Thanks
- Zeppelinrox for the V6 Supercharger and the associated scripts/tools
- Rexstor for the ODEX guide
- Android community for all the other tools (smali/baksmali/sign)
- Google for Android... luv ya!!!
If you feel like I deserve a beer for what I've done, feel free to consider donating to Zeppelinrox first as I'm just making his fabulous work a tiny bit more accessible. And if you still think I deserve a beer, you can use the button below.
downloads and changelog
Downloads
http://dev.pepcok.info/jellyscreampatcher/JellyScreamPatcherV6_0.9.0.6.7z
Changelog
0.9.0.6 [2012-09-23]
still using ALL_ROMS_Ultimate_Jar_Power_Tools-Jelly_ISCream+Maximum_MultiTasking_Mods-Smali_Patcher_Test_11.sh
added a proper error reporting when sdcard is not writable in online mode
0.9.0.5 [2012-09-20]
using ALL_ROMS_Ultimate_Jar_Power_Tools-Jelly_ISCream+Maximum_MultiTasking_Mods-Smali_Patcher_Test_11.sh
multiple users with Odexed ROMs have reported this version to work. Feel free to try
with online mode, there is a framework restart after patching, causing warm reboot of the device.
0.9.0.4 [2012-09-13]
using ALL_ROMS_Ultimate_Jar_Power_Tools-Jelly_ISCream+Maximum_MultiTasking_Mods-Smali_Patcher_Test_11.sh
Warning for odexed ROM users - proceed with cautions, many have reported bootloops (even with previous version). Investigating
0.9.0.3c [2012-09-12]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
fixes STUPID bug with storage detection (I hope)
0.9.0.3b [2012-09-12]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
storage detection, as requested by one of the users (thanks Zep for the code! )
fixes in shell scripts for online mode
removal of the -f flag for rm commands
0.9.0.3 [2012-09-11]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
odex: if the baksmali decompile fails (e.g. file missing, although being in BOOTCLASSPATH), the tool will create an alternate BOOTCLASSPATH based on the files that were pulled from the phone and try decompile again. It even this fails, then I guess the world will end in 2012
ui: revamped the whole ui, user is now selecting offline vs online (adb) mode at the beginning
ui: added a proper note for the user to make sure to clean cache/dalvik cache when rebooting for the first time with the new services
ui: added instructions for the user in offline mode (when he wants to do the final steps manually)
internal: added some file exists checking, online (with adb) mode works better now and is prettier
other: as always, please read what the tool says.
0.9.0.2 [2012-09-06]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
instead of using crappy adb commands, the final patching is done via shell scripts in the phone - please help me test that. I already restored my phone's system partition 4 times (since patching a GB MotoDefy+ with ICS HTC Evo services is not healthy, but necessary for my testing), all the final patching seems to work fine here. Tested for both odexed and deodexed files and my phone already hates me
the tool will make a backup of your original services.jar/odex file into a CWM recovery update.zip (will be in the backup folder) .. that's your way back from potential hell
fixed a typo in manual API level selection - thanks for catching
0.9.0.1 [2012-09-05]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
few fixes (shell user detection, trying to implement better /system rw mount )
0.9.0 [2012-09-05]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
initial support for ODEXed ROMs - alpha version. I need testers please ! Since my phone does not have any odexed ICS or JB, I was able to test with sample files from xda fellow members end-to-end, but the real full fledged experience, I can't verify
0.8.9.2 [2012-09-05]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
minor update to capture the system calls, stdout and stderr into the log, for people who have problems with java. Let's see how it works
0.8.9 [2012-09-04]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
updated adb communication
added proper logging
internal preparation for ODEX ROMs (yeah, 0.9.0 will work with ODEXed ROMs !!!)
added framework folder as the working folder (reduces file clutter.. LOL)
0.8.5 [2012-08-27]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_9.sh
update-binary from Titanium Backup
0.8.4 [2012-08-26]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_8.sh
minor fixes only
0.8.3 [2012-08-25]
patcher: Jelly_IScream+Time_Killer_Killer--Smali_Patcher_Test_8.sh
this one should work with services.jar files where the smali files don't include debug information
0.8.2 [2012-08-23]
some more checks for "non-compatible" data, will provide warnings to the user in case of "incompatible" services.jar. Users seeing that message should proceed with caution until the next version. Zeppelinrox is aware of the potential problem.
0.8.1 [2012-08-22]
patching based on Zep's v7 script
resolves patching issue with the services.jar from the Alliance 2.1 ROM for Galaxy Note (GT-N7000)
resolves a weird compilation error when running the executable
0.8 [2012-08-22]
First public version, based on Zep's v6 patcher
Good job and thanks.
Sent from my Galaxy Nexus using Tapatalk 2
FYI I added this to Post 2 of the SuperCharger thread...
B) Equally Effective AND EASIER than A) - use the Jelly ISCream Automatic Patcher for Windows!
This does everything that is explained in this very post - from start to finish! Yep... it does Steps 1 to 9!
I know... it's complicated... this is what you do...
1. Plug in your phone
2. Run the Windows exe to patch and install services.jar!
OK?
Click to expand...
Click to collapse
thanks buddy
I guess tomorrow I'll need a guinea pig ... oh... I mean a tester !!! LOL ... for the ODEX stuff.. it looks good locally, just need to close my eyes for a few hours cuz I can't see anything any longer today.
zeppelinrox said:
FYI I added this to Post 2 of the SuperCharger thread...
Click to expand...
Click to collapse
People are still going to get it wrong....
Sent from my Galaxy Nexus using Tapatalk 2
Thanks for this. Trying it now on my GS3 (running a deodexed Touchwiz rom). After hitting [ENTER], the screen hangs on:
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
Click to expand...
Click to collapse
Did I miss something?
jdhas:
The text you pasted is start of the adb server, the next step after that is waiting for device. Did you have the phone connected to the PC via USB, with USB debugging enabled? I should probably add some text saying that it's waiting for the device
pepcisko said:
jdhas:
The text you pasted is start of the adb server, the next step after that is waiting for device. Did you have the phone connected to the PC via USB, with USB debugging enabled? I should probably add some text saying that it's waiting for the device
Click to expand...
Click to collapse
I'm definitely connected, and I definitely have USB debugging enabled. I am, admittedly, trying this from my work computer, which may be too "locked down" for this sort of fun. Will attempt again when I get home.
well, the easiest thing to check (even at work) is to run
Code:
adb devices
manually from the console. This way you can check if adb is seeing the device.
EDIT: What the tool is doing, is the following:
Code:
adb\adb.exe start-server
adb\adb.exe wait-for-device
adb\adb.exe pull /system/framework/services.jar framework\services.jar
so my assumption is, if it fails in the second command, it's waiting for the device.
jova33 said:
People are still going to get it wrong....
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
That's why the next update might have a little surprise if they run the jelly iscream script without the smali files in the same folder... hehehe... makem scream for realzzz
Looking forward to the update....
Sent from my GT-N7000 using Tapatalk 2
Well... here's what may be possible...
http://forum.xda-developers.com/showpost.php?p=31137111&postcount=5066
I just quickly made a new services.jar hack.
Breaking the lowmemorykiller so that it doesn't kill anything was easy... just one simple edit LOL
I'm hoping that increasing max hidden apps from 15 to 50 will work... that would be optimal
===============================
Oh yeah I had used a goo.gl link in Post 2... http://goo.gl/OfOOE+
Already a nice number of clicks lol
Great work. Looking forward to your next update for odexed roms. :thumbup:
Sent from my Pro using xda app-developers app
jdhas said:
Thanks for this. Trying it now on my GS3 (running a deodexed Touchwiz rom). After hitting [ENTER], the screen hangs on:
Did I miss something?
Click to expand...
Click to collapse
USB debugging enabled? Phone plugged it?
Close the win app and try again. It's hung in a couple of spots for me. I just close it and run it again and it'll go through the second time
Sent from my Nexus 7 using Tapatalk 2
I need help. I get the following error message when the patch is running on my computer.
"Important files are missing after decompiling services.jar See the log for details. Exiting..."
Log attached below. The log shows me trying twice with the same error message causing exit. Please advise.
Edit: I'm on Jellybean CM10 with the Droid Incredible.
Do you have java installed on the PC?
Sent from my Galaxy Nexus using Tapatalk 2
jova33 said:
Do you have java installed on the PC?
Click to expand...
Click to collapse
Java6 Update 26 (64-bit) shows as installed under programs.
folks, who have problems with this
Important files are missing after decompiling services.jar See the log for details. Exiting.
Click to expand...
Click to collapse
Can you download the new minor update? I uploaded 0.8.9.2 which adds some more logging and is a bit more "bulletproof" in the system calls.
Please let me know and send (or attach) logfiles if it goes wrong.. Thanks
Good news !!!
I successfully broke my device when I end-to-end tested the ODEX patching on my Motorola Defy+, using test files from a HTC EVO
But that was expected and I did it willingly.
Flashing the stock SBF now, will do one last final test and then (within 1-2 hours) upload the ODEX-capable patcher

[TOOL]Universal Deodexer for Bash

WARNING: I am not responsible for you breaking your phone, you need to make sure you have a PROPER backup before using this tool, and if you don't know what a proper backup is, then I suggest you do more research before attempting something like this.
ABOUT
This is a bash script I just wrote, it can deodex your entire phone, or just a specified file, it can also restore the original odexed files. You can just drop the files in the working directory, or you can add them to your global $PATH variable, either way it will be able to work (even if you use a symlink for the $PATH variable, it'll still be able to detect where the included smali and baksmali files are).
DEPENDANCIES
Bash (obviously), 7z, adb, and realpath (might not be installed by default on most Linux distros)
Code:
sudo apt-get install p7zip && sudo apt-get install realpath
IMPORTANT
I consider this script to be in Beta, even though I tested it thoroughly on my phone, until more people test it you need to be prepared that it may not work 100% on your phone, and if it doesn't PLEASE copy and paste the command output, I want this script to work on as many devices as possible but that requires people to let me know when it doesn't work for them.
FOR THIS TO WORK PROPERLY MAKE SURE YOU ARE BOOTED TO RECOVERY WITH THE SYSTEM PARTITION MOUNTED
Example Usage
deodex --all
-This will scan your phone for odexed files, pull them, deodex them, push them back, and delete the odex files from the phone
deodex <file_name_without_extension>
-This is not as useful, it does the same thing as the --all option, except it only deodexes the specified file
-Example: deodex SystemUI (notice you leave off the extension, THIS IS IMPORTANT, file name ONLY without extension)
deodex --restore
-This will restore all your original files back to the phone (as long as you didn't delete the original folder that was created when deodexing :silly
The project is located on GitHub:
https://github.com/tgaurnier/UniversalDeodexer

Categories

Resources