-
Notifications You must be signed in to change notification settings -
Fork 3.3k
Tinker Access Guide
buildscript { dependencies { classpath ( ' com.tencent.tinker:tinker-patch-gradle-plugin:1.9.1 ' ) } }
dependencies { // Optional, used to generate application classes provided( ' com.tencent.tinker:tinker-android-anno:1.9.1 ' ) // Tinker's core library compile( ' com.tencent.tinker:tinker-android-lib:1.9.1 ' ) } .. . .. . // Apply tinker plug-in apply plugin : ' com.tencent.tinker.patch '
|
|
|
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-
Automatically insert TINKER_ID into the meta item of AndroidManifest, and the output path is build/intermediate/tinker_intermediates/AndroidManifest.xml; -
If minifyEnabled is true, Tinker's proguard rules will be automatically added to proguardFiles, and the output path is build/intermediate/tinker_intermediates/linker_proguard.pro, Here you don't need to copy them to your own proguard configuration file ; -
If multiDexEnabled is true, the keep rule that Tinker needs to place in the main dex will be automatically generated. Before tinker 1.7.6, you You need to manually copy the generated rules to your multiDexKeepProguard file 。 For example, in Sample multiDexKeepProguard file("keep_in_main_dex.txt") 。 After 1.7.6, it will be automatically processed through script, and there is no need to fill in manually. -
Open the jumboMode of dexOptions.
ext { tinkerBuildFlavorDirectory = "${bakPath}/app-1014-13-35-12" }
|
|
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
java - jar tinker - patch - cli . jar - old old . apk - new new . apk - config tinker_config . xml - out output_path
< meta-data android : name = " TINKER_ID " android : value = " tinker_id_b168b32 " />
-
tinker_config.xml example -
tinker_proguard.pro Example of proguard configuration -
tinker_multidexkeep.pro Main dex configuration instance
-
build; The tools used in compiling are tinker-patch-cli.jar and some configuration information that may be used; -
android; It needs to be placed in the dependency library on the mobile phone, where tinker-android-anno.jar As an optional library, only those that use Tinker's annotation need to be imported.
-
call assembleDebug Compile. We will save the compiled package in build/bakApk. Then we install it to the phone, click SHOW INFO Button, you can see that the patch has not been loaded -
Modify the code, such as changing MainActivity in I am on patch onCreate The Log of is opened. Then we need to modify build.gradle Copy the path of the installation package compiled and saved in Step 1 to tinkerPatch In oldApk Parameter. -
call tinkerPatchDebug , the patch package and related logs will be saved in /build/outputs/tinkerPatch/ 。 Then we will patch_signed_7zip.apk Push to the sdcard of the mobile phone. adb push ./ app / build / outputs / tinkerPatch / debug / patch_signed_7zip . apk / storage / sdcard0 / -
click LOAD PATCH Button, if you see patch success, please restart process To lock the screen or click KILL SELF Button -
We can see that it does appear I am on patch onCreate Log, and click SHOW INFO The button shows that the patch package has been loaded successfully.
-
Backup the installation package and mapping file for each compilation or contracting; -
If there is a need for patch packs, modify your code, library files, etc. according to your own needs; -
Input the backup benchmark installation package and mapping file into the configuration of tinkerPatch; -
Run tinkerPatchRelease to automatically compile the latest installation package and make a difference from the input benchmark package to get the final patch package.
compile ( "com.tencent.tinker:tinker-android-loader:${TINKER_VERSION}" ) { changing = true } compile ( "com.tencent.tinker:aosp-dexutils:${TINKER_VERSION}" ) { changing = true } compile ( "com.tencent.tinker:bsdiff-util:${TINKER_VERSION}" ) { changing = true } compile ( "com.tencent.tinker:tinker-commons:${TINKER_VERSION}" ) { changing = true }
-
Master branch; The last release of stable code, we tag the master branch; -
Dev branch; The development branch will contain the code of the next version. We can only provide pr for the dev branch and verify that some of the repaired issues have been repaired; -
Hotfix branch; To fix the branch of tinker's emergency bug.