yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] cauli:
You're a bad man/woman - I've been trying to avoid that. It's months since I looked into the binary format (pre apktool) & I've not needed to since. Can't remember a darned thing & if I peek I'll be compelled to re read all that guff... still, I suppose a diff wouldn't hurt... <goes away muttering 'ought to know better, i ought... bad bad man, bad man...'>.

[Edit:] Five months ago it seems; my retention is barely five minutes. This hurts. A simple diff of the hex is of little help as the string pool entries are in a different order resulting in lots of irrelevant mismatches. I was gonna give up for now, but I see Brut.all is on top of it, so instead I can just chime in with an 'i was about to say that' ;)
[G1 Android Development] Brut.all:
@mr_sarge, @cauli

http://code.google.com/p/android-apktool/issues/detail?id=100

Thanks for your help. It's a horrible bug, I need to fix it quickly.
[G1 Android Development] mr_sarge:
Ho !

Thanks that great program and for taking time to fix-it !
[G1 Android Development] cauli:
Ah wonderful, the guy with a sack of clues is back :D When you get this fixed, if you have the time I'd love to know why the current bug results in this erroneous escaping of @, for instance, only sometimes. I'm just curious about the current broken logic & how the fix works. Fair dos if you're not inclined to waste more time explaining. Cheers for the continued support of this invaluable tool :)
[G1 Android Development] Brut.all:
That escaping was always a problem, it's really confusing for me. I have changed my assumption many times and always something goes wrong ;-) I need regressions tests, working on this.

http://code.google.com/p/android-apktool/issues/detail?id=76#c1

Since 1.3.2 apktool prefers to use string value of an attribute. It uses int value if string is empty or it's something like "android:layout_width="fill_parent"". I didn't look at above issue, but seems e.g. "functionKeyBackground="@drawable/qwerty_function_key"" is written differently, so apktool treats it like any string. And "any string" must be escaped if it's starting with "@".
[G1 Android Development] cauli:
Thanks for the detailed explanation; appreciated. I can see how important a test suite is for apktool, especially with problems that don't throw run time errors. Good luck.
[G1 Android Development] technofab:
HI all,

I'm using APktool 1.3.2 in a windows xp enviroment.

I decomiple ok, next i try to rebuild, also without any change and obtain this error:

I: Checking whether sources has changed...
I: Smaling...
Exception in thread "main" java.lang.NullPointerException
at org.jf.util.PathUtil.getRelativeFile(Unknown Source)
at org.jf.smali.smaliFlexLexer.getSourceName(Unknown Source)
at org.jf.smali.smaliFlexLexer.getErrorHeader(Unknown Source)
at org.jf.smali.smaliFlexLexer.nextToken(Unknown Source)
at org.antlr.runtime.CommonTokenStream.fillBuffer(Unknown Source)
at org.antlr.runtime.CommonTokenStream.LT(Unknown Source)
at org.jf.smali.smaliParser.smali_file(Unknown Source)
at brut.androlib.mod.SmaliMod.assembleSmaliFile(Unknown Source)
at brut.androlib.src.DexFileBuilder.addSmaliFile(Unknown Source)
at brut.androlib.src.DexFileBuilder.addSmaliFile(Unknown Source)
at brut.androlib.src.SmaliBuilder.buildFile(Unknown Source)
at brut.androlib.src.SmaliBuilder.build(Unknown Source)
at brut.androlib.src.SmaliBuilder.build(Unknown Source)
at brut.androlib.Androlib.buildSourcesSmali(Unknown Source)
at brut.androlib.Androlib.buildSources(Unknown Source)
at brut.androlib.Androlib.build(Unknown Source)
at brut.androlib.Androlib.build(Unknown Source)
at brut.apktool.Main.cmdBuild(Unknown Source)
at brut.apktool.Main.main(Unknown Source)

What i need to do? :confused::confused:
[G1 Android Development] Brut.all:
Could you upload original apk file? If you did any changes to smali files, then please upload directory with these files too.
[G1 Android Development] technofab:
Here is my files. Tnx.
[G1 Android Development] cauli:
@Brut.all I fully understand you might not be able to answer this, but do you have any idea, however imprecise, when you might have a fix for 1.3.2? It's just to help me decide what to pluck off my todo list next. If there's anything I can do to help with the regression testing just say; I'd have offered before, but I doubt it's an option. Shame there isn't some way you can share out the testing until it can be automated.
[G1 Android Development] REYES702:
For god sakes

I have been at this for god knows how long and I just can't get it to build;

I get that every damn time. I have no clue why. I actually think it's changed since this morning but it never finishes building. I'm trying to implement this http://xdaforums.com/showthread.php?t=775810 into my current framework-res.apk. I do the changes noted but whenever I try to rebuild it give me that error.

Anyway, I saw a video that said to get classes.dex and any would do, so I got that from my ContactsProvider.apk. The framework-res.apk I attached this post is an adb pull directly from my phone with an added classes.dex.

I'm not sure if I have included enough detail for someone to help me out but any help is appreciated. I've been at this for so damn long. It took me 2 days of 3 hours a piece to figure out how to decompile, lol.

Thanks,

Robert
[G1 Android Development] Fr4gg0r:
I have the same problem (with framework.jar) :(

All worked perfectly with other apps, but with framework.jar it always crashed when compiling. Updated to newest version, but did not help.
[G1 Android Development] moritan:
hello i have the same error with app generate with appinventor.

any idea why ?
[G1 Android Development] REYES702:
The worst part is I changed frame works and am using the one ihftp made and I pulled that from my phone to try and change the battery logo and it rebuilt fine after making the necessary changes. I wonder what the issue could be. I can't help but to think that it is related to the changes I made to the framework.
[G1 Android Development] phaelox:
Trying to decode resources.arsc in com.htc.resources.apk extracted from custom Android 2.1 ROM (Kimera 2.1).

What steps will reproduce the problem?

apktool d -s com.htc.resources.apk htc

What is the expected output? What do you see instead?

I: Loading resource table...

I: Decoding resources...

Exception in thread "main" brut.androlib.AndrolibException: brut.directory.PathN

otExist: AndroidManifest.xml

at brut.androlib.res.decoder.ResFileDecoder.decode(Unknown Source)

at brut.androlib.res.AndrolibResources.decode(Unknown Source)

at brut.androlib.Androlib.decodeResourcesFull(Unknown Source)

at brut.androlib.ApkDecoder.decode(Unknown Source)

at brut.apktool.Main.cmdDecode(Unknown Source)

at brut.apktool.Main.main(Unknown Source)

Caused by: brut.directory.PathNotExist: AndroidManifest.xml

at brut.directory.AbstractDirectory.getFileInput(Unknown Source)

... 6 more

What version of the product are you using? On what operating system?

Apktool v1.3.2 / Windows 7 Ultimate x64

Please provide any additional information below.

There is indeed no AndroidManifest.xml in this file, only 1 file "resources.arsc".

This apk is not deodexed for what it's worth. Deodexing and adding the resulting classes.dex file to the APK does not help. Besides, I'm using "-s", which seems to skip the dex file anyway.

Apologies if I'm missing the obvious, I'm new at this. Thanks.
[G1 Android Development] REYES702:
I'm fairly new myself but from my experimentations, my guess is it has to do with you not specifying the path to the APK.

Is your apk in C:/Windows with apktool? If not, you'll have to tell it what the path is. (IE: C:/sdk/tools/com.htc.resources.apk) You'll also have to do the same with the output folder. (IE: C:/sdk/tools/htc) otherwise, it's going to throw the output folder in C:/Windows where you have apktool.
[G1 Android Development] phaelox:
Thanks for your reply. I have previously decoded APKs like this without any problem, so I don't think that's it. Apktool is in a directory that's in my PATH environment variable and I'm executing the command from the directory where the com.htc.resources.apk resides. It appears to be "reading" the file, but then it croaks. There is no AndroidManifest.xml inside the apk as it rightly says in the error, but I've seen people mention decoding this particular htc apk (from other roms) using apktool...

I've decoded/built framework-res.apk to replace the battery icon with a circular one that shows percentages (with 1% increments!!), and I got that working fine. (Took some messing about, but hey..succeeded in the end :D ) I'm just trying to find out what this other resources file holds to possibly play around with. ;)
[G1 Android Development] pendo:
Why are you using the -s switch anyway? That won't decode any of the resources....it's almost the same output if you were to open the apk in a zip manager.

Could you be a little more specific about your goal? The way I've most recently used the htc resources file is to aid in decompiling so that I don't have problems with public.xml. For this you use the -t switch like this:

apktool if com.htc.resources.apk <whatever tag name>

Then apktool will create a folder with those resources in it so that when you decompile

apktool d -t <whatever tag name> framework-res.apk out

it uses both the resources that are in the frame-res, and the htc resources.

Don't know if that helps though since we're not certain what you want to do..
[G1 Android Development] phaelox:
Maybe I'm misunderstanding you, but the -s switch skips decoding sources, not resources. I'm not interested in decoded sources (smali files), just resources (xml/png/etc files). In this case you're right in any case, as there's only a resources file inside the apk, no sources. I could just leave out the -s switch, but it makes no difference with regards to the error.

My goal is to simply find out what specific resources HTC put in this file. Most theming is done for AOSP ROMs, not a lot for Sense ROMs. So it's mostly a learning exercise... Plus I know apktool can decode this type of file, I've seen ppl mention apktool decoding com.htc.resources.apk, but it croaks on this specific version (from the Kimera2.1 ROM) and I'm trying to learn why.

I have installed that file as framework. But since I'm trying to decode the framework itself, the point is moot. Even if I specify the tag, apktool ignores it as the framework I refer to using the tag is the file I'm trying to decode. I hope that made sense, lol

EDIT:

I've been reading some more about resources.arsc and classes.dex files and such, and learned the arsc file is merely a resource table, and does not contain any actual resources. Since there was only this table in the file I had adb pull'ed from my phone, I decided to extract a copy from the ROM zip. Lo and behold, it was almost 9MB, whereas the file I was looking at this whole time was only 764KB.

The com.htc.resources.apk from the ROM zipfile contained a res folder and a AndroidManifest.xml as well as the resources.arsc and decoded just fine using apktool.... so either the file was corrupted on my phone, or the adb pull went awry somehow (winrar didn't show any errors opening the file though), or I simply don't understand what happens to the file upon first boot, but at least I can peak at the resources inside the file now.

Thanks for trying to help!
[G1 Android Development] ichjetzthier:
I am having the same problem. Any solution anywhere? Working on Windows 7 64bit

Thanks a lot! :-)
[G1 Android Development] mobiousdigital:
[resolved problem]
[G1 Android Development] pendo:
You are quite right....my bad. I was thinking about the -r switch. And thanks for correcting my terminology, too :)

I believe you can 'double tag' things as long as you give them the same name, although I'm not 100% sure. I tried once for a particular frame-res, but was unsuccessful and had to pursue other routes to successfully decode.

Yeah, there's really not been too many times I edited anything in there. A few times I've removed an entry in public.xml, but that's not the norm.
[G1 Android Development] pendo:
brut.all,

Can you help me a little with this one:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Coordinate out of bounds!
at sun.awt.image.ByteInterleavedRaster.setDataElements(ByteInterleavedRaster.java:539)
at java.awt.image.BufferedImage.setRGB(BufferedImage.java:981)
at brut.androlib.res.decoder.Res9patchStreamDecoder.drawVLine(Unknown Source)
at brut.androlib.res.decoder.Res9patchStreamDecoder.decode(Unknown Source)
at brut.androlib.res.decoder.ResStreamDecoderContainer.decode(Unknown Source)
at brut.androlib.res.decoder.ResFileDecoder.decode(Unknown Source)
at brut.androlib.res.decoder.ResFileDecoder.decode(Unknown Source)
at brut.androlib.res.AndrolibResources.decode(Unknown Source)
at brut.androlib.Androlib.decodeResourcesFull(Unknown Source)
at brut.androlib.ApkDecoder.decode(Unknown Source)
at brut.apktool.Main.cmdDecode(Unknown Source)
at brut.apktool.Main.main(Unknown Source)

This follows few malformed .9.pngs that your script renames to .png. Problem is, it doesn't really let me know which file threw the error..
[G1 Android Development] Brut.all:
Use zipinfo tool to find out, what is the difference between both apks.

BTW: if I compile libAndroid.so for apktool with "-O2" switch, resulting file is of course smaller (about 60% of unoptimized size), but after ziping it is... larger :-D
[G1 Android Development] AnderWeb:
Archive: Phone.apk
Zip file size: 1100890 bytes, number of entries: 177
177 files, 1426027 bytes uncompressed, 1072354 bytes compressed: 24.8%

Archive: Phone.apk
Zip file size: 541355 bytes, number of entries: 177
177 files, 1387621 bytes uncompressed, 513075 bytes compressed: 63.0%

Seems it's compressed differently... :?
[G1 Android Development] Brut.all:
It should give you an info about compression algorithm and version used for each file.

$ zipinfo Vending.apk
Archive: Vending.apk
Zip file size: 757904 bytes, number of entries: 132
-rw---- 2.0 fat 11322 bX defN 08-Aug-21 17:13 META-INF/MANIFEST.MF
-rw---- 2.0 fat 11364 bl defN 08-Aug-21 17:13 META-INF/CERT.SF
-rw---- 2.0 fat 1580 bl defN 08-Aug-21 17:13 META-INF/CERT.RSA
-rw---- 2.0 fat 16856 bl defN 08-Aug-21 17:13 AndroidManifest.xml
-rw---- 2.0 fat 89888 bl defN 08-Aug-21 17:13 assets/fonts/Storopia.ttf
-rw---- 2.0 fat 607056 bl defN 08-Aug-21 17:13 classes.dex
-rw---- 2.0 fat 436 bl defN 08-Aug-21 17:13 res/anim/fade_in.xml
-rw---- 2.0 fat 436 bl defN 08-Aug-21 17:13 res/anim/fade_out.xml
-rw---- 2.0 fat 968 bl defN 08-Aug-21 17:13 res/color/informational_text.xml
-rw---- 1.0 fat 888 b- stor 08-Aug-21 17:13 res/drawable-finger/ic_network_error.png
-rw---- 1.0 fat 1567 b- stor 08-Aug-21 17:13 res/drawable-finger/ic_tab_newest_selected.png
(...)
132 files, 1225875 bytes uncompressed, 737629 bytes compressed: 39.8%

You could simply compare these informations.
[G1 Android Development] AnderWeb:
Yeah, i noticed some files got "store" instead "defN", but how can i repackage them using aapt? Tried with 7zip but something went wrong.

Doing

7za a -tzip Phone.apk "Phone/*" -mm=Deflate

but the resulting files are compressed showing "bx" instead of "b-" or "bl" like the original .apk.

And flashing it makes everything FC's...

So maybe a 7za param i missed or better do it with aapt, right?
[G1 Android Development] Brut.all:
aapt is a single one officially supported tool, which give you sureness that apk will be properly built. At the beginning I was using zip or jar to package apks and it worked, but some people had problems with "resource not found" exceptions. I have discovered that it was caused by different algorithm used for packaging some of the files: AFAIR some devices requires that .ogg are packaged uncompressed (stor), but zip/jar have deflated them.

So: we could experiment with other methods of packaging apks, maybe we could get smaller apks and maybe Cyan does it. But I really don't know :-)
[G1 Android Development] AnderWeb:
That's the point of asking help to use aapt instead of 7zip, cause i can't found the right params to just "pick this package folder and make a .apk of it!" IF it can be done :)
[G1 Android Development] Brut.all:
$ aapt p -F <file.apk> <dir>

and that's it :-)
[G1 Android Development] AnderWeb:
LOL... so that's all...

And why is MUCH smaller than the one generated by the "make app" within android source? Don't get it...

BTW, this command makes different "zipinfo", files are compressed with "DefX" instead of "DefN"... but i flashed it and it worked like a charm.

One last comment:

Finally did a working "compression" with 7zip by updating the original .apk this way:

7z a -tzip -r ../Phone.apk ./*

BUT that only worked if i previously deleted de META-INF dir from the extracted dir before "recompressing".
[G1 Android Development] Brut.all:
4 hours of WTFing and I just found a bug in Android C++ sources... :-/
[G1 Android Development] AnderWeb:
Lol, a serious one? you reported them?
[G1 Android Development] canadiancow:
Care to share?
[G1 Android Development] Brut.all:
No, no ;-)

Theoretically AssetManager can load assets from a zip file or a directory, but second one does not work. I think this feature isn't used currently, all assets are in jar or apk files and so no one noticed it so far.

I will send fix to AOSP, but I must be sure, that this is really a bug :-)
[G1 Android Development] Brut.all:
If you are curious:

https://review.source.android.com/13967
[G1 Android Development] Brut.all:
But I use it! ;-D

BTW: they are superb fast in responding :-)
[G1 Android Development] AnderWeb:
Great, you're just awesome... thanks for all that hard wor? dudea!
[G1 Android Development] Brut.all:
(...)
Testing ./com.appdroid.anycut.apk...
Decoding...
Building...
Ok.
Testing ./com.htc.clicker.apk...
Decoding...
Building...
Ok.
Testing ./com.nethackff.apk...
Decoding...
Building...
Ok.
Testing ./com.adobe.psmobile.apk...
Decoding...
Building...
Ok.
Testing ./com.fheft.graviturn.apk...
Decoding...
Building...
Ok.
Testing ./com.google.tts.apk...
Decoding...
Building...
Ok.
Testing ./android.tether.usb.apk...
Decoding...
Building...
Ok.
Testing ./com.glu.android.bonsai.apk...
Decoding...
Building...
Ok.
(...)

What a wonderful view ;-D It was much worse a few days ago :-)

I've tried to compile it for Windows: 3 hours spent, tried Cygwin and MinGW, compiling on Windows and crosscompiling on Linux and I'm at starting point. Anyone knows, how to compile something for Windows?
[G1 Android Development] canadiancow:
Looks sexy :)

As for Windows compatibility...I've never had any issues literally dragging and dropping Java or .NET between Linux and Windows.
[G1 Android Development] Brut.all:
Java isn't a problem. But there are quite a lot of C++ code extracted from AOSP (libAndroid.so inside apktool.jar file).
[G1 Android Development] canadiancow:
What I was trying to say is that if you want cross platform compatibility, you might want to look at porting the code to Java :p

Anyway, I'm content with it only working on Linux.
[G1 Android Development] Brut.all:
~/proj/brut.androlib.jni/android$ du -hs --apparent-size .
683K	.

Heh, maybe in a next millenium ;-)

And I am not, because it might be great tool for themers and not every graphic designer must be a linux geek ;-)

BTW: there are some HAVE_WIN32_THREADS, HAVE_WIN32_FILEMAP, etc. checks and some code specific for Windows, so seems it was written with Windows support in mind.
[G1 Android Development] djmcnz:
Is there any way we can ignore drawables in a file? Specifically if we just want to recompile xml?

I ask because of troublesome framework decoding, more often than not the drawables can be ignored (because they can just be inserted into the apk) and only the xml needs to be edited.

For the most part I typically can't decode/encode a framework-res.apk without drawable errors all over the place (and no output file)... so, back to the original question... any way to just ignore the drawables but decompile the xml... and then recompile?
[G1 Android Development] pendo:
So you don't even get any output file? What errors are you seeing? I know I'm not nearly experienced as you(I think yours was my 2nd rom after I learned how to root:p), but I've yet to find a framework-res that I haven't been able to work with-or at least I can't remember one. There was one that took me a while to figure out, but it was fairly unique situation (I think, never seen one like), but even then once I took the time to test my theory, I had apktool doing its thing. I

Is it for some of the MIUI you're working with? If you don't mind I'd be happy to try and help if I can. :)

<edit>

After reading your post again, I think I know what you're asking. You would like a command switch, like -x, that would only decode the xml's. Is that right? I've thought this would be kind of cool too, especially if one could get it to work right with metamorph.
[G1 Android Development] djmcnz:
You know... sometimes it only takes a good night's sleep and a sensible reply to get me back on track... just reading your reply made me think and I've solved my own problem now... I was just working on too many different roms...

Nevertheless, I was implying a switch would be a good think and yes, I do think it would be valuable... even it's just to speed some things up (i.e. decoding/encoding just xml would be faster than all res).

Food for thought, might be a good enhancement but consider my issue closed! Thanks... :D
[G1 Android Development] ihtfp69:
Great work on this invaluable tool brut.all. I use this tool on a regular basis and absolutely love it. It works great and I never really have an issue that I have not been able to solve.

However, recently it was brought to my attention that buttons were missing, or rather invisible, except for the text in some apps including the browser and gmail. For example, the "Show Pictures" button in gmail just shows the text and no button. However, it still continues to function. I tracked the issue down to only happening on a re-encoded framework-res.apk. I just can't figure it out. The graphic for that button after the re-encode looks fine to me from a general standpoint. I even tried replacing it with an original after the re-encode. It seems to have only affected buttons that use that specific graphic in the framework. Has anyone experienced this or know how to fix it?
[G1 Android Development] pendo:
Nope, never had a problem like that.

That said, if only happening with buttons, then you're talking about 9 patch stuff. On later revisions of apktool, malformed 9 patch files are renamed as a straight png, which *maybe* could have something to do with what you're talking about.
[G1 Android Development] xtort1417:
Brut.all thanks for this amazing tool. Never had a problem before bit recently I decoded an app and on reencoding a background file I did not change would not show and the actual layout of the widget was all wacky. It still worked bit things were in incorrect places. Can't figure it out. It's like the xml got mixed up

Edit: NM, I see there is a bug in 1.3.2 with xml files and escaped characters. I bet this is what I am running into. Is there an updated version coming or do you recommend going back to 1.3.1?

sent from my incredible
[G1 Android Development] ihtfp69:
It did rename all my 9 patch files. Is it not supposed to? Why would the originals be malformed?
[G1 Android Development] pendo:
When you say "originals" are they true originals from Google (you mentioned gmail earlier) or are they what what included in a rom package (perhaps a themed rom package)? A true 9 patch has very specific requirements that often times are not followed in the theming process. They can still be called for use though, they just won't have all the 9 patch flexibility. There's a whole section on how to create 9 patch pngs on the developer.android.com site

You could always do it the old way, and just inject the offending .9.png back into the apk after it's compiled.
[G1 Android Development] ihtfp69:
Originals meaning what was supplied by HTC in the ruu. I tried injecting them before, but the button still seems to be invisible. I'm wondering if public.xml needs to reflect the .9 in the name?