Android 腾讯Bugly 热更新

这个是一位大佬教我的，我自己照着做写博客

热更新虽然看起来很复杂，但是Bugly通过集成，使得这个过程很简单。我这里不涉及多渠道热更新，只讲述最简单的情况。

1.首先我们需要在Bugly上有个应用这个不就不多说，我的上一篇博客写了，大家可以去参考
http://blog.csdn.net/z979451341/article/details/78696789

2.配置环境

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

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        // tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明确版本号，例如1.0.4
        classpath "com.tencent.bugly:tinker-support:1.0.8"
    }
}

gradle配置

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

  android {
        defaultConfig {
          ndk {
            //设置支持的SO库架构
            abiFilters ‘armeabi‘ //, ‘x86‘, ‘armeabi-v7a‘, ‘x86_64‘, ‘arm64-v8a‘
          }
        }
      }
      dependencies {
          compile "com.android.support:multidex:1.0.1" // 多dex配置
          //注释掉原有bugly的仓库
          //compile ‘com.tencent.bugly:crashreport:latest.release‘//其中latest.release指代最新版本号，也可以指定明确的版本号，例如2.3.2
          compile ‘com.tencent.bugly:crashreport_upgrade:1.3.1‘
          compile ‘com.tencent.bugly:nativecrashreport:latest.release‘ //其中latest.release指代最新版本号，也可以指定明确的版本号，例如2.2.0
      }

并在末尾添加

// 依赖插件脚本
apply from: ‘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.1.2"

    // 构建多渠道补丁时使用
    // buildAllFlavorsDir = "${bakPath}/${baseApkDir}"

    // 是否启用加固模式，默认为false.(tinker-spport 1.0.7起支持）
    // isProtectedApp = true

    // 是否开启反射Application模式
    enableProxyApplication = false

}

/**
 * 一般来说,我们无需对下面的参数做任何的修改
 * 对于各参数的详细介绍请参考:
 * 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的分配
    }
}

这个文件的配置非常重要，稍后实施环节再说
自定义Application，记得改包名

public class SampleApplication extends TinkerApplication {
    public SampleApplication() {
        super(ShareConstants.TINKER_ENABLE_ALL, "xxx.xxx.SampleApplicationLike",
                "com.tencent.tinker.loader.TinkerLoader", false);
    }
}

自定义ApplicationLike（记得改appID）

public class SampleApplicationLike extends DefaultApplicationLike {

    public static final String TAG = "Tinker.SampleApplicationLike";

    public SampleApplicationLike(Application application, int tinkerFlags,
            boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime,
            long applicationStartMillisTime, Intent tinkerResultIntent) {
        super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
    }

    @Override
    public void onCreate() {
        super.onCreate();
        // 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId
        // 调试时，将第三个参数改为true
        Bugly.init(getApplication(), "900029763", false);
    }

    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    @Override
    public void onBaseContextAttached(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)
    public void registerActivityLifecycleCallback(Application.ActivityLifecycleCallbacks callbacks) {
        getApplication().registerActivityLifecycleCallbacks(callbacks);
    }

}

在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" />

Activity配置

<activity
    android:name="com.tencent.bugly.beta.ui.BetaActivity"
    android:configChanges="keyboardHidden|orientation|screenSize|locale"
    android:theme="@android:style/Theme.Translucent" />

配置FileProvider

 <provider
    android:name="android.support.v4.content.FileProvider"
    android:authorities="${applicationId}.fileProvider"
    android:exported="false"
    android:grantUriPermissions="true">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/provider_paths"/>
</provider>

在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>

3.实施环节

现在我们安装apk到手机，我的代码

public class MainActivity extends AppCompatActivity
{

    @Override
    protected void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        TextView tv = (TextView)findViewById(R.id.tv);
        tv.setOnClickListener(new View.OnClickListener()
        {
            @Override
            public void onClick(View v)
            {

                //Toast.makeText(MainActivity.this,"热更新成功",Toast.LENGTH_SHORT).show();
            }
        });
    }
}

然后我在这个app/build/bakApk文件夹下可以看到一些apk的包，这个就是基准包

我们选对应刚才时间的文件夹下的apk进行在Bugly的应用更新上报

最重要的环节来了，生成补丁包
先修改代码，在点击事件里添加一行代码Toast.makeText(MainActivity.this,"热更新成功", Toast.LENGTH_SHORT).show();

将baseApkDir修改成之前基准包所在文件夹的名字，例如：baseApkDIr = "app-1206-09-03-07"
还有将 tinkerId 修改成另一种id， 我是将base换成patch，例如： tinkerId = "patch-1.1.2"

然后点击右边的GradleProjects/app/tinker-support/buildTinkerPatchDebug,生成补丁包

这个补丁包在app/build/tinkerPatch/debug文件夹下，叫patch_signed_7zip.apk，还有就是我没有去签名，我这是系统签名，自己要签名的话，在build.gradle里写代码去签名

上报补丁

去Bugly的热更新界面，点击发布的新补丁，我们只要选择了文件，它自动识别补丁对应版本，记得之前的tinkerId吗，基准包和补丁包只通过这个来确定关系的，还有 versionCode 和versionName ，下发范围选全量设备，点击立即下发

测试补丁
这个需要等几分钟，再去打开应用，再重启，多试几次，当点击事件弹出吐司，就说明热更新成功，这个热更新是静默安装用户是不知道的，

还有就是如果在SampleApplicationLike设置 Bugly.init(getApplication(), "4daa5845f4", true);其中那个为true的话就是设置为调试模式，当你连接网络打开应用，应用会下载补丁，并安装，我的Log如下

12-06 09:25:16.497 16309-16309/zzw.buglyredfix I/CrashReport: [patch] inject success
12-06 09:25:16.499 16309-16309/zzw.buglyredfix I/CrashReport: TINKER_ID:patch-1.0.1
12-06 09:25:16.499 16309-16309/zzw.buglyredfix I/CrashReport: NEW_TINKER_ID:patch-1.0.1

再见

原文地址：http://blog.51cto.com/13591594/2067129

时间： 2024-10-24 09:30:47

Android 腾讯Bugly 热更新的相关文章

Bugly热更新——初探

Bugly热更新是基于微信的Tinker实现的.集成其热更新功能后可以一键生成patch包,然后上传到bugly平台. 基本步骤 编辑根目录下的build.gradle 编辑module(如:app)下的build.gradle 添加Application(extends com.tencent.tinker.loader.app.TinkerApplication) 添加ApplicationLike(extends com.tencent.tinker.loader.app.DefaultA

Cocos Code IDE解决ios模拟器和Android真机无法热更新代码问题

修改Runtime.cpp文件,添加一些代码 bool FileServer::receiveFile(int fd) { // ... string finish("finish\n"); send(fd, finish.c_str(), finish.size(),0); CCLOG("finish\n"); // I add these code Director::getInstance()->getScheduler()->performFun

React Native之code-push的热更新(ios android)

React Native之code-push的热更新(ios android) React Native支持大家用React Native技术开发APP,并打包生成一个APP.在动态更新方面React Native只是提供了动态更新的基础,对将应用部署到哪里,如何进行动态更新并没有支持的那么完善.好在微软开发了CodePush,填补React Native 应用在动态更新方面的空白.CodePush 是微软提供的一套用于热更新 React Native 和 Cordova 应用的服务.下面将向大

Unity实现c#热更新方案探究（一）

最近研究了一下如何在unity中实现c#的热更新,对于整个DLL热更新的过程和方案有一个初步的了解,这儿就写下来,便于后续的深入调查和方案选择. 一.C# DLL的动态加载和卸载 既然要热更新,那么就是动态的加载c#的DLL,所以第一步就是研究如何实现DLL的动态加载和卸载. 在CLR Via C#中,对于DLL的加载有详细的讲解,这儿就不再长篇幅的讲解整个过程,简单的来说,在C#的工程中,都会生成一个默认的程序域appDomain,就叫做DefaultAppDomain吧,在这个程序域的基础上

【腾讯bugly干货分享】微信Android热补丁实践演进之路

本文来自于腾讯bugly开发者社区,非经作者同意,请勿转载,原文地址:http://bugly.qq.com/bbs/forum.php?mod=viewthread&tid=1264&extra=page%3D1 继插件化后,热补丁技术在2015年开始爆发,目前已经是非常热门的Android开发技术.其中比较著名的有淘宝的Dexposed.支付宝的AndFix以及QZone的超级热补丁方案.微信对热补丁技术的研究并不算早,大约开始于2015年6月.经过研究与尝试现有的各个方案,我们发现它

【腾讯Bugly干货分享】Android UI：机智的远程动态更新策略

Android UI:机智的远程动态更新策略 作者:王金波    腾讯Bugly特约撰稿人 1问题描述 做过Android开发的人都遇到过这样的问题:随着需求的变化,某些入口界面通常会出现 UI的增加.减少.内容变化.以及跳转界面发生变化等问题.每次发生变化都要手动修改代码,而入口界面通常具有未读信息提醒这样的"小红点"逻辑:一旦UI变化,"小红点"逻辑也要重新计算.如果不同的RD来维护这些代码,耦合性非常高,出错概率也很大.本文以自选股的个人页卡为例(界面如下图所

Android热更新开源项目Tinker集成实践总结

前言 最近项目集成了Tinker,开始认为集成会比较简单,但是在实际操作的过程中还是遇到了一些问题,本文就会介绍在集成过程大家基本会遇到的主要问题. 考虑一:后台的选取 目前后台功能可以通过三种方式实现: 1.自己搭建后台布丁下发系统2.第三方提供的服务,目前如原微信simsun大神的个人tinkerpatch平台,目前出于内测阶段,暂时免费.后期应该会按下发量对app进行收费.3.腾讯Bugly提供的服务,提供了热更新的下发后台,集成到了bugly的升级sdk中.免费.根据公司的精神,我们选择

【腾讯Bugly干货分享】Android Patch 方案与持续交付

本文来自于腾讯bugly开发者社区,非经作者同意,请勿转载,原文地址:http://dev.qq.com/topic/57a31921ac3a1fb613dd40f3 Android 不仅系统版本众多,机型众多,而且各个市场都各有各的政策和审核速度,每次发布一个版本对于开发同学来讲都是一种漫长的煎熬.相比于 iOS 两三天就能达到 80% 的覆盖速度而言,Android 应用版本升级至少需要两周才能达到 80% 的升级率,严重阻碍了版本迭代速度.也导致市场上 App 版本分散,处理 bug 和投

移动端热更新方案（iOS+Android）

PPT资源包含iOS+Android 各种方案分析:https://github.com/qiyer/Share/blob/master/%E7%83%AD%E6%9B%B4%E6%96%B0%E5%88%86%E4%BA%ABPPT.pptx 一 .热更新(热修复)产品背景 这里谈到的热更新都是指APP(不包含网页).APP按大类别可以粗略分为 应用 和 游戏.APP的开发周期是极其快速的,在实际开发流程中,我们总会有一些需求迫使我们短时间内快速上线,比如需求流程出错,程序员主观导致的一些bu