android - 为什么在签名过程之后进行 zipaligning?

标签 android sign android-build zipalign

我最近问自己,为什么在 Android 中我们必须先签名然后然后 zipalign apk。我搜索了一些背景信息,这些过程在技术上是如何工作的。我还是有点不高兴,因为这些描述并没有真正从技术上解释为什么这个序列是必要的。

但让我们从头开始:

我知道在 apk-build-process 中以下顺序是必要的

  1. 许多预先的步骤...
  2. 创建 apk 文件
  3. 签署 apk 文件(修改 apk)
  4. zipaligning apk 文件(修改 apk)

我在这里找到了一些信息:
zipalign

很明显,zipalign 会将内部对齐到 4 字节边界,以便所有内容都可以使用 mmap 加载。 似乎签名过程会破坏这种对齐方式。因此,必须在签名后的过程结束时调用 zipaligning。

但为什么可以在不破坏 apk 签名的情况下重新对齐 apk 内容!?
apk 被修改并且签名在修改后的 apk 之后应该无效,我想......

也许有人比我在这里找到的技术背景信息更多:
Signing your application

谢谢,如果有人有一些有用的、技术上更详细的信息。
卢克

最佳答案

APK 的数字签名是通过散列 APK 组件来执行的。因此,您保护的是单个文件的内容,而不是它们在内存中的位置。换句话说,APK 内容已签名,但作为单个文件的 APK 本身并未签名。正如您正确指出的那样,zipalign 只是填充 APK 中的文件,以便它们从对齐的边界开始,以便更有效地 mmap(2)(并且能够轻松丢弃文件)。但是,内容不会改变,因此不会违反签名。

关于android - 为什么在签名过程之后进行 zipaligning?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28124448/

相关文章:

android - 获取snackbar支持库的高度

performance - 如何在没有乘法/分支的情况下使用一些常量和运算符翻转整数值的符号

windows-10 - 避免使用authenticode cert签名的install4j安装程序出现 "Windows protected your PC"消息

android - 我在签名时似乎无法构建我的android应用程序

Gradle 在 TransformClassesWithDexForDebug 上构建缓慢

android - 替换android apk中的.so文件

android - BitmapFactory.decodeStream 线程安全吗?有时我的异步任务在完成之前完成

android - getIntent 在 MainActivity 中不起作用。越来越奇怪的行为

java - 编写Android项目时的常见错误

Android NDK 集成 : Error:Unable to load class BuildType$Impl