How Meituan’s Robust Hot‑Patch Framework Solves Android Update Challenges

Background

Meituan‑Dianping, China’s largest O2O platform with over 600 million users, requires its Android app to be extremely stable. Traditional release cycles cannot fix critical bugs instantly, prompting the need for a reliable hot‑update mechanism.

Existing Hot‑Update Solutions

Prior Android hot‑update approaches fall into two groups: multidex‑based frameworks (e.g., Nuwa, Tinker) and native‑hook solutions (e.g., AndFix, Dexposed). The former needs a restart to apply patches; the latter requires Dalvik/ART adaptations, native code, and may break on certain instruction sets, especially under Android N’s mixed‑profile compilation.

Instant Run Inspiration and Robust Design

Google’s Instant Run (Android Studio 2.0) demonstrated real‑time code swapping. Meituan built on this idea to create the Robust framework, which inserts a ChangeQuickRedirect field and proxy logic into every method at compile time, completely transparent to business code. public long getIndex() { return 100; } After Robust processing:

public static ChangeQuickRedirect changeQuickRedirect;
public long getIndex() {
    if (changeQuickRedirect != null && PatchProxy.isSupport(new Object[0], this, changeQuickRedirect, false)) {
        return ((Long) PatchProxy.accessDispatch(new Object[0], this, changeQuickRedirect, false)).longValue();
    }
    return 100L;
}

Patch Generation Process

When a method’s behavior changes (e.g., returning 106 instead of 100), Robust generates two classes— PatchesInfoImpl.java and StatePatch.java. The app loads the compiled patch.dex with DexClassLoader, reflects PatchesInfoImpl to discover target classes, and injects the new ChangeQuickRedirect instance.

public class PatchesInfoImpl implements PatchesInfo { ... }
public class StatePatch implements ChangeQuickRedirect { ... }

Problems Encountered in Production

Deploying Robust in Meituan’s main app revealed two critical issues:

Method‑count overflow: Adding proxy fields and methods pushed the total method count over the 65 536 limit, causing dex compilation failures.

ProGuard inlining: Methods that ProGuard would normally inline (single‑line getters/setters) were kept, further inflating the method count. The team added a filter to skip patching methods likely to be inlined, reducing the extra methods to under 1 000.

Impact on APK Size and Runtime Performance

Each instrumented method adds roughly 17.5 bytes; with >60 000 methods, the APK grew from 19.71 MB to 20.73 MB. Runtime overhead was measured on a Huawei 4A device: a pure‑computation method executed 100 000 times took 128 ms longer after instrumentation. Startup time increased by only ~5 ms.

Patch Implementation Details

Two additional challenges were addressed:

Obfuscation: Patch classes are generated before obfuscation, then their bytecode is rewritten using the release‑time mapping file to match the runtime class names.

Super‑method calls: To invoke a superclass method from a patched class, the framework rewrites the invokesuper instruction and ensures the patched class extends the original superclass, allowing correct dispatch without increasing method count.

Online Deployment Results

From July 14 to July 18, Robust patches were rolled out and rolled back based on observed failures. Success metrics showed:

Patch list fetch success rate ≈ 97 % (network‑limited).

Patch download success rate > 99.8 %.

Patch apply success rate > 99.8 %.

Conclusion

Robust offers a higher‑compatibility, near‑real‑time hot‑patch solution compared with existing multidex or native‑hook approaches. While it introduces modest APK size growth and a small runtime cost, the framework’s transparency and ability to handle obfuscation and super calls make it a practical choice for large‑scale Android apps. Future work will focus on reducing method‑count impact and extending support to native libraries and resources.