A few days ago, I was using JADX MCP to analyze my phone, but JADX MCP was just too laggy. I had a large number of APKs to analyze, and nearly every one of them required spinning up a new JADX process. With just two or three of them, my computer ran out of memory. The efficiency was terribly low, so I came up with an idea and wrote a script.
I built a on-demand Android decompiler called Droid ASC. Literally dozens to hundreds of times faster than JADX, no exaggeration.
Here are the benchmark charts. I tested APKs across 4 orders of magnitude. For a ~50MB APK, a global cross reference index search takes 400ms, which is 41 times faster than JADX. For a 300MB APK, it takes only 1.79s, which is 269 times faster than JADX.
I have stopped using jadx mcp entirely. ASC can analyze dozens of APKs in parallel with no problem. Here is an experiment I ran: using GPT5.6 + ASC, with almost no human intervention, an automated pipeline ran for two days straight. It analyzed every APK with uid=1000 on my device, pulling in nearly 100 APK/JAR/APEX files. In the end it found one RCE vuln, one system uid arbitrary file write vuln, two vulnerabilities that can execute ROOT commands, and one SELinux restricted vulnerability that can execute ROOT commands. Pretty wild!
JADX's memory management has long been a serious problem, and many people in the mobile reverse engineering community have suffered from it. Hope this helps optimize everyone's reverse engineering pipeline.
I built a on-demand Android decompiler called Droid ASC. Literally dozens to hundreds of times faster than JADX, no exaggeration.
Here are the benchmark charts. I tested APKs across 4 orders of magnitude. For a ~50MB APK, a global cross reference index search takes 400ms, which is 41 times faster than JADX. For a 300MB APK, it takes only 1.79s, which is 269 times faster than JADX.
I have stopped using jadx mcp entirely. ASC can analyze dozens of APKs in parallel with no problem. Here is an experiment I ran: using GPT5.6 + ASC, with almost no human intervention, an automated pipeline ran for two days straight. It analyzed every APK with uid=1000 on my device, pulling in nearly 100 APK/JAR/APEX files. In the end it found one RCE vuln, one system uid arbitrary file write vuln, two vulnerabilities that can execute ROOT commands, and one SELinux restricted vulnerability that can execute ROOT commands. Pretty wild!
JADX's memory management has long been a serious problem, and many people in the mobile reverse engineering community have suffered from it. Hope this helps optimize everyone's reverse engineering pipeline.
This looks like exactly what I need. Have you considered adding MCP?