来源：Android 签名机制 v1、v2、v3

APK 签名方案 v1

签名工具

• jarsigner：jdk 自带的签名工具，可以对 jar 进行签名。使用 keystore 文件进行签名。生成的签名文件默认使用 keystore 的别名命名。
• apksigner：Android sdk 提供的专门用于 Android 应用的签名工具。使用 pk8、x509.pem 文件进行签名。其中 pk8 是私钥文件，x509.pem 是含有公钥的文件。生成的签名文件统一使用“CERT”命名。

keystore 文件的内容，会发现里面包含有一个 MD5 和 SHA1 摘要，这个就是 keystore 文件中私钥的数据摘要，这个信息也是我们在申请很多开发平台账号时需要填入的信息。

V1签名过程

apk解压后META-INF 文件夹下有三个文件：MANIFEST.MF、CERT.SF、CERT.RSA。

完整的签名过程

MANIFEST.MF

该文件中保存的内容其实就是逐一遍历 APK 中的所有条目

如果是目录就跳过，文件的话执行以下几部

1. 用 SHA1（或者 SHA256）消息摘要算法提取出该文件的摘要
2. 文件摘要进行** BASE64** 编码后，作为「SHA1-Digest」属性的值写入到 MANIFEST.MF 文件中的一个块中。
   （该块有一个「Name」属性， 其值就是该文件在 APK 包中的路径）

CERT.SF

• 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 编码

CERT.RSA

这里会把之前生成的 CERT.SF 文件，用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存。这里要注意的是，Android APK 中的 CERT.RSA 证书是自签名的，并不需要这个证书是第三方权威机构发布或者认证的，用户可以在本地机器自行生成这个自签名证书。Android 目前不对应用证书进行 CA 认证。

什么是自签名证书？
所谓自签名证书是指自己给自己颁发的证书，即公钥证书中 Issuer（发布者）和 Subject（所有者）是相同的。当然，APK 也可以采用由 CA 颁发私钥证书进行签名。采用非自签名时，最终 APK 的公钥证书中就会包含证书链，并且会存在多余一个证书，证书间通过 Issuer 与 Subject进行关联，Issuer 负责对 Subject 进行认证。当安装 APK 时，系统只会用位于证书链 中最底层的证书对 APK 进行校验，但并不会验证证书链的有效性。

在 HTTPS 通信中使用自签名证书时浏览器的显示效果：

CERT.RSA 文件中的内容

RSA 文件加密了，所以我们需要用 openssl 命令才能查看其内容

$ openssl pkcs7 -inform DER -in /<文件存放路径>/Sample-release_new/original/META-INF/CERT.RSA -text -noout -print_certs

V1签名校验过程

一个完整的签名验证过程

签名验证是发生在 APK 的安装过程中，一共分为三步：

1. 检查 APK 中包含的所有文件，对应的摘要值与 MANIFEST.MF 文件中记录的值一致。

2. 使用证书文件（RSA 文件）检验签名文件（SF 文件）没有被修改过。

3. 使用签名文件（SF 文件）检验 MF 文件没有被修改过。

V1签名方案缺点

• 签名校验速度慢
  校验过程中需要对apk中所有文件进行摘要计算，在 APK 资源很多、性能较差的机器上签名校验会花费较长时间，导致安装速度慢。
• 完整性保障不够
  META-INF 目录用来存放签名，自然此目录本身是不计入签名校验过程的，可以随意在这个目录中添加文件，比如一些快速批量打包方案就选择在这个目录中添加渠道文件。

APK 签名方案 v2

为了解决V1的缺点，在 Android 7.0 Nougat 中引入了全新的 APK Signature Scheme v2。

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

v2 带来了什么变化？

由于在 v1 仅针对单个 ZIP 条目进行验证，因此，在 APK 签署后可进行许多修改 — 可以移动甚至重新压缩文件。事实上，编译过程中要用到的 ZIPalign 工具就是这么做的，它用于根据正确的字节限制调整 ZIP 条目，以改进运行时性能。而且我们也可以利用这个东西，在打包之后修改 META-INF 目录下面的内容，或者修改 ZIP 的注释来实现多渠道的打包，在 v1 签名中都可以校验通过。

v2 签名将验证归档中的所有字节，而不是单个 ZIP 条目，因此，在签署后无法再运行 ZIPalign（必须在签名之前执行）。正因如此，现在，在编译过程中，Google 将压缩、调整和签署合并成一步完成。

v2 签名模式

简单来说，v2 签名模式在原先 APK 块中增加了一个新的块（签名块），新的块存储了签名，摘要，签名算法，证书链，额外属性等信息，这个块有特定的格式，具体格式分析见后文，先看下现在 APK 成什么样子了。

为了保护 APK 内容，整个 APK（ZIP 文件格式）被分为以下 4 个区块：

• ZIP 条目的内容（从偏移量 0 处开始一直到“APK 签名分块”的起始位置）
• APK 签名分块
• ZIP 中央目录
• ZIP 中央目录结尾

其中，应用签名方案的签名信息会被保存在 区块 2（APK Signing Block）中，而区块 1（Contents of ZIP entries）、区块 3（ZIP Central Directory）、区块 4（ZIP End of Central Directory）是受保护的，在签名后任何对区块 1、3、4 的修改都逃不过新的应用签名方案的检查。

V2签名过程

1. 把 APK 按照 1M 大小分割，分别计算这些分段摘要
2. 把这些分段的摘要再进行计算得到最终的摘要也就是 APK 的摘要。
3. 将 APK 的摘要 + 数字证书 + 其他属性生成签名数据写入到 APK Signing Block 区块。

V2签名校验过程

其中 v2 签名机制是在 Android 7.0 以及以上版本才支持。因此对于 Android 7.0 以及以上版本，在安装过程中，如果发现有 v2 签名块，则必须走 v2 签名机制，不能绕过。否则降级走 v1 签名机制。
v1 和 v2 签名机制是可以同时存在的，其中对于 v1 和 v2 版本同时存在的时候，v1 版本的 META_INF 的 .SF 文件属性当中有一个 X-Android-APK-Signed 属性，因此如果想绕过 v2 走 v1 校验是不行的。

X-Android-APK-Signed: 2

v2 对多渠道打包的影响

之前的渠道包生成方案是通过在 META-INF 目录下添加空文件，用空文件的名称来作为渠道的唯一标识。但在新的应用签名方案下 META-INF 已经被列入了保护区了，向 META-INF 添加空文件的方案会对区块 1、3、4 都会有影响。

可以参考：美团解决方案。

APK 签名方案 v3 （9.0引入）

V3签名方案

Android 9.0 中引入了新的签名方式，它的格式大体和 v2 类似，在 v2 插入的签名块（Apk Signature Block v2）中，又添加了一个新快（Attr块）。

在这个新块中，会记录我们之前的签名信息以及新的签名信息，以密钥转轮的方案，来做签名的替换和升级。这意味着，只要旧签名证书在手，我们就可以通过它在新的 APK 文件中，更改签名。

v3 签名新增的新块（attr）存储了所有的签名信息，由更小的 Level 块，以链表的形式存储。

其中每个节点都包含用于为之前版本的应用签名的签名证书，最旧的签名证书对应根节点，系统会让每个节点中的证书为列表中下一个证书签名，从而为每个新密钥提供证据来证明它应该像旧密钥一样可信。

这个过程有点类似 CA 证书的证明过程，已安装的 App 的旧签名，确保覆盖安装的 APK 的新签名正确，将信任传递下去。

V3签名校验过程

需要注意的是，对于覆盖安装的情况，签名校验只支持升级，而不支持降级。也就是说设备上安装了一个使用 v1 签名的 APK，可以使用 v2 签名的 APK 进行覆盖安装，反之则不允许。