Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> 關於Android編程 >> 新一代開源Android渠道包生成工具Walle

新一代開源Android渠道包生成工具Walle

編輯:關於Android編程

在Android 7.0(Nougat)推出了新的應用簽名方案APK Signature Scheme v2後,之前快速生成渠道包的方式已經行不通了,在此應用簽名方案下如何快速生成渠道包呢?

本文會對新的應用簽名方案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文件格式)會被分為以下四個區塊:

  1. Contents of ZIP entries(from offset 0 until the start of APK Signing Block)
  2. APK Signing Block
  3. ZIP Central Directory
  4. ZIP End of Central Directory

\

新應用簽名方案的簽名信息會被保存在區塊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 Signature Scheme v2 Block

通過上面的描述,可以看出因為APK包的區塊1、3、4都是受保護的,任何修改在簽名後對它們的修改,都會在安裝過程中被簽名校驗檢測失敗,而區塊2(APK Signing Block)是不受簽名校驗規則保護的,那是否可以在這個不受簽名保護的區塊2(APK Signing Block)上做文章呢?我們先來看看對區塊2格式的描述:

偏移 字節數 描述 @+0 8 這個Block的長度(本字段的長度不計算在內) @+8 n 一組ID-value @-24 8 這個Block的長度(和第一個字段一樣值) @-16 16 魔數 “APK Sig Block 42”

區塊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來組成,那我們是不是可以在這裡做一些文章呢?

為了驗證我們的想法,先來看看新的應用簽名方案是怎麼驗證簽名信息的,見下圖:

\

通過上圖可以看出新的應用簽名方案的驗證過程:

  1. 尋找APK Signing Block,如果能夠找到,則進行驗證,驗證成功則繼續進行安裝,如果失敗了則終止安裝
  2. 如果未找到APK Signing Block,則執行原來的簽名驗證機制,也是驗證成功則繼續進行安裝,如果失敗了則終止安裝

那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);
        }
        ...
    }

新一代渠道包生成工具

到這裡為止一個新的渠道包生成方案逐步清晰了起來,下面是新一代渠道包生成工具的描述:

  1. 對新的應用簽名方案生成的APK包中的ID-value進行擴展,提供自定義ID-value(渠道信息),並保存在APK中
  2. 而APK在安裝過程中進行的簽名校驗,是忽略我們添加的這個ID-value的,這樣就能正常安裝了
  3. 在App運行階段,可以通過ZIP的EOCD(End of central directory)、Central directory等結構中的信息(會涉及ZIP格式的相關知識,這裡不做展開描述)找到我們自己添加的ID-value,從而實現獲取渠道信息的功能

新一代渠道包生成工具完全是基於ZIP文件格式和APK Signing Block存儲格式而構建,基於文件的二進制流進行處理,有著良好的處理速度和兼容性,能夠滿足不同的語言編寫的要求,目前筆者采用的是Java+Groovy開發, 該工具主要有四部分組成:

  1. 用於寫入ID-value信息的Java類庫
  2. Gradle構建插件用來和Android的打包流程進行結合
  3. 用於讀取ID-value信息的Java類庫
  4. 用於供com.android.application使用的讀取渠道信息的AAR

這樣,每打一個渠道包只需復制一個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來構建我們新一代渠道包生成工具。

新一代渠道包生成工具能夠滿足新應用簽名方案對安全性的要求,同時也能滿足對渠道包打包時間的要求,至此大家生成渠道包的方式需要升級了!

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved