Shulou(Shulou.com)06/03 Report--

Editor to share with you the example analysis of Android hot repair Tinker access, I believe that most people do not know much about it, so share this article for your reference, I hope you will learn a lot after reading this article, let's learn about it!

I. Overview

Hot repair technology has basically become an important module of the project. Mainly because the project after the launch, there will inevitably be a variety of problems, and rely on the release version to repair the problem, the cost is too high.

Now the hot repair technology basically has Ali's AndFix, QZone's plan, Meituan's idea plan and Tencent's Tinker and so on.

AndFix access may be the easiest (similar to Tinker command line access), but there are still some problems with compatibility. QZone scheme will have a certain impact on performance, and memory confusion occurs in Art mode (in fact, I am not clear about this problem before, mainly pointed out by tinker on MDCC); Meituan's idea is mainly based on the principle of Instant Run, which is not yet open source, but I still like this scheme, mainly because of its good compatibility.

From this point of view, if you choose an open source solution, tinker is currently the best choice. The introduction of tinker has this sentence:

Tinker already runs on hundreds of millions of Android devices on Wechat, so why don't you use Tinker?

All right, having said that, let's take a look at how tinker is connected, and the general principle analysis of tinker. Hope that through this article can help you better access to tinker, and to understand a general principle of tinker.

2. Connect to Tinker

At present, there are two ways to access tinker, one is based on the command line, which is similar to that of AndFix, and the other is gradle.

Consider that there should be a lot of app using Andfix in the early days, and many people still find it cumbersome to configure gradle. Here are two ways to introduce them.

(1) Command line access

Before accessing, let's consider the premise that is normally needed for access (enable the state of confusion).

For API

Generally speaking, when we connect to the hot repair library, we will initialize it in Application#onCreate. Then somewhere, call an API like loadPatch to load the patch file.

For the generation of patch

The simple way is to compare the two apk and then generate; it should be noted that: the two apk to do the comparison, the prerequisite required, the second packaging confusion using the mapping file should be the same as the online apk.

Finally, let's see if there is any need to configure confusion in this project.

With a general concept, we have a basic understanding of the steps required to connect the command line to tinker.

Dependency introduces dependencies {/ /... / optional, which is used to generate the core library compile ('com.tencent.tinker:tinker-android-lib:1.7.7')} of the application class provided (' com.tencent.tinker:tinker-android-anno:1.7.7') / / tinker

By the way, add the configuration of signature:

Android {/ /... SigningConfigs {release {storeFile file ("release.keystore") storePassword "testres" keyAlias "testres" keyPassword "testres"} catch (ex) {throw new InvalidUserDataException (ex.toString ())} buildTypes {release {minifyEnabled true signingConfig signingConfigs.release proguardFiles getDefaultProguardFile ('proguard-android.txt') 'proguard-rules.pro'} debug {debuggable true minifyEnabled true signingConfig signingConfigs.release proguardFiles getDefaultProguardFile (' proguard-android.txt'), 'proguard-rules.pro'}

There will be the download address of demo at the end of the article. You can refer to the build.gradle file directly. You don't have to worry about where to find these signature files.

API introduction

API is mainly initialization and loadPacth.

Normally, we will consider initializing it in the onCreate of Application, but tinker recommends the following:

@ DefaultLifeCycle (application = ".SimpleTinkerInApplication", flags = ShareConstants.TINKER_ENABLE_ALL, loadVerifyFlag = false) public class SimpleTinkerInApplicationLike extends ApplicationLike {public SimpleTinkerInApplicationLike (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);}}

ApplicationLike, as you might guess by name, is not a subclass of Application, but a class similar to Application.

Tinker suggests writing a subclass of ApplicationLike that you can use as Application. Note the note at the top: @ DefaultLifeCycle, whose application attribute generates a SimpleTinkerInApplication class at compile time.

So, although we wrote this, the Application is actually generated at compile time, so it looks like this in AndroidManifest.xml:

If you write it, you can build it.

As a matter of fact, you can guess that there is an Annotation Processor processing behind this note.

Through this article, you will have a certain grasp of the running process of a compile-time annotation and the basic API, and you will also parse the source code of this part of the tinker.

The initialization of tinker is completed above, so when we call loadPatch, we directly add a Button setting to Activity:

Public class MainActivity extends AppCompatActivity {@ Override protected void onCreate (Bundle savedInstanceState) {super.onCreate (savedInstanceState); setContentView (R.layout.activity_main);} public void loadPatch (View view) {TinkerInstaller.onReceiveUpgradePatch (getApplicationContext (), Environment.getExternalStorageDirectory (). GetAbsolutePath () + "/ patch_signed.apk");}}

We will push the patch file directly to the sdcard root directory

So be sure to pay attention to: add SDCard permissions, if you are more than 6.x system, add your own authorization code, or manually open SDCard read and write permissions on the settings page.

In addition to this, a special place is that tinker needs to specify TINKER_ID in AndroidManifest.xml.

/ /...

At this point, the API related is over, and all that's left is to consider how the patch is generated.

Patch generation

Tinker provides patch-generated tools, the source code can be seen in: tinker-patch-cli, into a jar can be used, and provides command line-related parameters and files.

The command line is as follows:

Java-jar tinker-patch-cli-1.7.7.jar-old old.apk-new new.apk-config tinker_config.xml-out output

What you need to pay attention to is tinker_config.xml, which contains the configuration of tinker, such as signature files.

Here we directly use the signature file provided by tinker, so there is no need to modify it, but the item of Application is modified to be consistent with this example:

The general structure of the file is as follows:

You can extract it from tinker-patch-cli, or download the example at the end of the article directly.

The commands generated by patch are described above, and the last thing to note is that when you type out apk for the first time, keep the generated mapping file in / build/outputs/mapping/release/mapping.txt.

You can copy to the same directory as proguard-rules.pro, and when you type the fix pack for the second time, add the following to proguard-rules.pro:

-applymapping mapping.txt

Make sure that subsequent packages use the same mapping file as the online package.

For the configuration related to the confusion of tinker itself, please refer to:

Tinker_proguard.pro

If you don't know this part of the description, you can check the source code directly.

test

First of all, randomly generate an apk (API, confusion related has been introduced in accordance with the above), and install it on the mobile phone or simulator.

Then, copy exports the mapping.txt file, sets the applymapping, modifies the code, packages it again, and generates the new.apk.

Twice apk, you can use command-line instructions to generate patch files.

If you download this example, the command needs to be executed in [this directory].

The product will eventually be generated in the output folder:

Let's patch_signed.apk push directly to sdcard, click loadpatch, and be sure to see if the command line is successful.

This example modifies title.

Click loadPatch to observe the log. If successful, the application restarts by default, and then starts again to achieve the repair effect.

This is the end of the introduction to the command line, which is basically the same as the way to access Andfix.

It is worth noting that this example only shows the basic access, for the various configuration information of tinker, you still need to read the tinker documentation (if you are sure to use) tinker-wiki.

(2) gradle access

The way of gradle access should be regarded as the mainstream way, so tinker also gives a direct example, and the tinker-sample-android can be introduced in project mode alone.

After it is introduced, you can view how it is connected to API, as well as the relevant configuration.

Every time you build, a locally packaged apk,R file, as well as a mapping file, will be generated under build/bakApk.

If you need to generate a patch file, you can do this by:

. / gradlew tinkerPatchRelease / / or. / gradlew tinkerPatchDebug

Generate.

The generated directory is: build/outputs/tinkerPatch

It should be noted that you need to set a comparative apk in app/build.gradle (that is, old.apk, this time new.apk)

Ext {tinkerEnabled = true / / old apk file to build patch apk tinkerOldApkPath = "${bakPath} / old.apk" / / proguard mapping file to build patch apk tinkerApplyMappingPath = "${bakPath} / old-mapping.txt"}

The example provided basically shows the custom extension of tinker. For more information, please see:

Tinker- Custom extension

So, if you use command-line access, don't forget to learn which extensions it supports.

3. How Application is generated at compile time

In terms of comments and naming:

/ / optional, used to generate the application class provided ('com.tencent.tinker:tinker-android-anno:1.7.7')

This is obviously the library, and its structure is as follows:

For a typical compile-time annotated project, see tinker-android-anno for source code.

The entry is com.tencent.tinker.anno.AnnotationProcessor, and the full path of the processing class can be found in the services/javax.annotation.processing.Processor file.

Again, if you don't understand, simply read how Android writes project articles based on compile-time annotations.

Look directly at the process method of AnnotationProcessor:

@ Overridepublic boolean process (Set

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.