| name | android-reverse-flow |
| description | Use when reverse-engineering Android APKs on-device in Termux/Shizuku, including unpacking with apktool, inspecting with jadx/smali, patching manifests/resources/code, rebuilding, signing, installing, and iterating with the MCP shell. |
Android Reverse Flow
Use this skill for end-to-end Android APK reversing on the phone.
Quick rules
- Use the MCP
shell tool as the main control surface.
- Keep shell output narrow. Prefer redirects,
rg, sed -n, jq, head, and tail over dumping full trees or files.
- For iterative work, prefer a persistent shell session over restarting one-shot commands.
- On Android/Termux, treat plain
apktool b ... as an anti-pattern. Always force --aapt /data/data/com.termux/files/usr/bin/aapt2.
- Prefer separate working directories per APK and per iteration.
- Treat
apktool output as the editable source of truth for resources/manifest/smali. Treat jadx output as read-mostly navigation.
Standard flow
- Verify toolchain and environment first.
- Copy the target APK into a disposable work directory.
- Decode once with
apktool d.
- Inspect Java/Kotlin structure with
jadx or jadx-cli.
- Patch the smallest layer possible:
manifest/resource first if enough;
smali only if resource-level patching is not enough.
- Rebuild with the helper script or
apktool b --aapt ....
- Sign the rebuilt APK.
- Install, launch, and capture failures.
- Iterate from the exact failing step instead of re-running the full chain.
Shell usage patterns
- Before reading big directories, ask for counts or filtered paths.
- Before reading large XML or smali files, pull only relevant slices with
rg -n and sed -n.
- When a build command is noisy, redirect stdout/stderr to files and inspect the tail first.
- If a workflow becomes interactive or iterative, stay inside one shell session instead of reopening commands repeatedly.
When to read references
Preferred helper
