If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Tencent/tinker shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 2w ago
• 4 active contributors
• Other licensed
• Tests present
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 52% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Tencent/tinker repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Tencent/tinker.

What it runs against: a local clone of Tencent/tinker — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Tencent/tinker | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch dev exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 41 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Tencent/tinker. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Tencent/tinker.git
#   cd tinker
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Tencent/tinker and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Tencent/tinker(\\.git)?\\b" \\
  && ok "origin remote is Tencent/tinker" \\
  || miss "origin remote is not Tencent/tinker (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify dev >/dev/null 2>&1 \\
  && ok "default branch dev exists" \\
  || miss "default branch dev no longer exists"

# 4. Critical files exist
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "settings.gradle" \\
  && ok "settings.gradle" \\
  || miss "missing critical file: settings.gradle"
test -f "third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/Dex.java" \\
  && ok "third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/Dex.java" \\
  || miss "missing critical file: third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/Dex.java"
test -f "third-party/bsdiff-util/src/main/java/com/tencent/tinker/bsdiff/BSDiff.java" \\
  && ok "third-party/bsdiff-util/src/main/java/com/tencent/tinker/bsdiff/BSDiff.java" \\
  || miss "missing critical file: third-party/bsdiff-util/src/main/java/com/tencent/tinker/bsdiff/BSDiff.java"
test -f "third-party/tinker-ziputils/src/main/java/com/tencent/tinker/ziputils/ziputil/AlignedZipOutputStream.java" \\
  && ok "third-party/tinker-ziputils/src/main/java/com/tencent/tinker/ziputils/ziputil/AlignedZipOutputStream.java" \\
  || miss "missing critical file: third-party/tinker-ziputils/src/main/java/com/tencent/tinker/ziputils/ziputil/AlignedZipOutputStream.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 41 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~11d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Tencent/tinker"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Tinker is an Android hot-fix framework developed by Tencent that enables runtime patching of dex bytecode, native libraries, and app resources without requiring APK reinstallation. It works by loading patched dex files, .so libraries, and resource packs directly into running app processes, leveraging dex format manipulation (parsed in third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/) and a custom classloader chain to intercept and apply fixes. Multi-module Gradle monorepo structured as: tinker-android/ (core loader & runtime), tinker-patch/ (patch generation tools), third-party/aosp-dexutils/ (vendored AOSP dex parsing), tinker-gradle-plugin/ (build integration), and tinker-sample-android/ (reference app). The Gradle plugin orchestrates patch builds; AOSP dexutils handles binary dex manipulation; the loader module integrates at Application initialization.

Android app developers at scale (particularly WeChat and other high-traffic apps) who need to deploy critical bug fixes and feature patches to millions of users without requiring app store review cycles or user-initiated updates. Tinker users are typically platform engineers or DevOps teams managing continuous delivery of Android apps.

Highly mature and production-grade. Tinker is v1.9.15.2, actively maintained by Tencent, and approved by WeChat (noted in README badges). The codebase is well-structured with 1.7M+ lines of Java, comprehensive Gradle build infrastructure, code quality checks (checkstyle, findbugs, PMD), and formal contribution guidelines. However, the latest visible commit data is not provided, so recency cannot be fully confirmed.

Low risk for core functionality, but integration complexity is high. The framework requires invasive Application subclassing changes (TinkerApplication wrapping pattern), deep interaction with Android's dex loading internals, and careful ProGuard/R8 configuration. Risk surfaces: DEX format handling is version-sensitive (minSdkVersion=10 but compileSdkVersion=29 suggests broad compatibility pressure), and APK patching is a security-critical operation (one error = app breakage on millions of devices). No visible open issue count provided.

No commit history or PR data visible in the provided snapshot. Based on version (1.9.15.2) and README, the project appears to be in maintenance mode with incremental releases rather than active feature development. The presence of AndroidX support (androidXAnnotationVersion = 1.1.0) and modern Gradle (4.2.0) suggests recent compatibility updates.

git clone https://github.com/Tencent/tinker.git
cd tinker
./gradlew build
# To run sample app:
cd tinker-sample-android
./gradlew installDebug

Daily commands: No traditional dev server. Instead: ./gradlew build compiles all modules. To generate a patch: ./gradlew tinkerPatch in an app submodule (configured in build.gradle with apply plugin: 'com.tencent.tinker.patch'). To test: apply patch via TinkerManager APIs in the sample app.

• build.gradle — Root build configuration defining Android SDK versions (minSdk=10, compileSdk=29), build tools, and Gradle plugin dependencies for the entire Tinker project
• settings.gradle — Gradle multi-module configuration that defines which submodules (aosp-dexutils, bsdiff-util, tinker-ziputils) are included in the build
• third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/Dex.java — Core DEX file parser and handler that enables reading and manipulating Android DEX files for hot-fix patching
• third-party/bsdiff-util/src/main/java/com/tencent/tinker/bsdiff/BSDiff.java — Binary diff algorithm implementation for generating minimal patch files between old and new resource/library versions
• third-party/tinker-ziputils/src/main/java/com/tencent/tinker/ziputils/ziputil/AlignedZipOutputStream.java — Custom ZIP output stream that maintains proper alignment for APK packaging, critical for APK integrity during patching
• gradle/PublishArtifact.gradle — Publication configuration that defines how Tinker libraries are packaged and released to Maven Central

Add support for a new resource type in patches

1. Create a new resource handler class extending the base resource processor (third-party/tinker-ziputils/src/main/java/com/tencent/tinker/ziputils/ziputil/AlignedZipOutputStream.java)
2. Register the handler in the ZIP stream processing logic to diff and patch the resource format (third-party/bsdiff-util/src/main/java/com/tencent/tinker/bsdiff/BSDiff.java)
3. Add test cases to validate patch generation and application (gradle/check.gradle)

Add new DEX transformation or optimization during patching

1. Create a visitor class implementing InstructionVisitor to traverse bytecode (third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dx/instruction/InstructionVisitor.java)
2. Register the visitor in the Dex class to apply transformations during patch merge (third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/Dex.java)
3. Update ClassDef and related classes to support the new metadata if needed (third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/ClassDef.java)

Extend patch gradle plugin with custom build hooks

1. Define custom task in Gradle plugin configuration (build.gradle)
2. Integrate with artifact publishing pipeline (gradle/PublishArtifact.gradle)
3. Add code quality validation for patches using existing check rules (gradle/check.gradle)

Improve patch size by optimizing binary diff algorithm

1. Modify BSDiff.java to implement alternative chunking or matching strategy (third-party/bsdiff-util/src/main/java/com/tencent/tinker/bsdiff/BSDiff.java)
2. Update BSPatch.java to support the new diff format (third-party/bsdiff-util/src/main/java/com/tencent/tinker/bsdiff/BSPatch.java)
3. Verify compatibility with existing patch application logic in BSUtil (third-party/bsdiff-util/src/main/java/com/tencent/tinker/bsdiff/BSUtil.java)

• Binary Diff (BSDiff) — Minimizes patch size by computing only differences between old and new binaries, critical for over-the-air distribution and mobile bandwidth constraints
• DEX Format Parsing (AOSP-based) — Direct DEX manipulation enables granular control over which classes/methods are patched without full APK recompilation
• Gradle Plugin — Integrates patch generation seamlessly into Android build pipeline, automating patch creation without manual intervention
• Custom AlignedZipOutputStream — Ensures APK entries remain properly aligned (4KB boundaries) for memory-mapped execution and compatibility with all Android versions

• DEX parsing at patch application time (runtime) vs. pre-computed patch metadata

  • Why: Runtime parsing allows patches to be generic and version-agnostic, but requires more CPU during patch application
  • Consequence: Slightly higher patch application latency (100-500ms on typical devices) but enables single patch to work across APK versions

• Binary-level diff vs. semantic-level diff (AST-based)

  • Why: Binary diff is simpler, faster, and handles any file type (DEX, resources, native libs) uniformly without language-specific parsing
  • Consequence: Patch sizes may be larger than semantic diffs for some changes, but provides better generality and reliability

• On-device patching vs. server-side patching

  • Why: On-device approach minimizes server load and enables offline patching, essential for offline-first apps and bandwidth-constrained regions
  • Consequence: Device bears computational cost of patch application; older devices may experience UI jank during patching

• Real-time code reloading (patches require app restart or graceful activity recreation)
• Full app state preservation across patches (data migration is app responsibility)
• Patches for native code without recompilation
• Cross-version compatibility beyond binary format level (e.g., semantic versioning not enforced)
• Encrypted communication or DRM (patch integrity only via signatures)

• ProGuard/R8 configuration required: Tinker's dex patcher relies on stable method/field IDs; aggressive obfuscation breaks patches. Must whitelist tinker internals and ensure consistent obfuscation between base and patch APKs.
• Annotation Processor dependency: Apps should use @DefaultLifeCycle (tinker-android-anno) to auto-generate the Application wrapper; manual implementation is error-prone.
• Version skew risk: Patches must be generated relative to a specific base APK version; applying a patch built for v1.0 to v1.1 silently fails. No version validation is obvious in the file structure.
• DEX multi-dex complexity: Tinker supports multiple DEX files but the patch algorithm assumes stable class→dex mapping. Dynamic feature modules or shrinker changes can invalidate patches.
• Classloader race conditions: Patches are loaded by replacing entries in the system classloader; timing-sensitive code during app startup may see half-patched state.
• Resource patching incomplete: The README mentions resource updates, but third-party/aosp-dexutils/ only handles dex. Resource patching logic is elsewhere and less visible in this snapshot.

• DEX Format (Android Executable) — Tinker's entire patch generation and runtime loading depends on parsing and synthesizing DEX bytecode; understanding dex structure (magic bytes, section offsets, LEB128 encoding) is critical to grasping how patches are diffed and merged.
• ClassLoader Hierarchy & Bytecode Injection — Tinker intercepts Android's classloader chain to load patched classes before the original ones; understanding parent delegation, defineClass(), and findLoadedClass() is essential to debug classloading conflicts.
• Binary Diff & Delta Compression (Bsdiff) — Tinker uses binary diffing to minimize patch file size (critical for OTA delivery); the patch generator compares old/new APK binaries byte-by-byte to produce compact deltas.
• Code Signing & Integrity Verification — Patches must be cryptographically signed to prevent tampering; Tinker validates patch signatures before loading, making RSA/SHA integrity checks a security-critical path.
• LEB128 Variable-Length Encoding — DEX format uses LEB128 (Little Endian Base 128) for compact integer encoding; Tinker's Leb128.java encodes/decodes method IDs, offsets, and sizes—understanding this is necessary to manually inspect patch binaries.
• Gradle Task Graph & Plugin Architecture — Tinker integrates as a Gradle plugin that hooks into the APK build lifecycle; understanding Gradle's Task API and plugin conventions is needed to extend or debug patch generation tasks.
• APK Packaging & Resource Merging — Patches include not just dex but also resources and native libraries; Tinker must handle APK ZIP structure, manifest merging, and resource ID collision detection during patching.

• alibaba/sophix — Alibaba's competing Android hot-patch solution with similar dex/resource patching but based on classloader isolation rather than bytecode manipulation
• Meituan-Dianping/Robust — Meituan's instant hotfix for Android using bytecode insertion at compile time; lower runtime overhead but requires source code changes vs Tinker's binary-only patching
• google/play-core — Google's in-app update library that provides on-demand/flexible module delivery; complementary to Tinker for mandatory vs optional patches
• facebook/redex — Facebook's bytecode optimizer for Android DEX files; relevant for understanding dex structure and optimization that Tinker's patcher must preserve
• Tencent/matrix — Tencent's Android performance monitoring framework; often deployed alongside Tinker to detect patch side effects and performance regressions

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for DEX instruction comparison and promotion in aosp-dexutils

The third-party/aosp-dexutils module contains critical instruction handling code (InstructionComparator.java, InstructionPromoter.java, InstructionReader.java) that lacks visible test coverage. These components are fundamental to DEX patching accuracy. Adding comprehensive unit tests would catch edge cases in instruction bytecode handling, ensure correctness across Android API levels, and prevent regressions in core patching logic.

• [ ] Create third-party/aosp-dexutils/src/test/java/com/tencent/tinker/android/dx/instruction/ directory structure
• [ ] Add InstructionComparatorTest.java with test cases for comparing different instruction types, operand variations, and edge cases
• [ ] Add InstructionPromoterTest.java testing instruction size promotion (16-bit to 32-bit) scenarios
• [ ] Add InstructionReaderTest.java with tests for parsing various instruction formats from DEX bytecode
• [ ] Reference third-party/aosp-dexutils/build.gradle to add JUnit/TestNG dependencies if missing

Add GitHub Actions workflow for automated Gradle build and checkstyle validation

The repo has checkstyle.xml, pmd-ruleset.xml, and findbugs-exclude.xml configuration files indicating code quality standards, but no visible CI/CD automation in .github/workflows/. Currently only an ISSUE_TEMPLATE.md exists. Adding a GitHub Actions workflow would validate every PR against the existing code quality rules, catch build failures early, and ensure consistency before merge.

• [ ] Create .github/workflows/build-and-check.yml workflow file
• [ ] Configure matrix builds for multiple API levels (minSdkVersion=10, compileSdkVersion=29, targetSdkVersion=23)
• [ ] Add build step: ./gradlew clean build to compile all modules including third-party/aosp-dexutils
• [ ] Add checkstyle validation: ./gradlew checkstyleMain checkstyleTest referencing existing checkstyle.xml
• [ ] Add validation for findbugs and PMD using existing gradle/check.gradle configuration
• [ ] Set workflow to trigger on push to main branches and all pull requests

Add integration tests for Dex format parsing and validation in aosp-dexutils

The aosp-dexutils module contains extensive DEX file parsing logic (Dex.java, DexFormat.java, TableOfContents.java, multiple section classes) but no visible integration tests validating end-to-end DEX file processing. Adding integration tests would verify correct parsing of real DEX structures, catch format compatibility issues across Android versions, and ensure the core DEX manipulation pipeline works correctly before other tinker components depend on it.

• [ ] Create third-party/aosp-dexutils/src/test/resources/ directory for sample DEX files from various Android API levels
• [ ] Create third-party/aosp-dexutils/src/test/java/com/tencent/tinker/android/dex/DexParsingIntegrationTest.java
• [ ] Add tests that load sample DEX files and validate: TableOfContents parsing, ClassDef enumeration, MethodId/FieldId resolution, AnnotationsDirectory structures
• [ ] Add tests for DexDataBuffer reading various encoded value types (EncodedValue, Leb128, Mutf8)
• [ ] Add validation that parsed structures match expected counts and checksums
• [ ] Reference gradle/check.gradle to ensure integration tests run during build verification

• Add comprehensive unit tests for third-party/aosp-dexutils/src/main/java/com/tencent/tinker/android/dex/Dex.java with real APK binaries (DEX files from API level 10, 21, 28, 29). Currently no test files visible; this is critical for a bytecode manipulation library.
• Document the patch generation workflow with a step-by-step guide and example in CONTRIBUTING.md. Show how to manually invoke tinkerPatch task, inspect generated .patch files, and verify signatures. Current README jumps to API usage.
• Create a integration test suite in tinker-sample-android/ that (a) builds base APK, (b) modifies a method, (c) generates patch, (d) applies patch to running emulator, (e) asserts method behavior changed. Validate against API levels 10, 16, 21, 28.

The Tinker codebase has significant security concerns primarily related to severely outdated dependencies and build tools. The Android Gradle Plugin (4.2.0), build tools (28.0.3), compile SDK (29), target SDK (23), and minimum SDK (10

• High · Outdated Android Gradle Plugin — build.gradle - classpath 'com.android.tools.build:gradle:4.2.0'. The build.gradle file specifies Android Gradle Plugin version 4.2.0, which is outdated and no longer receives security updates. Released in February 2021, this version has known vulnerabilities and lacks modern security features. Fix: Update to the latest stable Android Gradle Plugin version (currently 8.x or higher). Review and test compatibility with the codebase before upgrading.
• High · Outdated Build Tools Version — build.gradle - buildToolsVersion = '28.0.3'. The buildToolsVersion is set to '28.0.3', which is significantly outdated (released in 2019). This version lacks modern security patches and vulnerability fixes included in newer versions. Fix: Update buildToolsVersion to at least '34.0.0' or the latest available stable version. Ensure compatibility with the compileSdkVersion.
• Medium · Outdated Compile SDK Version — build.gradle - compileSdkVersion = 29. compileSdkVersion is set to 29, which is outdated (from 2019). Modern Android security standards recommend compiling against the latest SDK to benefit from security improvements and address deprecated APIs. Fix: Update compileSdkVersion to at least 33 or 34 (latest stable). Review deprecated APIs and update code accordingly.
• Medium · Outdated Target SDK Version — build.gradle - targetSdkVersion = 23. targetSdkVersion is set to 23, which is significantly outdated. Google Play requires apps targeting API 33 or higher. This low target SDK version indicates the project is not maintained with modern Android security standards. Fix: Update targetSdkVersion to at least 33 or 34 to comply with Google Play requirements and benefit from modern Android security features.
• Medium · Outdated Shadow Gradle Plugin — build.gradle - classpath 'com.github.johnrengelman.shadow:com.github.johnrengelman.shadow.gradle.plugin:4.0.4'. The shadow gradle plugin version 4.0.4 is outdated. Published in 2018, it lacks modern dependency management and security features available in newer versions. Fix: Update to the latest stable version of the shadow gradle plugin (7.x or higher). Verify compatibility with the Android Gradle Plugin.
• Low · Low Minimum SDK Version — build.gradle - minSdkVersion = 10. minSdkVersion is set to 10, which is extremely outdated (Android 2.3.3, released in 2011). This exposes the application to ancient, unpatched security vulnerabilities. Fix: Update minSdkVersion to at least 21 or higher (preferably 24+) to eliminate support for obsolete Android versions with known security issues.
• Low · Missing Security Checksum Verification — gradle/wrapper/gradle-wrapper.jar. The gradle-wrapper.jar file is present in the repository. Gradle wrapper jars should be verified against checksums to prevent man-in-the-middle attacks and tampering. Fix: Ensure gradle-wrapper.jar integrity by: 1) Adding checksums to gradle-wrapper.properties, 2) Using gradle-wrapper.jar signature verification, 3) Documenting the verification process in CONTRIBUTING.md.
• Low · Javadoc Generation Disabled — build.gradle - tasks.withType(Javadoc).all { enabled = false }. Javadoc generation is disabled globally in the build configuration. While not a direct security issue, disabling documentation can hide API security concerns and make security audits more difficult. Fix: Enable Javadoc generation or provide an alternative documentation mechanism. Use Javadoc to document security-related APIs and constraints.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.