How would I go about making the launcher in my regular Ion ROM have 5 icons across instead of the normal 4? If this isn't in the correct forum, please move.
if you had the source code for ion's launcher it would be as simple as editing the source code of the launcher.apk and recompiling, signing and copying onto the device. You could also compile the source code from the cupcake trunk and try to use that one although im not sure if it would work due to framework differences between the ion and the cupcake branch.
Another way to get this to work would be to dissassemble the classes.dex file using baksmali (by JF), editing it, reassembling using smali (again by JF), signing it and pushing it to the phone. I have tried this method with the Rogers build im using at the moment to no avail, as everything just force closes on boot :S.
Good luck
Hey guys, so this script de-odexe's a rom's apks and jar's.
Many thanks to ofcourse JesusFreke who created this method and the way to do it. Also to coolbho for his apkopt script from which i learnt certain techniques of batch programming. This is crzyruski script updated with jesus freke's latest smali/baksmali update ver 1.2.3
It incorporates detecting the bootclasspath of the odex instead of the user specifying it. For non standard odex however a specific bootclass path must be defined. For example:
According to Jr33 for rosie deodexing u have to add class paths com.htc.framework.jar. Thank him for the new Sense bootclasspaths
For those who dont know, this essentially uses jf's method of baksmali'ing the odex file into smali files, and then recreating the classes.dex file and packaging it into the apk hence disregarding the need for the odex.
*New Menu added
*Ability to specify custom bootclasspath (eg for sense ui)
*Added a java check at the beginning
*Added 1.2.3 smali/baksmali with froyo support(thank jf ofcourse )
*Modified it so if an error is encountered during deodexing, it leaves that file behind so once done you know what files encountered errors
*Added Ignore Mode
*Removed zipalign
*If apk doesnt have corresponding odex, it moves it to deodexed_APK instead of user manually moving it
*Added compression level option
*You can monitor the status of ignore mode / compression level right above the main menu
DISCLAIMER:
Its a batch file so it'll only work on windows.
Convince farmatito to bring this to linux
Thanks
So I checked this out and all ...
It's only apk's, right?
I only glanced but I didn't see anything in there for framework, etc.
If I'm right, then perhaps .. you should just say it de-odex's a ROM's apk's instead of the entire ROM.
~enom~
enomther said:
So I checked this out and all ...
It's only apk's, right?
I only glanced but I didn't see anything in there for framework, etc.
If I'm right, then perhaps .. you should just say it de-odex's a ROM's apk's instead of the entire ROM.
~enom~
Click to expand...
Click to collapse
Oh, yea so it takes the apk and odex and creates the classes.dex and repackages into the apk so u only need the apk. Ok, ill change the post a bit also yes, it doesnt do frameworks cuz i dont think they have odex's and the jar's do but i dunno of a method to do tht
Daneshm90 said:
Oh, yea so it takes the apk and odex and creates the classes.dex and repackages into the apk so u only need the apk. Ok, ill change the post a bit also yes, it doesnt do frameworks cuz i dont think they have odex's and the jar's do but i dunno of a method to do tht
Click to expand...
Click to collapse
Yea ... the jar's have dex's too and can be odex-d and can also be un-odex-d. I personally have never been able to successfully de-odex a fully odex'd framework (but I haven't tried hard enough either ). The main difference is once they are de-odex'd ... you insert the classes.dex into the jar and no re-signing required (as they aren't signed).
Either way, nice script mate. Good Job!
~enom~
enomther said:
Yea ... the jar's have dex's too and can be odex-d and can also be un-odex-d. I personally have never been able to successfully de-odex a fully odex'd framework (but I haven't tried hard enough either ). The main difference is once they are de-odex'd ... you insert the classes.dex into the jar and no re-signing required (as they aren't signed).
Either way, nice script mate. Good Job!
~enom~
Click to expand...
Click to collapse
Ah sweet, something i shall incorporate in the script later on. thanx
so will this script allow you to take an app from say a cliq dump and allow it to run on any android device?
Will this allow you to grab the MyFaves from a TMO rom and de-odex it and install?
Joe333x said:
so will this script allow you to take an app from say a cliq dump and allow it to run on any android device?
Click to expand...
Click to collapse
Emm...no im 99.99% sure it doesnt help tht way. I know that odex's cause customization problems in roms....there are other factors im sure
mrandroid said:
Will this allow you to grab the MyFaves from a TMO rom and de-odex it and install?
Click to expand...
Click to collapse
MyFaves == No Go ... it requires some other form of trickery ... I'm not sure what exactly ... as I did de-odex it and it would not work properly on test-key ROM's like CM, etc.
... So it requires more than a simple de-odex.
~enom~
does your phone need to be connected? I noticed some ADB commands in the script
Daneshm90 said:
Hey guys, so this script de-odexe's a rom's apks.
Many thanks to ofcourse JesusFreke who created this method and the way to do it. Also to coolbho for his apkopt script from which i learnt certain techniques of batch programming
For those who dont know, this essentially uses jf's method of baksmali'ing the odex file into smali files, and then recreating the classes.dex file and packaging it into the apk hence disregarding the need for the odex.
Oh also make sure to place only apk's that have their corresponding odex's. Dont place only apk's !!!!!
Instructions:[WINDOWS ONLY & Phone Must stay connected with adb WORKING]
1. Download http://www.mediafire.com/?mwownkhzm4m
2. Extract to a folder
3. Place all your rom's apk's which have odex's attached to them into that folder
4. Run deoall
5. Copy all the apk's from the deodexed folder into ur corresponding rom app folder
Thanks
Upcoming:
Seperate Framework & apps folder
De-odex framework apk's and jar's (thanx for the tip enomther )
Click to expand...
Click to collapse
So the apk after that has the DEX built in or is dexopt still needed?
wesgarner said:
So the apk after that has the DEX built in or is dexopt still needed?
Click to expand...
Click to collapse
>.<.......................
kingklick said:
>.<.......................
Click to expand...
Click to collapse
Hey I am just double checking
If you're having problems de-odexing the framework is because there's a particular order to it.
If you look at your bootclasspath you'll see the framework files necessary to boot the android system, the rest (whatever's not in there) can be dexopted in any order.
If you're trying to de-odex the framework, you're going to have to backtrace yourself.
Personally, I do:
for i in /system/app/*.apk
unodex
for j in /system/framework/nonCoreJar1.jar /system/framework/nonCoreJar2.jar /system/framework/...nonCoreJarN.jar
unodex
for k in /system/framework/bootClassPathJarN.jar /system/framework/bootClassPathJarN-1.jar /system/framework/...bootClassPathJarN-y.jar
unodex
it requires a couple of reboots along the way to deal with any created dalvik-cache so that it doesn't interfere with the next needed classes.dex
the only turn-off was that it requires a running system to do it (it's not that big of a problem, but porting and then flashing starts getting old after a while).
Has that changed?
Does OP mean you can take the apks, toss them into a folder, and then do it from the computer without the phone?
---edit---
shoot me for not reading.
Daneshm90 said:
Instructions:[WINDOWS ONLY & Phone Must stay connected with adb WORKING]
Click to expand...
Click to collapse
jubeh said:
If you're having problems de-odexing the framework is because there's a particular order to it.
If you look at your bootclasspath you'll see the framework files necessary to boot the android system, the rest (whatever's not in there) can be dexopted in any order.
If you're trying to de-odex the framework, you're going to have to backtrace yourself.
Personally, I do:
for i in /system/app/*.apk
unodex
for j in /system/framework/nonCoreJar1.jar /system/framework/nonCoreJar2.jar /system/framework/...nonCoreJarN.jar
unodex
for k in /system/framework/bootClassPathJarN.jar /system/framework/bootClassPathJarN-1.jar /system/framework/...bootClassPathJarN-y.jar
unodex
it requires a couple of reboots along the way to deal with any created dalvik-cache so that it doesn't interfere with the next needed classes.dex
the only turn-off was that it requires a running system to do it (it's not that big of a problem, but porting and then flashing starts getting old after a while).
Has that changed?
Does OP mean you can take the apks, toss them into a folder, and then do it from the computer without the phone?
Click to expand...
Click to collapse
Yea I would figure as much ... simply b/c one must follow the BOOTCLASSPATH order when odex'ing ...
So Jubeh .. you're saying you've personally de-odex'd an fully odex'd framework b4?
Just looking for confirmation from someone who has personally ... since I'm too lazy to go through that hectik crappy process
~enom~
enomther said:
Yea I would figure as much ... simply b/c one must follow the BOOTCLASSPATH order when odex'ing ...
So Jubeh .. you're saying you've personally de-odex'd an fully odex'd framework b4?
Just looking for confirmation from someone who has personally ... since I'm too lazy to go through that hectik crappy process
~enom~
Click to expand...
Click to collapse
I did it with the tattoo build, but upon boot I would get all sorts of fc's, but I think that was due more to a bad, hasty port than the deodexing. It was also a long time ago when the tool first came out, dont know if there's been newer revisions, so I'll try it again on that funky tattoo rom.
K guys one problem i found after doing multiple apk's is that i need to give the listening dex command a bit delay so its ready for baksmali. I was doing it right after which it misses for some conversions. I'll upload with delay between the two commands. Hmm framework i gotta give a shot :/ Sounds interesting ...
Solid script! Should make deodexing A LOT easier
Ok so i uploaded with delay between, seems to work fine, tested a LOT of times
thanks for this! can't wait for frameworks to be de-odexed.
jubeh: Thanks for the info. I had no idea and have informed JF previously here: http://jf.andblogs.net/2009/11/08/smalibaksmali-v1-0/ (see comments)
Hi all -
I'm using a GSM Galaxy Nexus with stock Android 4.1.1, and I'm trying to reduce the dim level, which kills my eyes at night. This is determined by a value "config_screenBrightnessDim" found in framework-res.apk. (In the source tree, it is found at frameworks/base/core/res/res/values/config.xml.)
I tried using apktool to decompile/recompile the stock framework-res.apk, but it doesn't seem to work with Jelly Jean. So, I instead attempted to replace the stock framework-res.apk with one I compiled from AOSP. When I do this, I get stuck at the boot animation. I assume this has something to do with the fact that my AOSP framework-res.apk is signed with a different certificate than the stock one. However, I also noticed that my AOSP file was ~10MB, while the stock one is only ~9.8MB, so there could be some other issue.
Any help with this would be greatly appreciated. Thanks!
(PS: Another modification I made was successful: I replaced the stock audio.primary.tuna.so with one I built from AOSP with a higher maximum volume. So, I think I am at least replacing the files correctly!)
Don't sign the framework file. Leave it unsigned and just move the cert from the stock framework. Also I would be interested in your audio boost file if you wouldn't mind sharing.
Sent from my Galaxy Nexus using Tapatalk 2
Thanks for the advice –*I'll try it out. I'll "unsign" my framework-res.apk by removing all the META-INF files in it. If it doesn't work, do you know a way to find the logs from the failed boot? Also, is there anything I should do (wipe cache, etc) after copying over the new framework-res.apk?
I've attached a zip containing three versions of the library audio.primary.tuna.so, found at /system/lib/hw/audio.primary.tuna.so: orig, loud, and aosp. "orig" was pulled from my phone with stock 4.1.1, "aosp" was built from aosp (the command you need is "make audio.primary.tuna"), and "loud" was made from aosp with the "device/samsung/tuna/audio/audio_hw.c" file altered to change the volume. Enjoy!
Geo411m said:
Don't sign the framework file. Leave it unsigned and just move the cert from the stock framework. Also I would be interested in your audio boost file if you wouldn't mind sharing.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
This worked! Thanks so much!
Great! Glad it worked for you. Also thanks for the Audio file.
How do you build just framework-res.apk from AOSP?
I've followed a tutorial and built the whole system, but I don't know where fraemwork-res.apk is built from in the source or how to only build it.
Edit:
figured out to build specific packages:
make (package name)
...omg
If you figure out how to use a framework-res.apk built from AOSP to replace one on the stock rom, let me know. I never did get that method to work.
michaelmotes said:
How do you build just framework-res.apk from AOSP?
I've followed a tutorial and built the whole system, but I don't know where fraemwork-res.apk is built from in the source or how to only build it.
Edit:
figured out to build specific packages:
make (package name)
...omg
Click to expand...
Click to collapse
There are some (most) things that you can modify in framework-res.apk and just copy over the old META-INF.
There are some things (like AndroidManifest.xml) that you can not modify and use the old META-INF.
The most radical solution is to resign your entire system with a new signature.
If the particular APK (not FW-R) does not use a sharedid, you might get away with just signing that.
(The above observations might be different on different versions Android.)
First I want to say thanks in advance for anyone who might be able to help - my guess is I'm missing something stupid, but I'm having some issues working it out. I've recently ported a Sense 4.1 ROM from a VilleC2 RUU to my device (HTC Holiday/Vivid) and have been working out some bugs. One of them was readding the hardware menu button functionality in Rosie. After some battling, I added the proper methods in the .smali, flashed it, menu button worked. Awesome, or so I thought. I baked the new Rosie.apk into the ROM, full wiped, flashed, and Rosie/Sense crash immediately after setup. So I full wiped, flashed the previous version of the ROM and all was well. Flashed the fixed Rosie.apk and all was even better. My question is what am I doing that the new Rosie.apk won't install properly from a full wipe/flash? Here are all the things I've tried that work/don't work...
First, what works..
Using VTS - if I make the edits and sign with either a test key, or the original key, the fix is applied as long as it's installed on top of an already working/stock Rosie (whether it's a dirty flash from a full build, or a standalone recovery flashable package)
What doesn't work..
Baking the "fixed" apk into the ROM and flashing after a full wipe. This results in Rosie/Sense crashing immediately after setup.
Trying to flash/install the fixed apk over the flashed ROM that had it baked in
I've tried using APKTool to decompile/edit/recompile, both using the newly outputted apk, as well as replacing classes.dex in the original .apk with the newly edited one, and this just results in Rosie crashing (whether it's baked in or installed on top of a working Rosie)
I've also tried the above with the outputted classes.dex from VTS (injecting into the original Rosie.apk), which also results in Rosie crashing.
Fixing permissions and/or wiping cache and dalvik doesn't fix the crashes.
While I am relatively new at this, I somewhat know my way around .apks and have been editing them without (too many) issues for a while now, but this one has me stumped...What am I doing wrong???
Edit: Maybe this was better in Chef Central > Android? If it needs to be moved, please do
Edit 2: I was just being stupid - while trying to not break the signature I was continually breaking the signature. This thread can be closed. Method used to get it to flash correctly with the ROM (I guess it helps to know how to PROPERLY use the tools available to you):
Decompile with apktool
Make edits
Build with apktool
Put META-INF folder and AndroidManifest.xml frin the original apk into /build/apk/
Build with apktool again
Use apk from /dist/
So I'm trying to learn how to create a launcher theme that works with P920/925 etc.
I took an existing theme, decompiled/decoded it, modded the drawables in an image editor, and rebuilt the apk with APK Tool.
It won't install or the launcher doesn't see it if I push it (actually the theme I modded was found in the 'uninstallable' folder of apk files, in the android system folder).
So will it not install because it's not signed? I've tried building as debug, but that doesn't work either.
Do I really, really have to go through the trouble of installing a unix/linux environment (i.e. Cygwin, etc) to sign it just for testing, or my own use?
I'd rather have something closer to final before I do all that...but maybe its just a necessary thing?
Or perhaps I should be doing this in Eclipse?
Thanks!
drastic00 said:
So I'm trying to learn how to create a launcher theme that works with P920/925 etc.
I took an existing theme, decompiled/decoded it, modded the drawables in an image editor, and rebuilt the apk with APK Tool.
It won't install or the launcher doesn't see it if I push it (actually the theme I modded was found in the 'uninstallable' folder of apk files, in the android system folder).
So will it not install because it's not signed? I've tried building as debug, but that doesn't work either.
Do I really, really have to go through the trouble of installing a unix/linux environment (i.e. Cygwin, etc) to sign it just for testing, or my own use?
I'd rather have something closer to final before I do all that...but maybe its just a necessary thing?
Or perhaps I should be doing this in Eclipse?
Thanks!
Click to expand...
Click to collapse
If I'm correct the themes are in the system folder and not have to be signed because is a system app.
Hmm. I'll look more into that. All I know is the one I decoded installs. The same one after modding doesn't. I did change color mode on a few images from indexed to RGB. Maybe it doesn't allow that without changing the code.