Android Enthusiasts Stack Exchange is a question and answer site for enthusiasts and power users of the Android operating system. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What does "zipalign" mean and what is its significance?

When a ROM claims to be "zipaligned" what does that mean and what the difference from a ROM that is not "zipaligned"?

share|improve this question
up vote 20 down vote accepted

This mechanism is described at the Android developers site as follows:

zipalign is an archive alignment tool that provides important optimization to Android application (.apk) files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file. Specifically, it causes all uncompressed data within the .apk, such as images or raw files, to be aligned on 4-byte boundaries. This allows all portions to be accessed directly with mmap() even if they contain binary data with alignment restrictions. The benefit is a reduction in the amount of RAM consumed when running the application.

In short: .apk content can be easier/faster/more optimal accessed due to the order of data inside the packed file.

For deeper information, there's a "complete guide" available at AddictiveTips: What Is Zipalign In Android And How To Make Apps Zipaligned, which answers the second part of your question:

Quite understandably, situation would be reserved for unaligned application packages. Resource reading would be slow and memory usage would be on the higher end of the spectrum. It would also depend on how many unaligned applications are present. For example, if less number of applications with an unaligned home application, you’d see slower application launch times. This is the best case scenario. For a worst case scenario, having a number of unaligned applications will result in the system repeatedly starting and killing processes, struggling with lags and huge battery drain.

share|improve this answer
For programmers it's more or less similar to struct alignment in C. Don't do struct x { uint16_t id; uint32_t data[100]; }; if you want it to be 32-bit aligned; use struct x { uint16_t id; uint16_t padding; uint32_t data[100]; }; – Matthew Read Sep 24 '12 at 16:34
There appears to be no downside do why aren't all apps zip aligned? Also is this really even a concern for end users or is it only relevant to developers? – Matt Sep 24 '12 at 20:53
It's an additional step for the dev I'd say. And of course the performance is a concern for end users ;) – Izzy Sep 24 '12 at 21:02

To add to above how exactly zipalign works -

In an Android operating environment, data files stored in each application package are accessed by multiple processes, for example, the installer will read the data manifest to determine the associated permissions; the system server can read these resources for multiple reasons, like displaying notifications; the Home application, for example, will read resources to get the application’s name and icon. Since Android is based on a a true multi-tasking operating infrastructure, these files are continually and repeatedly accessed. Finally, but not least, the application itself reads the manifest data.

As Android is Linux-based, memory-mapping plays a key role in efficient handling of processes. Essentially, the optimal alignment for the Android OS’ resource-handling code is 4-byte boundaries. What this means is that, if APKs are memory-mapped to 4-byte boundaries, and aligned accordingly, the OS will not need to ‘read through’ the whole application package to get to the desired data manifest. Every system process will know in advance where to look for it’s desired resources, and hence will execute much smoother and faster.

Summing it up, zipaligning an APK results in all uncompressed data within the package to be aligned on 4-byte boundaries, allowing all portions to be accessed directly with the memory-map. RAM consumption is lowered while execution because the querying code doesn’t have to read through the entire application package.


share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.