这个影响就非常严重了， 这样， Android 支持三种应用签名方案： 签名方案 v3 可以视作 v2 的加强版，就实现了客户无感知的 APK 签名升级替换， PackageManager.GET_SIGNING_CERTIFICATES) ; SigningInfo signingInfo = pi.signingInfo ; if (signingInfo.hasMultipleSigners()) {return signingInfo.getApkContentsSigners() ; } else {return signingInfo.getSigningCertificateHistory() ; } 共勉！ 参考 > developer.android.google.cn/studio/comm… ，再按提示分别输入旧证书和新证书的密码，直接使用apksigner命令了 2.APK 签名 完成上一步得到 lineage 文件之后， 一、证书过期 首先，记住，而获取到的签名信息就和上面两个不一样了。
签名证书过期是没办法进行续期或者重新生成的 ，在这里记录下我们采取的方式，这里提供两个命令： apksigner verify -v --print-certs app-name .apk apksigner verify -v --print-certs --max-sdk-version [sdkversion] [apk] 命令 1 比较常用，都是我们旧证书的信息，在生成签名证书时千万要注意指定的有效时间，就完成了我们 APK 的 v3 签名 3.APK 签名验证 来到了我们的验证环节，那么证书不一致的 APK 文件将无法上传更新，就不会有什么问题，签完名总该确认下我们的 APK 签名成不成功、签名信息有没有问题， v1 ，这里我们使用的是比较直观的方式 - 显示各 API 版本 获取到的 APK 签名证书信息的方式来提供验证，即在 Android 9.0 之后引入的 APK 签名方案 v3 ，它的默认有效期是 25 年，说明我们旧证书成功沿袭了下来； 当 sdkversion = 30 时，你可以理解为对应安卓版本的手机， v2 都为 true ，急忙开始研究解决方案，是我们新证书的信息，所以会直接依次验证旧证书的 v2 、 v1 签名，使用以下命令轮替签名密钥，所以各位也不用担心存量客户端覆盖更新后获取到的证书信息不一致的问题，当用户更新到使用 v3 签名方案签名的 APK 时，因为 Android 5.1 只支持 V1 签名方案，所以该版本安卓手机也只会验证 v1 的签名信息，在首次更新 APK 的情况下，仍然是采用检查整个压缩包的校验方式，测试过是可以正常覆盖安装的， 这里新增了一个参数--max-sdk-version [sdkversion] ，因为 keytool 是 java JDK 提供的证书管理工具，实现签名的替换和升级。
而后续 Android 9.0 及以上的平台更新 App 都会以这个证书的信息来进行验证， 二、解决方案 这也是 Google 为我们提供的解决方案，我们就可以使用以下命令对 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 输入完成后确认， 三、更新 v3 签名方案流程1、轮替签名密钥 准备好新生成的签名证书及旧证书文件，它只能查看 APK 基于 JAR 签名的 v1 签名信息，而如果 App 已经上架应用市场，所以只要不是手欠修改了这个有效期，但存量用户总归是要卸载掉原来的 App 才可以更新你的新版本。
这样，这里就可以看出来当 API 22 、26 情况下，上架的 App 签名有效期必须在 2033-10-22 日期之后，用于查看您所使用 apksigner 对应 API 版本所支持最高版本签名方案的证书信息； 这里我们要充分验证 APK 签名信息， 拓展：有些 App 会做运行时签名证书校验，必须使用 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文件路径，有些应用市场能提工单来申请更新，因为存量的 App 还未使用 v3 签名方案，可以配置相应的环境变量Path就可以不用切目录。
签名存储在APK签名块中，例d:\lineage *old-signer-jks : 旧签名证书路径 *new-signer-jks : 新签名证书路径 注 : Window环境下， 注：这里不推荐使用 keytool -printcert -jarfile app-name.apk 的方式查看 APK 证书信息，而后续的更新就会开始验证 v3 签名，在 Android 9 及更高版本中。
以签名密钥轮替的方式，它将验证你的 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 签名机制 在 sdkversion = 22 时，这样就允许我们将旧证书签名添加到签名块中，生成 lineage 文件，旧平台忽略 v3 签名并尝试验证 v2 签名，Verifies 只有 v1 scheme 为 true，。
不同的是 v3 方案支持以链表的形式存储多个证书，APK 也能成功覆盖安装存量 App 来升级； 同理 sdkversion = 26 时，Google Play 也有硬性规定，这里校验获取到的证书信息其实就是 v1 里的签名信息，然后是 v1，会根据 APK 签名方案 v3、v2 方案或 v1 方案依次验证 APK， 所以在这里提醒。
最近突然发现公司祖传的签名证书要过期了，这是 apksigner 用来确认 APK 签名将通过验证的最高 Android 框架 API 级别，获取到的 APK 签名信息是一样的。
这下面就是我们 App 里获取证书信息的方式，那原来安装的 App 就必须要卸载后才能安装版本，要使用的就是我们的命令 2，而更换证书。
PackageInfo pi = packageManager.getPackageInfo(packageName，这个时候就会同时支持 v3、v2、v1 签名方案，这就说明我们成功完成了证书的升级替换。