asp.net 手机网站模板edm营销

最近突然发现公司祖传的签名证书要过期了，急忙开始研究解决方案，在这里记录下我们采取的方式。

一、证书过期

• 首先，签名证书过期是没办法进行续期或者重新生成的。而更换证书，那原来安装的 App 就必须要卸载后才能安装版本，而如果 App 已经上架应用市场，那么证书不一致的 APK 文件将无法上传更新，有些应用市场能提工单来申请更新，但存量用户总归是要卸载掉原来的 App 才可以更新你的新版本，这个影响就非常严重了。
• 所以在这里提醒，在生成签名证书时千万要注意指定的有效时间，它的默认有效期是 25 年，Google Play 也有硬性规定，上架的 App 签名有效期必须在 2033-10-22 日期之后，所以只要不是手欠修改了这个有效期，就不会有什么问题。

二、解决方案

这也是 Google 为我们提供的解决方案，即在 Android 9.0 之后引入的 APK 签名方案 v3。

Android 支持三种应用签名方案：

• v1 方案：基于 JAR 签名
• v2 方案： APK 签名方案 v2 ，在 Android 7.0 中引入。
• v3 方案： APK 签名方案 v3 ，在 Android 9 中引入。

签名方案 v3 可以视作 v2 的加强版，仍然是采用检查整个压缩包的校验方式，签名存储在APK签名块中，不同的是 v3 方案支持以链表的形式存储多个证书，这样就允许我们将旧证书签名添加到签名块中，以签名密钥轮替的方式，实现签名的替换和升级。

这样，当用户更新到使用 v3 签名方案签名的 APK 时，在 Android 9 及更高版本中，会根据 APK 签名方案 v3、v2 方案或 v1 方案依次验证 APK。旧平台忽略 v3 签名并尝试验证 v2 签名，然后是 v1。在首次更新 APK 的情况下，因为存量的 App 还未使用 v3 签名方案，所以会直接依次验证旧证书的 v2 、 v1 签名，这样，就实现了客户无感知的 APK 签名升级替换，而后续的更新就会开始验证 v3 签名。

三、更新 v3 签名方案流程

1、轮替签名密钥

准备好新生成的签名证书及旧证书文件，使用以下命令轮替签名密钥，生成 lineage 文件。记住，必须使用 API 28 及以上的 apksigner 生成（Android 9.0 之后才支持的 v3 签名方案）

apksigner rotate --out *lineage --old-signer --ks *old-signer-jks --new-signer --ks *new-signer-jks

• *lineage : 生成的lineage文件路径，例d:\lineage
• *old-signer-jks : 旧签名证书路径
• *new-signer-jks : 新签名证书路径

注 : Window环境下，可以配置相应的环境变量Path就可以不用切目录，直接使用apksigner命令了

2.APK 签名

完成上一步得到 lineage 文件之后，我们就可以使用以下命令对 APK 进行签名了（仍是 API 28 及以上）

apksigner sign --ks *old-signer-jks --next-signer --ks *new-signer-jks --lineage *lineage app.apk

• *lineage : 上一步生成的lineage文件
• *old-signer-jks : 旧签名证书
• *new-signer-jks : 新签名证书
• app.apk : 待签名 APK

输入完成后确认，再按提示分别输入旧证书和新证书的密码，就完成了我们 APK 的 v3 签名

3.APK 签名验证

来到了我们的验证环节，签完名总该确认下我们的 APK 签名成不成功、签名信息有没有问题，这里我们使用的是比较直观的方式 - 显示各 API 版本 获取到的 APK 签名证书信息的方式来提供验证，这里提供两个命令：

apksigner verify -v --print-certs app-name.apkapksigner verify -v --print-certs --max-sdk-version [sdkversion] [apk]

• 命令 1 比较常用，用于查看您所使用 apksigner 对应 API 版本所支持最高版本签名方案的证书信息；

• 这里我们要充分验证 APK 签名信息，要使用的就是我们的命令 2， 这里新增了一个参数
  --max-sdk-version [sdkversion] ，这是 apksigner 用来确认 APK 签名将通过验证的最高 Android 框架 API 级别。你可以理解为对应安卓版本的手机，它将验证你的 APK 的哪一个版本签名方案的签名信息；

举栗：

apksigner verify -v --print-certs --max-sdk-version 22 app-name.apk

apksigner verify -v --print-certs --max-sdk-version 26 app-name.apk`

apksigner verify -v --print-certs --max-sdk-version 30 app-name.apk

• Android 7.0 (API 24) 及以上支持 v2 签名机制
• Android 9.0 (API 28) 及以上支持 v3 签名机制

1. 在 sdkversion = 22 时，Verifies 只有 v1 scheme 为 true，因为 Android 5.1 只支持 V1 签名方案，所以该版本安卓手机也只会验证 v1 的签名信息，APK 也能成功覆盖安装存量 App 来升级；
2. 同理 sdkversion = 26 时， v1 , v2 都为 true 。这里就可以看出来当 API 22 、26 情况下，获取到的 APK 签名信息是一样的，都是我们旧证书的信息，说明我们旧证书成功沿袭了下来；
3. 当 sdkversion = 30 时，这个时候就会同时支持 v3、v2、v1 签名方案，而获取到的签名信息就和上面两个不一样了，是我们新证书的信息，这就说明我们成功完成了证书的升级替换，而后续 Android 9.0 及以上的平台更新 App 都会以这个证书的信息来进行验证。

• 注：这里不推荐使用 keytool -printcert -jarfile app-name.apk 的方式查看 APK 证书信息，因为 keytool 是 java JDK 提供的证书管理工具，它只能查看 APK 基于 JAR 签名的 v1 签名信息。

拓展：有些 App 会做运行时签名证书校验，这里校验获取到的证书信息其实就是 v1 里的签名信息，所以各位也不用担心存量客户端覆盖更新后获取到的证书信息不一致的问题，这下面就是我们 App 里获取证书信息的方式，测试过是可以正常覆盖安装的。

PackageInfo pi = packageManager.getPackageInfo(packageName, PackageManager.GET_SIGNING_CERTIFICATES);
SigningInfo signingInfo = pi.signingInfo;
if (signingInfo.hasMultipleSigners()) {return signingInfo.getApkContentsSigners();
} else {return signingInfo.getSigningCertificateHistory();
}

共勉！

参考 > https://developer.android.google.cn/studio/command-line/apksigner?hl=zh-cn