編輯:關於Android編程
在Android 7.0(Nougat)推出了新的應用簽名方案APK Signature Scheme v2後,之前快速生成渠道包的方式已經行不通了,在此應用簽名方案下如何快速生成渠道包呢?
本文會對新的應用簽名方案APK Signature Scheme v2以及新一代渠道生成工具進行詳細深入的介紹。
Android 7.0(Nougat)引入一項新的應用簽名方案APK Signature Scheme v2,它是一個對全文件進行簽名的方案,能提供更快的應用安裝時間、對未授權APK文件的更改提供更多保護,在默認情況下,Android Gradle 2.2.0插件會使用APK Signature Scheme v2和傳統簽名方案來簽署你的應用。
下面以新的應用簽名方案來指APK Signature Scheme v2。
目前該方案不是強制性的,在build.gradle添加v2SigningEnabled false,就能使用傳統簽名方案來簽署我們的應用(見下面的代碼片段)。
android { ... defaultConfig { ... } signingConfigs { release { storeFile file("myreleasekey.keystore") storePassword "password" keyAlias "MyReleaseKey" keyPassword "password" v2SigningEnabled false } } }
但新的應用簽名方案有著良好的向後兼容性,能完全兼容低於Android 7.0(Nougat)的版本。對比舊簽名方案,它有更快的驗證速度和更安全的保護,因此新的應用簽名方案可能會被采納成一個強制配置,筆者認為現在有必要對現有的渠道包生成方式進行檢查、升級或改造來支持新的應用簽名方案。
新的簽名方案對已有的渠道生成方案有什麼影響呢?下圖是新的應用簽名方案和舊的簽名方案的一個對比:
新的簽名方案會在ZIP文件格式的Central Directory區塊所在文件位置的前面添加一個APK Signing Block區塊,下面按照ZIP文件的格式來分析新應用簽名方案簽名後的APK包。
整個APK(ZIP文件格式)會被分為以下四個區塊:
新應用簽名方案的簽名信息會被保存在區塊2(APK Signing Block)中, 而區塊1(Contents of ZIP entries)、區塊3(ZIP Central Directory)、區塊4(ZIP End of Central Directory)是受保護的,在簽名後任何對區塊1、3、4的修改都逃不過新的應用簽名方案的檢查。
之前的渠道包生成方案是通過在META-INF目錄下添加空文件,用空文件的名稱來作為渠道的唯一標識,之前在META-INF下添加文件是不需要重新簽名應用的,這樣會節省不少打包的時間,從而提高打渠道包的速度。但在新的應用簽名方案下META-INF已經被列入了保護區了,向META-INF添加空文件的方案會對區塊1、3、4都會有影響,新應用簽名方案簽署的應用經過我們舊的生成渠道包方案處理後,在安裝時會報以下錯誤:
Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES: Failed to collect certificates from base.apk: META-INF/CERT.SF indicates base.apk is signed using APK Signature Scheme v2, but no such signature was found. Signature stripped?]
目前另外一種比較流行的渠道包快速生成方案(往APK中添加ZIP Comment)也因為上述原因,無法在新的應用簽名方案下進行正常工作。
如果新的應用簽名方案後續改成強制要求,那我們現有的生成渠道包的方式就會無法工作,那我們難道要退回到解放前,通過傳統的方式(例如:使用APKTool逆向工具、采用Flavor + BuildType等比較耗時的方案來進行渠道包打包)來生成支持新應用簽名方案的渠道包嗎?
如果只有少量渠道包的場景下,這種耗時時長還能夠勉強接受。但是目前我們有將近900個渠道,如果采用傳統方式打完所有的渠道包需要近3個小時,這是不能接受的。
那我們有沒有其他更好的渠道包生成方式,既能支持新的應用簽名方案,又能體驗毫秒級的打包耗時呢?我們來分析一下新方案中的區塊2——Block。
通過上面的描述,可以看出因為APK包的區塊1、3、4都是受保護的,任何修改在簽名後對它們的修改,都會在安裝過程中被簽名校驗檢測失敗,而區塊2(APK Signing Block)是不受簽名校驗規則保護的,那是否可以在這個不受簽名保護的區塊2(APK Signing Block)上做文章呢?我們先來看看對區塊2格式的描述:
區塊2中APK Signing Block是由這幾部分組成:2個用來標示這個區塊長度的8字節 + 這個區塊的魔數(APK Sig Block 42)+ 這個區塊所承載的數據(ID-value)。
我們重點來看一下這個ID-value,它由一個8字節的長度標示+4字節的ID+它的負載組成。V2的簽名信息是以ID(0x7109871a)的ID-value來保存在這個區塊中,不知大家有沒有注意這是一組ID-value,也就是說它是可以有若干個這樣的ID-value來組成,那我們是不是可以在這裡做一些文章呢?
為了驗證我們的想法,先來看看新的應用簽名方案是怎麼驗證簽名信息的,見下圖:
通過上圖可以看出新的應用簽名方案的驗證過程:
那Android應用在安裝時新的應用簽名方案是怎麼進行校驗的呢?筆者通過翻閱Android相關部分的源碼,發現下面代碼段是用來處理上面所說的ID-value的:
public static ByteBuffer findApkSignatureSchemeV2Block( ByteBuffer apkSigningBlock, Result result) throws SignatureNotFoundException { checkByteOrderLittleEndian(apkSigningBlock); // FORMAT: // OFFSET DATA TYPE DESCRIPTION // * @+0 bytes uint64: size in bytes (excluding this field) // * @+8 bytes pairs // * @-24 bytes uint64: size in bytes (same as the one above) // * @-16 bytes uint128: magic ByteBuffer pairs = sliceFromTo(apkSigningBlock, 8, apkSigningBlock.capacity() - 24); int entryCount = 0; while (pairs.hasRemaining()) { entryCount++; if (pairs.remaining() < 8) { throw new SignatureNotFoundException( "Insufficient data to read size of APK Signing Block entry #" + entryCount); } long lenLong = pairs.getLong(); if ((lenLong < 4) || (lenLong > Integer.MAX_VALUE)) { throw new SignatureNotFoundException( "APK Signing Block entry #" + entryCount + " size out of range: " + lenLong); } int len = (int) lenLong; int nextEntryPos = pairs.position() + len; if (len > pairs.remaining()) { throw new SignatureNotFoundException( "APK Signing Block entry #" + entryCount + " size out of range: " + len + ", available: " + pairs.remaining()); } int id = pairs.getInt(); if (id == APK_SIGNATURE_SCHEME_V2_BLOCK_ID) { return getByteBuffer(pairs, len - 4); } result.addWarning(Issue.APK_SIG_BLOCK_UNKNOWN_ENTRY_ID, id); pairs.position(nextEntryPos); } throw new SignatureNotFoundException( "No APK Signature Scheme v2 block in APK Signing Block"); }
上述代碼中關鍵的一個位置是if (id == APK_SIGNATURE_SCHEME_V2_BLOCK_ID) {return getByteBuffer(pairs, len - 4);},通過源代碼可以看出Android是通過查找ID為APK_SIGNATURE_SCHEME_V2_BLOCK_ID = 0x7109871a的ID-value,來獲取APK Signature Scheme v2 Block,對這個區塊中其他的ID-value選擇了忽略。
在APK Signature Scheme v2中沒有看到對無法識別的ID,有相關處理的介紹。
當看到這裡時,我們可不可以設想一下,提供一個自定義的ID-value並寫入該區域,從而為快速生成渠道包服務呢?
怎麼向ID-value中添加信息呢?通過閱讀ZIP的文件格式和APK Signing Block格式的描述,筆者通過編寫下面的代碼片段進行驗證,發現通過在已經被新的應用簽名方案簽名後的APK中添加自定義的ID-value,是不需要再次經過簽名就能安裝的,下面是部分代碼片段。
public void writeApkSigningBlock(DataOutput dataOutput) { long length = 24; for (int index = 0; index < payloads.size(); ++index) { ApkSigningPayload payload = payloads.get(index); byte[] bytes = payload.getByteBuffer(); length += 12 + bytes.length; } ByteBuffer byteBuffer = ByteBuffer.allocate(Long.BYTES); byteBuffer.order(ByteOrder.LITTLE_ENDIAN); byteBuffer.putLong(length); dataOutput.write(byteBuffer.array()); for (int index = 0; index < payloads.size(); ++index) { ApkSigningPayload payload = payloads.get(index); byte[] bytes = payload.getByteBuffer(); byteBuffer = ByteBuffer.allocate(Integer.BYTES); byteBuffer.order(ByteOrder.LITTLE_ENDIAN); byteBuffer.putInt(payload.getId()); dataOutput.write(byteBuffer.array()); dataOutput.write(bytes); } ... }
到這裡為止一個新的渠道包生成方案逐步清晰了起來,下面是新一代渠道包生成工具的描述:
新一代渠道包生成工具完全是基於ZIP文件格式和APK Signing Block存儲格式而構建,基於文件的二進制流進行處理,有著良好的處理速度和兼容性,能夠滿足不同的語言編寫的要求,目前筆者采用的是Java+Groovy開發, 該工具主要有四部分組成:
這樣,每打一個渠道包只需復制一個APK,然後在APK中添加一個ID-value即可,這種打包方式速度非常快,對一個30M大小的APK包只需要100多毫秒(包含文件復制時間)就能生成一個渠道包,而在運行時獲取渠道信息只需要大約幾毫秒的時間。
這個項目我們取名為Walle(瓦力),已經開源,項目的Github地址是:https://github.com/Meituan-Dianping/walle(求Issue、PR、Star)。希望業內有類似需求的團隊能夠在APK Signature Scheme V2簽名下愉快地生成渠道包,同時也期待大家一起對該項目進行完善和優化。
以上就是我們對新的應用簽名方案進行的分析,並根據它所帶來的文件存儲格式上的變化,找到了可以利用的ID-value,然後基於這個ID-value來構建我們新一代渠道包生成工具。
新一代渠道包生成工具能夠滿足新應用簽名方案對安全性的要求,同時也能滿足對渠道包打包時間的要求,至此大家生成渠道包的方式需要升級了!
一、知識點講解當我們點擊系統自帶的按鈕時,按鈕的外觀會發生變化。上篇博文中我們畫了一個三角形按鈕,但點擊還不能變色,下面我們就來實現點擊變色功能。從知識體系上我們需要了解
為大家提供的MySQL忘記密碼的解決方案,供大家參考,具體內容如下1.在操作系統windows操作系統,xp或win7.中進入如下目錄:復制代碼 代碼如下:C:\User
作為一個完成的應用程序,數據存儲操作是必不可少的,因此,Android系統提供了四種數據儲存方式,分別是:SharedPreference、File、SQLite以及Co
前提:手機已經root; 1.手機連接電腦,打開Cmd,運行命令adb shell;//因為android用的Linux內核,很多linux的命令,在Android也可以