Related
So, i need some help from you.
Everytime I put some statusbaar icons into the framework-res.apk and resign it, it stucks in a boot loop.
In ddms it says me that the package android (i think its a file in the framework-res, or the framework-res) isn't signed correctly.
I attached the statusbaricons and the WORKING framework-res.
Could someone please integrate the files in the res/drawables folder and sign it correctly for me?
Thank you..
You would get a credit in my rom ;-) (Yes, i know, it's not very well known :-D , my roms name is MaxismaR, just search for it here..)
P.S: I'm on Windows 7, maybe that affects the signing process..
maxisma said:
So, i need some help from you.
Everytime I put some statusbaar icons into the framework-res.apk and resign it, it stucks in a boot loop.
In ddms it says me that the package android (i think its a file in the framework-res, or the framework-res) isn't signed correctly.
I attached the statusbaricons and the WORKING framework-res.
Could someone please integrate the files in the res/drawables folder and sign it correctly for me?
Thank you..
You would get a credit in my rom ;-) (Yes, i know, it's not very well known :-D , my roms name is MaxismaR, just search for it here..)
P.S: I'm on Windows 7, maybe that affects the signing process..
Click to expand...
Click to collapse
What are you using to sign? Keytools/Jarsigner?
I'm using the autosign.exe.
Ahh, Try my attachment.
Ok, tried and it gives me this :
06-18 21:52:40.797: ERROR/PackageManager(77): Package android signatures do not match the previously installed version; ignoring!
have you tried deleting the META-INF folder before you sign?
maxisma said:
Ok, tried and it gives me this :
06-18 21:52:40.797: ERROR/PackageManager(77): Package android signatures do not match the previously installed version; ignoring!
Click to expand...
Click to collapse
I've come across that error before, it's just telling you the current installation of framework-res doesn't match the signatures with the one you're trying to reinstall. I believe this framework jar file is located only in /system/framework so you would first have to remove any reference to the file (basically uninstall it). I know you can't uninstall a jar but basically you need to remove references to the file and signature of the file before you can replace it. It's possible you only need to remove /system/framework/framework-res.jar and /data/dalvik-cache/*framework-res*
I can't guarantee that if you remove this file that android will still boot up without errors. Be prepared to have to wipe and reload
why not take a full ROM update and put your images into that and then sign it. also make sure your images aren't too big. if you are using linux you can use pngcrush otherwise i'm no help
But there's no framework-res.jar in there.
But will try wiping after installing the new framework-res ;-)
If u r including icons like battery, check the number of icons in the framework of hero & that of ur rom, if it dosent mach, try removing or incliding some more or ger the source cod & insert those hero stuff inor source code & rebuild rom then get both framework res apk & the jar file....
thats the way i had implemented the percentage battery statusbar icons into 1.5
I know your always supposed to resign the apk's but the only workaround I have found for the exact same problem is to put.zip at the end of framework-res.apk.Right click on it explore to what directory im inserting my images in and paste em while leaving it zipped,when done take .zip back off dont sign it and it works then in the update.
THX to crotalusfreak! That fixed it! You'll get a credit in my next upload ;-)
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)
Hey guys/girls. I'm creating a theme for Andromeda 3 and one thing I cannot fifure out is how to make my theme CWM flashable to test it.
I opened the zip from a different flashable theme, replaced the framework-res.apk and twframework-res.apk with the modified ones from Andromeda and repackaged them using Winrar. I have followed the guides to resign the APK's and ZIP but no mater what I do, after a reboot I get a solid black screen and the phone vibrates.
Im not sure what I am doing wrong because I thought that was all that went into creating a CWM file.
Thanks in advance......
7 posts under this one
http://forum.xda-developers.com/showthread.php?t=1037842
the meta info is alot more specific than just swap any other files...
Thanks, I found that one about 5 mins ago but couldn't seem to find it when I searched the forum before posting. Must have missed it
Should also point out that if you're decompiling the framework apks with apktool, modifying any of the xml's or code, and recompiling, you'll need to sign the resulting apk or you'll end up with a boot loop.
modest_mandroid said:
Should also point out that if you're decompiling the framework apks with apktool, modifying any of the xml's or code, and recompiling, you'll need to sign the resulting apk or you'll end up with a boot loop.
Click to expand...
Click to collapse
Actually, I'm just opening the apk's with winrar. I make the changes to the folders/files and rezip them with Winrar with Store mode (no compression?) Then I resign them with testsign.jar.
I have read the themeing guides but they are really lacking in the small details dept.
modest_mandroid said:
Should also point out that if you're decompiling the framework apks with apktool, modifying any of the xml's or code, and recompiling, you'll need to sign the resulting apk or you'll end up with a boot loop.
Click to expand...
Click to collapse
Wrong.
Never resign system apks such as framework-res or twframework-res. His problem has nothing to do with the signature.
If you are simply copying over files inside the apk and getting this error, then you are adding more files than was originally inside the apk. I repeat, DO NOT ADD FILES THAT ARE NOT ALREADY INSIDE UNLESS YOU KNOW HOW TO RE-COMPILE THE RESOURCES.ASRC!
Also, use 7-zip to edit apks when you just want to overwrite files. Never unzip, or re-zip. Just right-click > 7-zip > Open Archive > Drag and drop files > close the window > you're done
Edit: Also, this goes in Q&A not General.
ryude said:
Wrong.
Never resign system apks such as framework-res or twframework-res. His problem has nothing to do with the signature.
If you are simply copying over files inside the apk and getting this error, then you are adding more files than was originally inside the apk. I repeat, DO NOT ADD FILES THAT ARE NOT ALREADY INSIDE UNLESS YOU KNOW HOW TO RE-COMPILE THE RESOURCES.ASRC!
Also, use 7-zip to edit apks when you just want to overwrite files. Never unzip, or re-zip. Just right-click > 7-zip > Open Archive > Drag and drop files > close the window > you're done
Edit: Also, this goes in Q&A not General.
Click to expand...
Click to collapse
Ok, thanks man.
Will I need to resign the final theme.zip before flashing it?
Also, can't I just grab the updater-script from another theme.zip and us it in my mine?
ryude said:
Wrong.
Never resign system apks such as framework-res or twframework-res. His problem has nothing to do with the signature.
Click to expand...
Click to collapse
I didn't say anything about resigning? Apktool creates an entirely new, unsigned apk, which unless I'm extremely mistaken you'll need to use if you intend to modify certain resources.
modest_mandroid said:
I didn't say anything about resigning? Apktool creates an entirely new, unsigned apk, which unless I'm extremely mistaken you'll need to use if you intend to modify certain resources.
Click to expand...
Click to collapse
He doesn't need to use apktool, because he isn't edited any code.
timbrendelaz said:
Ok, thanks man.
Will I need to resign the final theme.zip before flashing it?
Also, can't I just grab the updater-script from another theme.zip and us it in my mine?
Click to expand...
Click to collapse
No, you don't have to sign CWM zips because Clockwork doesn't check for a signature.
You could use another updater-script, but the problem with that is if it tries to perform an action on a file or folder that isn't inside your zip it will crash while flashing. You'll be left with a bricked phone and have to ODIN back to restore.
ryude said:
He doesn't need to use apktool, because he isn't edited any code.
Click to expand...
Click to collapse
But what if he is lol? Cause that's what im trying to do and having some issues. Know of a good thread on this? Editing xml that is
Sent from my SGH-T959 using XDA Premium App
TXLunchbox said:
But what if he is lol? Cause that's what im trying to do and having some issues. Know of a good thread on this? Editing xml that is
Sent from my SGH-T959 using XDA Premium App
Click to expand...
Click to collapse
If you're editing code, I recommend using apk manager since it will automatically recompile the resources.asrc for you. Just make sure to downgrade the apktool that comes with it to 1.3.1, 1.3.2 is known to cause problems with xml edits.
1. Set new project apk.
2. Decompile apk, if it's a system apk use the option for dependency apk and use twframework-res.apk as the dependency apk.
3. Edit your xml files.
4. Recompile, when asked use yes twice. It will tell you to delete files in the Keep folder.
5. Delete the resources.asrc if you edited any xml/added new files. Delete the files that you added/edited.
6. Once you're done it will automatically copy over the signature and use the compression that you set (default level 9, I recommend level 0).
Don't worry that it says "unsignedFramework-res.apk", it will work since it's a system apk because system apk signatures get copied over to the new file. Just rename it to Framework-res.apk or whatever you need it to be called.
ryude said:
He doesn't need to use apktool, because he isn't edited any code.
Click to expand...
Click to collapse
Hence the 'if' in my original statement, you know, 'if' he ever chose to in the future.
I've looked around for some good tutorials on decompiling APKs using APKTool but haven't been able to get a few questions answered. Hoping someone can guide me with this process a bit since I'm really new at it.
A few things first: I am running CM 7.1 on a Droid Incredible (orig) and I'm also on Windows, not Linux. I'm looking to make some changes to the code of an APK and have APKtool downloaded. Questions I have so far are:
1) Do I need to use the CM 7.1 framework-res.apk file for any decompiling / /recompiling work on this 3rd party APK? Or can I do all the work without it? No one seems to have a clear answer on that and I'm not sure exactly what the framework-res.apk is for exactly.
2) After I decompile an APK and make code changes to a SMALI file, is there anything I need to do special before running the compile command?
3) After I have a newly compiled APK, what do I need to do to make this work on my phone? If I do nothing, the overall file size of the compiled APK seems much smaller than the original one that I decompiled so it seems like something is wrong. Plus it won't install. I saw one video where the newly compiled APK is renamed to .ZIP and the contents are put into the ORIGINAL APK (also renamed to .zip), overwriting all the original contents. Is this required?
4) I've also read that APKs need to be signed to install on Android. Is this correct? I found "SignApk" online which seems like it just asks you to rename your APK to app.apk and it does the signing by running a .BAT file. Is that all I have to do before installing the APK on my phone?
Would really appreciate any help on this. Or if there's a great tutorial out there on doing this, I'd be happy to read through.
Thanks for any help in advance!
I want to know these too! Hope someone helps
Hello,
I a quite new to Android development/hacking and need some clarification regarding signing system apps.
I did not find any answer yet that fully helped me solve my problem...yes, I did use search on the forum and even Google :laugh:
Scenario:
Let's assume I wanted to modify some system apks (in /priv-app or /app doesn't matter).
All those apks I want to modify do rely on the same framework.apk.
As far as I know, if I modify a system apk all other system apks that rely on the same framework.apk have to be resigned using the same certificate.
1) Is this correct (any pitfalls there)?
2) Do I have to resign the used framework.apk with the same certificate also?
3) Do I have to take other files/things into consideration that would have to be changed / resigned / etc.?
Thanks in advance! :good:
Regards
Markus
deomaki said:
Hello,
I a quite new to Android development/hacking and need some clarification regarding signing system apps.
I did not find any answer yet that fully helped me solve my problem...yes, I did use search on the forum and even Google :laugh:
Scenario:
Let's assume I wanted to modify some system apks (in /priv-app or /app doesn't matter).
All those apks I want to modify do rely on the same framework.apk.
As far as I know, if I modify a system apk all other system apks that rely on the same framework.apk have to be resigned using the same certificate.
1) Is this correct (any pitfalls there)?
2) Do I have to resign the used framework.apk with the same certificate also?
3) Do I have to take other files/things into consideration that would have to be changed / resigned / etc.?
Thanks in advance! :good:
Regards
Markus
Click to expand...
Click to collapse
All system apps have to be signed the same way, yes. You can sometimes mod your services.jar to turn off signature verification but that can leave you a bit more open to malware.
When you mod a system app, you just have to make sure you use the original signature in the new version. The only exception to this is if you change anything in the manifest. Then you will need a new signature, which means either signing everything else with that signature or doing the services.jar I mentioned earlier.
Hello Ticklefish,
first of all: Thanks a lot!
To summarize your answer:
1) Modding services.jar is out of the question! Would never have done this anyway...(risky from a malware point of view)
2) In case I modify a system apk WITHOUT altering the manifest.xml I can reuse the old apk signature for my new apk (the whole META-INF folder has to be copied over to the new apk?)
Nothing else has to be adjusted?
I suppose I still can do a zipalign afterwards in that case?
3) In case of modifying the manifest.xml I would have to resign ALL system apks.
All of them or only those that rely on the same framework as the modded apk?
Do I have to resign the framework apk as well?
I am asking, because I will have to mod several apks relying on different frameworks: At least one where I have to alter manifest.xml...
Thanks in advance
Markus
deomaki said:
Hello Ticklefish,
first of all: Thanks a lot!
To summarize your answer:
1) Modding services.jar is out of the question! Would never have done this anyway...(risky from a malware point of view)
2) In case I modify a system apk WITHOUT altering the manifest.xml I can reuse the old apk signature for my new apk (the whole META-INF folder has to be copied over to the new apk?)
Nothing else has to be adjusted?
I suppose I still can do a zipalign afterwards in that case?
3) In case of modifying the manifest.xml I would have to resign ALL system apks.
All of them or only those that rely on the same framework as the modded apk?
Do I have to resign the framework apk as well?
I am asking, because I will have to mod several apks relying on different frameworks: At least one where I have to alter manifest.xml...
Thanks in advance
Markus
Click to expand...
Click to collapse
If you're modifying an APK without changing the manifest, the best method is to use 7zip or similar to open the new APK and drag the modded files over to the original APK. That way you're still using the same META-INF at the same compression ratio.
Or use Tickle My Android (https://forum.xda-developers.com/showthread.php?t=1633333) to do it for you....cough...cough...
You can zipalign afterwards, just remember that any further changes will affect that zipaligning so you'll have to do it again.
As far as resigning the APK goes, all I know is that you have to change every file that uses the same key/signature as the app you resigned so that they all match.
I have to confess that I've never actually done this. I rarely change the manifest myself and, when I do, I disable signature verification. Yes, it makes you more prone to malware but as long as you're careful about what you install you should be okay.
deomaki said:
Hello,
I a quite new to Android development/hacking and need some clarification regarding signing system apps.
I did not find any answer yet that fully helped me solve my problem...yes, I did use search on the forum and even Google :laugh:
Scenario:
Let's assume I wanted to modify some system apks (in /priv-app or /app doesn't matter).
All those apks I want to modify do rely on the same framework.apk.
As far as I know, if I modify a system apk all other system apks that rely on the same framework.apk have to be resigned using the same certificate.
1) Is this correct (any pitfalls there)?
2) Do I have to resign the used framework.apk with the same certificate also?
3) Do I have to take other files/things into consideration that would have to be changed / resigned / etc.?
Thanks in advance! :good:
Regards
Markus
Click to expand...
Click to collapse
I usually use Mixplorer, (if you use your phone to de/re-compile). Click on compiled apk, select 'explore' and a new tab opens with the contents of the apk. Delete the manifest that was created in recompile, then go to folder with decompiled apk, /original, and long-press to select android manifest xml, and META-INF folder. Choose copy, and paste them into new apk.