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中进行以下配置:
权限配置
<uses-permission android:name="android.permission.READ_PHONE_STATE" /><uses-permission android:name="android.permission.INTERNET" /><uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /><uses-permission android:name="android.permission.ACCESS_WIFI_STATE" /><uses-permission android:name="android.permission.READ_LOGS" /><uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /><uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />
在Androidmanifest配置activity
<activity android:name="com.tencent.bugly.beta.ui.BetaActivity" android:configChanges="keyboardHidden|orientation|screenSize|locale" android:theme="@android:style/Theme.Translucent" />
留神:如果您想兼容Android N(Android 7.0)或者以上的设施,必须要在AndroidManifest.xml文件中配置FileProvider来访问共享门路的文件。
<provider android:name="androidx.core.content.FileProvider" android:authorities="com.ruan.mygitignore.fileprovider" android:exported="false" android:grantUriPermissions="true"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/provider_paths" /> </provider>
这里要留神一下,FileProvider类是在support-v4包中的,查看你的工程是否引入该类库。
在res目录新建xml文件夹,创立provider_paths.xml文件如下:
<?xml version="1.0" encoding="utf-8"?><paths xmlns:android="http://schemas.android.com/apk/res/android"> <!-- /storage/emulated/0/Download/${applicationId}/.beta/apk--> <external-path name="beta_external_path" path="Download/"/> <!--/storage/emulated/0/Android/data/${applicationId}/files/apk/--> <external-path name="beta_external_files_path" path="Android/data/"/></paths>
下面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中增加权限:
<uses-permission android:name="android.permission.READ_PHONE_STATE" /><uses-permission android:name="android.permission.INTERNET" /><uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /><uses-permission android:name="android.permission.ACCESS_WIFI_STATE" /><uses-permission android:name="android.permission.READ_LOGS" />
注:如果您的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”配置项:
<application <!-- 配置APP ID --> <meta-data android:name="BUGLY_APPID" android:value="<APP_ID>" /> <!-- 配置APP版本号 --> <meta-data android:name="BUGLY_APP_VERSION" android:value="<APP_Version>" /> <!-- 配置APP渠道号 --> <meta-data android:name="BUGLY_APP_CHANNEL" android:value="<APP_Channel>" /> <!-- 配置Bugly调试模式(true或者false)--> <meta-data android:name="BUGLY_ENABLE_DEBUG" android:value="<isDebug>" /></application>
不同于“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:最重要的就是不要去看远方含糊的,而要做手边分明的事