ApkChannelPackage是一種快速多渠道打包工具，同時支援基於V1和V2簽名進行渠道打包。外掛本身會自動檢測Apk使用的簽名方法，並選擇合適的多渠道打包方式，對使用者來說完全透明。

概述

眾所周知，因為國內Android應用分發市場的現狀，我們在釋出APP時，一般需要生成多個渠道包，上傳到不同的應用市場。這些渠道包需要包含不同的渠道資訊，在APP和後臺互動或者資料上報時，會帶上各自的渠道資訊。這樣，我們就能統計到每個分發市場的下載數、使用者數等關鍵資料。

普通的多渠道打包方案

既然我們需要進行多渠道打包，那我們就看下最常見的多渠道打包方案。

Android Gradle Plugin

Gradle Plugin本身提供了多渠道的打包策略：

首先，在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中的渠道資訊了。

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

1. 每生成一個渠道包，都要重新執行一遍構建流程，效率太低，只適用於渠道較少的場景。

2. Gradle會為每個渠道包生成一個不同的BuildConfig.java類，記錄渠道資訊，導致每個渠道包的DEX的CRC值都不同。一般情況下，這是沒有影響的。但是如果你使用了微信的Tinker熱補丁方案，那麼就需要為不同的渠道包打不同的補丁，這完全是不可以接受的。（因為Tinker是通過對比基礎包APK和新包APK生成差分補丁，然後再把補丁和基礎包APK一起合成新包APK。這就要求用於生成差分補丁的基礎包DEX和用於合成新包的基礎包DEX是完全一致的，即：每一個基礎渠道包的DEX檔案是完全一致的，不然就會合成失敗）

ApkTool

ApkTool是一個逆向分析工具，可以把APK解開，新增程式碼後，重新打包成APK。因此，基於ApkTool的多渠道打包方案分為以下幾步：

1. 複製一份新的APK

2. 通過ApkTool工具，解壓APK（apktool d origin.apk）

3. 刪除已有簽名信息

4. 新增渠道資訊（可以在APK的任何檔案新增渠道資訊）

5. 通過ApkTool工具，重新打包生成新APK（apktool b newApkDir）

6. 重新簽名

經過測試，這種方案完全是可行的。

優點：

不需要重新構建新渠道包，僅需要複製修改就可以了。並且因為是重新簽名，所以同時支援V1和V2簽名。

缺點：

1. ApkTool工具不穩定，曾經遇到過升級Gradle Plugin版本後，低版本ApkTool解壓APK失敗的情況。

2. 生成新渠道包時，需要重新解包、打包和簽名，而這幾步操作又是相對比較耗時的。經過測試：生成企鵝電競10個渠道包需要16分鐘左右，雖然比Gradle Plugin方案減少很多耗時。但是若需要同時生成上百個渠道包，則需要幾個小時，顯然不適合渠道非常多的業務場景。

那有沒有一種方案，可以在新增渠道資訊後，不需要重新簽名那？

首先我們要了解一下APK的簽名和校驗機制。

資料摘要、數字簽名和數字證書

在進一步學習V1和V2簽名之前，我們有必要學習一下簽名相關的基礎知識。

資料摘要

資料摘要演算法是一種能產生特定輸出格式的演算法，其原理是根據一定的運算規則對原始資料進行某種形式的資訊提取，被提取出的資訊就是原始資料的訊息摘要，也稱為資料指紋。

一般情況下，資料摘要演算法具有以下特點：

1. 無論輸入資料有多大（長），計算出來的資料摘要的長度總是固定的。例如：MD5演算法計算出的資料摘要有128Bit。

2. 一般情況下（不考慮碰撞的情況下），只要原始資料不同，那麼其對應的資料摘要就不會相同。同時，只要原始資料有任何改動，那麼其資料摘要也會完全不同。即：相同的原始資料必有相同的資料摘要，不同的原始資料，其資料摘要也必然不同。

3. 不可逆性，即只能正向提取原始資料的資料摘要，而無法從資料摘要中恢復出原始資料。

著名的摘要演算法有RSA公司的MD5演算法和SHA系列演算法。

數字簽名和數字證書

數字簽名和數字證書是成對出現的，兩者不可分離（數字簽名主要用來校驗資料的完整性，數字證書主要用來確保公鑰的安全發放）。

要明白數字簽名的概念，必須要了解資料的加密、傳輸和校驗流程。一般情況下，要實現資料的可靠通訊，需要解決以下兩個問題：

1. 確定資料的來源是其真正的傳送者。

2. 確保資料在傳輸過程中，沒有被篡改，或者若被篡改了，可以及時發現。

而數字簽名，就是為了解決這兩個問題而誕生的。

首先，資料的傳送者需要先申請一對公私鑰對，並將公鑰交給資料接收者。

然後，若資料傳送者需要傳送資料給接收者，則首先要根據原始資料，生成一份數字簽名，然後把原始資料和數字簽名一起傳送給接收者。

數字簽名由以下兩步計算得來：

1. 計算髮送資料的資料摘要

2. 用私鑰對提取的資料摘要進行加密

這樣，資料接收者拿到的訊息就包含了兩塊內容：

1. 原始資料內容

2. 附加的數字簽名

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

1. 用相同的摘要演算法計算出原始資料的資料摘要。

2. 用預先得到的公鑰解密數字簽名。

3. 對比簽名得到的資料是否一致，如果一致，則說明資料沒有被篡改，否則資料就是髒資料了。

因為私鑰只有傳送者才有，所以其他人無法偽造數字簽名。這樣通過數字簽名就確保了資料的可靠傳輸。

綜上所述，數字簽名就是只有傳送者才能產生的別人無法偽造的一段數字串，這段數字串同時也是對傳送者傳送資料真實性的一個有效證明。

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

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

可見，數字證書也用到了數字簽名技術。只不過簽名的內容是資料傳送方的公鑰，以及一些其它證書資訊。

這樣資料傳送者傳送的訊息就包含了三部分內容：

1. 原始資料內容

2. 附加的數字簽名

3. 申請的數字證書。

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

所以，數字證書主要解決了公鑰的安全發放問題。

因此，包含數字證書的整個簽名和校驗流程如下圖所示：

V1簽名和多渠道打包方案

V1簽名機制

預設情況下，APK使用的就是V1簽名。解壓APK後，在META-INF目錄下，可以看到三個檔案：MANIFEST.MF、CERT.SF、CERT.RSA。它們都是V1簽名的產物。其中，MANIFEST.MF檔案內容如下所示：

它記錄了APK中所有原始檔案的資料摘要的Base64編碼,而資料摘要演算法就是SHA1。CERT.SF檔案內容如下所示：

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，整個簽名流程如下圖所示：

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

V1校驗流程

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

若中間任何一步校驗失敗，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的數字簽名那？理論上不可能，因為破壞者沒有開發者的私鑰。那破壞者是不是可以用自己的私鑰和數字證書重新簽名那，這倒是完全可以！

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

APK檔案結構

由上述V1簽名和校驗機制可知，修改APK中的任何檔案都會導致安裝失敗！那怎麼新增渠道資訊那？只能從APK的結構入手了。

APK檔案本質上是一個ZIP壓縮包，而ZIP格式是固定的，主要由三部分構成，如下圖所示：

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

第二部分稱為中央目錄，包含了多個central directory file header（和第一部分的local file header一一對應），每個中央目錄檔案頭主要記錄了壓縮演算法、註釋資訊、對應local file header的偏移量等，方便快速定位資料。

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

根據之前的V1簽名和校驗機制可知，V1簽名只會檢驗第一部分的所有壓縮檔案，而不理會後兩部分內容。因此，只要把渠道資訊寫入到後兩塊內容就可以通過V1校驗，而EOCD的註釋欄位無疑是最好的選擇。

基於V1簽名的多渠道打包方案

既然找到了突破口，那麼基於V1簽名的多渠道打包方案就應運而生：在APK檔案的註釋欄位，新增渠道資訊。

整個方案包括以下幾步：

1. 複製APK

2. 找到EOCD資料塊

3. 修改註釋長度

4. 新增渠道資訊

5. 新增渠道資訊長度

6. 新增魔數

7. 新增渠道資訊後的EOCD資料塊如下所示：

這裡新增魔數的好處是方便從後向前讀取資料，定位渠道資訊。
因此，讀取渠道資訊包括以下幾步：

1. 定位到魔數

2. 向前讀兩個位元組，確定渠道資訊的長度LEN

3. 繼續向前讀LEN位元組，就是渠道資訊了。

通過16進位制編輯器，可以檢視到新增渠道資訊後的APK（小端模式），如下所示：

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位置的方案。整個計算流程如下圖所示：

整個方案介紹完了，該方案的最大優點就是：不需要解壓縮APK，不需要重新簽名，只需要複製APK，在註釋欄位新增渠道資訊。每個渠道包僅需幾秒的耗時，非常適合渠道較多的APK。

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

V2簽名和多渠道打包方案

為什麼需要V2簽名

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

1. MANIFEST.MF中的資料摘要是基於原始未壓縮檔案計算的。因此在校驗時，需要先解壓出原始檔案，才能進行校驗。而解壓操作無疑是耗時的。

2. V1簽名僅僅校驗APK第一部分中的檔案，缺少對APK的完整性校驗。因此，在簽名後，我們還可以修改APK檔案，例如：通過zipalign進行位元組對齊後，仍然可以正常安裝。

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

1. V2簽名是對APK本身進行資料摘要計算，不存在解壓APK的操作，減少了校驗時間。

2. V2簽名是針對整個APK進行校驗（不包含簽名塊本身），因此對APK的任何修改（包括添加註釋、zipalign位元組對齊）都無法通過V2簽名的校驗。

關於第一點的耗時問題，這裡有一份實驗室資料（Nexus 6P、Android 7.1.1）可供參考。

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

V2簽名機制

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

APK簽名塊位於中央目錄之前，檔案資料之後。V2簽名同時修改了EOCD中的中央目錄的偏移量，使簽名後的APK還符合ZIP結構。

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

首先是8位元組的簽名塊大小，此大小不包含該欄位本身的8位元組；其次就是ID-Value序列，就是一個4位元組的ID和對應的資料；然後又是一個8位元組的簽名塊大小，與開始的8位元組是相等的；最後是16位元組的簽名塊魔數。

其中，ID為0x7109871a對應的Value就是V2簽名塊資料。

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

1. 首先，根據多個簽名演算法，計算出整個APK的資料摘要，組成左上角的APK資料摘要集；

2. 接著，把最左側一列的資料摘要、數字證書和額外屬性組裝起來，形成類似於V1簽名的“MF”檔案（第二列第一行）；

3. 其次，再用相同的私鑰，不同的簽名演算法，計算出“MF”檔案的數字簽名，形成類似於V1簽名的“SF”檔案（第二列第二行）；

4. 然後，把第二列的類似MF檔案、類似SF檔案和開發者公鑰一起組裝成通過單個keystore簽名後的v2簽名塊（第三列第一行）。

5. 最後，把多個keystore簽名後的簽名塊組裝起來，就是完整的V2簽名塊了（Android中允許使用多個keystore對apk進行簽名）。

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

除此之外，Google也優化了計算資料摘要的演算法，使得可以平行計算，如下圖所示：

資料摘要的計算包括以下幾步：

1. 首先，將上述APK中檔案內容塊、中央目錄、EOCD按照1MB大小分割成一些小塊。

2. 然後，計算每個小塊的資料摘要，基礎資料是0xa5 + 塊位元組長度 + 塊內容。

3. 最後，計算整體的資料摘要，基礎資料是0x5a + 資料塊的數量 + 每個資料塊的摘要內容。

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

V2校驗流程

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

該屬性會強制APK走V2校驗流程（7.0之上），以充分利用V2簽名的優勢（速度快和更完善的校驗機制）。

因此，同時包含V1和V2簽名的APK的校驗流程如下所示：

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

這裡引申出另外一個問題：APK簽名時，只有V2簽名，沒有V1簽名行不行？

經過嘗試，這種情況是可以編譯通過的，並且在Android 7.0之上也可以正確安裝和執行。但是7.0之下，因為不認識V2，又沒有V1簽名，所以會報沒有簽名的錯誤。

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

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

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

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

1. 首先，如果破壞者修改了APK檔案的任何部分（簽名塊本身除外），那麼APK的資料摘要就和“MF”資料塊中記錄的資料摘要不一致，導致校驗失敗。

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

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

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

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

到這裡，V2簽名已經介紹完了。但是在最後一步“資料摘要校驗”這裡，隱藏了一個點，不知道有沒有人發現？

因為，我們V2簽名塊中的資料摘要是針對APK的檔案內容塊、中央目錄和EOCD三塊內容計算的。但是在寫入簽名塊後，修改了EOCD中的中央目錄偏移量，那麼在進行V2簽名校驗時，理論上在“資料摘要校驗”這步應該會校驗失敗啊！但是為什麼V2簽名可以校驗通過那？

這個問題很重要，因為我們下面要介紹的基於V2簽名的多渠道打包方案也會修改EOCD的中央目錄偏移量。

其實也很簡單，原來Android系統在校驗APK的資料摘要時，首先會把EOCD的中央目錄偏移量替換成簽名塊的偏移量