腾讯Bugly热更新集成以及问题

前言

热更新能力是Bugly为解决开发者紧急修复线上bug，而无需重新发版让用户无感知就能把问题修复的一项能力。Bugly目前采用微信Tinker的开源方案，开发者只需要集成我们提供的SDK就可以实现自动下载补丁包、合成、并应用补丁的功能，我们也提供了热更新管理后台让开发者对每个版本补丁进行管理。

Tinker是什么：

Tinker是微信官方的Android热补丁解决方案，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新。当然，你也可以使用Tinker来更新你的插件。

为什么使用Tinker：

当前市面的热补丁方案有很多，其中比较出名的有阿里的AndFix、美团的Robust以及QZone的超级补丁方案。但它们都存在无法解决的问题，Tinker我们不仅可以用做bugfix,甚至可以替代功能的发布。Tinker已运行在微信的数亿Android设备上，那么为什么你不使用Tinker呢？

Tinker热更新的优势

接入Bugly热更新  接入了热更新就已经接入了异常上报了，所有就不需要在进行异常上报的接入了。

第一步：添加插件依赖

工程根目录下“build.gradle”文件中添加：

buildscript{repositories{  

      jcenter()   

 }dependencies{

// tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明确版本号，例如1.0.4

     classpath"com.tencent.bugly:tinker-support:latest.release"

}

}

版本对应关系:

tinker-support 1.0.5 对应 tinker 1.7.8（支持部分加固app的热更新）

tinker-support 1.0.4 对应 tinker 1.7.7

tinker-support 1.0.3 对应 tinker 1.7.6

tinker-support 1.0.2 对应 tinker 1.7.5（需配置tinker插件的classpath）

第二步：集成SDK

gradle配置

在app module的“build.gradle”文件中添加（示例配置）：

android {      

  defaultConfig {          

ndk {

//设置支持的SO库架构

abiFilters'armeabi'//, 'x86', 'armeabi-v7a', 'x86_64', 'arm64-v8a'}        }      }

dependencies{

// 多dex配置//注释掉原有bugly的仓库  必须依赖multidex才可以使用 MultiDex.install(base);

compile"com.android.support:multidex:1.0.1" 

//其中latest.release指代最新版本号，也可以指定明确的版本号，例如1.2.0

compile'com.tencent.bugly:crashreport_upgrade:latest.release'

'//其中latest.release指代最新版本号，也可以指定明确的版本号，例如2.2.0

compile'com.tencent.bugly:nativecrashreport:latest.release

}

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

// 依赖插件脚本

applyfrom:'tinker-support.gradle'

tinker-support.gradle内容如下所示（示例配置）：

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

applyplugin:'com.tencent.bugly.tinker-support'

defbakPath = file("${buildDir}/bakApk/")

/**

*此处填写每次构建生成的基准包目录  根据下面的基准包生成对应的补丁包

*/

defbaseApkDir ="app-0507-11-13-19"

/**

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

*/

tinkerSupport {

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

enable =true

//指定归档目录，默认值当前module的子目录tinker

autoBackupApkDir ="${bakPath}"

//是否启用覆盖tinkerPatch配置功能，默认值false

//开启后tinkerPatch配置不生效，即无需添加tinkerPatch

overrideTinkerPatchConfiguration =true

//编译补丁包时，必需指定基线版本的apk，默认值为空

//如果为空，则表示不是进行补丁包的编译

// @{link tinkerPatch.oldApk }

baseApk ="${bakPath}/${baseApkDir}/app-release.apk"

//对应tinker插件applyMapping

baseApkProguardMapping ="${bakPath}/${baseApkDir}/app-release-mapping.txt"

//对应tinker插件applyResourceMapping

baseApkResourceMapping ="${bakPath}/${baseApkDir}/app-release-R.txt"

//构建基准包和补丁包都要指定不同的tinkerId，并且必须保证唯一性

 tinkerId = "base-1.0.4"      //生成对于的基包版本  只有生成基准包的时候使用

//tinkerId ="patch-1.0.4"     //对于生成的补丁包版本  只有生成补丁包的时候使用

//构建多渠道补丁时使用 

// buildAllFlavorsDir = "${bakPath}/${baseApkDir}"

//支持加固需要添加的属性  1.7.8以后才可以使用的

isProtectedApp =true

//是否开启反射Application模式   这里有2中情况 

enableProxyApplication =true

}

/**

*一般来说,我们无需对下面的参数做任何的修改

*对于各参数的详细介绍请参考:

* https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97

*/

tinkerPatch {

oldApk ="${bakPath}/${baseApkDir}/app-release.apk"

ignoreWarning =false

useSign =true

dex {

dexMode ="jar"

pattern = ["classes*.dex"]

loader = []

}

lib {

pattern = ["lib/*/*.so"]

}

res {

pattern = ["res/*","r/*","assets/*","resources.arsc","AndroidManifest.xml"]

ignoreChange = []

largeModSize =100

}

packageConfig {

}

sevenZip {

zipArtifact ="com.tencent.mm:SevenZip:1.1.10"

//        path = "/usr/local/bin/7za"

}

buildConfig {

keepDexApply =false

//tinkerId = "1.0.1-base"

//applyMapping = "${bakPath}/${appName}/app-release-mapping.txt" //可选，设置mapping文件，建议保持旧apk的proguard混淆方式

//applyResourceMapping = "${bakPath}/${appName}/app-release-R.txt" //可选，设置R.txt文件，通过旧apk文件保持ResId的分配

}

}

第三步：初始化SDK

enableProxyApplication = false 的情况

这是Tinker推荐的接入方式，一定程度上会增加接入成本，但具有更好的兼容性。

集成Bugly升级SDK之后，我们需要按照以下方式自定义ApplicationLike来实现Application的代码（以下是示例）：

自定义Application

public class SampleApplication extends TinkerApplication {

/*注意：这个类集成TinkerApplication类，这里面不做任何操作，所有Application的代码都会放到ApplicationLike继承类当中

参数解析

参数1：tinkerFlags表示Tinker支持的类型dex only、library only or all suuport，default: TINKER_ENABLE_ALL

参数2：delegateClassName Application代理类 这里填写你自定义的ApplicationLike

参数3：loaderClassName Tinker的加载器，使用默认即可

参数4：tinkerLoadVerifyFlag加载dex或者lib是否验证md5，默认为false*/

publicSampleApplication() {

super(TINKER_ENABLE_ALL,"com.bugly.smile.buglydemo.SampleApplicationLike","com.tencent.tinker.loader.TinkerLoader", false);

}

}

自定义的ApplicationLike

public class SampleApplicationLike extends DefaultApplicationLike {

public static finalStringTAG="Tinker.SampleApplicationLike";

public SampleApplicationLike (Application application, inttinkerFlags,

booleantinkerLoadVerifyFlag, longapplicationStartElapsedTime,

longapplicationStartMillisTime,Intent tinkerResultIntent) {

super(application,tinkerFlags,tinkerLoadVerifyFlag,applicationStartElapsedTime,applicationStartMillisTime,tinkerResultIntent);

}

@Override

public voidonCreate() {

super.onCreate();

//这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId

//调试时，将第三个参数改为true

Bugly.init(getApplication(),"<申请的APPID>", false);

}

@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)

@Override

public voidonBaseContextAttached(Context base) {

super.onBaseContextAttached(base);

// you must install multiDex whatever tinker is installed!

MultiDex.install(base);

//安装tinker

// TinkerManager.installTinker(this);替换成下面Bugly提供的方法

Beta.installTinker(this);

}

@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)publicvoidregisterActivityLifecycleCallback(Application.ActivityLifecycleCallbacks callbacks){

getApplication().registerActivityLifecycleCallbacks(callbacks);

}

}

注意：tinker需要你开启MultiDex,你需要在dependencies中进行配置compile "com.android.support:multidex:1.0.1"才可以使用MultiDex.install方法； SampleApplicationLike这个类是Application的代理类，以前所有在Application的实现必须要全部拷贝到这里，在onCreate方法调用SDK的初始化方法，在onBaseContextAttached中调用Beta.installTinker(this);

enableProxyApplication = true 的情况

public class MyApplication extends Application {

@Override

public voidonCreate() {

super.onCreate();

//设置为开发设备 注意这个必须在初始化Bugly之前设置为开发设备

Bugly.setIsDevelopmentDevice(this, true);

//这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId

//调试时，将第三个参数改为true  打印Log的开关

Bugly.init(this,"申请的appId", false);

//异常展示时候，建议设置为手机号码，方便后期Bug的修复

CrashReport.setUserId(this,"你需要作为UseId的参数"); 

}

@Override

protected voidattachBaseContext(Context base) {

super.attachBaseContext(base);

// you must install multiDex whatever tinker is installed!

MultiDex.install(base);

//安装tinker

Beta.installTinker();

}

}

注：无须你改造Application，主要是为了降低接入成本，我们插件会动态替换AndroidMinifest文件中的Application为我们定义好用于反射真实Application的类

最后只需要在AndroidManifest文件中将Application替换上就可以使用了。

第四步：AndroidManifest.xml配置

1. 权限配置

<uses-permissionandroid:name="android.permission.READ_PHONE_STATE"/>

<uses-permissionandroid:name="android.permission.INTERNET" />

<uses-permissionandroid:name="android.permission.ACCESS_NETWORK_STATE" />

<uses-permissionandroid:name="android.permission.ACCESS_WIFI_STATE"/>

<uses-permissionandroid:name="android.permission.READ_LOGS"/>

<uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

<uses-permissionandroid:name="android.permission.READ_EXTERNAL_STORAGE"/>

第五步：混淆配置

为了避免混淆SDK，在Proguard混淆文件中增加以下配置：

-dontwarn com.tencent.bugly.**

-keep public class com.tencent.bugly.**{*;}

如果你使用了support-v4包，你还需要配置以下混淆规则：

-keep class android.support.**{*;}

到这里为止 Bugly热更新就已经完成了，下面就是如何使用了，我们需要验证热更新的能力：

注意tinker无法使用热更新修复的情况：

由于原理与系统限制，Tinker有以下已知问题：

Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大组件；

由于Google Play的开发者条款限制，不建议在GP渠道动态更新代码；

在Android N上，补丁对应用启动时间有轻微的影响；

不支持部分三星android-21机型，加载补丁时会主动抛出"TinkerRuntimeException:checkDexInstall failed"；

对于资源替换，不支持修改remoteView。例如transition动画，notification icon以及桌面图标。

验证Bugly热更新 必须在联网的情况下才可以使用热更新

普通打包

1、编译基准包

配置基准包的tinkerId （注意这里的base版本必须联网上报 才可以上传补丁包）

设置你的基准版本号 最好是和app version对应

Bugly基线版本

执行assembleRelease编译生成基准包： 

在android studio的右边选择gradle找到我们接入热更新的model 进入build中选择生成的基准包类型：这里可以是Release和Debug版本 

生成基准包

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

生成的基准Apk目录

这里面有的app-release.apk就是我们需要上线的基线版本，请注意保存线上发布版本的基准apk包、mapping文件、R.txt文件，如果线上版本有bug，就可以借助我们tinker-support插件进行补丁包的生成。

如果你没有开启混淆是不会有mapping.txt文件的，需要在Moudle的build.g'radle文件中开启混淆

开启基线混淆

   如何生成签名文件这里就不介绍了。

2、对基线版本的bug修复

上面生成了base包了，那就需要去生成patch包了。

基准包的代码：

base包的代码

补丁包（patch）的代码：

pacth代码

3、根据基线版本生成补丁包

这里需要注意的：基准包目录必须是你上次生成的base包，注意这里是按照时间命名的，检查是否正确，tinkerId 需要生成patch包必须使用 tinkerId="patch-base版本号对应"

patch补丁生成配置

执行构建补丁包的task

patch补丁包的task

如果你要生成不同编译环境的补丁包，只需要执行TinkerSupport插件生成的task，比如buildTinkerPatchRelease就能生成release编译环境的补丁包。

生成的补丁包在build/outputs/patch目录下，其中7zip.apk就是我们需要使用的补丁包：

补丁包目录

打开补丁包可以看到里面会有一个YAPATCH.MF，这里面包含了我们是从base版本到patch版本：以及app的version信息

补丁包

4、上传补丁包到平台

进入到对应appid的app中，选择应用升级，热更新，发布新补丁。

发布patch版本，选择补丁文件之后会自动从补丁包的YAPATCH.MF去寻找base版本以及app版本，注意这里的base版本必须联网上报（必须在联网的情况下启动app），才可以上传补丁成功。如果没有

上传补丁包

上传了补丁包可以选择下发的范围：

开发设备：仅仅针对设置了开发设备。

利用代码：Bugly.setIsDevelopmentDevice(this, true);设置为开发者设备。

全量设备：针对所有的用户。

自定义：可以设置下发范围:随机下发设置的版本数量，还可以设置android版本范围，仅仅在这个范围内才会下发并且生效。

下发补丁之后：

下发补丁的撤回

里面包括了激活的用户数量以及下发的数量，在操作过程中我们可能对于上个补丁不太满意，我们需要发布一个新的补丁，bugly提供了2中操作。

停止下发：点击之后将不会在下发bugly补丁，但是之前已经下载并且激活的不会删除掉补丁。

撤回：点击之后将停止下发补丁，并且之前已经下载并且激活的用户将会删除掉补丁包，并且恢复到基准包的版本。

检查patch包是否生效：

基准包执行效果图：

基准包效果图

修复之后的效果图：

补丁合成效果图

不能立即生效，需要吧app至于后台一段时间才能生效。

如果你的手机root的话，可以在data/data/app包名目录下有一个tinker目录，里面就有对于的patch补丁包下载在里面。

补丁包生效统计

如果用户以及补丁下载成功以及激活的都会有统计的。

热更新加固：

之前的tinker只有1.7.5之前支持加固，tinker 1.7.8 可以通过 isProtectedApp 开启加固支持，这种模式仅仅可以使用在加固应用中。

isProtectedApp=true  

加固厂商                         测试

腾讯云·乐固                  Tested

爱加密                           Tested

梆梆加固                        Tested

360加固暂不支持，需要等待新版本发布

其他请自行测试，只要满足下面规则的都可以支持

最后附上自己在github上面的BuglyDemo。

https://github.com/caoyuanxiao/BuglyDemo.git