[GH-ISSUE #3918] [Feature] Make JADX operation deadlines configurable for slow multidex APK loading #1529

New issue

Closed

opened 2026-10-16 21:06:43 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:06:43 +00:00

Owner

Originally created by @jaychou813 on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3918

Before submitting

I searched open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration.
This request includes no credentials, private samples, private paths, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

With rea-agents@6.4.0, inspect_android_package on a large multidex APK reached provider_timeout at exactly 120,000 ms before APK loading completed. The retained partial observation contained a successful rea_jvm_status reply, but no completed package analysis.

The observed worker reported:

{
  "max_heap_bytes": 4294967296,
  "java_version": "21.0.12.1"
}

The failure projection was:

{
  "code": "provider_timeout",
  "category": "timeout",
  "details": {
    "operation": "inspect_android_package",
    "timeout_ms": 120000
  }
}

This observation is not a confirmed Java OOM. It also does not demonstrate the old forced-512-MiB behavior in #893/#901. No larger-heap retry or longer internal-deadline experiment is claimed.

Reproduction and verification limits

Configure a full JDK and the audited jadx-headless-mcp 0.7.1 JAR.
Invoke inspect_android_package with an APK whose cold loading exceeds the current operation deadline. The CLI counterpart is:
```
rea inspect-android-package "$PWD/input.apk" --json
```
Inspect the typed timeout and retained runtime reply rather than treating it as a complete analysis result.

The input-specific timing observation came through the real REA/JADX path on macOS arm64 with Node 24.19.0 and Temurin 21.0.12.1. There is no redistributable minimal APK attached, so the exact timing is not independently reproducible from this report alone. The cold-load cause has not been isolated. Selected-DEX/selected-method analysis through a direct JADX API path did work, but that does not prove equivalent full-APK behavior through REA.

Source-derived constraint

At separately inspected revision a32b4b6ac54a02a8fe9a7cb62861e54473ba5eb0:

JadxProvider.ts defines OPERATION_TIMEOUT_MS = 120_000 and creates an operation abort signal from it.
JadxSession.ts also passes timeout: 120_000 to its client tool call.

Thus increasing only an outer MCP client's wait cannot extend both internal deadlines. I found supported heap/processor settings, but no corresponding deadline setting in these owners. This is source inspection, not a claim that the source revision was retested against the APK.

Desired outcome and success criteria

A caller should be able to select a longer, finite Android operation deadline for a known slow cold load, with provider/session/upstream deadlines coordinated and the effective values reported. Preserve the current default, immediate explicit cancellation, bounded output, partial observations, and verified owned-process cleanup.

If a deadline cannot be extended, expose an actionable limitation or bounded alternative that can make progress before a whole-APK load completes. A smaller class query alone may not help if it still requires the same initial load.

Expected interaction with targets

Read existing APK files. Trusted Java/JADX analysis workers and REA-owned temporary copies/workspaces are involved; no APK installation, app execution, emulator/device access, or selected-file modification is requested.

Verification available so far

I have a prototype or observed results: one retained real-provider timeout and runtime reply, plus source inspection. This is not a benchmark, a proven memory diagnosis, or evidence that extending the deadline necessarily fixes the underlying load cost.

Alternatives considered

REA_JADX_HEAP_MIB addresses heap configuration, but does not change a fixed wall-clock deadline.
A larger client timeout does not override the internal provider/session timers.
Direct targeted JADX analysis worked around the blocked investigation, but bypassed the REA provider/Evidence workflow.

References

Provider deadline.
Session implementation.
Documented resource limits.
#893/#901/#908 address earlier heap propagation, eager code generation, and session reuse problems.
#1451 proposes another backend for large APKs. This request is narrower: bounded configurable deadlines and recovery for the existing JADX provider, without introducing a new backend.

Originally created by @jaychou813 on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3918 ### Before submitting - [x] I searched open and closed issues and pull requests for a related proposal. - [x] I understand the contribution scope must be reviewed before integration. - [x] This request includes no credentials, private samples, private paths, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation With `rea-agents@6.4.0`, `inspect_android_package` on a large multidex APK reached `provider_timeout` at exactly 120,000 ms before APK loading completed. The retained partial observation contained a successful `rea_jvm_status` reply, but no completed package analysis. The observed worker reported: ```json { "max_heap_bytes": 4294967296, "java_version": "21.0.12.1" } ``` The failure projection was: ```json { "code": "provider_timeout", "category": "timeout", "details": { "operation": "inspect_android_package", "timeout_ms": 120000 } } ``` This observation is **not a confirmed Java OOM**. It also does not demonstrate the old forced-512-MiB behavior in #893/#901. No larger-heap retry or longer internal-deadline experiment is claimed. ### Reproduction and verification limits 1. Configure a full JDK and the audited `jadx-headless-mcp` 0.7.1 JAR. 2. Invoke `inspect_android_package` with an APK whose cold loading exceeds the current operation deadline. The CLI counterpart is: ```sh rea inspect-android-package "$PWD/input.apk" --json ``` 3. Inspect the typed timeout and retained runtime reply rather than treating it as a complete analysis result. The input-specific timing observation came through the real REA/JADX path on macOS arm64 with Node 24.19.0 and Temurin 21.0.12.1. There is no redistributable minimal APK attached, so the exact timing is not independently reproducible from this report alone. The cold-load cause has not been isolated. Selected-DEX/selected-method analysis through a direct JADX API path did work, but that does not prove equivalent full-APK behavior through REA. ### Source-derived constraint At separately inspected revision `a32b4b6ac54a02a8fe9a7cb62861e54473ba5eb0`: - `JadxProvider.ts` defines `OPERATION_TIMEOUT_MS = 120_000` and creates an operation abort signal from it. - `JadxSession.ts` also passes `timeout: 120_000` to its client tool call. Thus increasing only an outer MCP client's wait cannot extend both internal deadlines. I found supported heap/processor settings, but no corresponding deadline setting in these owners. This is source inspection, not a claim that the source revision was retested against the APK. ### Desired outcome and success criteria A caller should be able to select a longer, finite Android operation deadline for a known slow cold load, with provider/session/upstream deadlines coordinated and the effective values reported. Preserve the current default, immediate explicit cancellation, bounded output, partial observations, and verified owned-process cleanup. If a deadline cannot be extended, expose an actionable limitation or bounded alternative that can make progress before a whole-APK load completes. A smaller class query alone may not help if it still requires the same initial load. ### Expected interaction with targets Read existing APK files. Trusted Java/JADX analysis workers and REA-owned temporary copies/workspaces are involved; no APK installation, app execution, emulator/device access, or selected-file modification is requested. ### Verification available so far I have a prototype or observed results: one retained real-provider timeout and runtime reply, plus source inspection. This is not a benchmark, a proven memory diagnosis, or evidence that extending the deadline necessarily fixes the underlying load cost. ### Alternatives considered - `REA_JADX_HEAP_MIB` addresses heap configuration, but does not change a fixed wall-clock deadline. - A larger client timeout does not override the internal provider/session timers. - Direct targeted JADX analysis worked around the blocked investigation, but bypassed the REA provider/Evidence workflow. ### References - [Provider deadline](https://github.com/morluto/rea/blob/a32b4b6ac54a02a8fe9a7cb62861e54473ba5eb0/src/android/JadxProvider.ts#L40). - [Session implementation](https://github.com/morluto/rea/blob/a32b4b6ac54a02a8fe9a7cb62861e54473ba5eb0/src/android/JadxSession.ts). - [Documented resource limits](https://github.com/morluto/rea/blob/a32b4b6ac54a02a8fe9a7cb62861e54473ba5eb0/docs/android-analysis.md#resource-and-lifecycle-limits). - #893/#901/#908 address earlier heap propagation, eager code generation, and session reuse problems. - #1451 proposes another backend for large APKs. This request is narrower: bounded configurable deadlines and recovery for the existing JADX provider, without introducing a new backend.

bsakaguchi closed this issue

2026-10-16 21:06:44 +00:00

bsakaguchi commented

2026-10-16 21:06:45 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 15, 2026):

Reasonable feature: large multidex APKs legitimately exceed a fixed 120s cold-load deadline, and a configurable operation deadline (per-call override or env-level default) lets users match the timeout to the artifact without losing the timeout safety net. Keeping it distinct from heap-size issues like #893/#901 is accurate — this is a wall-clock budget, not a memory cap.

@XinwangTao commented on GitHub (Oct 15, 2026): Reasonable feature: large multidex APKs legitimately exceed a fixed 120s cold-load deadline, and a configurable operation deadline (per-call override or env-level default) lets users match the timeout to the artifact without losing the timeout safety net. Keeping it distinct from heap-size issues like #893/#901 is accurate — this is a wall-clock budget, not a memory cap.

bsakaguchi referenced this issue

2026-10-17 21:01:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-17 21:12:08 +00:00

[PR #1529] [CLOSED] test(javascript): check #1495 growth rate instead of wall time #2945