bugly开发文档地址:https://bugly.qq.com/docs/introduction/app-upgrade-introduction/?v=20180709165613;
我们在使用腾讯的bugly服务进行android版本的全量更新(应用升级)及热更新时,按照官方文档走基本上就能满足我们的日常开发需求;但是由于我们在研发的过程中,可能会由于自己的环境配置或者是其他的一些原因,会导致集成SDK失败,无法实现我们想要的效果,为了避免犯这样的错误,我将自己的集成过程做个记录。
在进行全量更新及热更新之前,我们需要去bugly平台注册自己的应用,获取注册时申请的APPID,bugly会根据这个id进行数据的下发:
1.登陆bugly成功后,点击新建产品,填写相应的产品信息即可完成应用的注册;
2.注册完成后,点击我的产品,找到我注册的应用点击后面的设置按钮即可找到我们需要的APPID;
一、全量更新(应用升级)
全量更新的原理在这里就不做介绍,有兴趣的可以查看源码进行了解,这里就简单的集成SDK以及实现应用升级下发做一个流程记录:
1、集成SDK有两种方式,一种是下载aar包,另外一种是添加依赖,我这里选择在app的gradle里添加依赖,配置如下:
2.权限设置
<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" />
3.配置Activity及FileProvider
<activity
android:name="com.tencent.bugly.beta.ui.BetaActivity"
android:configChanges="keyboardHidden|orientation|screenSize|locale"
android:theme="@android:style/Theme.Translucent" />
①
如果您想兼容Android N或者以上的设备,必须要在AndroidManifest.xml文件中配置FileProvider来访问共享路径的文件。
②如果你使用的第三方库也配置了同样的FileProvider, 可以通过继承FileProvider类来解决合并冲突的问题,示例如下:
<provider
android:name=".utils.BuglyFileProvider"
android:authorities="${applicationId}.fileProvider"
android:exported="false"
android:grantUriPermissions="true"
tools:replace="name,authorities,exported,grantUriPermissions">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/provider_paths"
tools:replace="name,resource"/>
</provider>
4.混淆配置
为了避免混淆SDK,在Proguard混淆文件中增加以下配置:
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}
-keep class android.support.**{*;}
5.初始化
①更新弹窗布局使用bugly提供的布局,false表示当前不是debug模式
Bugly.init(getApplicationContext(), "注册时申请的APPID", false);
②更新布局使用自己设计的布局,只需要将控件对应的tag标签和bugly提供的更新弹窗一致即可
6.发布升级:只需要在bugly平台应用列表点击自己的应用图标,进入到应用详情界面,点击右侧的应用升级即可发布新版本,新版本发布并启动之后,下发的是需要一定的时间,关闭原程序进程等待大概20分子左右就能收到更新弹窗信息
选择弹窗样式中,前三个代表选择bugly提供的样式,第四个表示选择自己绘制的弹窗样式;
创建策略完成后,我们需要启动我们的策略:
7.这样就完成了bugly的应用升级集成
8.当然我们也可以通过代码手动检测是否有新版本
Beta.getUpgradeInfo()方法返回值upgradeInfo用于获取当前是否有新版本,如果为null表示没有新版本,若不为null,我们可 以通过Beta.checkUpgrade()获取最新版本并下载;
二、热更新
1、在工程目录下“build.gradle”文件中添加依赖:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
google()
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:3.1.4'
classpath "com.tencent.bugly:tinker-support:1.1.2"//添加Bugly插件
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
google()
jcenter()
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}
2.在app module的“build.gradle”文件中添加(示例配置):
apply plugin: 'com.android.application'
apply from: 'tinker-support.gradle'//热更新插件
android {
compileSdkVersion 27
defaultConfig {
applicationId "com.cxc.demo.buglydemo"
minSdkVersion 15
targetSdkVersion 27
versionCode 1
versionName "1.0"
//设置支持的SO库架构
ndk {
abiFilters "armeabi", "armeabi-v7a", 'x86'
}
}
signingConfigs {
release {
storeFile file('bugly.jks')
storePassword "123456"
keyAlias "bugly"
keyPassword "123456"
}
debug {
storeFile file('debug.keystore')
storePassword "android"
keyAlias "androiddebugkey"
keyPassword "android"
}
}
//配置签名
buildTypes {
release {
signingConfig signingConfigs.release
//是否开启混淆
minifyEnabled true
//混淆规则
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
signingConfig signingConfigs.debug
}
}
}
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation 'com.android.support:appcompat-v7:27.1.1'
implementation 'com.android.support.constraint:constraint-layout:1.1.3'
/** **************************** 第三方服务 *******************************/
//latest.release指代最新的版本号
implementation 'com.tencent.bugly:crashreport_upgrade:latest.release'//bugly
implementation 'com.tencent.bugly:nativecrashreport:latest.release'//bugly
implementation "com.android.support:multidex:1.0.1" // 多dex配置
// 指定tinker依赖版本(注:应用升级1.3.5版本起,不再内置tinker)
implementation 'com.tencent.tinker:tinker-android-lib:1.9.9'
}
由于生成的apk和补丁包是需要通过gradle的指令执行的,所以在app的gralde中要把签名配置放到里面,这样才能生成签名过的文件;
3.在app下生成与build.gradle同级的tinker-support.gradle这个文件。
apply plugin: 'com.tencent.bugly.tinker-support'
def bakPath = file("${buildDir}/bakApk/")
/**
* 此处填写每次构建生成的基准包目录
*/
def baseApkDir = ""
// 用于生成基准包,为当前apk的版本号,生成补丁包时此内容要隐藏
def myTinkerId = "base-1.0.1" // 用于生成基准包(不用修改)
// 用于生成补丁包(每次生成补丁包都要修改一次,当前版本号后代补丁包的递增序列号),生成基准包补丁包要隐藏
//def myTinkerId = "patch-1.0.1.0.1"
/**
* 对于插件各参数的详细解析请参考
*/
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 = "${myTinkerId}"
// 构建多渠道补丁时使用
buildAllFlavorsDir = "${bakPath}/${baseApkDir}"
// 是否启用加固模式,默认为false.(tinker-spport 1.0.7起支持)
isProtectedApp = true
// 是否开启反射Application模式
enableProxyApplication = true
// 是否支持新增非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 {
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"
}
buildConfig {
keepDexApply = false
}
}
在这里需要着重说明一下,其他的配置都可以不用修改:
①def myTinkerId = "base-1.0.1" 生成基准包时需要把这个打开,1.0.1代表的是当前的版本号;
②def myTinkerId = "patch-1.0.1.0.1" 生成补丁包时需要把这个打开,要把①中的生成基准包的注释掉,1.0.1代表当前版本号,后面的.0.1代表补丁包的编号,我们用这个来区分当前的补丁;
③def baseApkDir = "" 具体的使用方法会在后面进行打包的时候进行描述,在没有生成基准包时,为空都没关系;
4.初始化SDK
由于我们在tinker-support.gradle中设置的enableProxyApplication = true,所以我们直接按照下面的方式初始化即可:
public class MyApplication extends Application{
@Override
public void onCreate() {
super.onCreate();
//可自定义布局,不写默认使用bugly的布局
// Beta.upgradeDialogLayoutId = R.layout.autoupdate_dialog_layout;
Bugly.init(getApplicationContext(), "cecee4d6ec", false);
}
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
// 安装tinker
Beta.installTinker();
}
}
5.AndroidManifest.xml配置和全量更新内容一致,这里就不做过多介绍了;
6.由于我们在app的gradle下开启了混淆,故在proguard-rules.pro中添加混淆配置
#bugly混淆
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}
# tinker混淆规则
-dontwarn com.tencent.tinker.**
-keep class com.tencent.tinker.** { *; }
-keep class android.support.**{*;}
7.接下来是重头戏,打基准包以及补丁包,并发布
①基准包
点击thinker-support.gradle,这时候由于是生成基准包,所以baseApkDir为空也没关系,点击右侧的gradle然后在build文件夹下找到assembleRelase进行打包
打包成功后,我们可以在左侧的bakApk文件夹下找到我们基准包的目录,其中mapping为混淆文件,app-release.apk就是我们需要的基准包;
由于这个build下的文件我们在进行编译的时候会把他清除了,而我们进行补丁包的打包时,必须要和这个基准包的目录和基准包下面的文件进行比对才能生成补丁包,所以app-1011-17-36-41目录我们要找个地方存起来,直到我们发布新版本,里面的apk我们可以经过乐固等加密工具进行加密,然后同全量更新的发布步骤进行发布,并启动;
②补丁包
打补丁包需要在基准包的基础上进行打包,我们在打包基准包成功之后已经把文件夹存储下来了,那么我们检查一下左侧的build-bakApk是否有该文件夹,如果没有我们要把他拖放进去,然后如图打补丁包
打补丁包成功后如下图
打开bugly平台,找到应用升级,打开热更新,发布补丁包,立即下发,过个几分钟就会下发到你的需要打补丁的用户的手机上了
当我们发布的补丁包发现有问题的时候需要回撤到之前的状态,我们可以点击右侧的撤回按钮,用户就算更新了补丁包之后也会回撤到之前没有更新补丁包的状态: