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 文件；