android:name="installchannel"
android
:value="$"
/>
"yingyongbao"
"360"
}通過apktool工具，解壓apk（apktool d origin.apk）
刪除已有簽名資訊
新增渠道資訊（可以在apk的任何檔案新增渠道資訊）
通過apktool工具，重新打包生成新apk（apktool b newapkdir）
重新簽名
生成新渠道包時，需要重新解包、打包和簽名，而這幾步操作又是相對比較耗時的。經過測試：生成企鵝電競10個渠道包需要16分鐘左右，雖然比gradle plugin方案減少很多耗時。但是若需要同時生成上百個渠道包，則需要幾個小時，顯然不適合渠道非常多的業務場景。
一般情況下（不考慮碰撞的情況下），只要原始資料不同，那麼其對應的資料摘要就不會相同。同時，只要原始資料有任何改動，那麼其資料摘要也會完全不同。即：相同的原始資料必有相同的資料摘要，不同的原始資料，其資料摘要也必然不同。
不可逆性，即只能正向提取原始資料的資料摘要，而無法從資料摘要中恢復出原始資料。
）。確保資料在傳輸過程中，沒有被篡改，或者若被篡改了，可以及時發現。
用私鑰對提取的資料摘要進行加密
附加的數字簽名
用預先得到的公鑰解密數字簽名。
對比簽名得到的資料是否一致，如果一致，則說明資料沒有被篡改，否則資料就是髒資料了。
附加的數字簽名
申請的數字證書。
name: res/drawable/skin_drawable_btm_line.xml
sha1-digest: jqjbk6/aswzmcgvehcxb33cdtrk=
\r\n
找到eocd資料塊
修改注釋長度
新增渠道資訊
新增渠道首席資訊官度
新增魔數
向前讀兩個位元組，確定渠道資訊的長度len
繼續向前讀len位元組，就是渠道資訊了。
v1簽名僅僅校驗apk第一部分中的檔案，缺少對apk的完整性校驗。因此，在簽名後，我們還可以修改apk檔案，例如：通過zipalign進行位元組對齊後，仍然可以正常安裝。
v2簽名是針對整個apk進行校驗（不包含簽名塊本身），因此對apk的任何修改（包括新增注釋、zipalign位元組對齊）都無法通過v2簽名的校驗。
取5次平均耗時（秒）
v1簽名apk
11.64
v2簽名apk
4.42。。
然後，計算每個小塊的資料摘要，基礎資料是0xa5 + 塊位元組長度 + 塊內容。
最後，計算整體的資料摘要，基礎資料是0x5a + 資料塊的數量 + 每個資料塊的摘要內容。
。 整個方案包括以下幾步：
找到apk簽名塊
獲取已有的id-value pair
新增包含渠道資訊的id-value
基於所有的id-value生成新的簽名塊
修改eocd的**目錄的偏移量（上面已介紹過：修改eocd的**目錄偏移量，不會導致資料摘要校驗失敗）
用新的簽名塊替代舊的簽名塊，生成帶有渠道資訊的apk
vasdolly
packer-ng-plugin
walle
v1簽名方案
支援支援
不支援v2簽名方案
支援不支援
支援已有注釋塊的apk
支援不支援
不支援根據已有apk生成渠道包
支援不支援
不支援命令列工具
支援支援
支援強校驗
支援不支援
支援多執行緒加速打包
支援不支援
不支援
Android多渠道打包
度娘能搜到很多種多渠道打包方式，我這裡簡單說下我們目前正在使用的打包方法。首先背景情況 我們不同渠道，除了渠道號 vendorid 不一樣外，還有功能上的稍許不同，所以還有幾個開關控制專案。方法原理 專案 中在res raw 下增加config.dat檔案，裡面有渠道號，和功能開關 apk包，其實是...
Gradle多渠道打包
廢話不多說，以友盟統計為例，在androidmanifest.xml裡面會有這麼一段 meta data android name umeng channel android value channel id 裡面的channel id就是渠道標示。我們的目標就是在編譯的時候這個值能夠自動變化。或者...
android Ant 批量多渠道打包
支援多渠道打包 需要配置在androidmanifest.xml配置個 android name和android value位置不能變 這裡先要說下必須的 1 ant版本1.7以上 adt版本的eclipse裡的ant是1.8.3 ok eclipse plugins org.apache.ant ...