Android打包工具的制作（Java GUI）支持三种打包方式

Android开发过程中，打渠道包是最平常的需求了，简化打包过程和自动化就很有必要了，你可能会说现在的Android Studio的Gradle配置就很方便，就连Eclipse也可以通过写ant插件来编写build.xml（构建文件）也可以实现多渠道打包。确实没错，但是这种打包方式需要开发者每次都去配置，然后每次都要重新在编辑器中完成。有种打包需求是通过现有的母包apk，再打出多个渠道包，即得现有一个生成好的渠道包。比如游戏渠道平台就需要从cp方获得游戏母包，然后再自己根据渠道要求打渠道包。

首先先来了解一些基本事实：

Android构建过程：用到aapt(编译资源)、proguard（混淆代码）、apktool.jar（回编成一个未签名的apk）

1.Android在构建过程中会将res资源编译成R.java

2.R.java、java源代码、编译成jar再编译成dex，最终编译成smali代码

3.assets目录下的文件并不会编译

4.最终生成一个未签名的apk

签名过程：（先用Keytool.exe 生成keystore或者jks签名文件）

1.用jarsigner.exe 和keystore或者jks对未签名的apk签名时，是对整个未签名apk作用的，所以对生成已签名的apk做任何修改时，都会破坏签名，需要重新签名（即使是assets目录下的资源）

优化对齐过程

1.一般签名过的apk，还要用zipalign.exe工具进行对齐优化才是我们最终的apk

好了，以上是一般将项目代码编译成可用apk的大致过程（具体细节复杂的多），那么现在有了一个可用的apk,怎么利用它来打渠道包呢？

最主要的是我们apk中是怎么定义渠道标示的，这直接决定打包工具的制作也决定打渠道包的效率，一般主要分为以下几种：

方式一：.AndroidManifest.xml中用meta-data标签定义渠道标示

方式二：.assets目录下的渠道配置文件

方式三：.签名目录META-INF下定义渠道配置文件

分析：方式一：.AndroidManifest.xml中定义meta-data方式是用的最多的，如果我们拿到一个这样定义渠道表示的apk母包，那么我们怎么通过这个apk打渠道包？

1.用apktool反编译母包apk 。 常用命名：apktool d [apk]   （生成smali代码）；apktool d -s [apk] （不生成smali代码）

2.然后再用代码动态修改AndroidManifest.xml中的渠道标示

3.然后用apktool回编成一个未签名的apk

4.用jarsigner.exe 和keystore或者jks来签名apk

5.最后再zipalign.exe优化apk,生成最终的渠道包

注意：该种方式的渠道标示是在AndroidManifest.xml中，所以一定要经过apktool的反编译和回编，所以效率低

           方式二：我们知道在构建apk的过程中assets目录下的资源不会被编译，所以这种方式我们不需要用apktool来反编译母包apk,所以步骤如下：

1.直接解压或者用7zip命名来动态修改assets中的渠道表示标示

2.用jarsigner.exe 和keystore或者jks来签名apk

3.最后再zipalign.exe优化apk,生成最终的渠道包

注意：因为渠道表示在assets目录下，所以不需要反编译和回编，但是还得重新签名和优化，因为只有修改META-INF目录下的资源才不用重新签名，所以该种方式比方式一要快

          方式三：该种方式是当前生成渠道包较快的方式，因为不需要反编译、回编、不需要重新签名，步骤：

1.直接解压或者用7zip命名来动态修改META-INF中的渠道表示标示
注意：该种方式打渠道较快

经过以上分析我们就可以结合javaGUI来制作我们的图形化工具了（其实就是对上述三种打包方式分析结合GUI的代码实现），这样我们就可以提供给运营人员来用了