在 Android Studio 中生成签名 APK 时签名版本之间的区别 - V1（Jar 签名）和 V2（完整 APK 签名）？

Question

请至少选择一个签名版本以在 Android Studio 2.3 中使用

现在在 Android Studio 中生成签名 APK 时，在生成签名 APK 的最后一步中显示两个选项（CheckBox），即 1.V1 (Jar Signature) 和 2.V2 (Full APK Signature) 作为 Signature Versions过程。

那么，在新的 Android Studio 更新中，V1（Jar Signature）和V2（Full APK Signature）有什么区别？

我应该使用哪个（或两者）来签署 apk 以发布 Play 商店？

另外，当我使用第二个选项时，我在安装 APK 时收到错误 Install Parse Failed No Certificates。

Answer 1

它是 Android 7.0 中引入的一种新的签名机制，具有旨在使 APK 签名更加安全的附加功能。

这不是强制性的。如果可能，您应该同时选中这两个复选框，但如果新的 V2 签名机制给您带来问题，您可以省略它。

因此，如果遇到问题，您可以不选中 V2，但如果可能的话，应该检查它。

更新：现在在面向 Android 11 时这是强制性的。

Answer 2

我应该使用（或两者）来签署 apk 以发布 Play 商店吗？ 答案是YES。

根据https://source.android.com/security/apksigning/v2.html#verification ：

在 Android 7.0 中，可以根据 APK 签名方案 v2（v2 方案）或 JAR 签名（v1 方案）来验证 APK。旧平台忽略 v2 签名，仅验证 v1 签名。

我尝试通过检查 V2(Full Apk Signature) 选项生成构建。然后，当我尝试在 7.0 设备下安装发布版本时，我无法在设备中安装版本。

之后我尝试通过选中版本复选框并生成发布版本来构建。然后就可以安装构建了。

Answer 3

here 写道：“默认情况下，Android Studio 2.2 和 Android Plugin for Gradle 2.2 使用 APK 签名方案 v2 和使用 JAR 签名的传统签名方案对您的应用程序进行签名。”

似乎这些新复选框出现在 Android 2.3 中，我知道我以前的 Android Studio 版本（至少是 2.2）确实使用这两个签名进行签名。因此，要像以前一样继续，我认为最好同时选中这两个复选框。

2017 年 3 月 31 日编辑： 提交了几个具有两个签名的应用 => 没问题 :)

Answer 4

根据此链接：signature help

APK 签名方案 v2 提供：

1. 更快的应用安装时间
2. 针对未经授权的 APK 文件更改提供更多保护。

Android 7.0 引入了 APK Signature Scheme v2，一种新的应用签名 提供更快的应用程序安装时间和更多保护的方案 防止未经授权更改 APK 文件。默认情况下，安卓 Studio 2.2 和 Android Plugin for Gradle 2.2 使用 APK 签名方案 v2 和传统的签名方案，其中 使用 JAR 签名。

推荐使用 APK 签名方案 v2，但不是强制性的。

虽然我们建议将 APK 签名方案 v2 应用于您的应用， 这个新计划不是强制性的。如果您的应用没有正确构建 使用 APK 签名方案 v2 时，您可以禁用新方案。

Answer 5

我认为this 代表了一个很好的答案。

APK 签名方案 v2 验证

1. 找到APK Signing Block 并验证：
   1. APK Signing Block 的两个大小字段包含相同的值。
   2. ZIP Central Directory 后面紧跟 ZIP End of Central Directory 记录。
   3. ZIP End of Central Directory 后面没有更多数据。
2. 在APK Signing Block 中找到第一个APK Signature Scheme v2 Block。如果存在 v2 Block（如果存在），请继续执行第 3 步。否则，回退到使用 v1 方案验证 APK。
3. 对于APK Signature Scheme v2 Block 中的每个签名者：
   1. 从签名中选择支持的最强签名算法 ID。强度排序取决于每个实现/平台版本。
   2. 使用公钥根据签名数据验证相应的签名。 （现在可以安全地解析签名数据。）
   3. 验证摘要和签名中签名算法 ID 的有序列表是否相同。 （这是为了防止签名剥离/添加。）
   4. 使用与签名算法使用的摘要算法相同的摘要算法计算 APK 内容的摘要。
   5. 验证计算的摘要是否与摘要中的相应摘要相同。
   6. 验证第一个证书的SubjectPublicKeyInfo与公钥相同。
4. 如果至少找到一个签名者，并且每个找到的签名者都成功执行第 3 步，则验证成功。

注意：如果第 3 步或第 4 步发生故障，则不得使用 v1 方案验证 APK。

JAR 签名的 APK 验证（v1 方案）

JAR 签名的 APK 是一个标准签名的 JAR，它必须完全包含 META-INF/MANIFEST.MF 中列出的条目，并且所有条目都必须由同一组签名者签名。其完整性验证如下：

1. 每个签名者由 META-INF/<signer>.SF 和 META-INF/<signer>.(RSA|DSA|EC) JAR 条目表示。
2. <signer>.(RSA|DSA|EC) 是带有 SignedData 结构的 PKCS #7 CMS ContentInfo，其签名通过 <signer>.SF 文件进行验证。
3. <signer>.SF 文件包含META-INF/MANIFEST.MF 的整个文件摘要和META-INF/MANIFEST.MF 的每个部分的摘要。验证了MANIFEST.MF 的整个文件摘要。如果失败，则改为验证每个 MANIFEST.MF 部分的摘要。
4. META-INF/MANIFEST.MF 为每个受完整性保护的 JAR 条目包含一个相应命名的部分，其中包含条目未压缩内容的摘要。所有这些摘要都经过验证。
5. 如果 APK 包含未在 MANIFEST.MF 中列出且不属于 JAR 签名的 JAR 条目，则 APK 验证失败。 因此，保护​​链是<signer>.(RSA|DSA|EC) → <signer>.SF → MANIFEST.MF → 每个受完整性保护的 JAR 条目的内容。