Android Reverse Engineering
Decompile Android APK, XAPK, JAR, and AAR files using jadx and Fernflower/Vineflower, trace call flows through application code and libraries, and produce structured documentation of extracted APIs. Two decompiler engines are supported — jadx for broad Android coverage and Fernflower for higher-quality output on complex Java code — and can be used together for comparison.
Prerequisites
This skill requires Java JDK 17+ and jadx to be installed. Fernflower/Vineflower and dex2jar are optional but recommended for better decompilation quality. Run the dependency checker to verify:
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/check-deps.sh
On Windows (PowerShell):
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/check-deps.ps1"
If anything is missing, follow the installation instructions in ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/setup-guide.md.
Workflow
Phase 0: Fingerprint the App (recommended before anything else)
Before installing tools or decompiling, run a fast triage to determine what
kind of app you are looking at. Decompiling Java is mostly useless for
Flutter, React Native, Cordova/Capacitor, and Xamarin apps — the real code
lives elsewhere. The fingerprint script tells you which.
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/fingerprint.sh <file.apk|file.xapk>
It prints, in one screen:
- Mobile framework (Flutter / React Native / Cordova / Xamarin / Native Kotlin / etc.) with the file marker that triggered the verdict.
- HTTP stack (Retrofit, OkHttp, Ktor, Apollo, Volley) detected via DEX string scan — works even when class names are obfuscated.
- DI / serialization signals (Hilt, Dagger, Koin, kotlinx.serialization, Moshi, Gson, Jackson).
- Obfuscation level estimate based on root-level short-named packages.
- Notable third-party SDKs (AppsFlyer, Datadog, Sentry, Firebase, payment SDKs, support/chat SDKs, etc.).
- Consolidated native libraries across the base APK and all splits — XAPK split bundles often place
.so files in config.<abi>.apk, not in base.apk.
- Recommended next step, which differs by framework (e.g. for Flutter the script suggests
blutter / strings libapp.so rather than jadx).
If the fingerprint says the app is Flutter / RN / Cordova / Xamarin, stop
and switch to the framework-appropriate tooling. Phases 1–5 below assume a
native (Java/Kotlin) Android app.
Phase 1: Verify and Install Dependencies
Before decompiling, confirm that the required tools are available — and install any that are missing.
Action: Run the dependency check script.
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/check-deps.sh
On Windows (PowerShell):
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/check-deps.ps1"
The output contains machine-readable lines:
INSTALL_REQUIRED:<dep> — must be installed before proceedingINSTALL_OPTIONAL:<dep> — recommended but not blocking
If required dependencies are missing (exit code 1), install them automatically:
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/install-dep.sh <dep>
On Windows (PowerShell):
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/install-dep.ps1" <dep>
The install script detects the OS and package manager, then:
- Installs without sudo when possible (downloads to
~/.local/share/, symlinks in ~/.local/bin/)
- Uses sudo and the system package manager when necessary (apt, dnf, pacman)
- If sudo is needed but unavailable or the user declines, it prints the exact manual command and exits with code 2 — show these instructions to the user
Windows notes: The PowerShell install script uses winget, scoop, or choco (in that order). If none are available, it downloads directly to %USERPROFILE%\.local\share\ and adds the directory to the user's PATH. After running install-dep.ps1, the PATH is persisted but the current terminal session may not see it. The check-deps.ps1 and decompile.ps1 scripts automatically refresh PATH from the user environment, so re-running them will find newly installed tools without restarting the terminal.
For optional dependencies, ask the user if they want to install them. Vineflower and dex2jar are recommended for best results.
After installation, re-run check-deps.sh to confirm everything is in place. Do not proceed to Phase 2 until all required dependencies are OK.
Phase 2: Decompile
Use the decompile wrapper script to process the target file. The script supports three engines: jadx, fernflower, and both.
Action: Choose the engine and run the decompile script. The script handles APK, XAPK, JAR, and AAR files.
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/decompile.sh [OPTIONS] <file>
On Windows (PowerShell):
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/decompile.ps1" [OPTIONS] <file>
For XAPK files (ZIP bundles containing multiple APKs, used by APKPure and similar stores): the script automatically extracts the archive, identifies all APK files inside (base + split APKs), and decompiles each one into a separate subdirectory. The XAPK manifest is copied to the output for reference.
Split/bundled APK detection: Some APKs are actually bundle wrappers — the outer APK contains base.apk plus split_config.*.apk files inside its resources directory. When this happens, jadx will decompile the thin wrapper and produce very few Java files. The decompile scripts automatically detect this (≤10 Java files + inner APKs present) and re-decompile base.apk into an <output>/base/ subdirectory. Config-only splits (ABI, language, density) are skipped. The main decompiled source will be in <output>/base/sources/.
Options:
-o <dir> — Custom output directory (default: <filename>-decompiled)--deobf — Enable deobfuscation (recommended for obfuscated apps)--no-res — Skip resources, decompile code only (faster)--engine ENGINE — jadx (default), fernflower, or both
Engine selection strategy:
| Situation | Engine |
|---|
| First pass on any APK | jadx (fastest, handles resources) |
| JAR/AAR library analysis | fernflower (better Java output) |
| jadx output has warnings/broken code | both (compare and pick best per class) |
| Complex lambdas, generics, streams | fernflower |
| Quick overview of a large APK | jadx --no-res |
When using --engine both, the outputs go into <output>/jadx/ and <output>/fernflower/ respectively, with a comparison summary at the end showing file counts and jadx warning counts. Review classes with jadx warnings in the Fernflower output for better code.
For APK files with Fernflower, the script automatically uses dex2jar as an intermediate step. dex2jar must be installed for this to work.
See ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/jadx-usage.md and ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/fernflower-usage.md for the full CLI references.
Phase 3: Analyze Structure
Navigate the decompiled output to understand the app's architecture.
Actions:
-
Read AndroidManifest.xml from <output>/resources/AndroidManifest.xml:
- Identify the main launcher Activity
- List all Activities, Services, BroadcastReceivers, ContentProviders
- Note permissions (especially
INTERNET, ACCESS_NETWORK_STATE)
- Find the application class (
android:name on <application>)
-
Survey the package structure under <output>/sources/:
- Identify the main app package and sub-packages
- Distinguish app code from third-party libraries
- Look for packages named
api, network, data, repository, service, retrofit, http — these are where API calls live
-
Read every BuildConfig.java — these are almost never obfuscated and frequently leak the highest-signal constants in the entire APK (base URLs, flavor names, build type, third-party API keys, feature flags):
find <output>/sources -name BuildConfig.java -exec grep -H '=' {} \;
Each Gradle module emits its own BuildConfig, so expect 1–N hits. Read all of them.
-
Identify the architecture pattern:
- MVP: look for
Presenter classes
- MVVM: look for
ViewModel classes and LiveData/StateFlow
- Clean Architecture: look for
domain, data, presentation packages
- This informs where to look for network calls in the next phases
Phase 3.5: Recover Kotlin Class Names (only for obfuscated Kotlin apps)
If Phase 0 reported moderate / high obfuscation and the app is Kotlin
(Compose / kotlin_module markers detected), run the metadata recovery
script before tracing call flows. R8 obfuscates JVM symbols but cannot
strip Kotlin metadata strings, so original FQNs leak through
@DebugMetadata and @Metadata.d2.
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/recover-kotlin-names.sh \
<output>/sources <output>/mapping
Then use the lookup helper instead of plain grep — every hit comes
annotated with the owning class's real name:
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/lookup-name.sh \
<output>/mapping --grep '"/api/' <output>/sources
Typical recovery on a real-world Kotlin app: ~100% of *Repository /
*ViewModel / *UseCase / *Impl classes, ~80% of DTOs.
See ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/kotlin-name-recovery.md
for the full technique and limitations.
Phase 4: Trace Call Flows
Follow execution paths from user-facing entry points down to network calls.
Actions:
-
Start from entry points: Read the main Activity or Application class identified in Phase 3.
-
Follow the initialization chain: Application.onCreate() often sets up the HTTP client, base URL, and DI framework. Read this first.
-
Trace user actions: From an Activity, follow:
onCreate() → view setup → click listeners- Click handler → ViewModel/Presenter method
- ViewModel → Repository → API service interface
- API service → actual HTTP call
-
Map DI bindings (if Dagger/Hilt is used): Find @Module classes to understand which implementations are provided for which interfaces.
-
Handle obfuscated code: When class names are mangled, use string literals and library API calls as anchors. Retrofit annotations and URL strings are never obfuscated.
See ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/call-flow-analysis.md for detailed techniques and grep commands.
Phase 5: Extract and Document APIs
Find all API endpoints and produce structured documentation.
Action: Run the API search script for a broad sweep.
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/
On Windows (PowerShell):
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.ps1" <output>/sources/
Targeted searches:
# Only Retrofit
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/ --retrofit
# Only hardcoded URLs
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/ --urls
# Only auth patterns
bash ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.sh <output>/sources/ --auth
On Windows (PowerShell):
# Only Retrofit
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.ps1" <output>/sources/ -Retrofit
# Only hardcoded URLs
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.ps1" <output>/sources/ -Urls
# Only auth patterns
& "${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/scripts/find-api-calls.ps1" <output>/sources/ -Auth
Document the endpoints in two tiers — going deep on every endpoint is
prohibitively expensive on apps with 100+ paths, and most of them do not
warrant it. Always produce Tier 1; expand Tier 2 only for the endpoints
that matter.
Tier 1 — flat inventory (always)
A single table covering every discovered endpoint. Aim for one line each;
if you cannot determine a column, write ?.
| Host | Method | Path | Auth | Source file |
|---|
api.example.com | GET | /v1/users/profile | Bearer | com/example/api/UserApi.java |
api.example.com | POST | /v1/auth/login | none | com/example/api/AuthApi.java |
This table answers "what does the backend look like" in one screen and
takes ~5 minutes to produce from the --paths output even on a large app.
Tier 2 — per-endpoint detail (only for high-value endpoints)
Reserve the detailed format for the few endpoints that actually need it:
- the entire authentication flow (login, refresh, logout, OTP/SMS, anonymous, registration)
- payment / checkout / order-creation endpoints
- anything the user explicitly asked about
- anything that looked unusual during the scan (custom signing, undocumented headers, etc.)
### `METHOD /path`
- **Source**: `com.example.api.ApiService` (ApiService.java:42)
- **Base URL**: `https://api.example.com/v1`
- **Path params**: `id` (String)
- **Query params**: `page` (int), `limit` (int)
- **Headers**: `Authorization: Bearer <token>`
- **Request body**: `{ "email": "string", "password": "string" }`
- **Response**: `ApiResponse<User>`
- **Called from**: `LoginActivity → LoginViewModel → UserRepository → ApiService`
As a default, do not produce Tier 2 entries for more than ~10 endpoints
unless the user explicitly asks for more — Tier 1 plus a Tier 2 deep dive
on auth + 1-2 key flows is what most consumers of this work actually want.
See ${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/api-extraction-patterns.md for library-specific search patterns and the full documentation template.
Output
At the end of the workflow, deliver:
- Decompiled source in the output directory
- Architecture summary — app structure, main packages, pattern used
- API documentation — all discovered endpoints in the format above
- Call flow map — key paths from UI to network (especially authentication and main features)
References
${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/setup-guide.md — Installing Java, jadx, Fernflower/Vineflower, dex2jar, and optional tools${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/jadx-usage.md — jadx CLI options and workflows${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/fernflower-usage.md — Fernflower/Vineflower CLI options, when to use, APK workflow${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/api-extraction-patterns.md — Library-specific search patterns and documentation template${CLAUDE_PLUGIN_ROOT}/skills/android-reverse-engineering/references/call-flow-analysis.md — Techniques for tracing call flows in decompiled code