Android Bugly集成升级，Crash上报和热更新方案
一：介绍
腾讯的开放给开发者的一种平台服务，主要用于android和ios平台上的移动应用的crash和卡顿检测和快速定位以及提供解决方案。是免费服务。
用过还知道，除了crash检测外，bugly还提供应用内升级和热修复Tinker
故：提供三种，崩溃日志收集，应用内升级和热修复
二：应用升级
应为我这个应用使用了这个，Bugly 应用升级服务为您的应用版本配置升级提醒，并可对用户范围及数量进行精准控制，多纬度数据监控，实时了解版本转化率。
升级功能是专为App的灰度升级而开发的组件，在bugly内测页面配置好App的更新策略，策略指定的老版本App在启动时会自动检测更新并提示升级，为团队的应用分发，灰度内测提供一站式解决方案。
第一步：gradle 配置方案
在app下的build.gradle添加
//当我们集成了，升级的功能就不用集成crash上报功能
//原因：升级SDK已经集成crash上报功能，已经集成Bugly的用户需要注释掉原来Bugly的jcenter库
//注释掉原来的bugly的carsh仓库
//implementation 'com.tencent.bugly:crashreport:latest.release'//这是上报功能集成
implementation 'com.tencent.bugly:crashreport_upgrade:1.4.2'//这个应用升级的集成
// implementation 'com.tencent.bugly:crashreport_upgrade:latest.release'//其中latest.release指代最新版本号，也可以指定明确的版本号，例如1.2.0，现在升级最新版本1.5.23还有要注意的：
已经配置过符号表的Bugly用户保留原有符号表配置； 尊敬的用户，因系统功能调整，符号表上传不再支持老版本(小于3.3.4)上传，请使用最新版本上传工具3.3.4。
Bugly SDK（2.1.5及以上版本）已经将Java Crash和Native Crash捕获功能分开，如果想使用NDK库，需要配置： compile 'com.tencent.bugly:nativecrashreport:latest.release'
第一步：还可以使用aar包配置使用
SDK下载，放在libs目录下
repositories {
flatDir {
dirs 'libs'
}
}
dependencies {
implementationfileTree(dir: 'libs', include: ['*.jar'])
implementation(name:'bugly_crashreport_upgrade-1.5.23',ext:'aar')//aar依赖添加
}注：升级SDK自1.2.0版本将不再支持Eclipse集成方式，建议使用gradle远程仓库集成和aar导入集成。
第二步：参数配置
在AndroidMainfest.xml中进行以下配置：
权限配置
在Androidmanifest配置activity
注意：如果您想兼容Android N(Android 7.0)或者以上的设备，必须要在AndroidManifest.xml文件中配置FileProvider来访问共享路径的文件。
这里要注意一下，FileProvider类是在support-v4包中的，检查你的工程是否引入该类库。
在res目录新建xml文件夹，创建provider_paths.xml文件如下：
上面Android 7.0对私有文件访问的约束
但是：注：1.3.1及以上版本，可以不用进行以上配置，aar已经在AndroidManifest配置了，并且包含了对应的资源文件。
第三步：
Buly注册
private void initBugly(boolean isDebug, String channel) {
//这里可以看bugly文档Android 应用升级SDK高级配置
BuglyStrategy buglyStrategy = new BuglyStrategy();
buglyStrategy.setAppChannel(channel);
// buglyStrategy.setAppChannel("sodao");
Beta.autoInit = true;//自动初始化开关true表示app启动自动初始化升级模块
Beta.largeIconId = R.mipmap.login_icon;//设置通知栏大图标
Beta.smallIconId = R.mipmap.login_icon;//设置状态栏小图标
Beta.enableNotification = true;//设置是否显示消息通知
Beta.enableHotfix = false;//关闭热更新能力,升级SDK默认是开启热更新能力的，如果你不需要使用热更新，可以将这个接口设置为false。
Beta.autoCheckUpgrade = !BuildConfig.DEBUG;//自动检查更新开关,true表示初始化时自动检查升级
if (isDebug) {
Bugly.setIsDevelopmentDevice(context, true);
}
Bugly.init(getApplicationContext(), BuildConfig.APPID_BUGLY, isDebug, buglyStrategy);
}
//BuildConfig.APPID_BUGLY,这个传进入就是appId
代码混淆设置
为了避免混淆SDK，在Proguard混淆文件中增加以下配置：
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}
-keep class android.support.**{*;}三：Crash异常上报
Bugly支持自动集成和手动集成两种方式，如果您使用Gradle编译Apk，我们强烈推荐您使用自动接入方式配置库文件。
第一步：
第一种方式Gradle自动集成
集成SDK
在Module的build.gradle文件中添加依赖和属性配置：
dependencies {
implementation'com.tencent.bugly:crashreport:latest.release' //其中latest.release指代最新Bugly SDK版本号，也可以指定明确的版本号，例如2.2.0，现在最新版本是3.3.9
}第二种方式Jar包依赖
在app下的build.gradle下
android{
。。。。。
sourceSets {
main {
jniLibs.srcDirs = ['libs']
}
}
}
dependencies {
implementation files('libs\\bugly_crash_release.jar')
}第二步：参数配置
在AndroidManifest.xml中添加权限：
注：如果您的App需要上传到google play store，您需要将READ_PHONE_STATE权限屏蔽掉或者移除，否则可能会被下架。
请避免混淆Bugly，在Proguard混淆文件中增加以下配置：
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}第三步：初始化
获取APP ID并将以下代码复制到项目Application类onCreate()中，Bugly会为自动检测环境并完成配置：
CrashReport.initCrashReport(getApplicationContext(), "注册时申请的APPID", false); 为了保证运营数据的准确性，建议不要在异步线程初始化Bugly。
第三个参数为SDK调试模式开关，调试模式的行为特性如下：
输出详细的Bugly SDK的Log；
每一条Crash都会被立即上报；
自定义日志将会在Logcat中输出。
此外，Bugly2.0及以上版本还支持通过“AndroidManifest.xml”来配置APP信息。如果同时又通过代码中配置了APP信息，则最终以代码配置的信息为准。
在“AndroidManifest.xml”的“Application”中增加“meta-data”配置项：
不同于“android:versionName”，“BUGLY_APP_VERSION”配置的是Bugly平台的APP版本号。
通过“AndroidManifest.xml”配置后的初始化方法如下：
CrashReport.initCrashReport(getApplicationContext());
高级使用
UserStrategy strategy = new UserStrategy(appContext);
//...在这里设置strategy的属性，在bugly初始化时传入
//...
strategy.setAppChannel("myChannel"); //设置渠道
strategy.setAppVersion("1.0.1"); //App的版本
strategy.setAppPackageName("com.tencent.xx"); //App的包名
CrashReport.initCrashReport(appContext, APPID, true, strategy);四：Bugly的符号表
符号表是内存地址与函数名、文件名、行号的映射表。符号表元素如下所示：
<起始地址> <结束地址> <函数> [<文件名:行号>]
为什么要配置符号表？
为了能快速并准确地定位用户APP发生Crash的代码位置，Bugly使用符号表对APP发生Crash的程序堆栈进行解析和还原。
五：Bugly热更新
热更新能力是Bugly为解决开发者紧急修复线上bug，而无需重新发版让用户无感知就能把问题修复的一项能力。Bugly目前采用微信Tinker的开源方案，开发者只需要集成我们提供的SDK就可以实现自动下载补丁包、合成、并应用补丁的功能，我们也提供了热更新管理后台让开发者对每个版本补丁进行管理。
第一步：添加插件依赖
工程根目录下“build.gradle”文件中添加：
buildscript {
repositories {
jcenter()
}
dependencies {
// tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明确版本号，例如1.0.4
classpath "com.tencent.bugly:tinker-support:1.1.5"
}
}注意：自tinkersupport 1.0.3版本起无需再配tinker插件的classpath。(最新版本1.2.3 )
版本对应关系:
tinker-support 1.1.3 对应 tinker 1.9.8
tinker-support 1.1.2 对应 tinker 1.9.6
tinker-support 1.1.1 对应 tinker 1.9.1
tinker-support 1.0.9 对应 tinker 1.9.0
tinker-support 1.0.8 对应 tinker 1.7.11
tinker-support 1.0.7 对应 tinker 1.7.9
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”文件中添加（示例配置）：
dependencies {
implementation 'com.tencent.bugly:crashreport_upgrade:1.4.2'//升级依赖
// 指定tinker依赖版本（注：应用升级1.3.5版本起，不再内置tinker）
implementation 'com.tencent.tinker:tinker-android-lib:1.9.9'//热更新tinker使用
}在app module的“build.gradle”文件中添加：
需要同级别目录下创建一个gradle
Flie-->new file :thinker-support.gradle
tinker-support.gradle内容如下所示（示例配置）：
注：您需要在同级目录下创建tinker-support.gradle这个文件哦。
apply plugin: 'com.tencent.bugly.tinker-support'
def bakPath = file("${buildDir}/bakApk/")
/**
* 此处填写每次构建生成的基准包目录
*/
def baseApkDir = "app-0208-15-10-00"
/**
* 对于插件各参数的详细解析请参考
*/
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.1"
// 构建多渠道补丁时使用
// buildAllFlavorsDir = "${bakPath}/${baseApkDir}"
// 是否启用加固模式，默认为false.(tinker-spport 1.0.7起支持）
// isProtectedApp = true
// 是否开启反射Application模式
enableProxyApplication = false
// 是否支持新增非export的Activity（注意：设置为true才能修改AndroidManifest文件）
supportHotplugComponent = true
}
/**
* 一般来说,我们无需对下面的参数做任何的修改
* 对于各参数的详细介绍请参考:
* https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97
*/
tinkerPatch {
//oldApk ="${bakPath}/${appName}/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的分配
}
}具体可以参考http://bugly.qq.com/docs/user...
END:最重要的就是不要去看远方模糊的，而要做手边清楚的事