apk解壓後META-INF 文件夾下有三個文件：MANIFEST.MF、CERT.SF、CERT.RSA。
該文件中保存的內容其實就是逐壹遍歷 APK 中的所有條目
這裏會把之前生成的 CERT.SF 文件，用私鑰計算出簽名, 然後將簽名以及包含公鑰信息的數字證書壹同寫入 CERT.RSA 中保存。這裏要註意的是，Android APK 中的 CERT.RSA 證書是自簽名的，並不需要這個證書是第三方權威機構發布或者認證的，用戶可以在本地機器自行生成這個自簽名證書。Android 目前不對應用證書進行 CA 認證。
RSA 文件加密了，所以我們需要用 openssl 命令才能查看其內容
簽名驗證是發生在 APK 的安裝過程中，壹***分為三步：
為了解決V1的缺點，在 Android 7.0 Nougat 中引入了全新的 APK Signature Scheme v2。
APK 簽名方案 v2 是壹種全文件簽名方案，該方案能夠發現對 APK 的受保護部分進行的所有更改，從而有助於加快驗證速度並增強完整性保證。
由於在 v1 僅針對單個 ZIP 條目進行驗證，因此，在 APK 簽署後可進行許多修改 — 可以移動甚至重新壓縮文件。事實上，編譯過程中要用到的 ZIPalign 工具就是這麽做的，它用於根據正確的字節限制調整 ZIP 條目，以改進運行時性能。而且我們也可以利用這個東西，在打包之後修改 META-INF 目錄下面的內容，或者修改 ZIP 的註釋來實現多渠道的打包，在 v1 簽名中都可以校驗通過。
v2 簽名將驗證歸檔中的所有字節，而不是單個 ZIP 條目，因此，在簽署後無法再運行 ZIPalign（必須在簽名之前執行）。正因如此，現在，在編譯過程中，Google 將壓縮、調整和簽署合並成壹步完成。
簡單來說，v2 簽名模式在原先 APK 塊中增加了壹個新的塊（簽名塊），新的塊存儲了簽名，摘要，簽名算法，證書鏈，額外屬性等信息，這個塊有特定的格式，具體格式分析見後文，先看下現在 APK 成什麽樣子了。
為了保護 APK 內容，整個 APK（ZIP 文件格式）被分為以下 4 個區塊：
其中，應用簽名方案的簽名信息會被保存在 區塊 2（APK Signing Block）中，而區塊 1（Contents of ZIP entries）、區塊 3（ZIP Central Directory）、區塊 4（ZIP End of Central Directory）是受保護的，在簽名後任何對區塊 1、3、4 的修改都逃不過新的應用簽名方案的檢查。
其中 v2 簽名機制是在 Android 7.0 以及以上版本才支持。因此對於 Android 7.0 以及以上版本，在安裝過程中，如果發現有 v2 簽名塊，則必須走 v2 簽名機制，不能繞過。否則降級走 v1 簽名機制。
v1 和 v2 簽名機制是可以同時存在的，其中對於 v1 和 v2 版本同時存在的時候，v1 版本的 META_INF 的 .SF 文件屬性當中有壹個 X-Android-APK-Signed 屬性，因此如果想繞過 v2 走 v1 校驗是不行的。
之前的渠道包生成方案是通過在 META-INF 目錄下添加空文件，用空文件的名稱來作為渠道的唯壹標識。但在新的應用簽名方案下 META-INF 已經被列入了保護區了，向 META-INF 添加空文件的方案會對區塊 1、3、4 都會有影響。
可以參考： 美團解決方案 。
Android 9.0 中引入了新的簽名方式，它的格式大體和 v2 類似，在 v2 插入的簽名塊（Apk Signature Block v2）中，又添加了壹個新快（Attr塊）。
在這個新塊中，會記錄我們之前的簽名信息以及新的簽名信息，以密鑰轉輪的方案，來做簽名的替換和升級。這意味著，只要舊簽名證書在手，我們就可以通過它在新的 APK 文件中，更改簽名。
v3 簽名新增的新塊（attr）存儲了所有的簽名信息，由更小的 Level 塊，以鏈表的形式存儲。
其中每個節點都包含用於為之前版本的應用簽名的簽名證書，最舊的簽名證書對應根節點，系統會讓每個節點中的證書為列表中下壹個證書簽名，從而為每個新密鑰提供證據來證明它應該像舊密鑰壹樣可信。
這個過程有點類似 CA 證書的證明過程，已安裝的 App 的舊簽名，確保覆蓋安裝的 APK 的新簽名正確，將信任傳遞下去。
需要註意的是，對於覆蓋安裝的情況，簽名校驗只支持升級，而不支持降級。也就是說設備上安裝了壹個使用 v1 簽名的 APK，可以使用 v2 簽名的 APK 進行覆蓋安裝，反之則不允許。