我认为这是一个很好的答案。

APK签名方案v2验证

Locate the APK Signing Block and verify that: Two size fields of APK Signing Block contain the same value. ZIP Central Directory is immediately followed by ZIP End of Central Directory record. ZIP End of Central Directory is not followed by more data. Locate the first APK Signature Scheme v2 Block inside the APK Signing Block. If the v2 Block if present, proceed to step 3. Otherwise, fall back to verifying the APK using v1 scheme. For each signer in the APK Signature Scheme v2 Block: Choose the strongest supported signature algorithm ID from signatures. The strength ordering is up to each implementation/platform version. Verify the corresponding signature from signatures against signed data using public key. (It is now safe to parse signed data.) Verify that the ordered list of signature algorithm IDs in digests and signatures is identical. (This is to prevent signature stripping/addition.) Compute the digest of APK contents using the same digest algorithm as the digest algorithm used by the signature algorithm. Verify that the computed digest is identical to the corresponding digest from digests. Verify that SubjectPublicKeyInfo of the first certificate of certificates is identical to public key. Verification succeeds if at least one signer was found and step 3 succeeded for each found signer.

注意:如果步骤3或步骤4失败，APK不能使用v1方案进行验证。

jar签名的APK验证(v1方案)

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

Each signer is represented by a META-INF/<signer>.SF and META-INF/<signer>.(RSA|DSA|EC) JAR entry. <signer>.(RSA|DSA|EC) is a PKCS #7 CMS ContentInfo with SignedData structure whose signature is verified over the <signer>.SF file. <signer>.SF file contains a whole-file digest of the META-INF/MANIFEST.MF and digests of each section of META-INF/MANIFEST.MF. The whole-file digest of the MANIFEST.MF is verified. If that fails, the digest of each MANIFEST.MF section is verified instead. META-INF/MANIFEST.MF contains, for each integrity-protected JAR entry, a correspondingly named section containing the digest of the entry’s uncompressed contents. All these digests are verified. APK verification fails if the APK contains JAR entries which are not listed in the MANIFEST.MF and are not part of JAR signature. The protection chain is thus <signer>.(RSA|DSA|EC) → <signer>.SF → MANIFEST.MF → contents of each integrity-protected JAR entry.

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

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

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

更新:现在这是强制性的，当针对Android 11。

这里写着“默认情况下，Android Studio 2.2和Android Plugin for Gradle 2.2使用APK签名方案v2和传统的签名方案(使用JAR签名)对应用程序进行签名。”

这些新的复选框似乎是在Android 2.3中出现的，我知道我之前版本的Android Studio(至少2.2)确实使用了两个签名。因此，继续我之前所做的，我认为最好同时选中两个复选框。

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

我认为这是一个很好的答案。

APK签名方案v2验证

Locate the APK Signing Block and verify that: Two size fields of APK Signing Block contain the same value. ZIP Central Directory is immediately followed by ZIP End of Central Directory record. ZIP End of Central Directory is not followed by more data. Locate the first APK Signature Scheme v2 Block inside the APK Signing Block. If the v2 Block if present, proceed to step 3. Otherwise, fall back to verifying the APK using v1 scheme. For each signer in the APK Signature Scheme v2 Block: Choose the strongest supported signature algorithm ID from signatures. The strength ordering is up to each implementation/platform version. Verify the corresponding signature from signatures against signed data using public key. (It is now safe to parse signed data.) Verify that the ordered list of signature algorithm IDs in digests and signatures is identical. (This is to prevent signature stripping/addition.) Compute the digest of APK contents using the same digest algorithm as the digest algorithm used by the signature algorithm. Verify that the computed digest is identical to the corresponding digest from digests. Verify that SubjectPublicKeyInfo of the first certificate of certificates is identical to public key. Verification succeeds if at least one signer was found and step 3 succeeded for each found signer.

注意:如果步骤3或步骤4失败，APK不能使用v1方案进行验证。

jar签名的APK验证(v1方案)

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

Each signer is represented by a META-INF/<signer>.SF and META-INF/<signer>.(RSA|DSA|EC) JAR entry. <signer>.(RSA|DSA|EC) is a PKCS #7 CMS ContentInfo with SignedData structure whose signature is verified over the <signer>.SF file. <signer>.SF file contains a whole-file digest of the META-INF/MANIFEST.MF and digests of each section of META-INF/MANIFEST.MF. The whole-file digest of the MANIFEST.MF is verified. If that fails, the digest of each MANIFEST.MF section is verified instead. META-INF/MANIFEST.MF contains, for each integrity-protected JAR entry, a correspondingly named section containing the digest of the entry’s uncompressed contents. All these digests are verified. APK verification fails if the APK contains JAR entries which are not listed in the MANIFEST.MF and are not part of JAR signature. The protection chain is thus <signer>.(RSA|DSA|EC) → <signer>.SF → MANIFEST.MF → contents of each integrity-protected JAR entry.

我是否应该使用(或两者都使用)来签署apk来发布play store ? 答案是肯定的。

如https://source.android.com/security/apksigning/v2.html#验证 ：

Android 7.0系统支持APK v2签名方案(v2方案)和JAR v1方案(v1方案)两种方式验证APK。旧的平台忽略v2签名，只验证v1签名。

我尝试用检查V2(完整的Apk签名)选项生成构建。然后，当我试图在7.0以下的设备中安装版本时，我无法在该设备中安装版本。

之后，我尝试通过检查版本复选框和生成发布版本来构建。然后能够安装构建。

根据这个链接:签名帮助

APK签名方案v2提供:

更快的应用程序安装时间 更多的保护，防止未经授权的更改APK文件。

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

建议使用APK签名方案v2，但不是强制的。

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