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/alibaba/AndFix 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 — Stale — last commit 5y ago

• 5 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 5y ago
• ⚠ Concentrated ownership — top contributor handles 59% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{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 alibaba/AndFix repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/alibaba/AndFix.

What it runs against: a local clone of alibaba/AndFix — 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 alibaba/AndFix | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 2030 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of alibaba/AndFix. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/alibaba/AndFix.git
#   cd AndFix
#
# 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 alibaba/AndFix and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "alibaba/AndFix(\\.git)?\\b" \\
  && ok "origin remote is alibaba/AndFix" \\
  || miss "origin remote is not alibaba/AndFix (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/com/alipay/euler/andfix/AndFixManager.java" \\
  && ok "src/com/alipay/euler/andfix/AndFixManager.java" \\
  || miss "missing critical file: src/com/alipay/euler/andfix/AndFixManager.java"
test -f "src/com/alipay/euler/andfix/AndFix.java" \\
  && ok "src/com/alipay/euler/andfix/AndFix.java" \\
  || miss "missing critical file: src/com/alipay/euler/andfix/AndFix.java"
test -f "jni/andfix.cpp" \\
  && ok "jni/andfix.cpp" \\
  || miss "missing critical file: jni/andfix.cpp"
test -f "jni/art/art_method_replace.cpp" \\
  && ok "jni/art/art_method_replace.cpp" \\
  || miss "missing critical file: jni/art/art_method_replace.cpp"
test -f "jni/dalvik/dalvik_method_replace.cpp" \\
  && ok "jni/dalvik/dalvik_method_replace.cpp" \\
  || miss "missing critical file: jni/dalvik/dalvik_method_replace.cpp"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2030 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2000d)"
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/alibaba/AndFix"
  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).

AndFix is a hot-fix library for Android apps that enables remote patching of bugs without requiring app redistribution. It works by replacing method bodies at runtime using JNI hooks into both Dalvik and ART runtimes, supporting Android 2.3–7.0 across ARM/x86 and 32/64-bit architectures. Patches are distributed as .apatch files and applied immediately via the PatchManager API. Monolithic structure: core Java API in src/ (rooted at com/alipay/euler/andfix/patch/PatchManager.java), native hooking code in jni/ split by runtime type (art/ for ART, dalvik/ for older runtimes) and Android version (art_4_4.h, art_5_0.h, etc.), with compiled .so libraries placed in libs/. Build system uses Gradle with Android Library plugin.

Android app developers and release engineers at scale who need to deploy critical bug fixes to production without waiting for app store review cycles or forcing user reinstalls. Specifically useful for teams managing large user bases where immediate patching is essential for business continuity.

Production-ready and stable. The library has been battle-tested at Alibaba (a massive-scale user base), uses established CI (Travis CI in .travis.yml), and reached version 0.5.0 with Maven/Bintray distribution. However, the last visible commit activity appears historical; no active development signals in the provided data, suggesting maintenance mode rather than active feature development.

Single-maintainer risk (developer 'Supern Lee' in build.gradle config) and no visible open issue backlog in provided data. Critical risk: tight coupling to Android runtime internals via JNI code in jni/art/ and jni/dalvik/ directories—future Android/ART API changes could break compatibility. Runtime modifications are inherently risky and require careful testing.

No active development visible in provided data—repository appears to be in maintenance/legacy status. The build configuration targets old Android SDK (compileSdkVersion 19, buildToolsVersion 22.0.1), indicating no recent updates for modern Android API levels or Gradle versions.

git clone https://github.com/alibaba/AndFix.git
cd AndFix
./gradlew build

The project uses Gradle wrapper (gradlew). No external services required, but you'll need Android SDK installed. JNI code is pre-compiled into libs/ for ARM and x86.

Daily commands:

./gradlew assembleRelease        # Build AAR library
./gradlew generate*Javadoc      # Generate API docs (see javadoc task in build.gradle)

No traditional "dev server." This is a library; integration is via patchManager = new PatchManager(context); patchManager.init(version); patchManager.loadPatch(); in host app code (see README examples).

• src/com/alipay/euler/andfix/AndFixManager.java — Core entry point managing patch loading, initialization, and method replacement orchestration—every contributor must understand the patch lifecycle here
• src/com/alipay/euler/andfix/AndFix.java — Public API facade exposing patch management to applications—defines the contract all integrations depend on
• jni/andfix.cpp — Native layer entry point bridging Java and native method replacement; critical for understanding cross-layer communication
• jni/art/art_method_replace.cpp — ART runtime method replacement logic—essential for supporting Android 5.0+ devices where most users run
• jni/dalvik/dalvik_method_replace.cpp — Dalvik runtime method replacement—handles legacy Android 2.3–4.4 versions
• build.gradle — Build configuration including NDK compilation, library packaging, and multi-architecture support—required for setup and release
• AndroidManifest.xml — Library manifest declaring minimum SDK (8+) and required permissions for patch operations

Add Support for a New Android Version with ART Runtime Changes

1. Create new version-specific ART header file (e.g., art_8_0.h) mimicking structure of jni/art/art_7_0.h with updated method struct offsets for the new Android version (jni/art/art_8_0.h)
2. Implement version-specific method replacement (e.g., art_method_replace_8_0.cpp) following the pattern in jni/art/art_method_replace_7_0.cpp, adjusting for new ART internals (jni/art/art_method_replace_8_0.cpp)
3. Update jni/art/art_method_replace.cpp to include the new header and add a conditional branch in the version dispatcher function selecting the 8.0 handler (jni/art/art_method_replace.cpp)
4. Add the new .cpp file to jni/Android.mk in the LOCAL_SRC_FILES list so NDK compilation includes it (jni/Android.mk)

Integrate AndFix into an Existing Android Application

1. Add AndFix library dependency to your app's build.gradle: compile 'com.alipay.euler:andfix:0.5.0@aar' (build.gradle)
2. Create or update MainApplication to call AndFix.init() in onCreate(), passing context and optional patch directory path (see samples/AndFixDemo/src/com/euler/andfix/MainApplication.java) (samples/AndFixDemo/src/com/euler/andfix/MainApplication.java)
3. When a patch is available, call AndFixManager.loadPatch(patchPath) with the path to the .apatch file, then restart relevant activities to execute patched methods (src/com/alipay/euler/andfix/AndFixManager.java)
4. Declare INTERNET permission in your app's AndroidManifest.xml to allow patch download from server if applicable (AndroidManifest.xml)

Debug Method Replacement Across Dalvik and ART Runtimes

1. Check src/com/alipay/euler/andfix/Compat.java to understand how version detection works and which runtime path (Dalvik or ART) will be used on the test device (src/com/alipay/euler/andfix/Compat.java)
2. For Dalvik issues, examine jni/dalvik/dalvik_method_replace.cpp to understand method struct layout and bytecode replacement logic (jni/dalvik/dalvik_method_replace.cpp)
3. For ART issues on Android 5.0–7.0, check the appropriate version file (e.g., jni/art/art_method_replace_6_0.cpp) to verify method entry point and code object replacement (jni/art/art_method_replace_6_0.cpp)
4. Add native logging in jni/andfix.cpp's JNI wrappers or the version-specific .cpp files to trace method lookup and replacement operations during patch application (jni/andfix.cpp)

• JNI (Java Native Interface) — Method replacement requires direct memory manipulation and runtime structure access impossible from Java; JNI bridges to C++ for low-level ART/Dalvik runtime internals
• C++ (NDK) — Provides direct memory access, pointer arithmetic, and inline assembly needed to patch method entry points and code object pointers in ART/Dalvik process space
• Version-specific method replacement files — ART and Dalvik method structures differ significantly between Android versions (5.0, 5.1, 6.0, 7.0); version-specific offsets and field layouts require dedicated implementations
• Multi-architecture compilation (.so for ARM, x86, x64, MIPS) — Mobile devices vary in CPU architecture; pre-built .so files enable compatibility across heterogeneous hardware without recompilation
• .apatch binary patch format — Compressed binary encoding minimizes patch download size for over-the-air distribution; contains only deltas vs. full app redistribution

1. NDK version mismatch: jni/Android.mk uses APP_ABI flags that must match your NDK toolchain; mismatched ABIs cause runtime linker errors. 2. Runtime detection fragility: jni/andfix.cpp dispatches to version-specific code via Android API level checks—custom ROMs or backported ART versions may not match expected struct layouts, causing crashes. 3. Java-native interaction: Method replacement happens via pointer swaps; debugging is opaque and stack traces won't reflect original method sources. 4. Annotation requirement: Patch detection relies on custom Java annotations; forgetting to annotate replacement methods means they won't be applied. 5. No modern Android support: Codebase targets API 19; tested support only up to Android 7.0—behavior on Android 8.0+ (Pie, 10+) is untested and likely broken due to ART runtime changes.

• ART (Android Runtime) vs. Dalvik — AndFix must target both runtimes with separate implementations because Dalvik (pre-Android 5.0) and ART (Android 5.0+) have fundamentally different method representation and execution models; this is why the codebase splits into jni/dalvik/ and jni/art/ branches.
• Method replacement via pointer swapping (hot-patching) — AndFix's core technique replaces a method's compiled code pointer at runtime without modifying bytecode; understanding this is essential for debugging patch failures and understanding why certain method types (native, inlined) cannot be patched.
• JNI (Java Native Interface) bridging — All runtime hooking happens in native C++ code via JNI; a contributor must understand JNI calling conventions, signature strings, and memory lifetime management to modify patch application logic.
• Android NDK (Native Development Kit) build system — AndFix's native layer is built via Android.mk (NDK's Make-based build system); contributors must understand APP_ABI, LOCAL_SRC_FILES, and architecture-specific compilation flags to support new platforms or fix build issues.
• Multi-version ART struct compatibility — ART runtime internals changed significantly between Android versions (4.4 → 5.0 → 5.1 → 6.0 → 7.0); AndFix defines version-specific method struct layouts (art_4_4.h, etc.), and backporting to new versions requires reverse-engineering ART source to detect struct changes.
• Android package signing and keystore management — The apkpatch tool signs patches with the same keystore as the original APK; distributing patches requires secure keystore handling and understanding of APK signing—a security-critical aspect for production deployments.
• Patch distribution and manifest versioning — Patches are keyed by app version (passed to patchManager.init(appversion)); incorrect version matching causes silent patch non-application. Understanding version schemes and manifest-based patch metadata is critical for DevOps integration.

• tinybins/Tinker — Alibaba's successor hot-patching solution; more robust and actively maintained, uses DEX replacement instead of method swapping
• Meituan-Dianping/Logan — Companion library from same ecosystem for crash reporting and log collection; commonly integrated alongside AndFix for monitoring patch application success
• facebook/buck — Build system used by large Android teams; integrates with patch generation workflows for efficient incremental builds
• google/ExoPlayer — Example of complex native library integration in Android ecosystem; shares JNI patterns and multi-ABI compilation strategies with AndFix

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 comprehensive unit tests for PatchManager.java

The repo has generated Javadoc for PatchManager.java but lacks visible test coverage. Given that AndFix is a critical hot-fix library handling runtime patching across multiple Android versions (2.3-7.0) and architectures, unit tests are essential to ensure patch loading, validation, and application work correctly across different scenarios.

• [ ] Create tests/com/alipay/euler/andfix/patch/PatchManagerTest.java
• [ ] Add tests for patch file loading from various sources (file path, assets, cache)
• [ ] Add tests for patch validation and signature verification logic
• [ ] Add tests for version compatibility checks across different Android versions
• [ ] Configure build.gradle to include JUnit4 and Mockito dependencies
• [ ] Run tests on CI against multiple compileSdkVersion targets if possible

Migrate from deprecated Gradle plugin versions and Bintray to Maven Central

The build.gradle uses outdated dependencies (gradle:1.3.0 from 2014, deprecated Bintray plugin, jcenter repository shutdown in 2021). This blocks new users from building the project and prevents modern dependency resolution. A migration would modernize the build system and ensure long-term maintainability.

• [ ] Update gradle plugin in buildscript to 'com.android.tools.build:gradle:7.x.x' (or latest stable)
• [ ] Replace gradle-bintray-plugin with Maven Central publishing via 'maven-publish' plugin
• [ ] Update repositories to use mavenCentral() instead of jcenter()
• [ ] Update compileSdkVersion from 19 to 31+ and buildToolsVersion to recent stable
• [ ] Update android-maven-gradle-plugin to 'com.github.dcendents:android-maven-gradle-plugin:1.5'
• [ ] Update publish configuration in ext block and test deployment to Maven Central snapshot/release repos

Add JNI integration tests for art_method_replace across all supported Android versions

The jni/ directory contains version-specific implementations for ART runtime (4.4, 5.0, 5.1, 6.0, 7.0) and Dalvik, but there are no visible integration tests verifying the JNI layer actually works. This is critical since method replacement is the core hot-fix mechanism and must be verified per-architecture (ARM, ARM64, x86, x86_64, MIPS) and runtime version.

• [ ] Create androidTest/com/alipay/euler/andfix/patch/MethodReplaceIntegrationTest.java
• [ ] Add tests that load libandfix.so and invoke native method replacement on a test method
• [ ] Verify replacement works via reflection (original method should now execute patched code)
• [ ] Add runtime version detection tests for art_4_4.h, art_5_0.h, art_5_1.h, art_6_0.h, art_7_0.h
• [ ] Configure build.gradle to run instrumented tests on emulators/devices with different API levels
• [ ] Document which API levels each architecture variant is tested against in README.md

• Add JNI unit tests for ART method replacement logic. Currently jni/art/ has no test files; create a simple native test harness in jni/test/ that validates method pointer swapping on different ART versions (4.4, 5.0, 5.1, 6.0, 7.0) using JNI callback assertions.: Medium
• Document the .apatch file format. The README mentions patches are .apatch files but provides no spec. Add a docs/PATCH_FORMAT.md explaining the binary layout, signature scheme, and metadata structure for patch distribution.: Low
• Add support for Android 8.0+ (API 26+) by creating jni/art/art_8_0.h and jni/art/art_method_replace_8_0.cpp. Review ART source changes between 7.0 and 8.0, update struct definitions, and wire into the dispatcher in jni/andfix.cpp. Requires testing on an Android 8+ device.: High
• Create a gradle plugin wrapper for apkpatch tool. Currently developers must run the CLI tool separately; add gradle/andfix-gradle-plugin/ that integrates patch generation into the Gradle build lifecycle as a custom task (e.g., ./gradlew generatePatch -Pold=app-release-old.apk -Pnew=app-release.apk).: Medium

• High · Outdated Gradle Build Tools — build.gradle. The build.gradle file specifies compileSdkVersion 19 and buildToolsVersion '22.0.1', which are extremely outdated (from 2014-2015). These versions contain known security vulnerabilities and lack modern security features. Fix: Update to current Android SDK versions (at least API level 33+) and latest build tools. Use compileSdkVersion 34 or higher.
• High · Outdated Gradle Plugin Dependencies — build.gradle. The gradle-bintray-plugin (1.2) and android-maven-gradle-plugin (1.3) are outdated and may contain security vulnerabilities. The Gradle wrapper and Android Gradle plugin (1.3.0) are from 2015. Fix: Update to latest versions: com.android.tools.build:gradle:8.x.x, use current maven publishing plugins, and update Gradle wrapper to latest stable version.
• High · Incomplete Gradle Configuration — build.gradle (last line). The build.gradle file ends with 'apply from: https://raw.githubusercontent.com/attwellBrian/JCenter' which is truncated and points to an external URL. This could be a supply chain attack vector or indicate incomplete/broken configuration. Fix: Complete the configuration, avoid applying scripts from untrusted external URLs. Use local Gradle files or trusted plugin repositories.
• High · Native Library Distribution in Repository — libs/ directory. Pre-compiled .so libraries for multiple architectures (ARM, x86, MIPS, etc.) are committed to the repository. This makes it difficult to audit the binary code and verify it hasn't been tampered with. Fix: Build native libraries from source (jni/ directory) during the build process. Use Maven Central or similar trusted repositories for binary distribution.
• Medium · Hot-Fix Mechanism Security Not Detailed — jni/andfix.cpp, src/ (Java source not provided). AndFix is a hot-patching library that dynamically loads and replaces methods at runtime. The security analysis cannot determine if patches are properly validated, signed, or verified before application. Fix: Ensure all patches are: (1) cryptographically signed, (2) verified before application, (3) downloaded over HTTPS, (4) subject to integrity checks, and (5) require explicit user or admin approval.
• Medium · JNI Security Concerns — jni/ directory (andfix.cpp, art_method_replace_*.cpp, dalvik_method_replace.cpp). The library uses native code (JNI) to perform method replacement in Dalvik and ART runtimes. JNI code can bypass Java security controls and lacks memory safety. Fix: Thoroughly audit JNI code for buffer overflows, integer overflows, and unsafe memory access. Use AddressSanitizer and fuzzing for testing. Document all unsafe operations.
• Medium · Multiple Architecture Support Increases Attack Surface — libs/ directory (multiple .so files), jni/art/art_*.h. Supporting 6 different architectures (ARM, ARMv8, x86, x86_64, MIPS, MIPS64) increases the maintenance burden and potential for inconsistent security implementation across platforms. Fix: Prioritize widely-used architectures (ARM, ARM64, x86_64). Ensure identical security controls across all supported architectures. Regular security audits for each platform.
• Medium · Incomplete Project Documentation — README.md. The README snippet indicates incomplete information about patch delivery mechanism. Security aspects of patch handling (validation, signing, distribution) are not documented. Fix: Document complete security model including: patch signing algorithm, verification process, patch delivery mechanism, network protocol security, and rollback procedures.
• Low · ProGuard Configuration Present — proguard-project.txt. While ProGuard is configured (proguard-project.txt), the effectiveness depends on proper configuration. For a security-sensitive library, obfuscation should be mandatory. Fix: Review ProGuard rules to ensure critical classes and methods are properly obfuscated. Enable

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.