zipalign

Align the data of a Zip file on 4-byte boundaries

$ zipalign [4] [path/to/input.zip] [path/to/output.zip]

$ zipalign -v -c [4] [path/to/input.zip]

zipalign [-f] [-v] <alignment> <infile.apk> <outfile.apk>
zipalign -c [-v] <alignment> <infile.apk>

-f
    Force overwrite existing <outfile.apk> without prompting.

-v
    Enable verbose output, showing more details about the alignment process.

-c
    Check alignment only. This option performs a check to verify if the <infile.apk> is already aligned correctly. No output file is generated.

<alignment>
    A positive integer representing the byte alignment, typically 4. This ensures that uncompressed data starts at an offset that is a multiple of this value within the APK. For 32-bit systems, 4-byte alignment is standard.

<infile.apk>
    Path to the input unaligned Android Package (APK) file.

<outfile.apk>
    Path where the aligned Android Package (APK) file will be saved. This parameter is ignored when using the -c (check) option.

The zipalign command is an archive alignment tool provided as part of the Android SDK Build Tools. Its primary function is to optimize Android Package (APK) files by ensuring that all uncompressed data within the archive, such as image and audio files, starts at a specific byte alignment relative to the beginning of the file. This alignment allows the Android system to directly memory-map the APK file, eliminating the need to copy data from the archive into RAM at runtime. The result is a significant reduction in RAM consumption for the application, faster loading times, and overall improved performance on Android devices.

Typically, zipalign is applied as a final optimization step before an APK is distributed. While modern Android signing tools like apksigner automatically incorporate this alignment, developers using older signing methods (like jarsigner) or custom build processes must manually run zipalign. It is crucial to run zipalign *before* signing an APK with jarsigner, as running it after would invalidate the digital signature.

If you are using the modern apksigner tool (Android SDK Build-Tools 24.0.3 and higher), zipalign is automatically performed as part of the signing process. Manually running it before apksigner is redundant.

If you are using the older jarsigner tool to sign your APK, it is absolutely critical to run zipalign *before* signing the APK. Running zipalign after jarsigner will invalidate the digital signature, making the APK untrustworthy and un-installable.

The most common and recommended <alignment> value is 4 (for 4-byte alignment), as it aligns with typical 32-bit memory access patterns on Android devices. Using an incorrect alignment value can lead to unexpected behavior or no performance benefits.

The standard 4-byte alignment is chosen because it matches the typical word size (32-bit) of ARM processors commonly used in Android devices. Ensuring that uncompressed data (like images and audio) starts at a memory address that is a multiple of 4 bytes allows the operating system and hardware to directly memory-map these files. This direct mapping avoids the need for copying data into a separate buffer in RAM, thereby reducing memory consumption and improving I/O performance as the data can be accessed directly from the APK file itself.

zipalign has been a core utility within the Android SDK Build Tools since early versions. It was developed by Google to address performance and memory efficiency challenges on Android devices, particularly concerning how resources are accessed within APK files. Initially, developers had to manually incorporate zipalign into their build pipelines. However, with the evolution of Android's build system and signing tools, especially the introduction of apksigner, the execution of zipalign has become largely automated and integrated into the standard signing workflow, simplifying the process for developers while maintaining the crucial optimization benefits.

apksigner(1), jarsigner(1), aapt(1), aapt2(1)