Checking ZipAlign

Question

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

Resource processing code in Android can effectively access resources when they are aligned at 4-byte boundaries by matching them with memory. But for resources that are not aligned (i.e. when zipalign is not running on apk), it should return to reading them explicitly, which is slower and consumes additional memory.

After starting the tool, you can check the alignment using the command.

zipalign -c -v 4 application.apk 

This creates a report and indicates whether there are errors or not. In my case, these reports indicate no alignment error, but the first number that I assume is the position of the resources in the final APK seems to indicate that some resources are not aligned at 4 byte boundaries.

Here is 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 a resource position? For example, Structures.xml similar to 595425 , which is not a multiple of 4 bytes.

Answer 1

For compressed data, alignment does not matter.

The idea is to be able to display uncompressed chunks in memory and access them directly. If, say, your PNG decoder tries to access data in the form of 32-bit integers, and you have an emulator that emulates the worst behavior of the ARM processor and throws out SIGBUS when you perform 32-bit access without alignment, then you cannot trivially accessing image data if it is not aligned.

The zlib inflate code does not matter if the data is aligned, so zipalign does not bother alignment of the compressed data.