[Android]腾讯Tinker热修复框架简单使用
2017-06-02 11:24
645 查看
前言
目前我们所知的热修复方案有阿里的AndFix、美团的Robust以及QZone的超级补丁方案,还有本篇的Tinker,如何在我们的自开发的软件上选用合适的方案呢?
先看看各家的框架效能对比,在作参考。
总体来说:
AndFix作为native解决方案,首先面临的是稳定性与兼容性问题,更重要的是它无法实现类替换,它是需要大量额外的开发成本的;
Robust兼容性与成功率较高,但是它与AndFix一样,无法新增变量与类只能用做的bugFix方案;
Qzone方案可以做到发布产品功能,但是它主要问题是插桩带来Dalvik的性能问题,以及为了解决Art下内存地址问题而导致补丁包急速增大的。
可以看出,Tinker热补丁方案既支持类、So和资源的替换,还支持了2.x-7.x平台。我们不仅可以用做bugfix,甚至可以替代功能的发布,况且Tinker已经在数亿Android端的微信上运行使用,这个噱头你还不用?
使用说明
Tinker提供了两种接入方式,gradle接入和命令行接入,这里先说明gradle的方式,这也是比较推荐的方式。
1.在项目的build.gradle中,添加tinker-patch-gradle-plugin的依赖:
3.在/app/build.gradle中加入tinkerPatch task 脚本,
注意,minifyEnabled一定要设置为true,别忘了设置tinkerId,在getSha方法里可以先写死。
代码里我们要做点什么呢?我需要先自定义Application类,因为引入了Tinker,所以原来的MyApplication必须改造。
程序启动时会加载默认的Application类,这导致我们补丁包是无法对它做修改了。如何规避?在这里我们并没有使用类似InstantRun hook Application的方式,而是通过代码框架的方式来避免,这也是为了尽量少的去反射,提升框架的兼容性。这里我们要实现的是完全将原来的Application类隔离起来,即其他任何类都不能再引用我们自己的Application。我们需要做的其实是以下几个工作:
将我们自己Application类以及它的继承类的所有代码拷贝到自己的ApplicationLike继承类中,例如MyApplicationLike。你也可以直接将自己的Application改为继承ApplicationLike;
Application的attachBaseContext方法实现要单独移动到onBaseContextAttached中;
对ApplicationLike中,引用application的地方改成getApplication();
对其他引用Application或者它的静态对象与方法的地方,改成引用ApplicationLike的静态对象与方法;
我的demo中原来是自定义的MyApplication,现在必须把之前的Application中定义的变量转移到自定义的ApplicationLike中去,然后自动生成MyApplication,这里使用Annotation生成Application类(推荐)。
MyApplicationLike.java
package com.example.myapp;
import android.app.Application;
import android.content.Context;
import android.content.Intent;
import com.example.myapp.db.dao.DaoMaster;
import com.example.myapp.db.dao.DaoSession;
import com.example.myapp.event.MyEventBusIndex;
import com.jan.lib.BusPoster;
import com.tencent.tinker.anno.DefaultLifeCycle;
import com.tencent.tinker.lib.tinker.TinkerInstaller;
import com.tencent.tinker.loader.app.DefaultApplicationLike;
import com.tencent.tinker.loader.shareutil.ShareConstants;
import org.greenrobot.greendao.database.Database;
/**
* Created by Jan on 2017/5/25.
*/
@DefaultLifeCycle(
application = ".MyApplication",
flags = ShareConstants.TINKER_ENABLE_ALL, ////tinkerFlags, tinker支持的类型,dex,library,还是全部都支持!
loaderClass = "com.tencent.tinker.loader.TinkerLoader",//loaderClassName, 我们这里使用默认即可!
loadVerifyFlag = false) //tinkerLoadVerifyFlag
public class MyApplicationLike extends DefaultApplicationLike {
public static final boolean ENCRYPTED = false;
private DaoSession mDaoSession;
public static Context mContext;
public MyApplicationLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) {
super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
}
@Override
public void onBaseContextAttached(Context base) {
super.onBaseContextAttached(base);
}
@Override
public void onCreate() {
super.onCreate();
TinkerInstaller.install(this);
MyApplication application = (MyApplication) getApplication();
BusPoster.registerSubIndex(new MyEventBusIndex());
mContext =application.getApplicationContext();
registerDaoComp();
}
private void registerDaoComp(){
DaoMaster.DevOpenHelper helper = new DaoMaster.DevOpenHelper(mContext,ENCRYPTED ? "app-db-encrypted" : "app-db");
Database db = ENCRYPTED ? helper.getEncryptedWritableDb("super-secret") : helper.getWritableDb();
mDaoSession = new DaoMaster(db).newSession();
}
public DaoSession getDaoSession(){
return mDaoSession;
}
}
AndroidMnaifest,xml里的android:name=".MyApplication" 这个是自动生成的哦~
为了方便测试效果,我们在demo的测试Activity中写入这样的逻辑:加入一个按钮A,用于执行加载修复补丁包,以及展示一段文字,为了和加入补丁后的代码进行比较,用来判断是否有效。
因为这里加载补丁包势必要有读取文件的权限:<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
Tinker tinker = Tinker.with(getApplicationContext());
//判断是否加载了补丁
if(tinker.isTinkerLoaded()){
Toast.makeText(this,"patch is loaded",Toast.LENGTH_SHORT).show();
}else {
Toast.makeText(this,"patch is not loaded",Toast.LENGTH_SHORT).show();
}
//用来加载补丁包的按钮
btn2 = (Button) findViewById(R.id.button2);
btn2.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
//adb push ./app/build/outputs/tinkerPatch/debug/patch_signed_7zip.apk /storage/sdcard0/
TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed_7zip.apk");
}
});
//关闭APP的按钮
btn3 = (Button) findViewById(R.id.button3);
btn3.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
ShareTinkerInternals.killAllOtherProcess(getApplicationContext());
android.os.Process.killProcess(android.os.Process.myPid());
}
});
好了,代码基本很简单。下面讲讲如何打包。
4.我们这里模拟打正式发布的包,先执行gradle上述的方法中的assembleRelease脚本
我们这里生成了基准包,在build/bakApk/下的。。。apk文件和mapping文件,R字典文件配置到如图的区域中。这一步骤可不能忘了。这个基准包apk我们是经过混淆过的,我们把这个app-release-xxx.apk,先安装到手机上。
接着修改 Activity中的文字展示的代码,然后开始生成补丁包,执行tinkerPatchRelease
这会儿在app\build\outputs\tinkerPatch\release目录下找到补丁包patch_signed_7zip.apk,然后push到手机sd卡下,准备加载动作。
执行命令adb push ./app/build/outputs/tinkerPatch/release/patch_signed_7zip.apk /storage/sdcard0/ 即可。
再打开我们刚开始装的app,点击执行加载补丁功能,如果成功,将会自动关闭下次启动后,发现展示的文字是最新修改过的。如果你失败了,那得看看日志,找找哪里出了问题。
Tinker 常见问题
目前我们所知的热修复方案有阿里的AndFix、美团的Robust以及QZone的超级补丁方案,还有本篇的Tinker,如何在我们的自开发的软件上选用合适的方案呢?
先看看各家的框架效能对比,在作参考。
总体来说:
AndFix作为native解决方案,首先面临的是稳定性与兼容性问题,更重要的是它无法实现类替换,它是需要大量额外的开发成本的;
Robust兼容性与成功率较高,但是它与AndFix一样,无法新增变量与类只能用做的bugFix方案;
Qzone方案可以做到发布产品功能,但是它主要问题是插桩带来Dalvik的性能问题,以及为了解决Art下内存地址问题而导致补丁包急速增大的。
可以看出,Tinker热补丁方案既支持类、So和资源的替换,还支持了2.x-7.x平台。我们不仅可以用做bugfix,甚至可以替代功能的发布,况且Tinker已经在数亿Android端的微信上运行使用,这个噱头你还不用?
使用说明
Tinker提供了两种接入方式,gradle接入和命令行接入,这里先说明gradle的方式,这也是比较推荐的方式。
1.在项目的build.gradle中,添加tinker-patch-gradle-plugin的依赖:
buildscript { dependencies { classpath ('com.tencent.tinker:tinker-patch-gradle-plugin:1.7.10') } }2.然后在app的gradle文件app/build.gradle,我们需要添加tinker的库依赖以及apply tinker的gradle插件.
dependencies { //可选,用于生成application类 provided('com.tencent.tinker:tinker-android-anno:1.7.10') //tinker的核心库 compile('com.tencent.tinker:tinker-android-lib:1.7.10') }
//apply tinker插件 apply plugin: 'com.tencent.tinker.patch'
3.在/app/build.gradle中加入tinkerPatch task 脚本,
def bakPath = file("${buildDir}/bakApk/") ext { //for some reason, you may want to ignore tinkerBuild, such as instant run debug build? tinkerEnabled = true //for normal build //old apk file to build patch apk tinkerOldApkPath = "${bakPath}/app-release-0601-14-29-28.apk" //proguard mapping file to build patch apk tinkerApplyMappingPath = "${bakPath}/app-release-0601-14-29-28-mapping.txt" //resource R.txt to build patch apk, must input if there is resource changed tinkerApplyResourcePath = "${bakPath}/app-release-0601-14-29-28-R.txt" //only use for build all flavor, if not, just ignore this field // tinkerBuildFlavorDirectory = "${bakPath}/app-0526-17-40-51" } //这个方法其实就是定义了一个tink_id def getSha() { try { String tinkId = "tink_id_676223321" if (tinkId == null) { throw new RuntimeException("you should add tinkeId to system path or just input test value, such as 'testTinkerId'") } return tinkId } catch (Exception e) { throw new RuntimeException("you should add tinkeId to system path or just input test value, such as 'testTinkerId'") } } def getOldApkPath() { return hasProperty("OLD_APK") ? OLD_APK : ext.tinkerOldApkPath } def getApplyMappingPath() { return hasProperty("APPLY_MAPPING") ? APPLY_MAPPING : ext.tinkerApplyMappingPath } def getApplyResourceMappingPath() { return hasProperty("APPLY_RESOURCE") ? APPLY_RESOURCE : ext.tinkerApplyResourcePath } def getTinkerIdValue() { return hasProperty("TINKER_ID") ? TINKER_ID : getSha() } def buildWithTinker() { return hasProperty("TINKER_ENABLE") ? TINKER_ENABLE : ext.tinkerEnabled } def getTinkerBuildFlavorDirectory() { return ext.tinkerBuildFlavorDirectory } if (buildWithTinker()) { apply plugin: 'com.tencent.tinker.patch' tinkerPatch { /** * necessary,default 'null' * the old apk path, use to diff with the new apk to build * add apk from the build/bakApk */ oldApk = getOldApkPath() /** * optional,default 'false' * there are some cases we may get some warnings * if ignoreWarning is true, we would just assert the patch process * case 1: minSdkVersion is below 14, but you are using dexMode with raw. * it must be crash when load. * case 2: newly added Android Component in AndroidManifest.xml, * it must be crash when load. * case 3: loader classes in dex.loader{} are not keep in the main dex, * it must be let tinker not work. * case 4: loader classes in dex.loader{} changes, * loader classes is ues to load patch dex. it is useless to change them. * it won't crash, but these changes can't effect. you may ignore it * case 5: resources.arsc has changed, but we don't use applyResourceMapping to build */ ignoreWarning = false /** * optional,default 'true' * whether sign the patch file * if not, you must do yourself. otherwise it can't check success during the patch loading * we will use the sign config with your build type */ useSign = true /** * optional,default 'true' * whether use tinker to build */ tinkerEnable = buildWithTinker() /** * Warning, applyMapping will affect the normal android build! */ buildConfig { /** * optional,default 'null' * if we use tinkerPatch to build the patch apk, you'd better to apply the old * apk mapping file if minifyEnabled is enable! * Warning: * you must be careful that it will affect the normal assemble build! */ applyMapping = getApplyMappingPath() /** * optional,default 'null' * It is nice to keep the resource id from R.txt file to reduce java changes */ applyResourceMapping = getApplyResourceMappingPath() /** * necessary,default 'null' * because we don't want to check the base apk with md5 in the runtime(it is slow) * tinkerId is use to identify the unique base apk when the patch is tried to apply. * we can use git rev, svn rev or simply versionCode. * we will gen the tinkerId in your manifest automatic */ tinkerId = getTinkerIdValue() /** * if keepDexApply is true, class in which dex refer to the old apk. * open this can reduce the dex diff file size. */ keepDexApply = false /** * optional, default 'false' * Whether tinker should treat the base apk as the one being protected by app * protection tools. * If this attribute is true, the generated patch package will contain a * dex including all changed classes instead of any dexdiff patch-info files. */ isProtectedApp = false } dex { /** * optional,default 'jar' * only can be 'raw' or 'jar'. for raw, we would keep its original format * for jar, we would repack dexes with zip format. * if you want to support below 14, you must use jar * or you want to save rom or check quicker, you can use raw mode also */ dexMode = "jar" /** * necessary,default '[]' * what dexes in apk are expected to deal with tinkerPatch * it support * or ? pattern. */ pattern = ["classes*.dex", "assets/secondary-dex-?.jar"] /** * necessary,default '[]' * Warning, it is very very important, loader classes can't change with patch. * thus, they will be removed from patch dexes. * you must put the following class into main dex. * Simply, you should add your own application {@code tinker.sample.android.SampleApplication} * own tinkerLoader, and the classes you use in them * */ loader = [ //use sample, let BaseBuildInfo unchangeable with tinker "com.tencent.tinker.loader.*", "com.tencent.tinker.*", "com.example.myapp.MyApplication" ] } lib { /** * optional,default '[]' * what library in apk are expected to deal with tinkerPatch * it support * or ? pattern. * for library in assets, we would just recover them in the patch directory * you can get them in TinkerLoadResult with Tinker */ pattern = ["lib/*/*.so"] } res { /** * optional,default '[]' * what resource in apk are expected to deal with tinkerPatch * it support * or ? pattern. * you must include all your resources in apk here, * otherwise, they won't repack in the new apk resources. */ pattern = ["res/*", "assets/*", "resources.arsc", "AndroidManifest.xml"] /** * optional,default '[]' * the resource file exclude patterns, ignore add, delete or modify resource change * it support * or ? pattern. * Warning, we can only use for files no relative with resources.arsc */ ignoreChange = ["assets/sample_meta.txt"] /** * default 100kb * for modify resource, if it is larger than 'largeModSize' * we would like to use bsdiff algorithm to reduce patch file size */ largeModSize = 100 } packageConfig { /** * optional,default 'TINKER_ID, TINKER_ID_VALUE' 'NEW_TINKER_ID, NEW_TINKER_ID_VALUE' * package meta file gen. path is assets/package_meta.txt in patch file * you can use securityCheck.getPackageProperties() in your ownPackageCheck method * or TinkerLoadResult.getPackageConfigByName * we will get the TINKER_ID from the old apk manifest for you automatic, * other config files (such as patchMessage below)is not necessary */ configField("TINKER_ID", getSha()) configField("app_name", "MyApp") configField("patchMessage", "这是一个测试"); /** * just a sample case, you can use such as sdkVersion, brand, channel... * you can parse it in the SamplePatchListener. * Then you can use patch conditional! */ configField("platform", "all") /** * patch version via packageConfig */ configField("patchVersion", "1.0") } //or you can add config filed outside, or get meta value from old apk //project.tinkerPatch.packageConfig.configField("test1", project.tinkerPatch.packageConfig.getMetaDataFromOldApk("Test")) //project.tinkerPatch.packageConfig.configField("test2", "sample") /** * if you don't use zipArtifact or path, we just use 7za to try */ sevenZip { /** * optional,default '7za' * the 7zip artifact path, it will use the right 7za with your platform */ zipArtifact = "com.tencent.mm:SevenZip:1.1.10" /** * optional,default '7za' * you can specify the 7za path yourself, it will overwrite the zipArtifact value */ // path = "/usr/local/bin/7za" } } List<String> flavors = new ArrayList<>(); project.android.productFlavors.each {flavor -> flavors.add(flavor.name) } boolean hasFlavors = flavors.size() > 0 def date = new Date().format("MMdd-HH-mm-ss") /** * bak apk and mapping */ android.applicationVariants.all { variant -> /** * task type, you want to bak */ def taskName = variant.name tasks.all { if ("assemble${taskName.capitalize()}".equalsIgnoreCase(it.name)) { it.doLast { copy { def fileNamePrefix = "${project.name}-${variant.baseName}" def newFileNamePrefix = hasFlavors ? "${fileNamePrefix}" : "${fileNamePrefix}-${date}" def destPath = hasFlavors ? file("${bakPath}/${project.name}-${date}/${variant.flavorName}") : bakPath from variant.outputs.outputFile into destPath rename { String fileName -> fileName.replace("${fileNamePrefix}.apk", "${newFileNamePrefix}.apk") } from "${buildDir}/outputs/mapping/${variant.dirName}/mapping.txt" into destPath rename { String fileName -> fileName.replace("mapping.txt", "${newFileNamePrefix}-mapping.txt") } from "${buildDir}/intermediates/symbols/${variant.dirName}/R.txt" into destPath rename { String fileName -> fileName.replace("R.txt", "${newFileNamePrefix}-R.txt") } } } } } } project.afterEvaluate { //sample use for build all flavor for one time if (hasFlavors) { task(tinkerPatchAllFlavorRelease) { group = 'tinker' def originOldPath = getTinkerBuildFlavorDirectory() for (String flavor : flavors) { def tinkerTask = tasks.getByName("tinkerPatch${flavor.capitalize()}Release") dependsOn tinkerTask def preAssembleTask = tasks.getByName("process${flavor.capitalize()}ReleaseManifest") preAssembleTask.doFirst { String flavorName = preAssembleTask.name.substring(7, 8).toLowerCase() + preAssembleTask.name.substring(8, preAssembleTask.name.length() - 15) project.tinkerPatch.oldApk = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release.apk" project.tinkerPatch.buildConfig.applyMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release-mapping.txt" project.tinkerPatch.buildConfig.applyResourceMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-release-R.txt" } } } task(tinkerPatchAllFlavorDebug) { group = 'tinker' def originOldPath = getTinkerBuildFlavorDirectory() for (String flavor : flavors) { def tinkerTask = tasks.getByName("tinkerPatch${flavor.capitalize()}Debug") dependsOn tinkerTask def preAssembleTask = tasks.getByName("process${flavor.capitalize()}DebugManifest") preAssembleTask.doFirst { String flavorName = preAssembleTask.name.substring(7, 8).toLowerCase() + preAssembleTask.name.substring(8, preAssembleTask.name.length() - 13) project.tinkerPatch.oldApk = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug.apk" project.tinkerPatch.buildConfig.applyMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug-mapping.txt" project.tinkerPatch.buildConfig.applyResourceMapping = "${originOldPath}/${flavorName}/${project.name}-${flavorName}-debug-R.txt" } } } } } }
注意,minifyEnabled一定要设置为true,别忘了设置tinkerId,在getSha方法里可以先写死。
代码里我们要做点什么呢?我需要先自定义Application类,因为引入了Tinker,所以原来的MyApplication必须改造。
程序启动时会加载默认的Application类,这导致我们补丁包是无法对它做修改了。如何规避?在这里我们并没有使用类似InstantRun hook Application的方式,而是通过代码框架的方式来避免,这也是为了尽量少的去反射,提升框架的兼容性。这里我们要实现的是完全将原来的Application类隔离起来,即其他任何类都不能再引用我们自己的Application。我们需要做的其实是以下几个工作:
将我们自己Application类以及它的继承类的所有代码拷贝到自己的ApplicationLike继承类中,例如MyApplicationLike。你也可以直接将自己的Application改为继承ApplicationLike;
Application的attachBaseContext方法实现要单独移动到onBaseContextAttached中;
对ApplicationLike中,引用application的地方改成getApplication();
对其他引用Application或者它的静态对象与方法的地方,改成引用ApplicationLike的静态对象与方法;
我的demo中原来是自定义的MyApplication,现在必须把之前的Application中定义的变量转移到自定义的ApplicationLike中去,然后自动生成MyApplication,这里使用Annotation生成Application类(推荐)。
MyApplicationLike.java
package com.example.myapp;
import android.app.Application;
import android.content.Context;
import android.content.Intent;
import com.example.myapp.db.dao.DaoMaster;
import com.example.myapp.db.dao.DaoSession;
import com.example.myapp.event.MyEventBusIndex;
import com.jan.lib.BusPoster;
import com.tencent.tinker.anno.DefaultLifeCycle;
import com.tencent.tinker.lib.tinker.TinkerInstaller;
import com.tencent.tinker.loader.app.DefaultApplicationLike;
import com.tencent.tinker.loader.shareutil.ShareConstants;
import org.greenrobot.greendao.database.Database;
/**
* Created by Jan on 2017/5/25.
*/
@DefaultLifeCycle(
application = ".MyApplication",
flags = ShareConstants.TINKER_ENABLE_ALL, ////tinkerFlags, tinker支持的类型,dex,library,还是全部都支持!
loaderClass = "com.tencent.tinker.loader.TinkerLoader",//loaderClassName, 我们这里使用默认即可!
loadVerifyFlag = false) //tinkerLoadVerifyFlag
public class MyApplicationLike extends DefaultApplicationLike {
public static final boolean ENCRYPTED = false;
private DaoSession mDaoSession;
public static Context mContext;
public MyApplicationLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) {
super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
}
@Override
public void onBaseContextAttached(Context base) {
super.onBaseContextAttached(base);
}
@Override
public void onCreate() {
super.onCreate();
TinkerInstaller.install(this);
MyApplication application = (MyApplication) getApplication();
BusPoster.registerSubIndex(new MyEventBusIndex());
mContext =application.getApplicationContext();
registerDaoComp();
}
private void registerDaoComp(){
DaoMaster.DevOpenHelper helper = new DaoMaster.DevOpenHelper(mContext,ENCRYPTED ? "app-db-encrypted" : "app-db");
Database db = ENCRYPTED ? helper.getEncryptedWritableDb("super-secret") : helper.getWritableDb();
mDaoSession = new DaoMaster(db).newSession();
}
public DaoSession getDaoSession(){
return mDaoSession;
}
}
AndroidMnaifest,xml里的android:name=".MyApplication" 这个是自动生成的哦~
为了方便测试效果,我们在demo的测试Activity中写入这样的逻辑:加入一个按钮A,用于执行加载修复补丁包,以及展示一段文字,为了和加入补丁后的代码进行比较,用来判断是否有效。
因为这里加载补丁包势必要有读取文件的权限:<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
Tinker tinker = Tinker.with(getApplicationContext());
//判断是否加载了补丁
if(tinker.isTinkerLoaded()){
Toast.makeText(this,"patch is loaded",Toast.LENGTH_SHORT).show();
}else {
Toast.makeText(this,"patch is not loaded",Toast.LENGTH_SHORT).show();
}
//用来加载补丁包的按钮
btn2 = (Button) findViewById(R.id.button2);
btn2.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
//adb push ./app/build/outputs/tinkerPatch/debug/patch_signed_7zip.apk /storage/sdcard0/
TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed_7zip.apk");
}
});
//关闭APP的按钮
btn3 = (Button) findViewById(R.id.button3);
btn3.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
ShareTinkerInternals.killAllOtherProcess(getApplicationContext());
android.os.Process.killProcess(android.os.Process.myPid());
}
});
好了,代码基本很简单。下面讲讲如何打包。
4.我们这里模拟打正式发布的包,先执行gradle上述的方法中的assembleRelease脚本
我们这里生成了基准包,在build/bakApk/下的。。。apk文件和mapping文件,R字典文件配置到如图的区域中。这一步骤可不能忘了。这个基准包apk我们是经过混淆过的,我们把这个app-release-xxx.apk,先安装到手机上。
接着修改 Activity中的文字展示的代码,然后开始生成补丁包,执行tinkerPatchRelease
这会儿在app\build\outputs\tinkerPatch\release目录下找到补丁包patch_signed_7zip.apk,然后push到手机sd卡下,准备加载动作。
执行命令adb push ./app/build/outputs/tinkerPatch/release/patch_signed_7zip.apk /storage/sdcard0/ 即可。
再打开我们刚开始装的app,点击执行加载补丁功能,如果成功,将会自动关闭下次启动后,发现展示的文字是最新修改过的。如果你失败了,那得看看日志,找找哪里出了问题。
Tinker 常见问题
相关文章推荐
- android 热修复框架Tinker的详细简单使用
- 关于使用腾讯 Bugly 平台 Tinker开源热修复框架的 项目集成
- Android 笔记: Tinker 热修复框架 简单上手教程
- Android 热修复,微信开源框架tinker的接入,就是这么简单
- Android探索之旅(第二十五篇)腾讯热修复框架Tinker与阿里第三代热修复框架Sophix对比
- Android 网络通信框架Volley的简单使用
- Android中常见的图片处理框架的简单使用
- Android热修复框架 Tinker 接入
- 微信热修复框架Tinker的使用
- Android框架之EventBus的简单使用
- Android集成微信Tinker热修复及使用
- Android热修复框架Tinker初体验
- Android 官方数据绑定框架 Data Binding 简单使用
- android Volley请求框架的简单使用——访问网络和加载图片
- Android网络请求框架:Volley简单使用
- Android注解框架(ButterKnife的简单使用)
- 零基础学习腾讯热修复框架Tinker
- Android热修复框架AndFix原理解析及使用
- Tinker热修复简单使用与接入
- Android热补丁动态修复技术(三)—— 使用Javassist注入字节码,完成热补丁框架雏形(可使用)