Android 新一代多渠道打包神器

01-31

關於作者：
李濤，騰訊Android工程師，14年加入騰訊SNG增值產品部，期間主要負責手Q動漫、企鵝電競等項目的功能開發和技術優化。業務時間喜歡折騰新技術，寫一些技術文章，個人技術博客：http://www.ltlovezh.com 。
n

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

Github地址：
ltlovezh/ApkChannelPackage

n

概述

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

普通的多渠道打包方案

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

Android Gradle Plugin

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

首先，在AndroidManifest.xml中添加渠道信息佔位符：

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

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

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

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

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

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

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

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的簽名和校驗機制。

數據摘要、數字簽名和數字證書

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

數據摘要

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

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

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

n

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

不可逆性，即只能正向提取原始數據的數據摘要，而無法從數據摘要中恢復出原始數據。
n

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

數字簽名和數字證書

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

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

確定數據的來源是其真正的發送者。

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

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

首先，數據的發送者需要先申請一對公私鑰對，並將公鑰交給數據接收者。

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

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

計算髮送數據的數據摘要

用私鑰對提取的數據摘要進行加密

這樣，數據接收者拿到的消息就包含了兩塊內容：

原始數據內容

附加的數字簽名

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

用相同的摘要演算法計算出原始數據的數據摘要。

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

對比簽名得到的數據是否一致，如果一致，則說明數據沒有被篡改，否則數據就是臟數據了。

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

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

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

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

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

這樣數據發送者發送的消息就包含了三部分內容：

原始數據內容

附加的數字簽名

申請的數字證書。

接收者拿到數據後，首先會根據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.xmln SHA1-Digest: JqJbk6/AsWZMcGVehCXb33Cdtrk=n rnn

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

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文件的注釋欄位，添加渠道信息。

整個方案包括以下幾步：

複製APK

找到EOCD數據塊

修改注釋長度

添加渠道信息

添加渠道信息長度

添加魔數

添加渠道信息後的EOCD數據塊如下所示：

這裡添加魔數的好處是方便從後向前讀取數據，定位渠道信息。

因此，讀取渠道信息包括以下幾步：

定位到魔數

向前讀兩個位元組，確定渠道信息的長度LEN

繼續向前讀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存在兩個弊端：

MANIFEST.MF中的數據摘要是基於原始未壓縮文件計算的。因此在校驗時，需要先解壓出原始文件，才能進行校驗。而解壓操作無疑是耗時的。
n

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

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

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

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

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

nAPK安裝耗時對比n取5次平均耗時（秒）n V1簽名APKn11.64n V2簽名APKn4.42n

可見，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，整體結構和流程如下圖所示：

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

接著，把最左側一列的數據摘要、數字證書和額外屬性組裝起來，形成類似於V1簽名的「MF」文件（第二列第一行）；
n

其次，再用相同的私鑰，不同的簽名演算法，計算出「MF」文件的數字簽名，形成類似於V1簽名的「SF」文件（第二列第二行）；
n

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

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

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

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

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

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

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

最後，計算整體的數據摘要，基礎數據是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不被篡改的？

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

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

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

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

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

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

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

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

其實也很簡單，原來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（小端模式），如下所示：

6C 65 6F 6E就是我們的渠道信息leon。向前4個位元組：FF 55 11 88就是我們添加的ID，再向前8個位元組：08 00 00 00 00 00 00 00就是我們的ID-Value的長度，正好是8。

整個方案介紹完了，該方案的最大優點就是：支持7.0之上新增的V2簽名，同時兼有V1方案的所有優點。

多渠道包的強校驗

那麼如何保證通過這些方案生成的渠道包，能夠在所有Android平台上正確安裝那？

原來Google提供了一個同時支持V1和V2簽名和校驗的工具：apksig。它包括一個apksigner命令行和一個apksig類庫。其中前者就是Android SDK build-tools下面的命令行工具。而我們正是藉助後面的apksig來進行渠道包強校驗，它可以保證渠道包在apk Minsdk ~ 最高版本之間都校驗通過。詳細代碼可參考VerifyApk.java

多渠道打包工具對比

目前市面上的多渠道打包工具主要有packer-ng-plugin和美團的Walle。下表是我們的ApkChannelPackage和它們之間的簡單對比。

這裡我之所以同時支持V1和V2簽名方案，主要是擔心後續Android平台加強簽名校驗機制，導致V2多渠道打包方案行不通，可以無痛切換到V1簽名方案。後續我也會儘快支持命令行工具。

ApkChannelPackage插件接入

多渠道打包方式選擇

目前Gradle Plugin 2.2以上默認開啟V2簽名，所以如果想關閉V2簽名，可將下面的v2SigningEnabled設置為false。

signingConfigs {n release {n ...n v1SigningEnabled truen v2SigningEnabled falsen }nn debug {n ...n v1SigningEnabled truen v2SigningEnabled falsen }n }n

接入流程

1.在根工程的build.gradle中，添加對打包Plugin的依賴：

dependencies {n classpath com.android.tools.build:gradle:2.2.0n classpath com.leon.channel:plugin:1.0.1}n

2.在主App工程的build.gradle中，添加對ApkChannelPackage Plugin的引用：

apply plugin: channeln

3.在主App工程的build.gradle中，添加讀取渠道信息的helper類庫依賴：

dependencies {n compile com.leon.channel:helper:1.0.1}n

4.在gradle.properties文件中，配置渠道文件名稱

channel_file=channel.txtn

其中channel.txt即為包含渠道信息的文件，需放置在根工程目錄下，一行一個渠道信息。

5.渠道包信息配置

若是直接編譯生成多渠道包，則通過channel標籤配置：

channel{ //多渠道包的輸出目錄，默認為new File(project.buildDir,"channel")n baseOutputDir = new File(project.buildDir,"xxx") //多渠道包的命名規則，默認為：${appName}-${versionName}-${versionCode}-${flavorName}-${buildType}n apkNameFormat =${appName}-${versionName}-${versionCode}-${flavorName}-${buildType}}n

其中，多渠道包的命名規則中，可使用以下欄位：

appName ：當前project的name

versionName ：當前Variant的versionName

versionCode ：當前Variant的versionCode

buildType ：當前Variant的buildType，即debug or release

flavorName ：當前的渠道名稱

appId ：當前Variant的applicationId

若是根據已有基礎包生成多渠道包，則通過rebuildChannel標籤配置：

rebuildChannel {n baseDebugApk = 已有Debug APK n baseReleaseApk = 已有Release APK//默認為new File(project.buildDir, "rebuildChannel/debug")debugOutputDir = Debug渠道包輸出目錄 n //默認為new File(project.buildDir, "rebuildChannel/release")releaseOutputDir = Release渠道包輸出目錄n }n

這裡要注意一下，已有APK的名字必須包含base字元串，這樣插件生成多渠道包時，會用當前的渠道替換base字元串，形成新的渠道包。

6.生成多渠道包

若沒有通過Gradle Plugin的 productFlavors配置多渠道，那麼通過以下Task

channelDebug 、channelRelease分別負責生成Debug和Release的多渠道包。

若是配置了productFlavors，那麼對應的Task則是channelFlavorXDebug、channelFlavorXRelease，FlavorX表示在productFlavors中配置的渠道名稱。

除此之外，如果是根據已有基礎包生成多渠道包，那麼對應的Task則是reBuildChannel。

7.讀取渠道信息

通過helper類庫中的ChannelReaderUtil類讀取渠道信息。

String channel = ChannelReaderUtil.getChannel(getApplicationContext());n

更多精彩內容歡迎關注騰訊 Bugly的微信公眾賬號：

騰訊 Bugly是一款專為移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的情況以及解決方案。智能合併功能幫助開發同學把每天上報的數千條 Crash 根據根因合併分類，每日日報會列出影響用戶數最多的崩潰，精準定位功能幫助開發同學定位到出問題的代碼行，實時上報可以在發布後快速的了解應用的質量情況，適配最新的 iOS, Android 官方操作系統，鵝廠的工程師都在使用，快來加入我們吧！