9

In Android, ZipAlign is used to align resources on 4 bytes boundaries to speed-up resources loading:

The resource-handling code in Android can efficiently access resources when they're aligned on 4-byte boundaries by memory-mapping them. But for resources that are not aligned (i.e. when zipalign hasn't been run on an apk), it has to fall back to explicitly reading them—which is slower and consumes additional memory.

After running the tool, it is possible to validate the alignment using the command.

zipalign -c -v 4 application.apk

This produces a report and tells if there are errors or not. In my case, this reports indicates no alignment error, but the first number, which I assume it the position of the resources in the final APK, seems to show that some resources are not aligned on 4 bytes boundaries.

Here is a the beginning of this report:

    Verifying alignment of APP-signed-aligned.apk (4)...
      50 META-INF/MANIFEST.MF (OK - compressed)
   24245 META-INF/KEYS.SF (OK - compressed)
   49830 META-INF/KEYS.DSA (OK - compressed)
   50683 AndroidManifest.xml (OK - compressed)
   53096 assets/Assets/DB_Normal.db (OK)
  595425 assets/Assets/Common/DM/Structures.xml (OK - compressed)

What did I miss? Is the first number the position of the resource? For example Structures.xml seems to be at 595425, which is not a multiple of 4 bytes.

J_D
  • 3,526
  • 20
  • 31

1 Answers1

7

The alignment doesn't matter for compressed data.

The idea is to be able to memory-map the uncompressed chunks and access them directly. If, say, your PNG decoder tries to access data as 32-bit integers, and you have an emulator that emulates worst-case ARM CPU behavior and throws a SIGBUS when you do an unaligned 32-bit access, then you can't trivially access the image data if it isn't aligned.

The zlib inflate code doesn't care if the data is aligned, so zipalign doesn't bother aligning the compressed data.

fadden
  • 51,356
  • 5
  • 116
  • 166