Four gates come before the first APK patch
apk-reverse starts by asking what kind of problem you have. Its four gates cover classification, the actual environment, a control build, and the intended deliverable before an agent changes bytes. The entry skill also has four override rules, a symptom index, a two-strike rule, and six conditions for calling work done. That structure is the product. It tries to stop an agent from treating every broken Android app as another invitation to improvise.
The useful distinction is client authority versus server authority. A local sign-in screen or forced-upgrade comparison may be patchable. An account-scoped resource that the server refuses to return is not. The README tells the agent to prove which side owns the decision and stop when an APK cannot change it. That can save more time than a clever patch, especially when the requested deliverable must work on an unrooted device rather than only on the analyst's phone.
The skill routes work across dex, native code, and device state
The installed skill contains one short procedure backed by topic-specific references and scripts. Coverage includes dex edits, repacking and signing, packers, custom loaders, native tamper responses, Flutter and Dart AOT, split APK sets, protocol inspection, and on-device tools. The agent loads a reference when a symptom matches instead of carrying the whole manual in every prompt.
This breadth does not mean every route is equally proven. The project separates executable tests from an evidence record under docs/tool-verification/. Its README says some extension material is inferred, some benchmark rows are unverified, and Flutter analysis begins with output from an external snapshot decoder. Those labels are useful. They tell you when the procedure describes a measured route and when it records a method that still needs confirmation on your target.
What happened when we ran it
Our sandbox installed commit 7b6c693 in 12 seconds, pulling 35 packages and occupying 37 MB. The build succeeded in 13 seconds. Pytest completed in 60 seconds with 594 passed, 0 failed, and 192 skipped in the recorded 594-test run. Pip-audit reported 0 known vulnerabilities. The checkout itself contained 181 files, about 29,453 lines of source, and used 2.8 MB.
The container had 3 CPUs, 8 GB of RAM, Python 3.12 on Debian, no secrets, and no elevated privileges. One CI workflow and a tests directory were present, while no Dockerfile was found. Those results test the repository's Python tooling and checks. They do not prove that Frida works on your phone, that an APK can be legally modified, or that a documented patch will survive a particular vendor's hardening.
A 37 MB install does not include the Android workbench
The Python environment is small, but practical analysis reaches outside it. The README names droidasc and ddc for locating and reading dex code, baksmali and dexlib2 for low-level changes, a JDK, Android SDK build tools, ADB, and optional Frida. Dynamic work may require a rooted device or emulator. doctor.py checks what exists and can search directories supplied through APKREV_TOOLS when utilities are not on PATH.
There is no Dockerfile that freezes this collection into one known workstation. That choice makes sense for device work, where SDK paths, USB access, operating systems, and GUI-only utilities vary. It also means the 12-second install is not a promise of a ready lab. A new user still has to assemble the tools needed for the chosen route and keep host and device components compatible.
The strongest advice is about failures that look successful
Several examples concern artifacts that build, install, or launch while remaining wrong. Removing all of META-INF/ can delete service registrations. A whole-tree smali round trip can damage optimized output without an obvious table mismatch. Re-signing may change a certificate-derived request key, leaving an app that renders normally while signed requests fail. A native termination patch can freeze a process if the replacement never returns.
These are good cases for agent guidance because the visible symptom points away from the cause. The skill asks for a control build, byte comparison, verifier-level checks, runtime observation, and a claim grade. It also treats two failures with the same shape as evidence that the hypothesis is wrong. That is stricter than asking a model for another variation of the same command.
Android-only scope and permission rules narrow the audience
The project is explicit about what it does not cover. iOS is out. Unity and IL2CPP recovery and React Native or Hermes internals are outside the documented depth. Server-side authority remains server-side. The repository also distributes no target APKs, device dumps, or third-party binaries, and it limits use to apps you own, authorized assessments, public challenges, and controlled sandboxes.
GitHub showed 3,248 stars and 0 open issues or pull requests when checked on October 7, 2026. The last push was September 24, and the repository had no tagged release. That combination shows recent work and attention, but no release channel for pinning a named version. Install by commit when repeatability matters. For an experienced Android analyst, the tested procedure is worth adding. For a newcomer who mainly needs to open an APK and read Java-like output, JADX is the clearer first tool.