关于android的更新，我了解到的方法有：
1、在应用市场，发布新版本
2、使用Bugly的全量更新（应用升级）
3、Bugly的热更新

1、应用升级、热更新（Bugly）

1、介绍

升级功能是专为App的灰度升级而开发的组件，在bugly内测页面配置好App的更新策略，策略指定的老版本App在启动时会自动检测更新并提示升级，为团队的应用分发，灰度内测提供一站式解决方案。

使用热更新（Bugly -微信Tinker），无需重新发版就可以使开发者紧急修复bug。使用Bugly 可以实现自动下载补丁包、合成、并应用补丁的功能，并且Bugly也提供了热更新管理后台让开发者对每个版本补丁进行管理。

2、集成

** 1、第一步：添加插件依赖**
在工程根目录下“build.gradle”文件中添加：

buildscript {
   ...
   dependencies {
       // tinkersupport插件
       classpath "com.tencent.bugly:tinker-support:1.0.7"
   }

}

** 2、第二步：集成SDK**
gradle配置
在app module的“build.gradle”文件中添加：

dependencies {
         compile 'com.tencent.bugly:crashreport_upgrade:1.3.0'
}

依赖插件脚本
在app module的“build.gradle”文件中添加：

 // 依赖插件脚本
 apply from: 'tinker-support.gradle'

tinker-support.gradle内容如下所示：

注：需要在同级目录下创建tinker-support.gradle这个文件。

apply plugin: 'com.tencent.bugly.tinker-support'

def bakPath = file("${buildDir}/bakApk/")
//在做补丁 的时候，需要修改这个
def appName = "app-0111-15-18-41"

/**
* 对于插件各参数的详细解析请参考
*/
tinkerSupport {

   // 开启tinker-support插件，默认值true
   enable = true

   // 指定归档目录，默认值当前module的子目录tinker
   autoBackupApkDir = "${bakPath}"

   // 是否启用覆盖tinkerPatch配置功能，默认值false
   // 开启后tinkerPatch配置不生效，即无需添加tinkerPatch
   overrideTinkerPatchConfiguration = true

   // 编译补丁包时，必需指定基线版本的apk，默认值为空
   // 如果为空，则表示不是进行补丁包的编译
   // @{link tinkerPatch.oldApk }
   baseApk =  "${bakPath}/${appName}/app-release.apk"

   // 对应tinker插件applyMapping
   baseApkProguardMapping = "${bakPath}/${appName}/app-release-mapping.txt"

   // 对应tinker插件applyResourceMapping
   baseApkResourceMapping = "${bakPath}/${appName}/app-release-R.txt"

   // 当前版本唯一标识
   //base：基线版本，patch：补丁
   tinkerId = "1.0.1-base"

   //多渠道
   //buildAllFlavorsDir="${bakPath}/${appName}"
   // 是否开启代理Application，设置之后无须改造Application，默认为false
   enableProxyApplication = false
}

** 3、添加权限、修改Application...**

3、打包

1、编译基准包
配置基准包的tinkerId

// 唯一标识当前版本
tinkerId = "1.0.1-base"

执行assembleRelease，编译生成基准包；在build/outputs/bakApk路径下生成每次编译的基准包、混淆配置文件、资源Id文件，如下图所示：

**执行assembleRelease**，编译生成基准包

![生成的基准包]A)PZ@YU5.png](https://img.haomeiwen.com/i2206304/493c1170c2f3e91b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

启动apk，上报联网数据
我们每次冷启动都会请求补丁策略，会上报当前版本号和tinkerId，这样我们后台就能将这个唯一的tinkerId对应到一个版本

2.1、应用升级

应用升级

2.2、对基线版本的bug修复，根据基线版本生成补丁包

修改待修复apk路径、mapping文件路径、resId文件路径，即修改3与2相同：

修改路径

执行tinkerPatchRelease，就能生成release编译环境的补丁包。

生成的补丁包在build/outputs/patch目录下：

补丁位置

3、上传补丁包到平台
上传patch_signed_7zip.apk

4、

app module的“build.gradle”文件：

apply plugin: 'com.android.application'
android {
   compileSdkVersion 24
   buildToolsVersion "24.0.2"

   // 签名配置
   signingConfigs {
       release {
           try {
               storeFile file("./keystore/buglyTest.jks")
               storePassword "111111"
               keyAlias "key"
               keyPassword "111111"
           } catch (ex) {
               throw new InvalidUserDataException(ex.toString())
           }
       }

       debug {
           storeFile file("./keystore/debug.keystore")
       }
   }

   defaultConfig {
       applicationId "com.buglydemo.buglytest"
       minSdkVersion 22
       targetSdkVersion 24
       versionCode 2
       versionName "1.0.1"

       // 开启multidex，可以生成多个dex，防止方法数超过限定（65k）
       multiDexEnabled true
   }
   //构建类型
   buildTypes {
       release {
           //不混淆
           minifyEnabled false
           proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
           //签名
           signingConfig signingConfigs.release
       }
       debug {
           debuggable true
           minifyEnabled false
           signingConfig signingConfigs.debug
       }
   }
   //跳过编译警告
   lintOptions {
       checkReleaseBuilds false
       abortOnError false
   }
}

dependencies {
   compile fileTree(dir: 'libs', include: ['*.jar'])
   testCompile 'junit:junit:4.12'
   compile 'com.android.support:appcompat-v7:24.2.1'

   compile "com.android.support:multidex:1.0.1" // 多dex配置
   compile 'com.tencent.bugly:crashreport_upgrade:latest.release'//其中latest.release指代最新版本号，也可以指定明确的版本号，例如1.2.0
}

apply from: 'tinker-support.gradle'

</br>

参考：
Bugly Android热更新使用指南、Bugly Android热更新详解、微信Android热补丁实践演进之路、解决Android方法数超出限定的问题

在编译时通过新旧两个Dex生成差异path.dex。在运行时，将差异patch.dex重新跟原始安装包的旧Dex还原为新的Dex。

坑

在使用bugly时，要注意它的版本，如果版本不一致，有些效果就不一样...

2、多渠道打包

2-1、多渠道打包-Flavors

在app module的“build.gradle”文件中添加：

android {
   ...
   defaultConfig {
       ...
       manifestPlaceholders = [ CHANNEL_VALUE:"default_channel" ]
   }
   productFlavors {
       default_channel{
       }
       yingyongbao {
       }
       open360 {
       }
       baidu {
       }
   }
   productFlavors.all{flavor->
       flavor.manifestPlaceholders=[CHANNEL_VALUE:name]
   }
}

tinker-support.gradle文件中添加：

tinkerSupport {
   ...
   buildAllFlavorsDir="${bakPath}/${appName}"
}

在AndroidManifest.xml中添加：

       <meta-data
           android:name="BaiduMobAd_CHANNEL"
           android:value="${CHANNEL_VALUE}" />

执行assembleRelease，会自动生成渠道包

渠道包

会自动在AndroidManifest.xml中添加渠道和tinkerId

bugly_channel、tinker_id

之后就可以把渠道包分别进行加固上传了...

1、应用升级

在应用升级的时候，可以根据版本、渠道、网络环境控制新版本的下发

下发条件-渠道

2、热更新

执行

2-2、多渠道打包 walle

1、配置

1、创建multiple-channel.gradle

apply plugin: 'walle'
walle {
   // 指定渠道包的输出路径
   apkOutputFolder = new File("${project.buildDir}/outputs/channels");
   // 定制渠道包的APK的文件名称
   apkFileNameFormat = '${appName}-${channel}-${buildType}-v${versionName}.apk';
   // 渠道配置文件
   channelFile = new File("${project.getProjectDir()}/channel")
}

2、配置build.gradle
在根目录 build.gradle 文件中添加：

buildscript {
   dependencies {
       classpath 'com.meituan.android.walle:plugin:1.1.3'
   }
}

并在当前app的 build.gradle中添加：

dependencies {
   compile 'com.meituan.android.walle:library:1.1.3'
}
// 多渠道使用walle示例（注：多渠道使用）
apply from: 'multiple-channel.gradle'

3、创建渠道文件channel

渠道文件

2、生成渠道包

生成渠道包的方式是和assemble${variantName}Channels指令结合，渠道包的生成目录默认存放在 build/outputs/apk/，也可以通过walle闭包中的apkOutputFolder参数来指定输出目录

gradle assembleReleaseChannels

渠道包

3、获取渠道信息

String channel = WalleChannelReader.getChannel(getApplication());

4、一个补丁修复所有渠道

在打渠道包的过程，因为会走编译流程，热更新插件也会在bakApk生成对应的基线版本，这个跟普通打包就没有差别了：

一个补丁修复所有渠道

只需要上传补丁包到补丁管理后台，然后下发即可。

来自于：Bugly 多渠道热更新解决方案

坑

如果把渠道包直接用工具进行加固，可能会粗错...

3、乐固+walle？

乐固 的 自助加固工具，在签名的时候采用的是v1签名，而渠道包生成工具walle，不支持V1签名方案，需要在APK Signature Scheme V2签名下才能生成渠道包。可以利用zipalign和apksigner对加固的apk进行v2签名，之后在多渠道打包。

1、检测APK的签名状态，工具地址：Android-GetAPKInfo

java -jar CheckAndroidV2SignatureByAPKSig.jar app-release.apk

正常打包一个release版，其签名状态：

release版

2、加固，可以先不设置签名和渠道

加固
使用不签名的加固

3、使用Android SDK中的zipalign - 对齐操作 - 优化

1、打开CMD，进入Android SDK -> build-tools -> 25.+目录
2、执行命令：zipalign -v 4 [待优化.apk路径] [优化后.apk路径]

zipalign -v 4 app-baidu-release-v2.7.2_legu.apk liyi.apk

优化

4、使用 apksigner 签名

1、打开CMD，进入Android SDK -> build-tools -> 25.+目录
2、执行命令：apksigner sign --ks [你的签名文件] [apk路径]，之后会输入签名文件密码。

apksigner sign --ks aishengjianshen.keystore app-release_legu_self_sign.apk

签名 重新签名之后的apk的状态

5、使用walle打渠道包

java -jar walle-cli-all.jar batch -c yingyongbao,open360,baidu app-release_legu_self_sign.apk

参考1-方法：Meituan-Dianping/walle、Android-GetAPKInfo、Android 7.0多渠道打包Signature Scheme v2签名失效、Bugly 多渠道热更新解决方案、Bugly-热更新
参考2-原理：新一代开源Android渠道包生成工具Walle、Android 新一代多渠道打包神器
参考的例子：Bugly-Android-Demo