Add an optional JADX managed-code backend

[subwire]

Summary

• add a native DecLib backend for APK, DEX, AAB, XAPK, JAR, class, and Smali inputs using JADX
• expose managed-code class, method, field, resource, manifest, and xref operations through the Python API and decompiler CLI
• use stable JVM/Dex reference strings so overloads and addressless managed-code objects remain unambiguous
• update the bundled agent skill and CLI documentation with Java/Android workflows, bounded-output guidance, and JADX xref cost guidance

Optional distribution model

This does not bundle the official JADX distribution or depend on an MCP server. DecLib ships only a reproducible 15 KB Java protocol bridge. At runtime it discovers Java 17+ and JADX 1.5.6+ through:

1. DECLIB_JADX_WORKER
2. DECLIB_JADX_JAR
3. JADX_HOME
4. jadx on PATH

decompiler backend status jadx --json diagnoses the installation without loading an input. Gradle is needed only by DecLib contributors rebuilding the bridge; installed wheels use the staged bridge directly.

Validation

• gradle --no-daemon -p declib/decompilers/jadx/worker test stageBridge
• verified the staged bridge is reproducible with git diff --exit-code
• pytest tests/test_jadx.py -v — 7 passed
• built and installed the wheel in a fresh virtual environment without Gradle
• tested official JADX 1.5.6 in a clean Linux container against both a real APK and a generated Java archive, including manifest/resources, source recovery, method xrefs, field xrefs, bounded binary resources, and worker shutdown

The release workflow rebuilds/tests the bridge, rejects a stale checked-in bridge, and verifies that the wheel contains it.

[subwire]

CI follow-up: the initial failure was the existing private IDA artifact setup trying to decrypt without TOOLING_KEY, which fork PRs cannot receive. Commit 44275b8 makes the IDA/Binary Ninja setup conditional, while still cloning the public fixtures and running the JADX, Ghidra, angr, CLI, and client/server coverage. The rerun is now fully green.

[mahaloz]

@subwire, since 44275b8 changed CI behavior, would you be able to open an Issue just saying that we need to fix this secret tomfoolery so that fork PRs can get tested as well?

Otherwise, we just dropped the majority of tests for outside PR checking.

[subwire]

Superseded by #218. The feature branch now lives in binsync/declib, allowing the unchanged secret-backed proprietary decompiler CI to run after contributor access was granted; the fork-safe CI workaround has been reverted.