homepage

This is definitely *not* a padding issue.
The problem is that one of the records has an extra field of length 1:
$ zipinfo -v bla.apk
...
Central directory entry #3:
---------------------------
 There are an extra 16 bytes preceding this file.
 res/raw/ice.png
 offset of local header from start of archive: 1190 (000004A6h) bytes
 file system or operating system of origin: MS-DOS, OS/2 or NT FAT
 version of encoding software: 1.0
 minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
 minimum software version required to extract: 1.0
 compression method: none (stored)
 file security status: not encrypted
 extended local header: no
 file last modified on (DOS date/time): 2012 Jan 13 15:30:08
 32-bit CRC value (hex): f969abab
 compressed size: 26250 bytes
 uncompressed size: 26250 bytes
 length of filename: 15 characters
 length of extra field: 1 bytes
 length of file comment: 0 characters
 disk number on which file begins: disk 1
 apparent file type: binary
 non-MSDOS external file attributes: 000000 hex
 MS-DOS file attributes (00 hex): none
 The central-directory extra field contains:
 There is no file comment.
Our implementation can't deal with that because of the line that Terry 
pointed out:
 tp, ln = unpack('<HH', extra[:4])
As Martin pointed out, the standard says that things must be in 
multiples of 4-bytes. So the record is non-portable.