基礎概念
簽名：在 APK 中寫入壹個「指紋」。指紋寫入以後，APK 中有任何修改，都會導致這個指紋無效，Android 系統在安裝 APK 進行簽名校驗時就會不通過，從而保證了安全性。
摘要算法： 使用壹段簡單的看上去隨機的不可逆向的固定長度的字符串來表示壹個文件的唯壹性。 常見的摘要算法如MD5(128個比特位)、SHA-1算法(160/192/256個比特位)。
公鑰密碼體制：也稱非對稱算法，特點是 公鑰是公開的 ，私鑰是保密的。常見的如：RSA。
展開討論壹下RSA：
Android中的簽名方案
V1 ：基於jarsigner(JDK自帶工具，使用keystore文件進行簽名) 或 apksigner(Android專門提供的，使用pk8、x509.pem進行簽名)。keystore和pk8/x509.pem可以相互轉換。
簽名原理：首先keystore文件包含壹個MD5和壹個SHA1摘要。 這也是很多開放平臺需要我們上傳的摘要數據 。
簽名APK後會在META-INF文件夾下生產CERT.RSA、CERT.SF、MANIFEST.MF三個文件。
在apk中，/META-INF文件夾中保存著apk的簽名信息，壹般至少包含三個文件，[CERT].RSA，[CERT].SF和MANIFEIST.MF文件。這三個文件就是對apk的簽名信息。
MANIFEST.MF中包含對apk中除了/META-INF文件夾外所有文件的簽名值，簽名方法是先SHA1()(或其他hash方法)在base64()。存儲形式是：Name加[SHA1]-Digest。
[CERT].SF是對MANIFEST.MF文件整體簽名以及其中各個條目的簽名。壹般地，如果是使用工具簽名，還多包括壹項。就是對MANIFEST.MF頭部信息的簽名，關於這壹點前面源碼分析中已經提到。
[CERT].RSA包含用私鑰對[CERT].SF的簽名以及包含公鑰信息的數字證書。
?是否存在簽名偽造可能：
修改(含增刪改)了apk中的文件，則：校驗時計算出的文件的摘要值與MANIFEST.MF文件中的條目不匹配，失敗。
修改apk中的文件+MANIFEST.MF,則：MANIFEST.MF修改過的條目的摘要與[CERT].SF對應的條目不匹配，失敗。
修改apk中的文件+MANIFEST.MF+[CERT].SF，則：計算出的[CERT].SF簽名與[CERT].RSA中記錄的簽名值不匹配，失敗。
修改apk中的文件+MANIFEST.MF+[CERT].SF+[CERT].RSA，則：由於證書不可偽造，[CERT].RSA無法偽造。
V2 ：7.0新增的
簽名後的包會被分為四部分
1. Contents of ZIP entries（from offset 0 until the start of APK Signing Block）
2. APK Signing Block
3. ZIP Central Directory
4. ZIP End of Central Directory
新應用簽名方案的簽名信息會被保存在區塊2（APK Signing Block） 中， 而區塊1（ Contents of ZIP entries ）、區塊3（ ZIP Central Directory ）、區塊4（ ZIP End of Central Directory ）是受保護的， 在簽名後任何對區塊1、3、4的修改都逃不過新的應用簽名方案的檢查 。
V3 ：9.0新增的
格式大體和 v2 類似，在 v2 插入的簽名塊（Apk Signature Block v2）中，又添加了壹個新快（Attr塊） 。
在這個新塊中，會記錄我們之前的簽名信息以及新的簽名信息，以 密鑰轉輪的方案，來做簽名的替換和升級。這意味著，只要舊簽名證書在手，我們就可以通過它在新的 APK 文件中，更改簽名 。
v3 簽名新增的新塊（attr）存儲了所有的簽名信息，由更小的 Level 塊，以 鏈表 的形式存儲。
其中每個節點都包含用於為之前版本的應用簽名的簽名證書，最舊的簽名證書對應根節點，系統會讓每個節點中的證書為列表中下壹個證書簽名，從而為每個新密鑰提供證據來證明它應該像舊密鑰壹樣可信。
這個過程有點類似 CA 證書的證明過程，已安裝的 App 的舊簽名，確保覆蓋安裝的 APK 的新簽名正確，將信任傳遞下去。
註意： 簽名方式只支持升級不支持降級，如安裝了V2的包，不能覆蓋替換為V1的包。
參考
Android App簽名(證書)校驗過程源碼分析
新壹代開源Android渠道包生成工具Walle
Android 簽名機制 v1、v2、v3