MG1937/ASC: an on-demand Android decompiler front end that queries the APK instead of indexing it

The problem ASC attacks: preprocessing that costs more than the search

Standard Android decompilation starts by inflating the whole artifact. The README describes the usual sequence plainly: tools eat gigabytes of RAM, fully inflate the artifacts, and spend tens of minutes building global indexes and cross references, all so that later code searches are fast. ASC's author argues this is backwards. A compiled artifact is already highly structured, and rebuilding a database of code relationships over already structured data spends time and memory to recover information the file still contains. The target user is not someone decompiling one class once. It is a mobile researcher or an agent loop issuing many small queries against a large commercial APK, where each query currently pays the full indexing cost. The README frames the alternative as a question: if a code relationship can be extracted from the APK in milliseconds, the preprocessing step has to justify itself.

Deflate probing, R8 layout, and the O(1) instruction locator

The mechanism has three parts. First, ASC avoids full inflate by probing directly inside the Deflate bitstream, building dense Huffman lookup tables so that it can extract core metadata without touching irrelevant data blocks. Second, it relies on R8 compiler behaviour. The README points to deterministic constant relocation and instruction deduplication leaving highly concentrated physical layouts, and ASC uses that layout to run cross-DEX code searches. Third, it maps raw bytecode offsets back to methods through what the README calls an O(1) instruction locating primitive, giving constant-time method resolution without a heavy mapping table. When a query hits, ASC extracts only the specific bytecodes and their dependencies and reconstructs a minimal, self-consistent DEX entirely in memory for decompilation. The data flow is therefore query-first: a class name or a reference pattern goes in, a small synthetic DEX comes out, and the JVM-side decompiler only ever sees that fragment.

Installing ASC and running a first getclass and findrefs query

The repository has no packaging metadata at the top level, so installation is the requirements file plus the entry script. The only pinned dependency in requirements.txt is androguard==4.1.3, which is worth noting because the parsing behaviour of that version is what the extraction path is built on.

pip install -r requirements.txt

The entry point is main.py, and the README documents two subcommands: getclass, which locates a target class in the APK, extracts one DEX in memory, then decompiles it, and findrefs, which finds code references for a string, type, method or field across all DEX entries. Running main.py with no subcommand prints the usage block. A first decompilation names the APK and the class, either in JVM descriptor form or dotted form, and can write the result to a file.

python main.py getclass app.apk Lcom/poc/Main; -o Main.java
python main.py getclass app.apk com.poc.Main --threads 16

The second command shows the --threads flag, which the README's example sets to 16. For reference hunting, findrefs takes the reference kind as a positional argument. A string search writes matches to a file, and a method search can be narrowed by class, with a fuzzy class match available when you do not know the exact owner.

python main.py findrefs app.apk string token -o string_refs.txt
python main.py findrefs app.apk method notify --class MainActivity --fuzzy-class -o method_refs.txt

The README also lists a GUI mode invoked as python main.py app.apk --gui, which is the quickest way to confirm the tool opens your APK at all before scripting queries.

Where the on-demand model breaks down

The design deliberately gives up whole-program context. Because ASC reconstructs a minimal DEX containing only the target class and its dependencies, anything that needs a complete call graph, a whole-APK type hierarchy, or a global string table has to be assembled by the caller from many separate queries. That is a real cost, not a theoretical one: a task like finding every implementation of an interface across a large app becomes a loop rather than one pass. The README's own numbers come from a single 352MB commercial APK, and it does not document behaviour on multi-APK splits, on APKs whose bytecode version androguard==4.1.3 cannot parse, or on obfuscated artifacts where R8's layout assumptions do not hold. The README is also silent on rollback, caching and how repeated queries interact. ASC is the wrong tool when the job is a one-off full decompile of a small app, because the indexing cost it avoids is small there, and when the output must be a consistent Java project rather than per-class fragments.

How ASC differs from running androguard or jadx directly

The obvious alternative is to call androguard directly, which is already a dependency here, or to run jadx. Both take the conventional route: load the artifact, build the analysis structures, then answer questions against them. ASC inverts the order. It answers the question first by reading the compressed stream and the bytecode offsets, and only materialises a DEX when a target has actually been hit. The practical difference is in the cost curve. With an indexing decompiler, the first query is expensive and later queries are cheap. With ASC, the README claims a flat cost per query: 1.79 seconds for global cross-reference searches and 177 milliseconds to decompile target classes, using 141MB of RAM on that 352MB APK. That trade favours many small, unrelated questions and penalises workloads that genuinely need the global index anyway. If your workflow is one APK, one pass, one output tree, the conventional tools remain the simpler choice.

Licence, maintenance and upgrade cost

ASC is licensed under Apache-2.0, and the LICENSE file sits at the repository root alongside main.py and requirements.txt. Apache-2.0 permits commercial and closed-source use and includes an explicit patent grant, but it also requires that you retain the licence and copyright notices and state significant changes when redistributing. That matters here because ASC ships no packaging metadata, so redistributing it inside an internal tool means carrying the notice yourself. This is a description of the licence text, not legal advice. On maintenance, the last push to main was on 2026-09-13, and no releases have been published, so there is no versioned artifact to pin against. Upgrades mean tracking the main branch. The single pinned dependency, androguard==4.1.3, is the main upgrade risk: bumping it can change how DEX parsing behaves, and the README does not describe a compatibility range.

Editorial conclusion

ASC suits mobile reverse engineers and agent pipelines that need repeated, targeted lookups inside large APKs where a full indexing pass costs more than the question being asked. It is the wrong tool when you need whole-program call graphs, cross-application analysis, or a stable Java output for large refactors, because it deliberately materialises only one class and its dependencies at a time. Before adopting it, run python main.py app.apk --gui against one of your own production APKs, then repeat a findrefs query for a string and a method and confirm the offsets land on the methods you already know are there. If the bytecode version in your APK is newer than what androguard==4.1.3 parses, the extraction path is the first thing to check.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. MG1937/ASC on GitHub
4. README