[feature] Headless whole-program call-graph API + export (DOT/JSON), reusing the engine behind the GUI graph views

[bbodisteanu-hacken]

Summary

jadx already has everything needed to produce a program-wide call graph, but it
is only reachable as a GUI dialog. Please expose a headless, whole-program
call-graph builder in jadx-core (jadx.api) plus an export option
(DOT / JSON) usable from the API and the CLI without opening the GUI.

What already exists (and why it's not enough)

1. Edge primitives — already public on master, exactly right:

   • JavaMethod.getUsed() resolved callees
   • JavaMethod.getUnresolvedUsed() unresolved (framework/lib) callees
   • JavaMethod.getUseIn() callers
   • virtual dispatch resolved by OverrideMethodVisitor, names post-rename.

   These are per-method only assembling the whole graph is left entirely to
   the consumer.

2. GUI graph views (PR feat: Graph views, code pane sync, and more #2784, merged) not reusable headless:
   jadx-gui/.../graphs/CallGraphDialog.java builds a graph, but it is

   • rooted at one selected JavaMethod (not the whole program),
   • depth-limited (callerDepthLimit / calleeDepthLimit),
   • GUI-only (Swing dialog, GraphViz render) no programmatic entry point
     and no data export.

3. CLI --cfg / --raw-cfg save a per-method control-flow graph to DOT a different thing entirely (intra-method, not the call graph).

So today, anyone building static-analysis tooling on jadx (reachability,
taint/call-graph analysis, security scanners) has to re-walk classes and
methods and re-assemble the graph from the primitives by hand, plus re-derive
everything getUsed() does not include (reflection Class.forName,
X.class constant refs, intent-action dispatch, etc.).

Proposed API

A small builder in jadx.api that materializes the program-wide graph from the
existing primitives:

try (JadxDecompiler jadx = new JadxDecompiler(args)) {
    jadx.load();

    CallGraph cg = jadx.buildCallGraph();           // whole program
    // or scoped/filtered:
    //   jadx.buildCallGraph(CallGraphOptions.builder()
    //        .includePackages("com.example")        // skip framework/libs
    //        .resolvedOnly(false)                    // include unresolved edges
    //        .build());

    for (CallGraph.Edge e : cg.edges()) {
        JavaMethod from = e.from();
        if (e.isResolved()) {
            JavaMethod to  = e.toMethod();       // resolved app callee
        } else {
            IMethodRef ref = e.toUnresolved();   // framework/lib ref (not a JavaNode)
        }
    }
    cg.writeDot(Path.of("callgraph.dot"));            // or writeJson(...)
}

Internally this is the same getUsed()/getUnresolvedUsed()/getUseIn() walk the
GUI already does just hoisted into core, run over getClasses() with no depth
cap, and given an export writer. (getUsed() requires
JadxArgs.setUsageInfoCache(new InMemoryUsageInfoCache()), which the builder can
set/validate itself.)

Proposed CLI

jadx --call-graph dot   -d out app.apk     # write out/callgraph.dot
jadx --call-graph json  -d out app.apk     # write out/callgraph.json

JSON form (stable, tool-friendly) — e.g.:

{
  "nodes": [{"id": 0, "method": "com.example.A.foo()V"}],
  "edges": [{"from": 0, "to": 1, "resolved": true}]
}

Why core, not GUI

• enables headless / CI / batch analysis (no Swing, no GraphViz needed for JSON),
• a single canonical implementation instead of every downstream tool
  re-deriving the graph slightly differently,
• the GUI graph dialog could then be a thin consumer of the same core builder.

Nice-to-haves (optional, can be follow-ups)

• include the edges getUsed() currently omits, or flag them as a separate edge
  kind: reflection (Class.forName, X.class), intent-action dispatch.
  (Related: the throws / constant-value usage gap see companion request.)
• per-edge call-site metadata (arg constants), so consumers don't re-walk
  instructions to recover literal arguments.

Happy to help with a PR the hard part (edge computation) already exists; this
is mostly hoisting + an export writer.

Environment

• jadx-core master 9d4babc (also on nightly r2658.c3f7027)
• JDK 17+, embedded JadxDecompiler (library use), headless analysis pipeline

[skylot]

@bbodisteanu-hacken that will be a nice feature and looks like it is not too hard to implement (at least for minimal scope).

I will make a new module/library jadx-analysis with simple implementation for start.
But some features like taint analysis or usage through reflection will be much harder to implement.
Also, dot graphs for a lot of nodes and edges will be not very useful because graphviz/dot render can just stuck or throw an error.
Anyway, thanks for suggestion 👍

[bbodisteanu-hacken]

Yea sure, no hard taint analysis, or something like that. callgraph will be enough. Thank you @skylot ❤️

[skylot]

I will make a new module/library jadx-analysis with simple implementation for start.

Done, cli option for export also added.
Please check: link.
Feel free to report any issues 🙂

[bbodisteanu-hacken]

Thanks @skylot, this is great! 🙌 Built from master (03009b5) and confirmed it works end-to-end.

jadx --call-graph json and --call-graph dot.

Results:

• ✅ Both exporters work. Whole-program graph: 12,388 nodes / 17,063 edges.
• ✅ Reproducible two consecutive runs (and a fresh clone + rebuild) produce byte-identical JSON. Node ids are assigned in getClasses(true)/getMethods() traversal order, so the
  output is stable. 👍
• ✅ Correct I cross-checked the resolved app→app edges against my own independent getUsed()-based walk of the same APK: 50/50 matched, zero missing edges. The core edge computation is solid.

A few small things I ran into, in case they're useful for follow-ups (no blockers):

1. CLI is hardcoded to resolvedOnly(true) (writeCallGraph in JadxCLI), so unresolved (framework/lib) edges can't be exported from the CLI at all they're only reachable via the API builder. For static-analysis use the app↔framework boundary is often exactly what you want, so a flag like --call-graph-unresolved (or folding the option into the CLI) would be handy.
2. includePackages takes a single prefix and is API-only. Tooling usually needs a set of prefixes and/or an exclude list (to drop vendor/SDK packages), plus CLI exposure.
   Something like includePackages(Collection) / an excludePackages variant would cover more cases.
3. Nodes use getRawFullId() on obfuscated APKs that's the obfuscated name, so the graph doesn't line up with the (deobfuscated) decompiled output. An option to emit the aliased/renamed id would help correlate the two.
4. Confirmed the reflection / Class.forName / intent-action edges aren't included yet matches what you noted as future scope, just flagging for completeness.

Nice touch dropping java.lang.Object.()V from unresolved usage cuts a lot of constructor noise. Thanks again for turning this around so fast! ❤️