How to Modify or Patch an Android Application: A Complete Reverse Engineering Guide

You can modify or patch an Android application by decompiling the APK into readable Java or Kotlin source, editing the specific logic you want to change, and then recompiling, signing, and reinstalling the package.

The Android Reverse-Engineering Skill—an open-source Claude-Code plugin hosted at SimoneAvogadro/android-reverse-engineering-skill—automates the heavy lifting of this workflow. It provides a pipeline that transforms binary APK, XAPK, JAR, or AAR files into editable source code and helps locate the exact methods you need to patch.

Understanding the Five-Phase Patch Workflow

According to the SKILL.md file, the skill organizes modification work into five distinct phases. Understanding this architecture helps you choose the right script for each step.

Phase	Purpose	Core Script
Dependency Verification	Ensures jadx, fernflower/vineflower, and dex2jar are installed.	check-deps.sh
Decompilation	Converts the APK into Java sources using jadx, fernflower, or both.	decompile.sh
Structure Analysis	Prints the top-level package tree to help you navigate the codebase.	print_structure function in decompile.sh
API Discovery	Locates network calls, URLs, and authentication patterns.	find-api-calls.sh
Patch Workflow	User-driven editing of the decompiled sources followed by manual rebuild.	External Android toolchain (Gradle/APKTool)

Step-by-Step Guide to Modify an Android App

Prepare the Environment

Before patching, verify that your system meets the tool requirements. The skill requires Java 17+, jadx, and optionally fernflower/vineflower and dex2jar for advanced decompilation.

Run the dependency checker from the repository root:

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/check-deps.sh

If the script emits INSTALL_REQUIRED:<dep>, use the provided installer:

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/install-dep.sh <dep>

Decompile the Target APK

The decompile.sh script handles the conversion. It parses CLI arguments (--engine, --deobf, --no-res) and automatically runs dex2jar on APK/AAR files when using the Fernflower engine.

Choose the engine based on your needs:

# Fast analysis with jadx (best for quick patches)

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/decompile.sh \
    --engine jadx app-release.apk

# High-quality Java output with fernflower (requires dex2jar)

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/decompile.sh \
    --engine fernflower app-release.apk

# Side-by-side comparison

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/decompile.sh \
    --engine both --deobf app-release.apk

The script creates <filename>-decompiled/ with a sources/ subfolder containing the decompiled Java/Kotlin files. It also runs the print_structure function to display the top-level package tree using find … -mindepth 1 -maxdepth 3, helping you navigate the codebase.

Locate Code to Patch

Before editing, identify the specific methods or constants you need to modify. The find-api-calls.sh script constructs targeted grep -E commands to find Retrofit, OkHttp, Volley calls, hard-coded URLs, and authentication patterns.

Search for all API-related code:

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/find-api-calls.sh \
    app-release-decompiled/sources/ --all

Or target specific libraries:

# Retrofit endpoints only

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/find-api-calls.sh \
    app-release-decompiled/sources/ --retrofit

# Hard-coded URLs

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/find-api-calls.sh \
    app-release-decompiled/sources/ --urls

The output format file:line:match (e.g., src/com/example/api/ApiService.java:42:@GET("/login")) allows you to navigate directly to the code that needs patching.

Edit the Decompiled Sources

Once you have identified the target files, modify them using any text editor or IDE. The decompiled output from decompile.sh preserves the original package hierarchy, making it straightforward to feed the sources back into a build system.

Common patch scenarios include:

• Changing API endpoints: Replace hard-coded URLs in constants or @GET/@POST annotations.
• Bypassing checks: Modify conditional logic that validates licenses or authentication tokens.
• Injecting logging: Add System.out.println or logging calls to trace execution flow.

Example modification:

// File: app-release-decompiled/sources/com/example/api/Config.java
// Before
public class Config {
    public static final String API_BASE = "https://prod.example.com/v1/";
    public static final boolean DEBUG = false;
}

// After patching
public class Config {
    public static final String API_BASE = "https://staging.example.com/v1/";
    public static final boolean DEBUG = true;  // Enable debug logging
}

Rebuild the APK

The Android Reverse-Engineering skill does not include a recompiler, so you must use standard Android toolchain to rebuild the application from your edited sources.

Option A: Gradle (Recommended for Java source)

If you can reconstruct a minimal Android project structure around the decompiled sources:

# Create a basic build.gradle pointing to your edited sources

# See the setup-guide.md for project structure templates

./gradlew assembleRelease

Option B: APKTool (For Smali/DEX manipulation)

If you need to work at the bytecode level or prefer not to manage a full Gradle project:

# Decompile to smali (if not already done)

apktool d app-release.apk -o temp_apk

# Replace or edit smali files, or convert your edited Java to dex:

# javac -cp android.jar com/example/api/Config.java

# d8 --output temp_apk/smali/com/example/api/ Config.class

# Rebuild

apktool b temp_apk -o app-patched.apk

Sign the Patched APK

Android requires all APKs to be digitally signed before installation. For testing purposes, generate a debug keystore:

# Generate debug keystore

keytool -genkeypair -alias debug -keyalg RSA -keysize 2048 -validity 3650 \
    -keystore debug.keystore -storepass android -keypass android \
    -dname "CN=Debug, OU=Debug, O=Debug, L=Debug, S=Debug, C=US"

# Sign the APK

apksigner sign --ks debug.keystore --ks-pass pass:android \
    --key-pass pass:android --out app-patched-signed.apk app-patched.apk

# Verify signature

apksigner verify -v app-patched-signed.apk

Install and Verify

Deploy the signed APK to a device or emulator to confirm your patches work correctly:

# Install (replace existing if present)

adb install -r app-patched-signed.apk

# Monitor logs to verify patch behavior

adb logcat -s "MyAppTag:D" *:S

Key Technical Files in the Repository

File	Purpose	Location
SKILL.md	Defines the five-phase workflow (dependency check → decompile → structure analysis → call-flow tracing → API extraction) triggered by the /decompile command.	plugins/android-reverse-engineering/skills/android-reverse-engineering/SKILL.md
decompile.sh	Core decompilation engine that orchestrates jadx, fernflower, and dex2jar. Handles XAPK extraction, deobfuscation flags (--deobf), and resource filtering (--no-res).	plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/decompile.sh
find-api-calls.sh	Greps decompiled sources for network patterns (Retrofit, OkHttp, Volley, URLs, auth tokens). Outputs file:line:match format for precise navigation.	plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/find-api-calls.sh
check-deps.sh	Validates presence of required external tools (jadx, fernflower, dex2jar). Emits INSTALL_REQUIRED directives if dependencies are missing.	plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/check-deps.sh
setup-guide.md	Installation instructions for Java 17+, Jadx, Fernflower/Vineflower, and dex2jar.	plugins/android-reverse-engineering/skills/android-reverse-engineering/references/setup-guide.md

Summary

• The Android Reverse-Engineering skill provides an automated pipeline for SimoneAvogadro/android-reverse-engineering-skill that converts binary APKs into editable Java/Kotlin source.
• Use decompile.sh to generate readable sources via jadx (fast) or fernflower (high-quality), with automatic handling of XAPK bundles and obfuscation.
• Use find-api-calls.sh to rapidly locate network logic, hard-coded URLs, and authentication checks within the decompiled tree.
• Modify the extracted sources using standard IDEs; the preserved package structure makes integration into Gradle or APKTool workflows straightforward.
• Rebuild and resign using standard Android tooling (apktool, d8, apksigner) to produce a deployable, patched APK.

Frequently Asked Questions

What is the difference between Jadx and Fernflower decompilation engines?

Jadx provides the fastest decompilation and is ideal for quick analysis and rapid iteration when modifying an Android application. Fernflower (or Vineflower) produces cleaner, more readable Java code that closely resembles original source structure, but requires dex2jar as a preprocessing step and takes longer to run. According to the decompile.sh implementation, you can use --engine both to generate outputs from both engines for side-by-side comparison.

Can the Android Reverse-Engineering skill automatically recompile my patched code into an APK?

No, the skill intentionally stops at the source-code level and does not provide automatic recompilation. The SKILL.md workflow defines five phases: dependency check, decompilation, structure analysis, call-flow tracing, and API extraction. After editing the decompiled sources in the <filename>-decompiled/sources/ directory, you must use standard Android tooling such as Gradle, APKTool, or the Android SDK (javac + d8) to rebuild the DEX bytecode and package the APK.

How do I locate specific network API calls when patching an Android app?

Use the find-api-calls.sh script to search the decompiled source tree for network-related patterns. This script constructs optimized grep -E commands to detect Retrofit annotations (@GET, @POST), OkHttp client builders, Volley request queues, hard-coded URLs, and authentication token patterns. The output format (file:line:match) allows you to navigate directly to the specific line in the decompiled Java or Kotlin file that needs modification.

Is it legal to modify or patch Android applications using these techniques?

Modifying or patching Android applications is legally permissible only when you own the application, have explicit permission from the copyright holder, or are conducting security research within the bounds of applicable laws such as the Computer Fraud and Abuse Act (CFAA) in the United States or similar fair-use provisions in your jurisdiction. The android-reverse-engineering-skill repository is designed for legitimate security analysis, debugging, and educational purposes. Never distribute patched versions of proprietary software without authorization, as this violates copyright law and the terms of service of most application stores.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}