apk簽名過程及多渠道

公司業務渠道較多共有70多個渠道，打包時間較長，所以抽時間研究一下美團的多渠道打包。本文介紹常見的多渠道打包方式：productFlavors方式，apktool,美團1.0，美團2.0,騰訊這些方式技術從舊到新，試圖說起多渠道打包的脈絡。

productFlavors

productFlavors不用切換項目分支就可以編譯調試不同項目版本的APK，并且可以快速打包所有項目版本的APK。例如是開發第三方Android OS的時候，由于要給不同的廠商做定制，并且適配不同的硬件平臺，所以發版本的時候，經常要切換項目分支，然后逐個編譯APK。關于更多productFlavor介紹參考：productFlavors詳細使用 
productFlavors多渠道打包具體詳情參見：Gradle實戰：Android多渠道打包方案匯總

早期的多渠道打包基本上是采用這種方式。首先，在AndroidManifest.xml中添加渠道信息占位符：

<meta-data android:name="InstallChannel" android:value="${InstallChannel}" />

然后，通過Gradle Plugin提供的productFlavors標簽，添加渠道信息：

productFlavors{
    "YingYongBao"{
        manifestPlaceholders = [InstallChannel : "YingYongBao"]
    }
    "360"{
        manifestPlaceholders = [InstallChannel : "360"]
    }
}

這樣，Gradle編譯生成多渠道包時，會用不同的渠道信息替換AndroidManifest.xml中的占位符。我們在代碼中，也就可以直接讀取AndroidManifest.xml中的渠道信息了。

但是，這種方式存在一些缺點：

每生成一個渠道包，都要重新執行一遍構建流程，效率太低，只適用于渠道較少的場景。
Gradle會為每個渠道包生成一個不同的BuildConfig.java類，記錄渠道信息，導致每個渠道包的DEX的CRC值都不同。一般情況下，這是沒有影響的。但是如果你使用了微信的Tinker熱補丁方案，那么就需要為不同的渠道包打不同的補丁，這完全是不可以接受的。（因為Tinker是通過對比基礎包APK和新包APK生成差分補丁，然后再把補丁和基礎包APK一起合成新包APK。這就要求用于生成差分補丁的基礎包DEX和用于合成新包的基礎包DEX是完全一致的，即：每一個基礎渠道包的DEX文件是完全一致的，不然就會合成失敗）

針對上述問題市面上出現了很多第三方，其中比較突出的是apktool,mcxiaoke的packer-ng-plugin，美圖的walle和騰訊的VasDolly

apk簽名過程及多渠道方案

現市面上存在的多渠道打包方式的原理大都是改apk文件，如此會造成簽名驗證問題。如此要掌握多渠道，需要先了解apk的簽名過程。apk的簽名先后有v1,v2,v3三種。

簽名相關的基礎知識

在了解apk的簽名方式之前，我們先要了解簽名相關的基礎知識

數據摘要

數據摘要算法是一種能產生特定輸出格式的算法，其原理是根據一定的運算規則對原始數據進行某種形式的信息提取，被提取出的信息就是原始數據的消息摘要，也稱為數據指紋。
一般情況下，數據摘要算法具有以下特點：

無論輸入數據有多大（長），計算出來的數據摘要的長度總是固定的。例如：MD5算法計算出的數據摘要有128Bit。
一般情況下（不考慮碰撞的情況下），只要原始數據不同，那么其對應的數據摘要就不會相同。
同時，只要原始數據有任何改動，那么其數據摘要也會完全不同。即：相同的原始數據必有相同的數據摘要，不同的原始數據，其數據摘要也必然不同。
不可逆性即只能正向提取原始數據的數據摘要，而無法從數據摘要中恢復出原始數據。
著名的摘要算法有RSA公司的MD5算法和SHA系列算法。

數字簽名和數字證書

數字簽名和數字證書是成對出現的，兩者不可分離（數字簽名主要用來校驗數據的完整性，數字證書主要用來確保公鑰的安全發放）。
要明白數字簽名的概念，必須要了解數據的加密、傳輸和校驗流程。一般情況下，要實現數據的可靠通信，需要解決以下兩個問題：

確定數據的來源是其真正的發送者。
確保數據在傳輸過程中，沒有被篡改，或者若被篡改了，可以及時發現。

而數字簽名，就是為了解決這兩個問題而誕生的。
首先，數據的發送者需要先申請一對公私鑰對，并將公鑰交給數據接收者。
然后，若數據發送者需要發送數據給接收者，則首先要根據原始數據，生成一份數字簽名，然后把原始數據和數字簽名一起發送給接收者。
數字簽名由以下兩步計算得來：

計算發送數據的數據摘要
用私鑰對提取的數據摘要進行加密
這樣，數據接收者拿到的消息就包含了兩塊內容：
原始數據內容
附加的數字簽名

接下來，接收者就會通過以下幾步，校驗數據的真實性：

用相同的摘要算法計算出原始數據的數據摘要。
用預先得到的公鑰解密數字簽名。
對比簽名得到的數據是否一致，如果一致，則說明數據沒有被篡改，否則數據就是臟數據了

因為私鑰只有發送者才有，所以其他人無法偽造數字簽名。這樣通過數字簽名就確保了數據的可靠傳輸。
綜上所述，數字簽名就是只有發送者才能產生的別人無法偽造的一段數字串，這段數字串同時也是對發送者發送數據真實性的一個有效證明。

想法雖好，但是上面的整個流程，有一個前提，就是數據接收者能夠正確拿到發送者的公鑰。如果接收者拿到的公鑰被篡改了，那么壞人就會被當成好人，而真正的數據發送者發送的數據則會被視作臟數據。那怎么才能保證公鑰的安全性那？這就要靠數字證書來解決了。

數字證書是由有公信力的證書中心（CA）頒發給申請者的證書，主要包含了：證書的發布機構、證書的有效期、申請者的公鑰、申請者信息、數字簽名使用的算法，以及證書內容的數字簽名。

可見，數字證書也用到了數字簽名技術。只不過簽名的內容是數據發送方的公鑰，以及一些其它證書信息。
這樣數據發送者發送的消息就包含了三部分內容：

原始數據內容
附加的數字簽名
申請的數字證書。

接收者拿到數據后，首先會根據CA的公鑰，解碼出發送者的公鑰。然后就與上面的校驗流程完全相同了。

所以，數字證書主要解決了公鑰的安全發放問題。
因此，包含數字證書的整個簽名和校驗流程如下圖所示：

[圖片上傳失敗...(image-ed00c-1560483246318)]

V1簽名和多渠道打包方案

在android 7.0（N）之前是這種。

V1簽名機制

默認情況下，APK使用的就是V1簽名。解壓APK后，在META-INF目錄下，可以看到三個文件：MANIFEST.MF、CERT.SF、CERT.RSA。它們都是V1簽名的產物。

其中，MANIFEST.MF文件內容如下所示：

[圖片上傳失敗...(image-da5e67-1560483246319)]

它記錄了APK中所有原始文件的數據摘要的Base64編碼,而數據摘要算法就是SHA1。

CERT.SF文件內容如下所示：

[圖片上傳失敗...(image-7ba85f-1560483246319)]

SHA1-Digest-Manifest-Main-Attributes主屬性記錄了MANIFEST.MF文件所有主屬性的數據摘要的Base64編碼。SHA1-Digest-Manifest則記錄了整個MANIFEST.MF文件的數據摘要的Base64編碼。其余的普通屬性則和MANIFEST.MF中的屬性一一對應，分別記錄了對應數據塊的數據摘要的Base64編碼。例如：CERT.SF文件中skin_drawable_btm_line.xml對應的SHA1-Digest，就是下面內容的數據摘要的Base64編碼。

Name: res/drawable/skin_drawable_btm_line.xml
SHA1-Digest: JqJbk6/AsWZMcGVehCXb33Cdtrk=
\r\n

這里要注意的是：最后一行的換行符是必不可少，需要參與計算的。

CERT.RSA文件包含了對CERT.SF文件的數字簽名和開發者的數字證書。RSA就是計算數字簽名使用的非對稱加密算法。

V1簽名的詳細流程可參考SignApk.java，整個簽名流程如下圖所示：

[圖片上傳失敗...(image-4ab8d7-1560483246319)]

整個簽名機制的最終產物就是MANIFEST.MF、CERT.SF、CERT.RSA三個文件。

v1校驗流程

在安裝APK時，Android系統會校驗簽名，檢查APK是否被篡改。代碼流程是：PackageManagerService.java -> PackageParser.java，PackageParser類負責V1簽名的具體校驗。整個校驗流程如下圖所示：

[圖片上傳失敗...(image-ea7c2f-1560483246319)]

若中間任何一步校驗失敗，APK就不能安裝。

OK，了解了V1的簽名和校驗流程。我們來看下，V1簽名是怎么保證APK文件不被篡改的？
首先，如果破壞者修改了APK中的任何文件，那么被篡改文件的數據摘要的Base64編碼就和MANIFEST.MF文件的記錄值不一致，導致校驗失敗。
其次，如果破壞者同時修改了對應文件在MANIFEST.MF文件中的Base64值，那么MANIFEST.MF中對應數據塊的Base64值就和CERT.SF文件中的記錄值不一致，導致校驗失敗。
最后，如果破壞者更進一步，同時修改了對應文件在CERT.SF文件中的Base64值，那么CERT.SF的數字簽名就和CERT.RSA記錄的簽名不一致，也會校驗失敗。
那有沒有可能繼續偽造CERT.SF的數字簽名那？理論上不可能，因為破壞者沒有開發者的私鑰。那破壞者是不是可以用自己的私鑰和數字證書重新簽名那，這倒是完全可以！

綜上所述，任何對在MANIFEST.MF中有對應數字摘要的文件修改都會導致簽名失敗，除非重新簽名。任何對在MANIFEST.MF文件的修改也會導致簽名失敗。
如此針對v1我們可以從以下3個方面下手避免添加渠道信息后導致簽名失敗。

添加不被簽名包含的文件寫入多渠道信息。我們發現在META-INF中新建的文件是不會改變簽名結構的，如此可知META-INF中新建文件寫入渠道信息，其中美團的第一代打包工具是這樣做的。
我們可以通過逆向手段，添加渠道信息。即解壓apk，添加渠道信息，重新簽名。市面上apktool是這樣弄的
修改apk文件。我們發現v1的apk分三部分:內容快，中央目錄塊和中央結束塊(EOCD)，其中EOCD是生成apk時自動加進去的，不受簽名保護，如此可在其中添加渠道信息。市面上mcxiaoke的packer-ng-plugin和騰訊的VasDolly是采用這種原理

apktool

ApkTool是一個逆向分析工具，可以把APK解開，添加代碼后，重新打包成APK，當然這些都是通過腳本實現的。因此，基于ApkTool的多渠道打包方案分為以下幾步：

復制一份新的APK
通過ApkTool工具，解壓APK（apktool d origin.apk）
刪除已有簽名信息
添加渠道信息（可以在APK的任何文件添加渠道信息）
通過ApkTool工具，重新打包生成新APK（apktool b newApkDir）
重新簽名
經過測試，這種方案完全是可行的。

優點：
不需要重新構建新渠道包，僅需要復制修改就可以了。并且因為是重新簽名，所以同時支持V1和V2簽名。

缺點：
ApkTool工具不穩定，曾經遇到過升級Gradle Plugin版本后，低版本ApkTool解壓APK失敗的情況。
生成新渠道包時，需要重新解包、打包和簽名，而這幾步操作又是相對比較耗時的。經過測試：生成企鵝電競10個渠道包需要16分鐘左右，雖然比Gradle Plugin方案減少很多耗時。但是若需要同時生成上百個渠道包，則需要幾個小時，顯然不適合渠道非常多的業務場景。

修改apk

apktool存在諸多缺點，針對v1我采用的還是添加文件和修改apk來添加渠道信息的。修改文件原理教簡單，下面我們重點介紹修改apk

apk文件結構

修改apk得先知道其結構。APK文件本質上是一個ZIP壓縮包，而ZIP格式是固定的，主要由三部分構成，如下圖所示：

[圖片上傳失敗...(image-74cf23-1560483246319)]

第一部分是內容塊，所有的壓縮文件都在這部分。每個壓縮文件都有一個local file header，主要記錄了文件名、壓縮算法、壓縮前后的文件大小、修改時間、CRC32值等。

第二部分稱為中央目錄，包含了多個central directory file header（和第一部分的local file header一一對應），每個中央目錄文件頭主要記錄了壓縮算法、注釋信息、對應local file header的偏移量等，方便快速定位數據。

最后一部分是EOCD，主要記錄了中央目錄大小、偏移量和ZIP注釋信息等，其詳細結構如下圖所示：

[圖片上傳失敗...(image-58a6c5-1560483246319)]

根據之前的V1簽名和校驗機制可知，V1簽名只會檢驗第一部分的所有壓縮文件，而不理會后兩部分內容。因此，只要把渠道信息寫入到后兩塊內容就可以通過V1校驗，而EOCD的注釋字段無疑是最好的選擇。

向apk文件結構中寫入渠道信息

既然找到了突破口，那么基于V1簽名的多渠道打包方案就應運而生：在APK文件的注釋字段，添加渠道信息。

整個方案包括以下幾步：

復制APK
找到EOCD數據塊
修改注釋長度
添加渠道信息
添加渠道信息長度
添加魔數
添加渠道信息后的EOCD數據塊如下所示：

[圖片上傳失敗...(image-91f24-1560483246319)]

這里添加魔數的好處是方便從后向前讀取數據，定位渠道信息。
因此，讀取渠道信息包括以下幾步：

定位到魔數
向前讀兩個字節，確定渠道信息的長度LEN
繼續向前讀LEN字節，就是渠道信息了。

通過16進制編輯器，可以查看到添加渠道信息后的APK（小端模式），如下所示：

[圖片上傳失敗...(image-d8a279-1560483246319)]

6C 74 6C 6F 76 75 7A 68是魔數，04 00表示渠道信息長度為4，6C 65 6F 6E就是渠道信息leon了。0E 00就是APK注釋長度了，正好是15。

雖說整個方案很清晰，但是在找到EOCD數據塊這步遇到一個問題。如果APK本身沒有注釋，那最后22字節就是EOCD。但是若APK本身已經包含了注釋字段，那怎么確定EOCD的起始位置那？這里借鑒了系統V2簽名確定EOCD位置的方案。整個計算流程如下圖所示：

[圖片上傳失敗...(image-b692b2-1560483246319)]

整個方案介紹完了，該方案的最大優點就是：不需要解壓縮APK，不需要重新簽名，只需要復制APK，在注釋字段添加渠道信息。每個渠道包僅需幾秒的耗時，非常適合渠道較多的APK。

但是好景不長，Android7.0之后新增了V2簽名，該簽名會校驗整個APK的數據摘要，導致上述渠道打包方案失效。所以如果想繼續使用上述方案，需要關閉Gradle Plugin中的V2簽名選項，禁用V2簽名。

V2簽名和多渠道打包方案

為什么需要V2簽名

從前面的V1簽名介紹，可以知道V1存在兩個弊端：

- MANIFEST.MF中的數據摘要是基于原始未壓縮文件計算的。因此在校驗時，需要先解壓出原始文件，才能進行校驗。而解壓操作無疑是耗時的。
- V1簽名僅僅校驗APK第一部分中的文件，缺少對APK的完整性校驗。因此，在簽名后，我們還可以修改APK文件，例如：通過zipalign進行字節對齊后，仍然可以正常安裝。

正是基于這兩點，Google提出了V2簽名，解決了上述兩個問題：

V2簽名是對APK本身進行數據摘要計算，不存在解壓APK的操作，減少了校驗時間。
V2簽名是針對整個APK進行校驗（不包含簽名塊本身），因此對APK的任何修改（包括添加注釋、zipalign字節對齊）都無法通過V2簽名的校驗。
關于第一點的耗時問題，這里有一份實驗室數據（Nexus 6P、Android 7.1.1）可供參考。

APK安裝耗時對比	取5次平均耗時（秒）
V1簽名APK	11.64
V2簽名APK	4.42

可見，V2簽名對APK的安裝速度還是提升不少的。

V2簽名機制

不同于V1，V2簽名會生成一個簽名塊，插入到APK中。因此，V2簽名后的APK結構如下圖所示：

[圖片上傳失敗...(image-ba6827-1560483246319)]

APK簽名塊位于中央目錄之前，文件數據之后。V2簽名同時修改了EOCD中的中央目錄的偏移量，使簽名后的APK還符合ZIP結構。

APK簽名塊的具體結構如下圖所示：

[圖片上傳失敗...(image-54d006-1560483246319)]

首先是8字節的簽名塊大小，此大小不包含該字段本身的8字節；
其次就是ID-Value序列，就是一個4字節的ID和對應的數據；
然后又是一個8字節的簽名塊大小，與開始的8字節是相等的；最后是16字節的簽名塊魔數。
其中，ID為0x7109871a對應的Value就是V2簽名塊數據。

V2簽名塊的生成可參考ApkSignerV2，整體結構和流程如下圖所示：

[圖片上傳失敗...(image-f003cc-1560483246319)]

首先，根據多個簽名算法，計算出整個APK的數據摘要，組成左上角的APK數據摘要集；
接著，把最左側一列的數據摘要、數字證書和額外屬性組裝起來，形成類似于V1簽名的“MF”文件（第二列第一行）；
其次，再用相同的私鑰，不同的簽名算法，計算出“MF”文件的數字簽名，形成類似于V1簽名的“SF”文件（第二列第二行）；
然后，把第二列的類似MF文件、類似SF文件和開發者公鑰一起組裝成通過單個keystore簽名后的v2簽名塊（第三列第一行）。
最后，把多個keystore簽名后的簽名塊組裝起來，就是完整的V2簽名塊了（Android中允許使用多個keystore對apk進行簽名）。

上述流程比較繁瑣。簡而言之，單個keystore簽名塊主要由三部分組成，分別是上圖中第二列的三個數據塊：類似MF文件、類似SF文件和開發者公鑰，其結構如下圖所示：

[圖片上傳失敗...(image-e251d8-1560483246319)]

除此之外，Google也優化了計算數據摘要的算法，使得可以并行計算，如下圖所示：

[圖片上傳失敗...(image-6be7d4-1560483246319)]

數據摘要的計算包括以下幾步：

首先，將上述APK中文件內容塊、中央目錄、EOCD按照1MB大小分割成一些小塊。
然后，計算每個小塊的數據摘要，基礎數據是0xa5 + 塊字節長度 + 塊內容。
最后，計算整體的數據摘要，基礎數據是0x5a + 數據塊的數量 + 每個數據塊的摘要內容。

這樣，每個數據塊的數據摘要就可以并行計算，加快了V2簽名和校驗的速度。

V2校驗流程

Android Gradle Plugin2.2之上默認會同時開啟V1和V2簽名，同時包含V1和V2簽名的CERT.SF文件會有一個特殊的主屬性，如下圖所示：

[圖片上傳失敗...(image-ecbad4-1560483246319)]

該屬性會強制APK走V2校驗流程（7.0之上），以充分利用V2簽名的優勢（速度快和更完善的校驗機制）。
因此，同時包含V1和V2簽名的APK的校驗流程如下所示：

[圖片上傳失敗...(image-11afa7-1560483246319)]

簡而言之：優先校驗V2，沒有或者不認識V2，則校驗V1。

這里引申出另外一個問題：APK簽名時，只有V2簽名，沒有V1簽名行不行？
經過嘗試，這種情況是可以編譯通過的，并且在Android 7.0之上也可以正確安裝和運行。但是7.0之下，因為不認識V2，又沒有V1簽名，所以會報沒有簽名的錯誤。

OK，明確了Android平臺對V1和V2簽名的校驗選擇之后，我們來看下V2簽名的具體校驗流程（PackageManagerService.java -> PackageParser.java-> ApkSignatureSchemeV2Verifier.java），如下圖所示：

[圖片上傳失敗...(image-632fdb-1560483246319)]

其中，最強簽名算法是根據該算法使用的數據摘要算法來對比產生的，比如：SHA512 > SHA256。

校驗成功的定義是至少找到一個keystore對應的簽名塊，并且所有簽名塊都按照上述流程校驗成功。

下面我們來看下V2簽名是怎么保證APK不被篡改的？

首先，如果破壞者修改了APK文件的任何部分（簽名塊本身除外），那么APK的數據摘要就和“MF”數據塊中記錄的數據摘要不一致，導致校驗失敗。

其次，如果破壞者同時修改了“MF”數據塊中的數據摘要，那么“MF”數據塊的數字簽名就和“SF”數據塊中記錄的數字簽名不一致，導致校驗失敗。

然后，如果破壞者使用自己的私鑰去加密生成“SF”數據塊，那么使用開發者的公鑰去解密“SF”數據塊中的數字簽名就會失敗；

最后，更進一步，若破壞者甚至替換了開發者公鑰，那么使用數字證書中的公鑰校驗簽名塊中的公鑰就會失敗，這也正是數字證書的作用。

綜上所述，任何對APK的修改，在安裝時都會失敗，除非對APK重新簽名。但是相同包名，不同簽名的APK也是不能同時安裝的。

其實也很簡單，原來Android系統在校驗APK的數據摘要時，首先會把EOCD的中央目錄偏移量替換成簽名塊的偏移量，然后再計算數據摘要。而簽名塊的偏移量不就是v2簽名之前的中央目錄偏移量嘛！！！，因此，這樣計算出的數據摘要就和“MF”數據塊中的數據摘要完全一致了。具體代碼邏輯，可參考ApkSignatureSchemeV2Verifier.java的416 ~ 420行

基于V2簽名的多渠道打包方案

在上節V2簽名的校驗流程中，有一個很重要的細節：Android系統只會關注ID為0x7109871a的V2簽名塊，并且忽略其他的ID-Value，同時V2簽名只會保護APK本身，不包含簽名塊。

因此，基于V2簽名的多渠道打包方案就應運而生：在APK簽名塊中添加一個ID-Value，存儲渠道信息。

整個方案包括以下幾步：

找到APK的EOCD塊
找到APK簽名塊
獲取已有的ID-Value Pair
添加包含渠道信息的ID-Value
基于所有的ID-Value生成新的簽名塊
修改EOCD的中央目錄的偏移量（上面已介紹過：修改EOCD的中央目錄偏移量，不會導致數據摘要校驗失敗）
用新的簽名塊替代舊的簽名塊，生成帶有渠道信息的APK

實際上，除了渠道信息，我們可以在APK簽名塊中添加任何輔助信息。

通過16進制編輯器，可以查看到添加渠道信息后的APK（小端模式），如下所示：

[圖片上傳失敗...(image-20e35e-1560483246319)]

V3簽名和多渠道打包方案

在android 9.0(N)引入的

為什么要有v3

主要是為了換簽名

生成簽名的時，可以指定一個有效時間，這個時間默認為 25 年，并且 Google Play 也有硬性規定，上架的 App 簽名有效期必須在 2033-10-22 日期之后。所以只要不是手欠修改了這個有效期，在當下這個時刻，是不會有問題，畢竟到現在還沒有一款 App 存在 25 年。當然還有可能是公司被收購需要改簽名
有些問題不在眼前，卻是真實存在的。對于一款上架的 App，最重要的就是用戶，而當簽名失效之后，我們只能被迫換簽名，此時因為簽名校驗無法通過，就會導致舊用戶無法覆蓋安裝。這些歷史用戶唯一的選擇，就是卸載后重新安裝。
好在這不僅僅是你我的問題，天塌下來有個子高的頂著，所以別擔心，Google 已經著手在解決這個問題了。

v3簽名塊結構

v3版本簽名塊也分成同樣的三部分，與v2不同的是在SignerData部分，v3新增了attr塊，其中是由更小的level塊組成。每個level塊中可以存儲一個證書信息。前一個level塊證書驗證下一個level證書，以此類推。最后一個level塊的證書，要符合SignerData中本身的證書，即用來簽名整個APK的公鑰所屬于的證書。兩個版本的簽名塊結構如下：

[圖片上傳失敗...(image-95af1f-1560483246319)]

v3驗證簽名流程

因為簽名的驗證就是發生在一個apk包的安裝過程中，所以為了更清楚驗證簽名的時機，有必要了解整個安裝的分類與大致流程。Android安裝應用主要有如下四種方式：

系統應用安裝：開機時完成，沒有安裝界面
網絡下載的應用安裝：通過市場應用完成，沒有安裝界面
ADB工具安裝：沒有安裝界面
第三方應用安裝：通過packageinstall.apk應用安裝，有安裝界面

但是其實無論通過哪種方式安裝都要通過PackageManagerService來完成安裝的主要工作，最終在PMS中會去驗證簽名信息，流程如下

[圖片上傳失敗...(image-fd0b3a-1560483246319)]

安裝過程中如果發現有v3簽名塊，則必須使用v3簽名的驗證機制，不能繞過。否則才使用v2簽名的驗證機制，以此類推。

驗證完整性

數據完整性校驗v3與v2版本相同，原理如下：

[圖片上傳失敗...(image-29bcb8-1560483246319)]

簽名塊包括對apk第一部分，第二部分，第三部分的二進制內容做加密保護，摘要算法以及簽名算法。簽名塊本身不做加密，這里需要特殊注意的是由于第三部分包含了對第二部分的引用偏移，因此如果簽名塊做了改變，比如在簽名過程中增加一種簽名算法，或者增加簽名者等信息就會導致這個引用偏移發生改變，因此在算摘要的時候需要剔除這個因素要以第三部分對簽名塊的偏移來做計算。

驗證證書

v2版本簽名驗證證書步驟：

利用PublicKey解密Signature，得到SignerData的hash明文
計算SignerData的hash值
兩個值進行比較，如果相同則認為APK沒有被修改過，解析出SignerData中的證書。否則安裝失敗
如果是第一次安裝，直接將證書保存在應用信息中
如果是更新安裝，即設備中原來存在這個應用，驗證之前的證書是否與本次解析的證書相同。若相同，則安裝成功，否則失敗

[圖片上傳失敗...(image-6bfa12-1560483246319)]

v3版本簽名驗證證書步驟：（前三步同v2）

利用PublicKey解密Signature，得到SignerData的hash明文
計算SignerData的hash值
兩個值進行比較，如果相同則認為APK沒有被修改過，解析出SignerData中的證書。否則安裝失敗
逐個解析出level塊證書并驗證，并保存為這個應用的歷史證書
如果是第一次安裝，直接將證書與歷史證書一并保存在應用信息中
如果是更新安裝，驗證之前的證書與歷史證書，是否與本次解析的證書或者歷史證書中存在相同的證書，其中任意一個證書符合即可安裝

[圖片上傳失敗...(image-af6403-1560483246319)]

新特性場景舉例

其實就是當開發者需要更換證書時，即可直接用新證書新的私鑰進行簽名。不過為了讓老應用相信新的證書，則需要用老證書來保證。舉個例子，有兩個level塊：level 1與level 2：

level 1放置老證書的信息
level 2中放置新證書的信息以及這段數據的簽名
level 2中的簽名是由老私鑰進行簽名的，則需要用老證書的公鑰來驗證
校驗原來的證書與level 1 相同，則相信本次更新的level 2 的證書，即簽名APK的證書
完成安裝并記錄新證書信息

v3多渠道方案

略原理和v2同

參考：

http://www.lxweimin.com/p/332525b09a88
https://github.com/Meituan-Dianping/walle/
https://segmentfault.com/a/1190000015554496
https://juejin.im/entry/5a586bfaf265da3e2c3808c5
https://blog.csdn.net/u010818425/article/details/52319382
https://github.com/Tencent/VasDolly
https://cloud.tencent.com/developer/article/1004884
http://picksomething.cn/2018/05/08/Android%E5%A4%9A%E6%B8%A0%E9%81%93%E6%89%B9%E9%>87%8F%E6%89%93%E5%8C%85%EF%BC%8C%E6%94%AF%E6%8C%81%E5%8F%8B%E7%9B%9F%E5%92%8C%E7%AC%>AC%E4%B8%89%E6%96%B9%E5%8A%A0%E5%9B%BA/
http://twei.site/2016/08/31/MarkdownPad-2-%E6%94%AF%E6%8C%81%E8%A1%A8%E6%A0%BC/

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

apk簽名過程及多渠道

apk簽名過程及多渠道

apk簽名過程及多渠道

productFlavors

apk簽名過程及多渠道方案

簽名相關的基礎知識

數據摘要

數字簽名和數字證書

V1簽名和多渠道打包方案

V1簽名機制

v1校驗流程

apktool

修改apk

apk文件結構

向apk文件結構中寫入渠道信息

V2簽名和多渠道打包方案

為什么需要V2簽名

V2簽名機制

V2校驗流程

基于V2簽名的多渠道打包方案

V3簽名和多渠道打包方案

為什么要有v3

v3簽名塊結構

v3驗證簽名流程

驗證完整性

驗證證書

新特性場景舉例

v3多渠道方案

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

apk簽名過程及多渠道

apk簽名過程及多渠道

productFlavors

apk簽名過程及多渠道方案

簽名相關的基礎知識

數據摘要

數字簽名和數字證書

V1簽名和多渠道打包方案

V1簽名機制

v1校驗流程

apktool

修改apk

apk文件結構

向apk文件結構中寫入渠道信息

V2簽名和多渠道打包方案

為什么需要V2簽名

V2簽名機制

V2校驗流程

基于V2簽名的多渠道打包方案

V3簽名和多渠道打包方案

為什么要有v3

v3簽名塊結構

v3驗證簽名流程

驗證完整性

驗證證書

新特性場景舉例

v3多渠道方案

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频