[GH-ISSUE #1124] fix(android): binary_session advertises tools without the required engine #397

New issue

Closed

opened 2026-10-15 18:24:45 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:24:45 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 8, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1124

Summary

The supported MCP startup path reports all five Android provider tools as available when REA_JADX_MCP_JAR is unset. A subsequent Android inspection fails with capability_unavailable and asks for that JAR. Agents using binary_session to select a usable analysis receive contradictory readiness information.

Steps to reproduce

Unset REA_JADX_MCP_JAR and JAVA_HOME, then start npx -y rea-agents@6.0.0 mcp as an MCP stdio server. No APK is needed for the availability request.
Send the following newline-delimited JSON-RPC messages in order, waiting for the initialization response before sending the initialized notification and tool call.

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"readiness-probe","version":"1.0.0"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"binary_session","arguments":{}}}

Inspect result.structuredContent.result.tool_availability in the tool-call response. Compare the entries whose surface is android-provider with the firmware entries.
As a discriminating control, run rea inspect-android-package /absolute/path/ApiDemos-debug.apk --json with the same unset JAR environment. The public APK is available from the Appium fixture release.

Expected behavior

binary_session should report capability availability consistent with the documented prerequisites. With the required Android JAR absent, the five Android provider tools should report unavailable with a reason and an actionable prerequisite message. Tool discovery can retain the complete catalog.

Actual behavior

The npx stdio run returned these entries, projected here to their meaningful fields:

[
  {"name":"inspect_android_package","available":true,"reason":"available","remediation":null},
  {"name":"search_android_classes","available":true,"reason":"available","remediation":null},
  {"name":"inspect_android_class","available":true,"reason":"available","remediation":null},
  {"name":"inspect_android_method","available":true,"reason":"available","remediation":null},
  {"name":"trace_android_references","available":true,"reason":"available","remediation":null}
]

In the same response, inspect_firmware_regions and extract_firmware returned available: false and reason: "provider_missing". Separate stdio runs of the isolated installed package returned the same Android entries with a JRE selected by JAVA_HOME, and with a PATH containing Node but no Java. The JAR was unset in each of those runs.

With the same public APK, supplied JAR and a full JDK, a separate package inspection exited 0 and loaded 2,876 classes.

The control inspection exited 1 with code: "capability_unavailable" and details.reason: "Set REA_JADX_MCP_JAR to the absolute path of a caller-supplied jadx-headless-mcp 0.7.1 JAR. REA does not download or install it."

Evidence

Expected source: The contribution guide requires capability- and session-scoped availability through binary_session; the Android guide requires a caller-supplied JAR and a full JDK.
Failure source: Fresh MCP stdio initialization and tools/call binary_session {} against the published package, followed by the CLI control described above.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

The contribution guide establishes the discovery contract, and the Android guide establishes the prerequisites.

The supported MCP startup always constructs and supplies an Android provider object. Consequently, the first operand of the availability guard, options.androidAnalysis !== undefined, is true even when its prerequisite environment is missing. The inventory policy then reports available. The provider constructor stores the environment; it does not establish engine readiness.

The same injection and inventory branches remain in the inspected main source. The current guard is unchanged. The main source was inspected; its runtime was not built or executed.

Restoration check

Repeat the no-JAR MCP request and verify that all five Android provider entries report unavailable with the missing prerequisite. With the documented JAR and a working full JDK, verify usable Android availability and successful package inspection. Check the Java-unavailable condition independently so object construction alone does not imply readiness. Keep the complete tool list and the unrelated execution-free project_android_application_graph capability intact.

Runtime or environment

REA release: npm rea-agents 6.0.0, tag rea-agents-6.0.0, commit 6fee42689ae6e95a0182e0d4d0f55644e73e72be. npm metadata still identified this as the latest published version during verification.
Inspected default branch: main at 84a17d55199b1b46493aea6bf4e41029a3b200fc.
Runtime: Node 22.23.2, npm 12.0.2, macOS 27.0 arm64.
Java fixtures: Temurin JRE and JDK 21.0.9+10, whose executables report OpenJDK 21.0.9. The full JDK was used for the successful package control.
Target control: public Appium ApiDemos-debug.apk 6.0.18; SHA-256 a9eecf37b26cd084855c530db81c2bb1b91f4c1b095a04f47aa7c20e2791f686.
Issue-form context: Area = Provider or capability discovery; Interface = MCP; Earliest failure stage = Setup or provider admission; Target = no active target for discovery, APK for the control.

Additional context

Searched open and closed issues and pull requests for the behavior.
Removed credentials, private paths, and sensitive target data.

No exact duplicate was found. Related Java runtime admission and Android provider factory work does not cover this discovery contradiction. The ineffective Android failure recovery advice is a separate observable contract, so it is reported independently.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: MCP callers receive false readiness for five tools and discover the missing prerequisite only after selecting an unusable operation. The failure is bounded to discovery and does not establish corruption of analysis results.
Workaround status: available
Workaround basis: Callers can verify the documented JAR and full JDK manually or attempt a real Android operation and inspect its failure instead of relying on the availability entries.

Originally created by @coygeek on GitHub (Oct 8, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1124 ## Summary The supported MCP startup path reports all five Android provider tools as available when `REA_JADX_MCP_JAR` is unset. A subsequent Android inspection fails with `capability_unavailable` and asks for that JAR. Agents using `binary_session` to select a usable analysis receive contradictory readiness information. ## Steps to reproduce 1. Unset `REA_JADX_MCP_JAR` and `JAVA_HOME`, then start `npx -y rea-agents@6.0.0 mcp` as an MCP stdio server. No APK is needed for the availability request. 2. Send the following newline-delimited JSON-RPC messages in order, waiting for the initialization response before sending the initialized notification and tool call. ```json {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"readiness-probe","version":"1.0.0"}}} {"jsonrpc":"2.0","method":"notifications/initialized"} {"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"binary_session","arguments":{}}} ``` 3. Inspect `result.structuredContent.result.tool_availability` in the tool-call response. Compare the entries whose `surface` is `android-provider` with the firmware entries. 4. As a discriminating control, run `rea inspect-android-package /absolute/path/ApiDemos-debug.apk --json` with the same unset JAR environment. The public APK is available from the [Appium fixture release](https://github.com/appium/android-apidemos/releases/tag/v6.0.18). ## Expected behavior `binary_session` should report capability availability consistent with the documented prerequisites. With the required Android JAR absent, the five Android provider tools should report unavailable with a reason and an actionable prerequisite message. Tool discovery can retain the complete catalog. ## Actual behavior The npx stdio run returned these entries, projected here to their meaningful fields: ```json [ {"name":"inspect_android_package","available":true,"reason":"available","remediation":null}, {"name":"search_android_classes","available":true,"reason":"available","remediation":null}, {"name":"inspect_android_class","available":true,"reason":"available","remediation":null}, {"name":"inspect_android_method","available":true,"reason":"available","remediation":null}, {"name":"trace_android_references","available":true,"reason":"available","remediation":null} ] ``` In the same response, `inspect_firmware_regions` and `extract_firmware` returned `available: false` and `reason: "provider_missing"`. Separate stdio runs of the isolated installed package returned the same Android entries with a JRE selected by `JAVA_HOME`, and with a PATH containing Node but no Java. The JAR was unset in each of those runs. With the same public APK, supplied JAR and a full JDK, a separate package inspection exited 0 and loaded 2,876 classes. The control inspection exited 1 with `code: "capability_unavailable"` and `details.reason: "Set REA_JADX_MCP_JAR to the absolute path of a caller-supplied jadx-headless-mcp 0.7.1 JAR. REA does not download or install it."` ## Evidence - Expected source: The contribution guide requires capability- and session-scoped availability through `binary_session`; the Android guide requires a caller-supplied JAR and a full JDK. - Failure source: Fresh MCP stdio initialization and `tools/call binary_session {}` against the published package, followed by the CLI control described above. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete The [contribution guide](https://github.com/morluto/rea/blob/6fee42689ae6e95a0182e0d4d0f55644e73e72be/CONTRIBUTING.md#L27) establishes the discovery contract, and the [Android guide](https://github.com/morluto/rea/blob/6fee42689ae6e95a0182e0d4d0f55644e73e72be/docs/android-analysis.md#L13-L32) establishes the prerequisites. The supported MCP startup [always constructs and supplies an Android provider object](https://github.com/morluto/rea/blob/6fee42689ae6e95a0182e0d4d0f55644e73e72be/src/main/transport.ts#L64-L75). Consequently, [the first operand of the availability guard](https://github.com/morluto/rea/blob/6fee42689ae6e95a0182e0d4d0f55644e73e72be/src/server/createServer.ts#L124-L127), `options.androidAnalysis !== undefined`, is true even when its prerequisite environment is missing. The [inventory policy](https://github.com/morluto/rea/blob/6fee42689ae6e95a0182e0d4d0f55644e73e72be/src/application/CapabilityInventory.ts#L323-L329) then reports `available`. The provider constructor stores the environment; it does not establish engine readiness. The same injection and inventory branches remain in the inspected `main` source. The [current guard](https://github.com/morluto/rea/blob/84a17d55199b1b46493aea6bf4e41029a3b200fc/src/server/createServer.ts#L124-L127) is unchanged. The `main` source was inspected; its runtime was not built or executed. ## Restoration check Repeat the no-JAR MCP request and verify that all five Android provider entries report unavailable with the missing prerequisite. With the documented JAR and a working full JDK, verify usable Android availability and successful package inspection. Check the Java-unavailable condition independently so object construction alone does not imply readiness. Keep the complete tool list and the unrelated execution-free `project_android_application_graph` capability intact. ## Runtime or environment - REA release: npm `rea-agents` 6.0.0, tag `rea-agents-6.0.0`, commit `6fee42689ae6e95a0182e0d4d0f55644e73e72be`. npm metadata still identified this as the latest published version during verification. - Inspected default branch: `main` at `84a17d55199b1b46493aea6bf4e41029a3b200fc`. - Runtime: Node 22.23.2, npm 12.0.2, macOS 27.0 arm64. - Java fixtures: Temurin JRE and JDK 21.0.9+10, whose executables report OpenJDK 21.0.9. The full JDK was used for the successful package control. - Target control: public Appium ApiDemos-debug.apk 6.0.18; SHA-256 `a9eecf37b26cd084855c530db81c2bb1b91f4c1b095a04f47aa7c20e2791f686`. - Issue-form context: Area = Provider or capability discovery; Interface = MCP; Earliest failure stage = Setup or provider admission; Target = no active target for discovery, APK for the control. ## Additional context - [x] Searched open and closed issues and pull requests for the behavior. - [x] Removed credentials, private paths, and sensitive target data. No exact duplicate was found. Related Java runtime admission and Android provider factory work does not cover this discovery contradiction. The ineffective Android failure recovery advice is a separate observable contract, so it is reported independently. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: MCP callers receive false readiness for five tools and discover the missing prerequisite only after selecting an unusable operation. The failure is bounded to discovery and does not establish corruption of analysis results. - Workaround status: available - Workaround basis: Callers can verify the documented JAR and full JDK manually or attempt a real Android operation and inspect its failure instead of relying on the availability entries.

bsakaguchi

2026-10-15 18:24:45 +00:00

closed this issue
added the
area: runtime

bug
labels

bsakaguchi commented

2026-10-15 18:24:45 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 9, 2026):

The missing-JAR/full-JDK/JRE/missing-Java real-provider matrix passes after c715af8, including complete SDK discovery and all five Android CLI/MCP operations. An adjacent false-ready case remains: with a working full JDK, a plain-text file selected as REA_JADX_MCP_JAR makes all five Android tools available, then execution fails with zip END header not found and JDK-first advice. I have reproduced this through stdio MCP and added a failing malformed/unrelated-JAR regression; keeping this open for the bounded archive-prerequisite follow-up (also relevant to #1125).

@N0zoM1z0 commented on GitHub (Oct 9, 2026): The missing-JAR/full-JDK/JRE/missing-Java real-provider matrix passes after c715af8, including complete SDK discovery and all five Android CLI/MCP operations. An adjacent false-ready case remains: with a working full JDK, a plain-text file selected as `REA_JADX_MCP_JAR` makes all five Android tools available, then execution fails with `zip END header not found` and JDK-first advice. I have reproduced this through stdio MCP and added a failing malformed/unrelated-JAR regression; keeping this open for the bounded archive-prerequisite follow-up (also relevant to #1125).

bsakaguchi referenced this issue

2026-10-15 18:28:29 +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-16 21:13:04 +00:00

[PR #433] [MERGED] feat: add runtime reconstruction roadmap workflows #1982