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.