Android為了保證系統及應用的安全性，在安裝APK的時候需要校驗包的完整性，同時，對於覆蓋安裝的場景還要校驗新舊是否匹配，這兩者都是通過Android簽名機制來進行保證的，本文就簡單看下Android的簽名與校驗原理，分壹下幾個部分分析下：
簽名是摘要與非對稱密鑰加密相相結合的產物，摘要就像內容的壹個指紋信息，壹旦內容被篡改，摘要就會改變，簽名是摘要的加密結果，摘要改變，簽名也會失效。Android APK簽名也是這個道理，如果APK簽名跟內容對應不起來，Android系統就認為APK內容被篡改了，從而拒絕安裝，以保證系統的安全性。目前Android有三種簽名V1、V2（N）、V3（P），本文只看前兩種V1跟V2，對於V3的輪密先不考慮。先看下只有V1簽名後APK的樣式：
再看下只有V2簽名的APK包樣式：
同時具有V1 V2簽名：
可以看到，如果只有V2簽名，那麽APK包內容幾乎是沒有改動的，META_INF中不會有新增文件，按Google官方文檔：在使用v2簽名方案進行簽名時，會在APK文件中插入壹個APK簽名分塊，該分塊位於zip中央目錄部分之前並緊鄰該部分。在APK簽名分塊內， 簽名和簽名者身份信息會存儲在APK簽名方案v2分塊中，保證整個APK文件不可修改 ，如下圖：
而V1簽名是通過META-INF中的三個文件保證簽名及信息的完整性：
V1簽名是如何保證信息的完整性呢？V1簽名主要包含三部分內容，如果狹義上說簽名跟公鑰的話，僅僅在.rsa文件中，V1簽名的三個文件其實是壹套機制，不能單單拿壹個來說事，
如果對APK中的資源文件進行了替換，那麽該資源的摘要必定發生改變，如果沒有修改MANIFEST.MF中的信息，那麽在安裝時候V1校驗就會失敗，無法安裝，不過如果篡改文件的同時，也修改其MANIFEST.MF中的摘要值，那麽MANIFEST.MF校驗就可以繞過。
CERT.SF個人覺得有點像冗余，更像對文件完整性的二次保證，同繞過MANIFEST.MF壹樣，.SF校驗也很容易被繞過。
CERT.RSA與CERT.SF是相互對應的，兩者名字前綴必須壹致，不知道算不算壹個無聊的標準。看下CERT.RSA文件內容：
CERT.RSA文件裏面存儲了證書公鑰、過期日期、發行人、加密算法等信息，根據公鑰及加密算法，Android系統就能計算出CERT.SF的摘要信息，其嚴格的格式如下：
從CERT.RSA中，我們能獲的證書的指紋信息，在微信分享、第三方SDK申請的時候經常用到，其實就是公鑰+開發者信息的壹個簽名：
除了CERT.RSA文件，其余兩個簽名文件其實跟keystore沒什麽關系，主要是文件自身的摘要及二次摘要，用不同的keystore進行簽名，生成的MANIFEST.MF與CERT.SF都是壹樣的，不同的只有CERT.RSA簽名文件。也就是說前兩者主要保證各個文件的完整性，CERT.RSA從整體上保證APK的來源及完整性，不過META_INF中的文件不在校驗範圍中，這也是V1的壹個缺點。V2簽名又是如何保證信息的完整性呢？
前面說過V1簽名中文件的完整性很容易被繞過，可以理解 單個文件完整性校驗的意義並不是很大 ，安裝的時候反而耗時，不如采用更加簡單的便捷的校驗方式。V2簽名就不針對單個文件校驗了，而是 針對APK進行校驗 ，將APK分成1M的塊，對每個塊計算值摘要，之後針對所有摘要進行摘要，再利用摘要進行簽名。
也就是說，V2摘要簽名分兩級，第壹級是對APK文件的1、3 、4 部分進行摘要，第二級是對第壹級的摘要集合進行摘要，然後利用秘鑰進行簽名。安裝的時候，塊摘要可以並行處理，這樣可以提高校驗速度。
APK是先摘要，再簽名，先看下摘要的定義：Message Digest：摘要是對消息數據執行壹個單向Hash，從而生成壹個固定長度的Hash值，這個值就是消息摘要，至於常聽到的MD5、SHA1都是摘要算法的壹種。理論上說，摘要壹定會有碰撞，但只要保證有限長度內碰撞率很低就可以，這樣就能利用摘要來保證消息的完整性，只要消息被篡改，摘要壹定會發生改變。但是，如果消息跟摘要同時被修改，那就無從得知了。
而數字簽名是什麽呢（公鑰數字簽名），利用非對稱加密技術，通過私鑰對摘要進行加密，產生壹個字符串，這個字符串+公鑰證書就可以看做消息的數字簽名，如RSA就是常用的非對稱加密算法。在沒有私鑰的前提下，非對稱加密算法能確保別人無法偽造簽名，因此數字簽名也是對發送者信息真實性的壹個有效證明。不過由於Android的keystore證書是自簽名的，沒有第三方權威機構認證，用戶可以自行生成keystore，Android簽名方案無法保證APK不被二次簽名。
知道了摘要跟簽名的概念後，再來看看Android的簽名文件怎麽來的？如何影響原來APK包？通過sdk中的apksign來對壹個APK進行簽名的命令如下：
其主要實現在 android/platform/tools/apksig 文件夾中，主體是ApkSigner.java的sign函數，函數比較長，分幾步分析
先來看這壹步，ApkUtils.findZipSections，這個函數主要是解析APK文件，獲得ZIP格式的壹些簡單信息，並返回壹個ZipSections，
ZipSections包含了ZIP文件格式的壹些信息，比如中央目錄信息、中央目錄結尾信息等，對比到zip文件格式如下：
獲取到 ZipSections之後，就可以進壹步解析APK這個ZIP包，繼續走後面的簽名流程，
可以看到先進行了壹個V2簽名的檢驗，這裏是用來簽名，為什麽先檢驗了壹次？第壹次簽名的時候會直接走這個異常邏輯分支，重復簽名的時候才能獲到取之前的V2簽名，懷疑這裏獲取V2簽名的目的應該是為了排除V2簽名，並獲取V2簽名以外的數據塊，因為簽名本身不能被算入到簽名中，之後會解析中央目錄區，構建壹個DefaultApkSignerEngine用於簽名
先解析中央目錄區，獲取AndroidManifest文件，獲取minSdkVersion(影響簽名算法)，並構建DefaultApkSignerEngine，默認情況下V1 V2簽名都是打開的。
第五步與第六步的主要工作是：apk的預處理，包括目錄的壹些排序之類的工作，應該是為了更高效處理簽名，預處理結束後，就開始簽名流程，首先做的是V1簽名（默認存在，除非主動關閉）：
步驟7、8、9都可以看做是V1簽名的處理邏輯，主要在V1SchemeSigner中處理，其中包括創建META-INFO文件夾下的壹些簽名文件，更新中央目錄、更新中央目錄結尾等，流程不復雜，不在贅述，簡單流程就是：
這裏特殊提壹下重復簽名的問題： 對壹個已經V1簽名的APK再次V1簽名不會有任何問題 ，原理就是：再次簽名的時候，會排除之前的簽名文件。
可以看到目錄、META-INF文件夾下的文件、sf、rsa等結尾的文件都不會被V1簽名進行處理，所以這裏不用擔心多次簽名的問題。接下來就是處理V2簽名。
V2SchemeSigner處理V2簽名，邏輯比較清晰，直接對V1簽名過的APK進行分塊摘要，再集合簽名，V2簽名不會改變之前V1簽名後的任何信息，簽名後，在中央目錄前添加V2簽名塊，並更新中央目錄結尾信息，因為V2簽名後，中央目錄的偏移會再次改變：
簽名校驗的過程可以看做簽名的逆向，只不過覆蓋安裝可能還要校驗公鑰及證書信息壹致，否則覆蓋安裝會失敗。簽名校驗的入口在PackageManagerService的install裏，安裝官方文檔，7.0以上的手機優先檢測V2簽名，如果V2簽名不存在，再校驗V1簽名，對於7.0以下的手機，不存在V2簽名校驗機制，只會校驗V1，所以，如果妳的App的miniSdkVersion<24(N)，那麽妳的簽名方式必須內含V1簽名：
校驗流程就是簽名的逆向，了解簽名流程即可，本文不求甚解，有興趣自己去分析，只是額外提下覆蓋安裝，覆蓋安裝除了檢驗APK自己的完整性以外，還要校驗證書是否壹致只有證書壹致（同壹個keystore簽名），才有可能覆蓋升級。覆蓋安裝同全新安裝相比較多了幾個校驗
這裏只關心證書部分：
Android V1及V2簽名簽名原理簡析
僅供參考，歡迎指正