V1是内部文件单个签 但是增加apk文件目录下面随意增加文件并不会有影响,它只关心meta-info文件 mf汇总清单的各个文件sha256

V2 整个APK文件,按文件进行hash 那么便不能随便在这里面增加文件了,增加了签名分块（不然签名信息存哪里）这里涉及一个文件概念  魔数!=名字=格式化名字=厂商命名的!=== oracle=.class=java-class

google 就是利用zip --EFS附加节点,除了附加节点之外的字节数据全部拿来计算hash,存入附加数据,该分块包含多个“ID-值”对，所采用的封装方式有助于更轻松地在 APK 中找到该分块。APK 的 v2 签名会存储为一个“ID-值”对，其中 ID 为 0x7109871a。

V3版本的签名 解决的问题是应用轮替证书问题,比如您之前申请的时效是5年 但是现在过期了,那么V3新证书就能解决,但是先决条件生成方式还得依赖老版本证书,签名数据部分中的 proof-of-rotation 属性包含一个单链表，其中每个节点都包含用于为之前版本的应用签名的签名证书

老版本as还支持选择

新版本的as 不支持选择 默认就是v2

APK打包流程
1.自己写代码 过程中 生成R资源清单表,由APPT完成,AIDL文件构成由AIDL工具完成

2.写完之后全部编译成.class文件

3.将所有.class文件打包成一个dex文件

4.拷贝dex,清单,res,等相关数据文件进行zip压缩,生成apk文件

5.对于apk文件进行工具签名

V1签名流程

总结:
1. 计算每个文件的 SHA-1 摘要，进行 BASE64 编码后写入摘要文件，即 MANIFEST.MF 文件；

2. 计算整个 MANIFEST.MF 文件的 SHA-1 摘要，进行 BASE64 编码后写入签名文件，即*.SF 文件；

3.计算 MANIFEST.MF 文件中每一块摘要的 SHA-1 摘要，进行 BASE64 编码后写入 签名文件，即*.SF 文件；

4.计算整个 *.SF 文件的数字签名（先摘要再私钥加密）；

6.将数字签名和 X.509 开发者数字证书（公钥）写入 *.RSA 文件；