How We Built Tinker: Android Hot‑Patch Framework for High‑Availability Apps

In the past six months the Android hot‑patch scene has exploded, with many companies releasing open‑source frameworks. Tencent’s Tinker recently passed internal review and became the first officially public project on github.com/Tencent.

Hot patch is not a dinner party.

The article shares WeChat’s experience to help developers decide whether to adopt hot‑patch technology and which solution to choose.

Hot‑Patch Technology Background

Android hot‑patch techniques can be divided into two streams:

Native – examples include Alibaba’s Dexposed, AndFix, and Tencent’s internal KKFix.

Java – examples include Qzone’s SuperPatch, Dazhong Dianping’s Nuwa, Baidu Finance’s rocooFix, Ele.me’s Amigo, and Meituan’s Robust.

Both streams have pros and cons; there is no universally best solution, only the most suitable one.

WeChat needed a “high‑availability” patch framework that satisfies three criteria:

Stability and compatibility : the app runs on hundreds of millions of devices, so even a 1% failure rate would affect thousands of users.

Performance : the framework must not degrade app performance, and patch packages should be as small as possible to save bandwidth and improve success rates.

Ease of use : the framework should be simple, fully supported, and capable of function‑level releases.

We evaluated the existing native and Java solutions. Native options (Dexposed/AndFix) struggled with stability, compatibility, and the inability to add new classes or fields. Java options (Qzone) suffered from performance penalties on Dalvik due to instrumentation and large patch sizes on ART caused by address offsets.

In March 2016, WeChat decided to build its own framework – Tinker.

Tinker v1.0 – Pursuing Extreme Performance

We chose the Java stream for stability and compatibility. The main challenge was overcoming Qzone’s performance issue. Inspiration came from Instant Run’s cold‑swap and Buck’s exopackage, both of which replace the entire Dex.

We replace the whole Dex, avoiding ART address misalignment and Dalvik instrumentation. To keep patch size small, we store only the differences between the old and new Dex. Three diff methods were investigated:

BsDiff : format‑agnostic but produces unstable output size; still used for native libraries and some resources.

DexMerge : high memory consumption (a 12 MB Dex can peak at over 70 MB).

DexDiff : a custom algorithm that generates tiny patches, uses little memory, and supports add/modify/delete operations.

We ultimately chose a self‑developed DexDiff algorithm, which became the core of Tinker v1.0.

1. DexDiff Technical Practice

Deep study of the Dex format revealed three major difficulties:

Complex Dex format : indexes (StringID, TypeID, etc.) and offset‑based data sections are heavily inter‑referenced; a tiny change can cascade many index and offset updates.

dex2opt and dex2oat verification : these tools enforce alignment, sorting, and other checks (e.g., Unicode sorting of StringID).

Low‑memory, fast processing : each Dex block must be read and written only once, unlike full‑structure tools such as baksmali or DexMerge.

Example of a simple index diff: delete element “b” at index 2, shift “c”, “d”, “e” forward automatically, then add “f” at position 5.

For the offset region, many elements exist per section, making the algorithm more complex. DexDiff processes each operation individually, avoiding loading the entire Dex into memory.

The result is a tiny patch (typically under 10 KB) with negligible runtime overhead (about 2% caused by MD5 verification of the patched Dex).

2. Android N Challenge

After release, a crash was reported on Huawei devices running Android N. The issue stemmed from Android N’s hybrid compilation mode, which broke the Java‑based hot‑patch approach.

Further analysis (see “Android N Hybrid Compilation and Hot‑Patch Impact” article) showed that the new compilation pipeline required different handling of Dex files.

3. OEM OTA Challenge

Shortly after fixing the Android N problem, Xiaomi developers reported black screens and ANRs on some devices during startup. The root cause was OTA updates changing system images, invalidating odex files that referenced image offsets.

We discovered that:

Dalvik checks modtime/crc.

ART checks checksum/image_checksum/image_offset.

Because OTA replaces the system image, the odex offsets become wrong, leading to long loading times (up to several seconds) and crashes.

To address this, we introduced platform‑specific Dex composition: full‑Dex synthesis for Dalvik and small‑Dex synthesis for ART, dramatically reducing patch size on ART and avoiding OTA‑related address issues.

4. Other Technical Challenges

Additional problems included:

Conflicts with Xposed‑based WeChat plugins, causing pre‑verification crashes on Dalvik and class‑version mismatches on ART. We resolve this by clearing patches when Xposed is detected.

Dex reflection succeeded but had no effect on some Samsung Android‑19 devices due to class‑loading order. We added a runtime check that flips an internal flag to verify successful reflection.

Tinker v1.0 Summary

1. Performance

Patch size : usually under 10 KB.

Runtime impact : almost none; only a 2% overhead from MD5 verification.

ART solution : revolutionary platform‑specific composition solves address offset and ROM size issues.

2. Success Rate

Application success rate = (number of devices that upgraded to the patch version) / (number of devices on the baseline version)

Three days after release, 94.1% of baseline users successfully upgraded. The figure is slightly conservative because baseline numbers keep growing and some users may switch versions.

By comparison, the Qzone solution achieved about 96.3% success in the same period, indicating room for further optimization.

3. Tinker v2.0 – Pursuing Stability

While v1.0 addressed performance, stability and compatibility under “high‑availability” remain critical. v2.0 will focus on comprehensive monitoring, automatic rollback, and robust exception handling; details will be covered in a future article.

Follow Tinker on GitHub and give it a star:

https://github.com/Tencent/tinker