apktool.jar throws java.util.zip.ZipException: error in opening zip file

[GoogleCodeExporter]

ApkDecoder localApkDecoder = new ApkDecoder();

        localApkDecoder.setDecodeSources((short)0);

        localApkDecoder.setForceDelete(true);

        localApkDecoder.setOutDir(tempFolder);

        localApkDecoder.setApkFile(ps.apk.getFile());

        localApkDecoder.decode();  ××× throws throws java.util.zip.ZipException: error in opening zip file 

i found that it was caused by ：

    java.util.zip.ZipFile zipFile = new java.util.zip.ZipFile(in);

when i use org.apache.tools.zip.ZipFile, it can unzip file successfal, what's 
wrong?

why not use org.apache.tools.zip.ZipFile , in ant.jar?

Original issue reported on code.google.com by ws008.li...@gmail.com on 4 May 2011 at 9:21

Attachments:

• a.apk

[GoogleCodeExporter]

Hmm.. did you rezipped that file using some advanced zip utility? java.util.zip 
should open all regular zip files normally, so everybody use it. Baksmali 
throws errors on that apk too, in addition java.util.zip is only one library 
included in Java and on Android itself. It's some kind of a standard in Java 
world.

Original comment by Brut.alll on 4 May 2011 at 11:58

[GoogleCodeExporter]

The apk file is a product of another company, I wan't to hack it to
get the icon file and other infomation.
So i don't know what advanced zip utility they used, also i don't know
how apache can unzip that file.

That really a big problem to me .

Original comment by ws008.li...@gmail.com on 5 May 2011 at 1:33

[GoogleCodeExporter]

Android can unzip that apk file,so i think there should be somting different 
from javase java.util.Zip to Android java.util.Zip. 

Original comment by ws008.li...@gmail.com on 5 May 2011 at 1:36

[GoogleCodeExporter]

I compiled android java.util.zip and use it to unzip that apk file, it works!
So i'm sure there is somthing different from j2se java.util.Zip.
Use android's java.util.zip to unzip the apk file should be the best way.

Original comment by ws008.li...@gmail.com on 5 May 2011 at 2:36

[GoogleCodeExporter]

Hmm.. i found the point why java.util.zip throw java.util.zip.ZipException.

replace the code "new ZipFile(f)" 

to 

 CheckedInputStream cis = new CheckedInputStream(new FileInputStream(
                srcFile), new CRC32());

ZipInputStream zis = new ZipInputStream(cis);
ZipEntry entry = zis.getNextEntry();

works excellent!!!

Original comment by ws008.li...@gmail.com on 5 May 2011 at 8:03

[GoogleCodeExporter]

I think if you would just unzip and zip apk file back, then you would be able 
to decode it properly :-)

But your findings are very interesting. I will try to find some more info about 
above solution. Thanks :-)

Ahh, I also tried to install your apk and I know Android OS opens it properly, 
but I think it may not even use Java zip library, but some native one.

Original comment by Brut.alll on 5 May 2011 at 9:37

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yes，you're right. I read the source code ,Both j2se and android use native 
method to decompress zip file. 

Original comment by ws008.li...@gmail.com on 9 May 2011 at 6:18

[GoogleCodeExporter]

It is important to note that the ZipInputStream class reads ZIP files 
sequentially. The class ZipFile, however, reads the contents of a ZIP file 
using a random access file internally so that the entries of the ZIP file do 
not have to be read sequentially.

Note: Another fundamental difference between ZIPInputStream and ZipFile is in 
terms of caching. Zip entries are not cached when the file is read using a 
combination of ZipInputStream and FileInputStream. However, if the file is 
opened using ZipFile(fileName) then it is cached internally, so if 
ZipFile(fileName) is called again the file is opened only once. The cached 
value is used on the second open. If you work on UNIX, it is worth noting that 
all zip files opened using ZipFile are memory mapped, and therefore the 
performance of ZipFile is superior to ZipInputStream. If the contents of the 
same zip file, however, are be to frequently changed and reloaded during 
program execution, then using ZipInputStream is preferred.

see http://java.sun.com/developer/technicalArticles/Programming/compression/

Original comment by ws008.li...@gmail.com on 9 May 2011 at 6:32

[GoogleCodeExporter]

how to solve this problem

Original comment by jackylu1...@gmail.com on 30 Mar 2012 at 3:17

[GoogleCodeExporter]

I tried out the Stream vs the Zipfile and time() resulted in slower performance 
for the Stream. This was a one time problem for you, and I can't duplicate it.

Original comment by connor.tumbleson on 19 Nov 2012 at 4:03

• Changed state: Idle