Hi guys,
Since there seems to be some demand for this kind of thing, I decided to post instructions on a mod I made a while back. This gives you the option of choosing between Samsung's GlassLock (i.e. the default TW lockscreen) or the stock keyguard of Android 2.1.
The method involves de- and re-compiling /system/framework/android.policy.odex, and you should have some basic knowledge of the tools involved (i'm not gonna spell out every step). Before beginning, take a backup of android.policy.jar and android.policy.odex (or preferably the whole framework folder). You should issue the commands in recovery mode.
Required tools: rooted SGS (I've done this only with JM2, and the code *might* need modifying for other roms, though I doubt it), adb, smali/baksmali, dexopt-wrapper, text & hex editor, winrar (or any jar editor).
Here we go:
1. Use adb to pull out /system/framework/android.policy.odex and other framework .odexes (required for de-odexing). Might be wise to backup the whole /system/framework/ directory at this point.
2. Use baksmali to deodex the file (java -jar baksmali.jar -x android.policy.odex -o android.policy). Baksmali will let you know if you are missing any of the framework .odexes.
3. Open LockPatternKeyguardView.smali and find the method getLockScreenMode()Lcom/android/internal/policy/impl/LockPatternKeyguardView$LockScreenMode;
4. Replace the contents of this method with the attached file getLockScreenMode.txt.
5. Save LockPatternKeyguardView.smali.
6. Use smali to compile the files back to classes.dex (java -jar smali.jar android.policy -o classes.dex)
7. Pull /system/framework/android.policy.jar, add the newly created classes.dex to it, and push it back to the device.
8. On your phone, do:
# cd /system/framework
# dexopt-wrapper android.policy.jar patched.odex /system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
Ouput should be:
--- BEGIN 'android.policy.jar' (bootstrap=0) ---
--- would reduce privs here
--- waiting for verify+opt, pid=3105
--- END 'android.policy.jar' (success) ---
9. You now have odexed the file into patched.odex. However, the signature of the file is not compatible with the other framework files, so you need to fix it. I think the proper way should be to re-odex all the framework files, but I haven't encountered any issues with just patching the signature.
10. Open the original android.policy.odex in a hex editor, and copy signature bytes from offsets 0x34-0x47 to the new patched.odex, and save it. Optionally, you can also do this on your device by issuing the command:
# dd if=original.android.policy.odex of=patched.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
Where if="..." is the original file, and of="..." is the file you want to patch.
11. Push the patched and hex-edited file to /system/framework/android.policy.odex and restore the original /system/framework/android.policy.jar.
12. Reboot and enjoy your good ol' keyguard
Some notes:
- If you want to revert back to Samsung's lock screen, just create a file called /data/local/enable_glass_lock ("adb touch /data/local/enable_glass_lock").
- By default, the menu button will also unlock the screen. To disable this behavior, you have to modify /res/values-hdpi-v4/bools.xml in /system/framework/framework-res.apk, and change the value of <bool name="config_disableMenuKeyInLockScreen">false</bool> to true. Can also be done by modifying code.
On a side note, the code for Smart Unlock (present in some Samsung phones) seems to be in there... it would be an interesting project to get that working
Great stuff, i've been waiting for someone to find out how to get rid of the glass screeen since first day.
Sadly i'm a real noob so it is useless for me.
Maybe someone can create an apk or a win program out of this.
thank you !
but could you explain it better ?
toca79 said:
Maybe someone can create an apk or a win program out of this.
Click to expand...
Click to collapse
+1 for an automated solution, provided method seems too hard for me.
Excellent post Ateisti! We need more of these advanced mods for SGS.
Ateisti said:
adb, smali/baksmali, dexopt-wrapper,
Click to expand...
Click to collapse
Could you provide links to this?
Or are those sw included in the Android SDK?
I want to do 6-step but I see:
Code:
C:\Users\Konrad>"C:\Program Files (x86)\Java\jre6\bin\java.exe" -jar "C
:\Users\Konrad\Desktop\smali.jar" android.policy -o classes.dex
android.policy\com\android\internal\policy\impl\LockPatternKeyguardView$LockScre
enMode.smali[0,-1] The file must contain a .class directive
What's wrong?
EDIT:
I've changed a wrong smali.
In step 10, how do i copy the signature bytes with my hex editor? I dont understand what offsets 0x34-0x57 is...
10. Open the original android.policy.odex and copy signature bytes from offsets 0x34-0x47 to the new patched.odex, and save it.
Click to expand...
Click to collapse
Can anyone who successfully coped with getting this done following the instructions above please do a video showing us how to do it, I think that might help us a lot... thanks a lot on behalf of us noobs
Stefanauss said:
Could you provide links to this?
Or are those sw included in the Android SDK?
Click to expand...
Click to collapse
ADB is included in the SDK, Smali and Baksmali can be downloaded here and dexopt-wrapper for example here.
qwas00 said:
In step 10, how do i copy the signature bytes with my hex editor? I dont understand what offsets 0x34-0x57 is...
Click to expand...
Click to collapse
It means to seek to the 52nd byte (or 0x34 in hex) of the file, and then copy and replace the following 20 bytes to the second file. But you can also do it on the device by issuing this command (I think busybox is required):
dd if=original.android.policy.odex of=patched.android.policy.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
...where "if=..." is the original file and "of=..." is the file you want to patch.
Ateisti said:
Hi guys,
Since there seems to be some demand for this kind of thing, I decided to post instructions on a mod I made a while back. This gives you the option of choosing between Samsung's GlassLock (i.e. the default TW lockscreen) or the stock keyguard of Android 2.1.
The method involves de- and re-compiling /system/framework/android.policy.odex, and you should have some basic knowledge of the tools involved (i'm not gonna spell out every step). Before beginning, take a backup of android.policy.jar and android.policy.odex (or preferably the whole framework folder). You should issue the commands in recovery mode.
Required tools: rooted SGS (I've done this only with JM2, and the code *might* need modifying for other roms, though I doubt it), adb, smali/baksmali, dexopt-wrapper, text & hex editor, winrar (or any jar editor).
Here we go:
1. Use adb to pull out /system/framework/android.policy.odex and other framework .odexes (required for de-odexing). Might be wise to backup the whole /system/framework/ directory at this point.
2. Use baksmali to deodex the file (java -jar baksmali.jar -x android.policy.odex -o android.policy). Baksmali will let you know if you are missing any of the framework .odexes.
3. Open LockPatternKeyguardView.smali and find the method getLockScreenMode()Lcom/android/internal/policy/impl/LockPatternKeyguardView$LockScreenMode;
4. Replace the contents of this method with the attached file getLockScreenMode.txt.
5. Save LockPatternKeyguardView.smali.
6. Use smali to compile the files back to classes.dex (java -jar smali.jar android.policy -o classes.dex)
7. Pull /system/framework/android.policy.jar, add the newly created classes.dex to it, and push it back to the device.
8. On your phone, do:
# cd /system/framework
# dexopt-wrapper android.policy.jar patched.odex /system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
Ouput should be:
--- BEGIN 'android.policy.jar' (bootstrap=0) ---
--- would reduce privs here
--- waiting for verify+opt, pid=3105
--- END 'android.policy.jar' (success) ---
9. You now have odexed the file into patched.odex. However, the signature of the file is not compatible with the other framework files, so you need to fix it. I think the proper way should be to re-odex all the framework files, but I haven't encountered any issues with just patching the signature.
10. Open the original android.policy.odex and copy signature bytes from offsets 0x34-0x47 to the new patched.odex, and save it.
11. Push the patched and hex-edited file to /system/framework/android.policy.odex and restore the original /system/framework/android.policy.jar.
12. Reboot and enjoy your good ol' keyguard
Some notes:
- If you want to revert back to Samsung's lock screen, just create a file called /data/local/enable_glass_lock ("adb touch /data/local/enable_glass_lock").
- By default, the menu button will also unlock the screen. To disable this behavior, you have to modify /res/values-hdpi-v4/bools.xml in /system/framework/framework-res.apk, and change the value of <bool name="config_disableMenuKeyInLockScreen">false</bool> to true. Can also be done by modifying code.
On a side note, the code for Smart Unlock (present in some Samsung phones) seems to be in there... it would be an interesting project to get that working
Click to expand...
Click to collapse
THANX TO ALL YOUR EFFORTS........ can you please attach a screen shot of the lock what you are talking about.. and does it work flawlessly without any sort of a lag.. and is it 100% bugs free?????
Could you also choose any other lockscreen, like WidgetLocker or SimplyLockscreen?
That would be great
Ateisti said:
It means to seek to the 52nd byte (or 0x34 in hex) of the file, and then copy and replace the following 20 bytes to the second file. But you can also do it on the device by issuing this command (I think busybox is required):
dd if=original.android.policy.odex of=patched.android.policy.odex bs=1 count=20 skip=52 seek=52 conv=notrunc
...where "if=..." is the original file and "of=..." is the file you want to patch.
Click to expand...
Click to collapse
Thanks, that worked fine
Thanks! This method worked like a charm. I hated that glass unlock thingy.
However my /system/framework/framework-res.apk doesn't have a value folder, so I can't remove the possibility to unlock with the menu button.
Couldn't find any bools.xml in there at all.
This is replacing the music player controls when the screen is locked, right? It's a nice functionality and would be a pity to loose it.
Otherwise its a great mod and it would be cool if someone can make the One Click LockScreen Changer ;-)
Sent from my GT-I9000 using Tapatalk
thE_29 said:
Could you also choose any other lockscreen, like WidgetLocker or SimplyLockscreen?
That would be great
Click to expand...
Click to collapse
Not as such, but technically it should be possible with some additional coding. I however don't have the time to undertake such a task.
Tharfrin said:
Thanks! This method worked like a charm. I hated that glass unlock thingy.
However my /system/framework/framework-res.apk doesn't have a value folder, so I can't remove the possibility to unlock with the menu button.
Couldn't find any bools.xml in there at all.
Click to expand...
Click to collapse
This might be a ROM version thingy. On my system there are actually two XML files with that same setting, but only one of them works (the one I mentioned in my original post). Just search all your framework-res xml files for "config_disableMenuKeyInLockScreen", and change every instance to true. Should do the trick.
Or if all else fails, just edit the file LockScreen.smali, method "shouldEnableMenuKey()", and make it always return 0 ("return v4" -> "return v6").
mobilx said:
This is replacing the music player controls when the screen is locked, right? It's a nice functionality and would be a pity to loose it.
Otherwise its a great mod and it would be cool if someone can make the One Click LockScreen Changer ;-)
Click to expand...
Click to collapse
That is unfortunately the case. The music controls (as well as the puzzle pieces) are coded into the GlassLock class, so it would required some additional reverse engineering to implement those in the stock keyguard.
4 hours working and it works (jm2).
I'm going to test on the jpc.
EDIT:
I put it on the jpc and it doesn't work.
Did not work with JPC I really want to use the stock lockscreen!
Sent from my GT-I9000 using XDA App
hi guy thanks for your instruction. However I'm using samset's 1.9f which has the ROM deodexed and i found no .odex files but .jar files. Is there a way to workaround this? I'd really love to revert back to stock eclair lockscreen~!
billytcf said:
hi guy thanks for your instruction. However I'm using samset's 1.9f which has the ROM deodexed and i found no .odex files but .jar files. Is there a way to workaround this? I'd really love to revert back to stock eclair lockscreen~!
Click to expand...
Click to collapse
same here no odex files...
Related
So, it seems that more people are taking an interest in making custom frameworks. This isn't really a full tutorial, but I thought it would be helpful to just post some tips on how to go about making your own framework-res.apk, save others a bit of time retreading old ground, since the methods are scattered around the site a bit!
Thanks to wdl1908 for prompting me to do this - should really have done this sooner!
Okay, so basic requirements:
Rooted Gen 8 (Uruk or chulri method)
Original Archos framework-res.apk
zip editor
image editing software
.png's to replace the stock ones with
That's about it! I've been using GIMP on Ubuntu for the image editing, and Phatch for batch resizing, but Photoshop will work just as well on Windows.
Edit: Thanks to wdl1908, have found that Gwenview gives much better results when resizing, compared to Phatch or GIMP. Works on both Ubuntu and KDE.
Use your preferred zip editor to unzip the contents of framework-res.apk to your chosen folder. The main folder of interest is "drawable-mdpi".
The Gen 8's use MDPI resolution images (well, A70 and A101 to at any rate. I think someone mentioned the A32 or A43 used HDPI images). Depending on your .png source, you may need to resize the images. I took my images from themes made for the Desire, which is an HDPI device, so I used GIMP/Phatch to resize them.
In terms of resizing, I compared the size of each new png with the original one, and resized. I know p0rkburn just resizes the images to 66%, but I've had problems with some images not coming out the right size that way. The other thing to watch out for is that not all the images need resizing. Also, some of the textfield and tab_select images are different proportions to their phone equivalents, so again watch out for that.
Once you've replaced the images you want to, they need to be put back into the .apk. I used to copy and paste into the framework-res.apk, but that doesn't work for 9patch files. Also, wdl1908's FrameWorkBuilder makes the compile process so ridiculously easy, there is no reason not to use that instead.
To put the new framework-res.apk on the device, I use this method via ADB wireless, which works fine.
Happy theming!
EDIT: 9patch files
These can be a PITA, until you understand how they work. I used the following two sources to finally crack it :
http://developer.android.com/guide/developing/tools/draw9patch.html
http://forum.xda-developers.com/showthread.php?t=580351
If you are changing 9patch files, you have to decompile and recompile using the FrameWorkBuilder.
I prefer using the draw9patch tool, as it lets you check that the 9patch works as expected.
Spent enough time bashing my head against a brick wall trying to sort out 9patch files, so if I can spare anyone else that, feel free to post/PM..
I'll leave this post here for my recommendations that will be more complex when you need to modify xml files.
In short the procedure is a follows (this needs to be expanded)
unpack the apk to framework-res-UNPACKED dir
decompile the apk to framework-res-DECOMPILED (with apktools)
copy framework-res-MOD to framework-res-DECOMPILED
compile framework-res-COMPILED (with apktools)
unpack the compiled apk to framework-res-COMPILED (with 7za)
remove all the files that are present in framework-res-MOD from the framework-res-UNPACKED dir
remove the file resources.arsc from framework-res-UNPACKED
copy all files from framework-res-UNPACKED to framework-res-COMPILED
zip all files in framework-res-COMPILED to the new framework-res.apk
remove the resources.arsc from that apk file
readd the resources.arsc file without compression to the new apk file
Done
The reason this is so complex is that their are bugs in apktools and the signature needs to be preserved.
FrameWorkBuilder v0.3
README.txt
-------------------------------------------------------------------------------------------------------
Place the script FrameWorkBuilder.sh in a directory and execute.
The script will download all the needed tools.
Place framework-res.apk in the dir framework-res-STOCK
Place mods in framework-res-MOD follow the usual directory structure.
Example:
framework-res-MOD
framework-res-MOD/res
framework-res-MOD/res/drawable-hdpi
framework-res-MOD/res/drawable-mdpi
framework-res-MOD/res/drawable
Execute FrameWorkBuilder.sh to apply the mod.
Modded framework-res.apk will be stored in the directory framework-res-MODDED.
-------------------------------------------------------------------------------------------------------
Changelog
-------------------------------------------------------------------------------------------------------
v0.3 Added xml png duplication check to avoid that animations don't work. .9.png support
v0.2 Added mod checks Added compile failure test
v0.1a BUGFIX cp dirs
v0.1 Initial version
-------------------------------------------------------------------------------------------------------
Have fun modding.
wdl1908 said:
I'll leave this post here for my recommendations that will be more complex when you need to modify xml files.
If you don't mind we'll make it a joined tutorial. I have no time now it's time I got some sleep.
Click to expand...
Click to collapse
I have no idea about editing XML files, but that was the next thing on my "To learn" list. I would be very happy for you to add your knowledge to this thread.
Also, if anyone has info to add/corrections to make, please feel free.
Good stuff, guys. At the very least we can make this a three man party.
The more the merrier!
Guys, can I ask what device you're both using?
fisha21 said:
Guys, can I ask what device you're both using?
Click to expand...
Click to collapse
A101IT with archangel root
A70IT with chulri's root
fisha21 said:
The more the merrier!
Click to expand...
Click to collapse
well, if i can do something, i'm here ;-)
wdl1908 said:
A101IT with archangel root
A70IT with chulri's root
Click to expand...
Click to collapse
Cool, thanks. Also, can I ask how you're viewing the XML files? Every program I've tried won't open them - keep getting error messages about invalid character content.
woti23 said:
well, if i can do something, i'm here ;-)
Click to expand...
Click to collapse
Welcome...
fisha21 said:
Cool, thanks. Also, can I ask how you're viewing the XML files? Every program I've tried won't open them - keep getting error messages about invalid character content.
Click to expand...
Click to collapse
You have to decompile the framework-res.apk with the apktools then all is revealed.
I have an A43it, and I find it to use a mixture of the hdpi and mdpi drawables, it is quite odd how they have it. I am drawing this conclusion because I only changed the hdpi drawables, and some things (status bar pull down for one) stayed original. I am going to work some more on it later today and will update here. My method for pushing to the device uses adb like such:
Code:
adb push framework-res.apk /sdcard/framework-res.apk
adb shell
su
stop
cp /sdcard/framework-res.apk /system/framework/framework-res.apk
chmod 644 /system/framework/framework-res.apk (only needs to be done the first time, as the permissions will adopt those when replacing in the future)
start
This causes the device to do a little soft-reboot (does not perform a proper full shutdown/reboot) that is pretty quick, and avoids any f/c situations you may encounter replacing the file while the system is live.
Edit 2 - ok, I just plain old missed the drawables earlier, they are all in hdpi for the A43. Posting screenshots of what I have put together shortly.
daveid said:
My method for pushing to the device uses adb like such:
Code:
adb push framework-res.apk /sdcard/framework-res.apk
adb shell
su
stop
cp /sdcard/framework-res.apk /system/framework/framework-res.apk
chmod 644 /system/framework/framework-res.apk (only needs to be done the first time, as the permissions will adopt those when replacing in the future)
start
This causes the device to do a little soft-reboot (does not perform a proper full shutdown/reboot) that is pretty quick, and avoids any f/c situations you may encounter replacing the file while the system is live.
Click to expand...
Click to collapse
Great I was looking for that.
wdl1908 said:
[*]compile framework-res-COMPILED (with apktools)
Click to expand...
Click to collapse
Getting stuck on the above step. Have got a folder called framework-res-DECOMPILED. When I try to compile it, the first message I get is:
Code:
w:Could not find sources.
It then runs through the process throwing up multiple error messages, and at the end I am left with an empty Build folder. Any ideas? I read on the Apktool thread that you need to add a classes.dex file to apk that don't already have one?
Thought I'd try your method as my primitive version keeps resulting in faulty apk's the last day or two!
fisha21 said:
Getting stuck on the above step. Have got a folder called framework-res-DECOMPILED. When I try to compile it, the first message I get is:
Code:
w:Could not find sources.
Click to expand...
Click to collapse
No problem there thats only a warning.
fisha21 said:
It then runs through the process throwing up multiple error messages, and at the end I am left with an empty Build folder.
Click to expand...
Click to collapse
What error messages?
fisha21 said:
Any ideas? I read on the Apktool thread that you need to add a classes.dex file to apk that don't already have one?
Click to expand...
Click to collapse
What version of apktools do you have?
never needed any classes.dex in framework-res.apk
fisha21 said:
Thought I'd try your method as my primitive version keeps resulting in faulty apk's the last day or two!
Click to expand...
Click to collapse
I'll try to cleanup my script and post it soon.
I just found out we can have custom boot animations on our gen 8 devices.
search for some bootanimation.zip on the web or go to UOT Kitchen and download one from the kitchen. place it in the directory /data/customization/ and reboot. This works even for the stock firmwares with archangel root.
Enjoy
I've added the first version of my FramWorkBuilder script in the second post.
wdl1908 said:
I've added the first version of my FramWorkBuilder script in the second post.
Click to expand...
Click to collapse
Thanks for the hard work!
Gave it a run through but get the following error messages:
Code:
Applying MOD...cp: cannot stat `/home/sarju/FWB/framework-res-MOD/*': No such file or directory
and
Code:
Copy files from UNPACKED to COMPILED that are not modified...cp: cannot stat `/home/sarju/FWB/WorkSpace/framework-res-UNPACKED/*': No such file or directory
The script is located in the "FWB" folder.
fisha21 said:
Code:
Copy files from UNPACKED to COMPILED that are not modified...cp: cannot stat `/home/sarju/FWB/WorkSpace/framework-res-UNPACKED/*': No such file or directory
The script is located in the "FWB" folder.
Click to expand...
Click to collapse
yeah download the 0.1a version and try again.
wdl1908 said:
yeah download the 0.1a version and try again.
Click to expand...
Click to collapse
Ok, think I'm just being stoopid here. Ran the v0.1a, no error messages BUT
If I use the folder structure "framework-res-MOD>drawable-mdpi", the resulting apk just has the original contents of drawable-mdpi. If I use "framework-res-MOD>res>drawable-mdpi", the resulting pak has an empty drawable-mdpi folder.
fisha21 said:
Ok, think I'm just being stoopid here. Ran the v0.1a, no error messages BUT
If I use the folder structure "framework-res-MOD>drawable-mdpi", the resulting apk just has the original contents of drawable-mdpi. If I use "framework-res-MOD>res>drawable-mdpi", the resulting pak has an empty drawable-mdpi folder.
Click to expand...
Click to collapse
the structure should look like this.
Code:
framework-res-MOD
framework-res-MOD/res
framework-res-MOD/res/drawable-hdpi
framework-res-MOD/res/drawable-ldpi
framework-res-MOD/res/drawable-mdpi
framework-res-MOD/res/drawable
but make sure you remove empty dirs.
I suspect it has to do with empty dirs I'll check that....
Nope tthats not it.
can you zip up the files files-to-remove.txt and log.txt in the WorkSpace dir and post them or via pm if thats possible.
'K, so'm new 2 android hacking, but I'd like 2 make a framework-res.apk that includes StarBurst's MotoBlur x-itions here, SAShady's CRT Off animation here, & Gingerbread's Overscroll & MotoBlur Orient8ion animations when they become available. How would I go about merging the MotoBlur x-itions w/ the CRT Off animation, as they're both framework-res.apk files? Also, where mite I extract Gingerbread's Overscroll & MotoBlur Orient8ion files, is it from a stock Gingerbread framework-res.apk & MotoBlur (possibly Photon 4G) framework-res.apk? &, how would I know which files 2 extract? Are there any particular s/w tools that I need?
Thnx.
That's going to be a bit of work. I just went through the learning process of decompiling, modifying, and recompiling .apks myself. I don't have the most efficient method down yet, but I can get you started.
First up, are you using an odexed or deodexed ROM?
Thnx 4 the help.
Sycobob said:
...I just went through the learning process of decompiling, modifying, and recompiling .apks...
Click to expand...
Click to collapse
I'd really dig a link(s) to these resources. &, I'd b usin' the Stock ROM, which I'd imagine is odex'd.
EDIT: Man do I feel foolish. I just typed out way more than I needed to, thinking framework-res.apk was odexed. *sigh*. Oh well, I guess I just started the tutorial I was thinking about posting.
This won't be too hard:
Pull your stock framework-res.apk from /system/framework/.
Gather the other modded .apks
Decompile each of the .apks (luckily framework-res.apk doesn't rely on other stuff, so decompiling is easier)
Drag the modified file(s) from one of the decompiled, modded .apks to the stock one overwriting the old file(s)
Repeat for each mod
Recompile the new uber-modded .apk
Push it back onto your phone
Decompiling
You're going to need Apk Manager for decompiling and recompiling.
Place the .apks you want to decompile in the 'to be modded' folder of Apk manager
Run the script in the Apk Manager folder
Enter 22 to 'Set Current Project'
Pick the .apk you want to decompile
Enter 9 to decompile (no dependencies)
Repeat 3-5 for each .apk
Recompiling
(In Apk Manager) Enter 22 to 'Set Current Project'
Enter 11 to compile
Enter y (this is a system app)
Enter y (I haven't been able to get it to work when I answer no here)
Follow the prompt and delete the files you've modified from the 'keep' folder
Go back to the command prompt and press a key to continue
As for actually finding the changes, you're on your own here. I guess you can look for files with different sizes/modified dates or try to search the forums to see if people mention what they had to change for the mod. If two mods change the same file, you're going to have to open the file and make both sets of changes then toss it into the .apk.
Pro tip: if you have Eclipse set up with the Android SDK, you can go to Window > Preferences > XML > XML Files > Editor and check "Split multiple attributes each on a new line" so that when you hit Ctrl+Shift+F while looking at the messy decompiled .xmls it will instantly format it into a more easily read form. <--This is why I love Eclipse
If you don't know how to push the file back into place, it's a bit of a pain without a modded boot.img that allows you to use 'adb remount'. Copy the .apk somewhere on your phone. From command prompt (with phone plugged in):
Code:
adb shell
su
stop
mount -o rw,remount -t ext3 /dev/block/mmcblk1p21 /system
cp /wherever/your/file/is/framework-res.apk /system/framework-res.apk
mount -o ro,remount -t ext3 /dev/block/mmcblk1p21 /system
reboot
Unless you have CWM and know how to write/reuse an update.zip.
Thnx, Sycobob. I'm just afraid that there'll be an overlap in overwritten files. But'll c.
Sycobob said:
...and updating the archive...ext3
Click to expand...
Click to collapse
&, what d'ya mean by upd8ing the archive, is it signing? Also, I'd thought all of the E4GT partitions were ext4. Didn't even activ8 my E4GT, 'cause'm still tryin' 2 get my TP2 repaired, so I can flip it. Maybe u can help me w/ another Q - I've been lookin' all ovr 4 info on android OS, &'ve been able 2 find what each partition is, using adb cmds, but cannot find, 4 the life of me!, a glossary of sorts on all of androids system files, a la "framework-res.apk is..." I really wanna get n2 android hacking/modding w/o havin' 2 use an app 2 make any & every change that I'd wanna make 2 the OS. Comin' from WiMo, I was very familiar w/ the registry, exploring & hacking it, but there's no real equivalent n android. Also, do go here & vote 4 my Brushed Aluminum Barely There Case with Kickstand suggestion. We're already n 9th place. Thnx again 4 ur help.
System packages don't get signed. By updating, I mean dragging the file into the WinRAR archive which automatically replaces the existing file in the archive, therefor updating it.
All the partitions are ext4. This is where my newbishness shows, I have no idea why I have to use ext3. /dev/block/mmcblk1p21 isn't the correct path either, but it works. In one of ptfdmedics posts he uses the same options. If I use the 'correct' mount -o rw,remount -t ext4 /dev/block/mmcblk0p9 /system it doesn't work. *shrug*
Also, I just realized something I missed in my first post. If you modify an .xml the resources.arsc in the .apk needs to be regenerated. This is done when you decompile and recompile the package. I'll be editing my previous post to reflect this.
As far as a glossary, I have no idea where to find one. I would mind having access to something like that though. If you find something, please post it.
EDIT: don't worry too much about overlap. I'd imagine it'll be easy to find the changes you need to make, then you can just copy+paste the relevant lines. Pro tip: if you have Eclipse set up with the Android SDK, somewhere in Window > Preferences > XML > XML Files > Editor > Check "Split multiple attributes each on a new line" and when you hit Ctrl+Shift+F while looking at the messy decompiled .xmls it will instantly format it into a more easily read form. Adding this to previous post.
Thnx, 4 all of ur help. I've got a lotta wrk ahead of me 2 experiment w/ this stuff. Now, just gotta find the time.
Hi,
Here's a patch for stock odexed XXKI3 to remove vibrate icon from status bar. I don't know whether it's a bug or a feature but I hated it and removed according to instructions from this thread
Thanks to tripc1 for instructions.
RAWI.NO_VIBRATE_ICON.MOD.zip
This one is with:
- CRT Effect
- % Circle Battery mod
RAWI.NO_VIBRATE_ICON.MOD_2.zip
If the first doesn't work then try the second file. I removed the icon having already crt and battery mode applied, so SystemUI.apk was different than stock.
PLEASE DO BACKUP PRIOR TO INSTALLING!
As I can't post in Android Development section (I haven't made 10 posts requirement) I'm posting it here.
This Mod is by vintozver
Removing vibrator icon on ODEXED roms. If you have deodexed one - you will not need to odex the apk again, you will need to sign the apk instead.
The method works for ANY android version actually. You SHOULD backup your device prior doing this. You SHOULD think what you do.
Patch may not work for your device. I did this for SGS2 2.3.6 KI4 (stock).
===
We need:
0. jre/jdk
1. adb
2. apktool (for looking for resources if they differ in your version).
3. smali/baksmali tools
4. dexopt-wrapper (on Device)
Process:
1. Download SystemUI.apk and SystemUI.odex on your computer.
2. Download /system/framework to your computer (framework folder for clarity).
3. BOOTCLASSPATH=framework /opt/smali/baksmali -d framework/ -o dx_obj --api-level 9 -x SystemUI.odex
You'll have dx_obj folder filled with dalvik VM source code (dex-source).
4. Apply patch (see below), which strips out unnecessary code and icon updates.
5. /opt/smali/smali dx_obj/
6. Rename out.dex to classes.dex
7. Put classes.dex to SystemUI.apk file
8. copy updated SystemUI.apk to temporary folder on your device like: adb push SystemUI.apk /sdcard/SystemUI.apk
9. adb shell
# cd /sdcard
# dexopt-wrapper SystemUI.apk SystemUI.odex
# cp SystemUI.odex /system/app/SystemUI.odex
# sync
10. reboot the device (you may issue "reboot" command in the shell as well).
Enjoy!
Patch may be different for some roms and some android versions. The best method of searching the code has been explained in http://forum.xda-developers.com/showthread.php?p=18033801 (unpacking apk within apktool and looking for identifiers). PM me for further help.
You haven't packed the apk mate.
Hm, it's not necessary, the change is only in .odex file....
The solution is based not on removing the actual vibrate icon from apk file but on removing lines of code that shows the icon in status bar.
did NOT work ! :s
Ok, I posted the second file. Now it's with SystemUI.apk but also with other tweaks.
The second file works for sure.
Appologise for inconvenience.
Can you tell us what tweaks please? I'd like to know what I'm doing to my device before making any changes.
Tweaks for batt circle mod and crt effects comes from this thread and this.
After that I patched against vibrate icon according to the instructions.
Strange, I'm on KI3 and don't have the issue with the vibrate icon when vibrate is set to always on.
gr8 second file made me lose notification bar ...
Have you installed any other themes/mods that also modifiy SystemUI.apk?
The file I posted works perfect on pure stock xxki3 from samfirmware.com...
I have KI3... dont have the vibrate icon aftet i set it to NEVER in settings->sound->vibration...
is it the same thing we are talking here? why do we needed a modified app to do the same ?
Yes, but the problem occurs when you want to set the option to ALWAYS and you DONT want to see the vibrate icon all the time
You can upload ONLY remove Vibrate MOD without CRT Effect and % Circle Battery mod, cause I don't want change it.
JKay Settings app has a lot of tweaks, including removal of vibro-icon and it works on any rom.
Thanks for trying anyway.
Sent from my GT-I9100 using xda premium
Is this in the Android market? Can't find it.
Sorry, I didn't read carefully. After installing the file from the first link, everything is in ok! Thanks guys.
ikeny said:
Is this in the Android market? Can't find it.
Click to expand...
Click to collapse
You must install the file from the first link by CFW.
There is also a free app "Contact Vibrate". You can set all calls to vibrate even though you don't have it on "Always Vibrate" under general setting.
With the app, you can even customize the vibration pattern for each contact (if you wish to). If not, it will use a master pattern (your choice) for all.
This is good for unrooted users, or those that don't want to mess with the ROM anymore.
It is possible for KI4?
ikeny said:
There is also a free app "Contact Vibrate". You can set all calls to vibrate even though you don't have it on "Always Vibrate" under general setting.
With the app, you can even customize the vibration pattern for each contact (if you wish to). If not, it will use a master pattern (your choice) for all.
This is good for unrooted users, or those that don't want to mess with the ROM anymore.
Click to expand...
Click to collapse
Thx for the tip, works fine and i don't see the vibrate icon anymore.
Remove vibration/silence icon on any android 2.3.x
Removing vibrator icon on ODEXED roms. If you have deodexed one - you will not need to odex the apk again, you will need to sign the apk instead.
The method works for ANY android version actually. You SHOULD backup your device prior doing this. You SHOULD think what you do.
Patch may not work for your device. I did this for SGS2 2.3.6 KI4 (stock).
===
We need:
0. jre/jdk
1. adb
2. apktool (for looking for resources if they differ in your version).
3. smali/baksmali tools
4. dexopt-wrapper (on Device)
Process:
1. Download SystemUI.apk and SystemUI.odex on your computer.
2. Download /system/framework to your computer (framework folder for clarity).
3. BOOTCLASSPATH=framework /opt/smali/baksmali -d framework/ -o dx_obj --api-level 9 -x SystemUI.odex
You'll have dx_obj folder filled with dalvik VM source code (dex-source).
4. Apply patch (see below), which strips out unnecessary code and icon updates.
5. /opt/smali/smali dx_obj/
6. Rename out.dex to classes.dex
7. Put classes.dex to SystemUI.apk file
8. copy updated SystemUI.apk to temporary folder on your device like: adb push SystemUI.apk /sdcard/SystemUI.apk
9. adb shell
# cd /sdcard
# dexopt-wrapper SystemUI.apk SystemUI.odex
# cp SystemUI.odex /system/app/SystemUI.odex
# sync
10. reboot the device (you may issue "reboot" command in the shell as well).
Enjoy!
Patch may be different for some roms and some android versions. The best method of searching the code has been explained in http://forum.xda-developers.com/showthread.php?p=18033801 (unpacking apk within apktool and looking for identifiers). PM me for further help.
Hello ,
How can I make CWM flashable zip ?
I'm making mod but I can't make flashable zip
Example : I made icon pack for Contacts , mms, video player. Carry the system folder manually. And set permissions. This is very exhausting. I want to make flashable zip.Please make detailed guide. If you help me I would be happy. Thank you.
Arnadel said:
Hello ,
How can I make CWM flashable zip ?
I'm making mod but I can't make flashable zip
Example : I made icon pack for Contacts , mms, video player. Carry the system folder manually. And set permissions. This is very exhausting. I want to make flashable zip.Please make detailed guide. If you help me I would be happy. Thank you.
Click to expand...
Click to collapse
Scripts for creating flashable zips and signing apk/zip files
Just wanted to share a few scripts that I have created for making things a little bit easier. These are bash scripts so they are only going to be functional in a bash shell such as Linux or OS X. If you're running on Windows then you might be able to execute these in Cygwin but I don't know that for certain. You could simply run the same commands in a DOS prompt. You might have to change syntax a little and manually execute them, but the basic process is the same.
I'm going to assume that you are familiar with adb. If not, go learn about it -- download the Android SDK, install the platform-tools, and make sure you can use it! You will probably want it to be in your PATH variable so that you can execute it at any time from a command line.
The next thing you will need is apktool installed, so that you can extract and build .apk files. This can be found here:
http://code.google.com/p/android-apktool/
Now we can move on to using these scripts. There are three files included inside of the scripts.zip file attached to this post. The zip file contains the following:
1. signit: This script will sign a .zip file or a .apk file. If you send in a .apk file as an argument then it will also zipalign the file. It uses testkeys to sign files. 2. createzip: This script will create a skeleton zip file for you. It will print out some instructions to help guide you with the creation. 3. update-binary: This file will never change. It's an interpreter for Edify scripts -- which is what YOU will be writing! You need to include an Edify script inside of the zip file so that recovery knows what exactly you want it to do. This file should be carried around inside of each zip as it converts your Edify script into something that recovery can actually understand and execute.
You will need to make sure that signit and createzip are executable. I would just use chmod +x on them.
The fourth and final thing you need is testsign.jar. You can get it here:
http://code.google.com/p/zen-droid/d...n.jar&can=2&q=
If you look at the top of the createzip/signit script you will see that the the variable binLoc gets set to /usr/local/bin. What this means is that you should place all four of the above files into that location. If you don't like /usr/local/bin then just change the binLoc variable to point to some other directory where you will store these 4 files, and make sure that directory is in your PATH variable.
We'll start by just modifying some images in a single file. For example, let's modify the battery icons in /system/framework/framework-res.apk. I'm not going to add or remove any icons that didn't previously exist, I'm simply going to change a few of them. If you really want to get into modifying some files then you will need to decompile the file in order to change any corresponding XML files (sidetrack -- if you're curious then look in res/drawable at the following 3 files: stat_sys_battery.xml, stat_sys_battery_charge.xml, zzz_stat_sys_battery_1.xml). I'm going to throw this step into the instructions, not because it's necessary here, but because it's a good idea to know how to do it anyway. So let's try and modify our icons!
The basic steps would be something like what I outline below. Before you try this I suggest you make a full backup in recovery just in case something goes wrong. I have reviewed the steps below several times and even walked through them to make sure they are correct so they should work for you.
1. Get the apk file:
Code: $ adb pull /system/framework/framework-res.apk
Copy this file somewhere safe because we are going to push it back to the phone later (you probably won't want to keep the edits we make in step 3 below indefinitely).
2. Decompile it with apktool:
Code: $ apktool d framework-res.apk
3. Update the necessary files:
Step 2 should have unpacked the file into a folder named framework-res. We want to update the necessary files inside of it. The battery icons are all stored res/drawable-hdpi. Navigate to that directory and look for files like stat_sys_battery_*.png. These are the images that get displayed while your phone is running on battery power. The charging images are stat_sys_battery_charge_anim*.png. If you have a set of icons that you want to use then simply paste those icons in and overwrite the existing ones. You can move on to the next step.
If you don't already have images lined up then we can just modify some existing ones to verify that your changes worked. I'll assume you have the stock MikG battery icons (or some way of knowing what your current charge level is) so take note of what your current charge level is, and then modify a few of those images around that area. For example, if your phone is currently at 65% then maybe you will want to modify stat_sys_battery_charge_anim66.png, stat_sys_battery_charge_anim67.png, stat_sys_battery_charge_anim68.png, etc. Just open up these files in GIMP, Photoshop, or whatever. Don't change their size but just change something -- maybe change the color from white to green. Or you could just draw some lines on them. Just make some changes that will be noticeable and then save the files.
4. Package it back up:
Code: $ apktool b framework-res framework-res.apk
5. Sign it using the signit script:
Code: $ signit framework-res.apk
6. Create a skeleton zip file using the createzip script:
Code: $ createzip system/framework framework-res.apk
Note that the createzip script accepts 2 arguments. The first is the directory where the file needs to go, and the second is the name of the .apk file. If you wish, you can run the script without any arguments and it will prompt you for the values. In either case it will give you instructions for what to do next. Here is an example in interactive mode (values that I typed in are highlighted in blue):
Code: $ createzip Please enter the directory that your apk file will go in Example: system/framework system/framework Please enter the apk file to put into this zip Example: framework-res.apk framework-res.apk Creating appropriate directory structure Directory structure complete. A sample updater-script file has been created for you. This sample script will push a file to the /system mount point.
Next steps: 1. If necessary, modify the file /home/gamblor/Desktop/scripts/zip/META-INF/com/google/android/updater-script
2. When script is complete then zip up the directory and sign it: $ cd zip $ zip -r name.zip * $ signit name.zip
7. Make the actual zip file:
Zip up the directory in a recursive fashion using the exact instructions supplied by the script. Note that the createzip script will build a sample updater-script file for you, which says to mount /system and push the files over to it (since that's what most flashable zips do anyway). For this reason, you shouldn't actually need to modify that script at all for the purposes of this tutorial. It doesn't do anything fancy like scroll text across the screen, but it should do the trick to get the file installed. Feel free to open it up with a text editor and see what it does. It will also copy the file framework-res.zip to the appropriate location so everything is in place and we can create our actual zip:
Code: $ cd zip $ zip -r battery-icons.zip * $ signit battery-icons.zip
8. Flash it like you would any other file:
At this point you should have a file named battery-icons-signed.zip. Copy that file to your sdcard and then reboot into recovery and flash it (remember to backup first, if you haven't already). If everything goes well then you should be able to reboot and then check the battery icons for the percentage level that you modified. If everything went well then you should see your modified icons. Congratulations!
As a side note, if you're making mods for yourself and don't plan on creating a flashable zip (or maybe not just yet), you can easily just push the file in adb. This saves you from having to make a zip file, sign it, copy it to your zip card, reboot, and then flash from recovery. So you can just replace step 6 above with the following commands and stop after this:
Code: $ adb remount $ adb shell stop $ adb push framework-res.apk /system/framework $ adb shell start
Obviously since this post was supposed to demonstrate creating a zip file, I included those instructions. But pushing stuff in adb is a shortcut if you're just looking to test things out on a single phone and don't want to waste time dropping into recovery. Remember that file that I told you save away in step 1? Well, if you want to restore your battery icons so that some of them don't have weird colors/marks on them then cd into the directory where you saved the original file away, and then just run the 4 commands above. It should replace the file with the original one, thus setting the battery icons back to the way they were before you ever ran any of the commands above.
Hey everyone.
Here is the deal:
I want to theme my statusbar to make it look like stock jelly bean (from nexus). It's possible to do that using apps such as "ROM Toolbox", but the problem is: The rom must be deodexed and mine isn't.
So I found this "how to" to deodex an apk in another forum:
Code:
Thanks all. Have successfully done what I wanted now
For info, this is what I did.
Created a new folder called 'system' in c:\android-sdk\tools. Obtained the odexed framework folder and placed that in the system folder. Then created a folder called app in the system folder and placed the Rosie.apk and Rosie.odex inside.
Then via cmd, entered the 'system/app' folder, so for me it was...
c:\android-sdk\tools\system\app
From there I ran the following command to end of that path: baksmali.jar -d ../framework -x Rosie.odex
This produced an out folder will all the decompiled .smali files etc. From there I was able to get to the Launcher.smali that i wanted, but to recompile to a classes.dex file you simply run the following command: smali.jar out
This produces an 'out.dex' that you can rename to 'classes.dex'
I am sure there are other commands that you can use to name files accordingly etc but this is what worked for me for what I wanted, so hopefully it will be of some help to people... if they can understand anything I've written.
Is that simple as it looks? I was planning to deodex only the file needed to customize the statusbar. I think it's the framework-res.apk.
Is there any other way to do that?
As I'm new on this deodex stuff, I would appreciate some help.
fndpena said:
Hey everyone.
Here is the deal:
I want to theme my statusbar to make it look like stock jelly bean (from nexus). It's possible to do that using apps such as "ROM Toolbox", but the problem is: The rom must be deodexed and mine isn't.
So I found this "how to" to deodex an apk in another forum:
Code:
Thanks all. Have successfully done what I wanted now
For info, this is what I did.
Created a new folder called 'system' in c:\android-sdk\tools. Obtained the odexed framework folder and placed that in the system folder. Then created a folder called app in the system folder and placed the Rosie.apk and Rosie.odex inside.
Then via cmd, entered the 'system/app' folder, so for me it was...
c:\android-sdk\tools\system\app
From there I ran the following command to end of that path: baksmali.jar -d ../framework -x Rosie.odex
This produced an out folder will all the decompiled .smali files etc. From there I was able to get to the Launcher.smali that i wanted, but to recompile to a classes.dex file you simply run the following command: smali.jar out
This produces an 'out.dex' that you can rename to 'classes.dex'
I am sure there are other commands that you can use to name files accordingly etc but this is what worked for me for what I wanted, so hopefully it will be of some help to people... if they can understand anything I've written.
Is that simple as it looks? I was planning to deodex only the file needed to customize the statusbar. I think it's the framework-res.apk.
Is there any other way to do that?
As I'm new on this deodex stuff, I would appreciate some help.
Click to expand...
Click to collapse
The statusbar is SystemUI.apk.. framework-res.apk deals with all the system pop ups etc.
I would recommend starting off with a deodexed base rom, for eg. wanams..
I would also recommend using apktool rather then baksmali.. iv had great success with apktool..
EDIT: You can find deodexed wanam base rom in general section of this section of the forum.
fOmey said:
The statusbar is SystemUI.apk.. framework-res.apk deals with all the system pop ups etc.
I would recommend starting off with a deodexed base rom, for eg. wanams..
I would also recommend using apktool rather then baksmali.. iv had great success with apktool..
Click to expand...
Click to collapse
Unfortunally, flash a new rom is not an option for me right now.
Is that OK to deodex only ONE apk in order to do what I want? In this case SystemUI.apk.
I just have to deodex it using apktool and put it back to android system?
do what fences do, compile it and put in the split test system, remember it is a system app
XxeAgLeAnGeLxX said:
do what fences do, compile it and put in the split test system, remember it is a system app
Click to expand...
Click to collapse
Sorry, but what is "split test system"?
EDIT: Nevermind... I did some research and now I'm running an AVD on android emulator.
I'll soon test the deodexed SystemUI.apk and post results. Thanks for the tips...