我们将围绕以下主要知识点进行思考：
1 为什么签名分Jar签名(v1)方案和v2方案呢?
2 只使用其中一种签名方案能否执行打包APK,并发布到应用市场,或者说覆盖之前的APK呢?
本篇不涉及Apk签名的具体流程,具体可参考 https://blog.csdn.net/jiangwei0910410003/article/details/50402000
1 Apk签名概述
当应用（APK 文件）安装到 Android 设备上时，软件包管理器会验证 APK 是否已经过适当签名（已使用 APK 中包含的证书签名）。如果该证书（或更准确地说，证书中的公钥）与设备上的任何其他 APK 使用的签名密钥一致，那么这个新 APK 就可以选择在清单中指定它将与其他以类似方式签名的 APK 共用一个 UID。
应用可以由第三方（OEM、运营商、其他应用市场）签名，也可以自行签名。Android 提供了使用自签名证书进行代码签名的功能，而开发者无需外部协助或许可即可生成自签名证书。应用并非必须由核心机构签名。Android 目前不对应用证书进行 CA 认证。
应用还可以在“签名”保护级别声明安全权限，以便只有使用同一个密钥签名的应用可以获得此仅限，同时让这些应用可以各自维持单独的 UID 和应用沙盒。通过共用 UID 功能，多个应用可以共用一个应用沙盒，从而建立起更紧密的联系。在该功能中，使用同一个开发者密钥签名的两个或更多应用可以在其清单中声明共用的 UID。
2 APK 签名方案
注意:此处我们可以找到本文开头所说的问题1的答案
Android 支持两种应用签名方案，一种是基于 JAR 签名的方案（v1 方案），另一种是 Android Nougat (Android 7.0) 中引入的 APK 签名方案 v2（v2 方案）。
为了最大限度地提高兼容性，应同时采用 v1 和 v2 这两种方案对应用进行签名。与只通过 v1 方案签名的应用相比，通过 v2 方案签名的应用能够更快速地安装到 Android Nougat 及更高版本的设备上。更低版本的 Android 平台会忽略 v2 签名，这就需要应用包含 v1 签名。
2.1 JAR 签名（v1 方案）
从一开始，APK 签名就是 Android 的一个有机部分。该方案基于签名的 JAR。如要详细了解如何使用该方案，请参阅介绍如何为您的应用签名的 Android Studio 文档。
v1 签名不保护 APK 的某些部分，例如 ZIP 元数据。APK 验证程序需要处理大量不可信（尚未经过验证）的数据结构，然后会舍弃不受签名保护的数据。这会导致相当大的受攻击面。此外，APK 验证程序必须解压所有已压缩的条目，而这需要花费更多时间和内存。为了解决这些问题，Android 7.0 中引入了 APK 签名方案 v2。
2.2 APK 签名方案 v2（v2 方案）
Android 7.0 中引入了 APK 签名方案 v2（v2 方案）。该方案会对 APK 的内容进行哈希处理和签名，然后将生成的“APK 签名分块”插入到 APK 中。如要详细了解如何在应用中使用 v2 方案，请参阅 Android N 开发者预览版中的 APK 签名方案 v2。
在验证期间，v2 方案会将 APK 文件视为 Blob，并对整个文件进行签名检查。对 APK 进行的任何修改（包括对 ZIP 元数据进行的修改）都会使 APK 签名作废。这种形式的 APK 验证不仅速度要快得多，而且能够发现更多种未经授权的修改。
新的签名格式向后兼容，因此，使用这种新格式签名的 APK 可在更低版本的 Android 设备上进行安装（会直接忽略添加到 APK 的额外数据），但前提是这些 APK 还带有 v1 签名。
2.3 APK 签名方案 v2 具体细节
使用 APK 签名方案 v2 进行签名时，会在 APK 文件中插入一个 APK 签名分块，该分块位于“ZIP 中央目录”部分之前并紧邻该部分。在“APK 签名分块”内，v2 签名和签名者身份信息会存储在 APK 签名方案 v2 分块中。
图 1. 签名前和签名后的 APK
APK 签名方案 v2 是在 Android 7.0 (Nougat) 中引入的。为了使 APK 可在 Android 6.0 (Marshmallow) 及更低版本的设备上安装，应先使用 JAR 签名功能对 APK 进行签名，然后再使用 v2 方案对其进行签名。
3 验证
注意:此处的验证是android系统自动执行的,此处我们可以找到本文开头所说的问题2的答案
在 Android 7.0 中，可以根据 APK 签名方案 v2（v2 方案）或 JAR 签名（v1 方案）验证 APK。更低版本的平台会忽略 v2 签名，仅验证 v1 签名。
图 4. APK 签名验证过程（新步骤以红色显示）
APK 签名方案 v2 验证
- 找到“APK 签名分块”并验证以下内容：
- “APK 签名分块”的两个大小字段包含相同的值。
- “ZIP 中央目录结尾”紧跟在“ZIP 中央目录”记录后面。
- “ZIP 中央目录结尾”之后没有任何数据。
- 找到“APK 签名分块”中的第一个“APK 签名方案 v2 分块”。如果 v2 分块存在，则继续执行第 3 步。否则，回退至使用 v1 方案验证 APK。
- 对“APK 签名方案 v2 分块”中的每个
signer执行以下操作：- 从
signatures中选择安全系数最高的受支持signature algorithm ID。安全系数排序取决于各个实现/平台版本。 - 使用
public key并对照signed data验证signatures中对应的signature。（现在可以安全地解析signed data了。） - 验证
digests和signatures中的签名算法 ID 列表（有序列表）是否相同。（这是为了防止删除/添加签名。） - 使用签名算法所用的同一种摘要算法计算 APK 内容的摘要。
- 验证计算出的摘要是否与
digests中对应的digest相同。 - 验证
certificates中第一个certificate的 SubjectPublicKeyInfo 是否与public key相同。
- 从
- 如果找到了至少一个
signer，并且对于每个找到的signer，第 3 步都取得了成功，APK 验证将会成功。
注意：如果第 3 步或第 4 步失败了，则不得使用 v1 方案验证 APK。
JAR 已签名的 APK 的验证（v1 方案）
JAR 已签名的 APK 是一种标准的已签名 JAR，其中包含的条目必须与 META-INF/MANIFEST.MF 中列出的条目完全相同，并且所有条目都必须已由同一组签名者签名。其完整性按照以下方式进行验证：
- 每个签名者均由一个包含 META-INF/<signer>.SF 和 META-INF/<signer>.(RSA|DSA|EC) 的 JAR 条目来表示。
- <signer>.(RSA|DSA|EC) 是具有 SignedData 结构的 PKCS #7 CMS ContentInfo，其签名通过 <signer>.SF 文件进行验证。
- <signer>.SF 文件包含 META-INF/MANIFEST.MF 的全文件摘要和 META-INF/MANIFEST.MF 各个部分的摘要。需要验证 MANIFEST.MF 的全文件摘要。如果该验证失败，则改为验证 MANIFEST.MF 各个部分的摘要。
- 对于每个受完整性保护的 JAR 条目，META-INF/MANIFEST.MF 都包含一个具有相应名称的部分，其中包含相应条目未压缩内容的摘要。所有这些摘要都需要验证。
- 如果 APK 包含未在 MANIFEST.MF 中列出且不属于 JAR 签名一部分的 JAR 条目，APK 验证将会失败。
因此，保护链是每个受完整性保护的 JAR 条目的 <signer>.(RSA|DSA|EC) -> <signer>.SF -> MANIFEST.MF -> 内容。
该文章参考自Google官网 https://source.android.google.cn/security/apksigning/