简介

大部分开发者对apk签名还停留在APK v2，对APK v3和APK v4了解很少，而且网上大部分文章讲解的含糊不清，所以根据官网文档重新整理一份。

apk签名从APK v1到APK v2改动很大，是颠覆性的，而APK v3只是对APK v2的一次升级，APK v4则是一个补充。

本篇文章主要参考Android各版本改动(https://developer.android.google.cn/about/versions/pie/)，下面来看看这四代签名有什么不同

APK v1

就是jar签名，apk最初的签名方式，大家都很熟悉了，签名完之后是META-INF 目录下的三个文件：MANIFEST.MF、CERT.SF、CERT.RSA。

1. MANIFEST.MF
   MANIFEST.MF中是apk种每个文件名称和摘要SHA1（或者 SHA256），如果是目录则只有名称

2. CERT.SF
   CERT.SF则是对MANIFEST.MF的摘要，包括三个部分：

• SHA1-Digest-Manifest-Main-Attributes：对 MANIFEST.MF 头部的块做 SHA1（或者SHA256）后再用 Base64 编码
• SHA1-Digest-Manifest：对整个 MANIFEST.MF 文件做 SHA1（或者 SHA256）后再用 Base64 编码
• SHA1-Digest：对 MANIFEST.MF 的各个条目做 SHA1（或者 SHA256）后再用 Base64 编码

3. CERT.RSA
   CERT.RSA是将CERT.SF通过私钥签名，然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存

通过这三层校验来确保apk中的每个文件都不被改动。

APK v2

官方说明(https://source.android.google.cn/security/apksigning/v2)

APK 签名方案 v2 是在 Android 7.0 (Nougat) 中引入的。为了使 APK 可在 Android 6.0 (Marshmallow) 及更低版本的设备上安装，应先使用 JAR 签名功能对 APK 进行签名，然后再使用 v2 方案对其进行签名。

APK v1的缺点就是META-INF目录下的文件并不在校验范围内，所以之前多渠道打包等都是通过在这个目录下添加文件来实现的。

APK 签名方案 v2 是一种全文件签名方案，该方案能够发现对 APK 的受保护部分进行的所有更改，从而有助于加快验证速度并增强完整性保证。

使用 APK 签名方案 v2 进行签名时，会在 APK 文件中插入一个 APK 签名分块，该分块位于“ZIP 中央目录”部分之前并紧邻该部分。在“APK 签名分块”内，v2 签名和签名者身份信息会存储在 APK 签名方案 v2 分块中。

通俗点说就是签名信息不再以文件的形式存储，而是将其转成二进制数据直接写在apk文件中，这样就避免了APK v1的META-INF目录的问题。

在 Android 7.0 及更高版本中，可以根据 APK 签名方案 v2+ 或 JAR 签名（v1 方案）验证 APK。更低版本的平台会忽略 v2 签名，仅验证 v1 签名。

APK v3

官方说明(https://source.android.google.cn/security/apksigning/v3)

APK 签名方案 v3 是在 Android 9 中引入的。

Android 9 支持 APK 密钥轮替，这使应用能够在 APK 更新过程中更改其签名密钥。为了实现轮替，APK 必须指示新旧签名密钥之间的信任级别。为了支持密钥轮替，我们将 APK 签名方案从 v2 更新为 v3，以允许使用新旧密钥。v3 在 APK 签名分块中添加了有关受支持的 SDK 版本和 proof-of-rotation 结构的信息。

简单来说APK v3就是为了Andorid9的APK 密钥轮替功能而出现的，就是在v2的基础上增加两个数据块来存储APK 密钥轮替所需要的一些信息，所以可以看成是v2的升级。具体结构见官网说明即可。

APK 密钥轮替功能可以参考官方文档(https://developer.android.google.cn/about/versions/pie/android-9.0)

具有密钥轮转的 APK 签名方案

Android 9 新增了对 APK Signature Scheme v3 的支持。该架构提供的选择可以在其签名块中为每个签名证书加入一条轮转证据记录。利用此功能，应用可以通过将 APK 文件过去的签名证书链接到现在签署应用时使用的证书，从而使用新签名证书来签署应用。

注：运行 Android 8.1（API 级别 27）或更低版本的设备不支持更改签名证书。如果应用的 minSdkVersion 为 27 或更低，除了新签名之外，可使用旧签名证书来签署应用。

详细了解如何使用 apksigner 轮转密钥参考官方文档(https://developer.android.google.cn/studio/command-line/apksigner#usage-rotate)

在 Android 9 及更高版本中，可以根据 APK 签名方案 v3、v2 或 v1 验证 APK。较旧的平台会忽略 v3 签名而尝试验证 v2 签名，然后尝试验证 v1 签名。

APK v4

官方说明(https://source.android.google.cn/security/apksigning/v4)

APK 签名方案 v4 是在 Android 11 中引入的。

Android 11 通过 APK 签名方案 v4 支持与流式传输兼容的签名方案。v4 签名基于根据 APK 的所有字节计算得出的 Merkle 哈希树。它完全遵循 fs-verity 哈希树的结构（例如，对salt进行零填充，以及对最后一个分块进行零填充。）Android 11 将签名存储在单独的 .apk.idsig 文件中。v4 签名需要 v2 或 v3 签名作为补充。

APK v4同样是为了新功能而出现的，这个新功能就是ADB 增量 APK 安装，可以参考Android11 功能和 API 概览(https://developer.android.google.cn/about/versions/11/features)：

ADB 增量 APK 安装

在设备上安装大型（2GB 以上）APK 可能需要很长的时间，即使应用只是稍作更改也是如此。ADB（Android 调试桥）增量 APK 安装可以安装足够的 APK 以启动应用，同时在后台流式传输剩余数据，从而加速这一过程。如果设备支持该功能，并且您安装了最新的 SDK 平台工具，adb install 将自动使用此功能。如果不支持，系统会自动使用默认安装方法。

运行以下 adb 命令以使用该功能。如果设备不支持增量安装，该命令将会失败并输出详细的解释。

adb install --incremental

在运行 ADB 增量 APK 安装之前，您必须先为 APK 签名并创建一个 APK 签名方案 v4 文件。必须将 v4 签名文件放在 APK 旁边，才能使此功能正常运行。

因为需要流式传输，所以需要将文件分块，对每一块进行签名以便校验，使用的方式就是Merkle 哈希树(https://www.kernel.org/doc/html/latest/filesystems/fsverity.html#merkle-tree)，APK v4就是做这部分功能的。所以APK v4与APK v2或APK v3可以算是并行的，所以APK v4签名后还需要 v2 或 v3 签名作为补充。

运行adb install --incremental命令时，adb 会要求 .apk.idsig 文件存在于 .apk 旁边（所以APK v4的签名文件.apk.idsig并不会打包进apk文件中）

默认情况下，它还会使用 .idsig 文件尝试进行增量安装；如果此文件缺失或无效，该命令会回退到常规安装。

总结

综上，可以看到APK v4是面向ADB即开发调试的，而如果我们没有签名变动的需求也可以不考虑APK v3，所以目前国内大部分还停留在APK v2。

​
签名后应用就可以发布了，自 2021 年 8 月起，Google Play 将开始要求新应用使用 Android App Bundle 进行发布。这里面就涉及另外一个功能：
《【Android开发】App Bundle技术之动态功能模块》

​