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 ?
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
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
Hello All,
I was trying to get the option of waking the phone using volume keys. I am on ICS (Asia Retail) on my MB865. Editing the Keylayout files did not work. It had worked for me before, but now they did not probably since my phone is locked by a password lock screen due to corporate policies. I tried to decompile android.policy.odex and change isWakeKeyWhenKeyguardShowing. But after I compiled it back and put the changed odex back to system/framwork. But strangely I got a boot loop. I tried a battery pull and also cleared cache and Dalvik cache. But could not get it to boot. Finally I had to restore /system from a backup.
I have detailed my steps below. Can anyone please point out what I am doing wrong here.
1. Get /system/framwork out and put it in a folder
2. Download smali-1.4.2 and baksmali-1.4.2 utilities.
3. I extracted android.policy.odex by java -jar baksmali.jar -d framework -x android.policy.odex
4. I changed the file KeyguardViewMediator.smali (removed lines for 0x18 and 0x19 under the switch case of the method isWakeKeyWhenKeyguardShowing(IZ)Z
5. Packed the odex file back by java -jar smali.jar -o android.policy.odex out
where "out" is the previously extracted folder
Then I replaced the android.policy.odex back to /system/framework
Please help! My power key is already showing some signs that it does not want to stay with me any more.
Thanks,
Sayantan
Re: Solved - Volume Rocker wake via android.policy.jar
Okay! I have been a total noob. I did not read enough about odexing and deodexing.. should have read more before I posted. Here's what I did (in short), thanks to Jordan Hotmann from http://www.jordanhotmann.com/2011/08/how-to-change-default-orientation-of.html
For detailed explanations, please visit the above website.
1. Downloaded smali and baksmali tools
2. Downloaded and installed dexopt-wrapper (just Google)
3. Extracted /system/framwork
4. Extracted android.policy.odex (used api level 15)
5. Modified the required files - KeyguardViewMediator.smali (removed lines for 0x18 and 0x19 under the switch case of the method isWakeKeyWhenKeyguardShowing(IZ)Z
6. Repacked the folder to classes.dex
7. Integrated classes.dex into android.policy and pushed the latter to /sdcard/
8. Created new odex file from android.policy.jar (dexopt-wrapper android.policy.jar new.odex BOOTCLASSPATH)
Got the BOOTCLASSPATH from init.rc which I pulled from the phone root directory
9. Copied the "signature" from the original .odex file to the newly created one (busybox dd if=/system/framework/android.policy.odex of=new.odex bs=1 count=20 skip=52 seek=52 conv=notrunc)
10. Replaced android.policy.odex
cd /system/framework/
busybox cp /sdcard/new.odex android.policy.odex
busybox chmod 644 android.policy.odex
(I already had my keylayout file modded. So not sure if they are actually required after the above mod)
Please take a nandroid backup before attempting this. I am not responsible for any damage being done to your phone as a result of this!
Thanks again to XDA forums and Devs here and Jordan Hotmann (from the link above)
Can't say about ICS but in JB we use the lab menu *#*#6686#*#* to have the functionality of the volume key waking the phone.
Right. I used the same when I was on the JB leak. It doesn't work on ICS. However, last time I was on ICS, changing the key layout files sufficed with the lock screen set to none. This time my phone has to have a password lock screen due to corporate policy and editing android.policy.jar seems to be the only way.
Regards,
Sayantan
Sent from my MB865 using xda app-developers app
Ok, in that case I learned something new to use in ICS as per your tutorial below :good:
Hi guys.
I stumbled upon this thread while researching info for modding framework-res.apk and android.policy.jar. I'm trying to make some changes to the power menu.
I'm pretty much a noob and so far I managed to get framework-res.apk to compile and install successfully, but android.policy.odex is giving me nightmares My rom is odexed, and no matter what I do I always end up stuck at boot.
So I tried to just baksmali and smali it again with no changes whatsoever, then dexopt-wrap from the phone exactly like the guide SMONDAL84 linked says, dd the old signature into the new odex file and finally move it to /system/framework.
Even that isn't working, so I wonder what am I doing wrong?
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