This project is read-only.

Problems working with APK files (similar to .jar files)

Feb 9, 2010 at 12:28 PM
Edited Feb 9, 2010 at 12:31 PM

Hi guys,

I'm trying to read some apk files.

Apk files are the applications in android, this files are ZIP-files with binaries and resources of each application. These files are similar to .jar files of Java.

I have detected 2 odd behaviors:

1) When I load this file:, the ZipFile class doesn´t contains entries for directory entries, when I select entry.IsDirectory == true I get an empty list. However I get the next entries:







But the ZipFile entry list don´t containt "META-INF" directory entry.

2) I get a ZipException when I try to load this file: If I use the constructor from ZipFile class the exception says: "C:\Temp\SkinDroid\extract\SystemApp\Calendar.apk is not a valid zip file", and if I use Load static method in ZipFile class the exception says: "Index out of bounds"


I think that these files are a valid zip files, I manage these in linux with Zip command line util from Info-Zip and don´t have any problem.

Can you help me?

Thanks in advance.



Feb 9, 2010 at 9:30 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Feb 9, 2010 at 10:41 PM


Regarding the first issue.  Depending on the creator of the zip file, there may or may not be an entry for the directory.  In the zip file model, directories are not actually containers.  It's possible to have a file entry with the name "META-INF/CERT.SF" without having a directory entry with the name "META-INF" (or "META-INF/") .  So the behavior you observed is expected.

Regarding the 2nd issue.  The format used by that Calendar.apk file is something I had not seen before.  The zip spec describes a structure called an "extra field", optionally included into each zip entry.  The spec calls for a header id of 2 bytes, and a datasize of 2 bytes, followed by datasize bytes.  For additional records in the "extra field", it just repeats that series.  In your zip file, some of the "extra field" had only 2 bytes, where there should be 4 (header id + datasize), according to the spec.

This is a clear case of an incorrectly formatted zip file.   That infozip handles it is not evidence of correctness.   At the same time DotNetZip needs to be more tolerant of those kinds of formatting problems, so I modified the code to do that.  Just so you're aware:  you won't necessarily get the same flexibility out of other zip tools or libraries.   Also, it looks like evidence of less-than-fully-bulletproof code in whatever tool you used to create that apk file.

I am testing the changes to DotNetZip now; I'll post an update to the DotNetZip release when the tests complete successfully, probably later tonight.

Thanks for the report!


Feb 10, 2010 at 2:46 AM

The fix I have made should correct the problem you reported.

This fix is now available in the updated release, v1.9.1.3.

Please test it and let me know if it works for you.

Feb 10, 2010 at 7:40 AM

Hi Chesso,

I have test it but now I get odd characters in FileName property of ZipEntry, see this image:

Thanks for your fast response and support.

Feb 10, 2010 at 1:26 PM

I'll need more information on this new problem.

Which file gives you that problem?  Can you show me the code that causes it?

Have you done an update to the zipfile with DotNetZip?  Etc. 


Feb 10, 2010 at 4:24 PM

Cheeso, all is right, sorry.

I don´t know what happened, but work fine now.


Thank you very much.

Feb 10, 2010 at 4:56 PM

I'm glad to hear it, thanks for the reply.  And good luck with DotNetZip.