Search code examples
androidsignandroid-buildzipalign

Why zipaligning after the signing-process?

I recently asked myself why in android we have to first sign and then zipalign the apk. I searched for some background information, how those processes are technically working in detail. I'm still a little bit unhappy, cause those description do not really technically explain why this sequence is necessary.

But lets start from the beginning:

I know the fact that in the apk-build-process following order is necessary

  1. a lot of prior steps...
  2. creating the apk-file
  3. signing the apk-file (modifies apk)
  4. zipaligning the apk-file (modifies apk)

I found some information here:
zipalign

So it is clear that zipalign will align internals to 4-byte-boundaries, so that all can be loaded with mmap. It seems that a Signing- process would destroy this alignment. Therefore zipaligning has to be called at the end of the process after signing.

But why is it possible to make a re-aligning of the apk-content, without destroying the signature of the apk!?
the apk gets modified and the signature should not be valid after a modified apk, i thought...

Maybe someone has more technically background information than I did found here:
Signing your application

Thanks, if anyone has some helpful, more technically detailed information.
Luke

Solution

  • The digital signature of the APK is performed by hashing the APK components. As such, you are protecting the contents of the individual files, and not their position in memory. In other words, the APK contents are signed, but not the APK itself as a single file. As you correctly state, zipalign is merely padding the files in the APK so they start on an aligned boundary, to mmap(2) more efficiently (and be able to discard files easily). The contents, however, do not change, and therefore the signature is not violated.