[GH-ISSUE #1945] apktool refusals show generic target advice, and a relative REA_APKTOOL_COMMAND escapes as UNKNOWN #648

New issue

Closed

opened 2026-10-15 18:26:54 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:26:54 +00:00

Owner

Originally created by @kaoru0822-kitauji on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1945

Observed behavior

Host/tool refusals from the apktool provider don't tell the user what to fix.

Missing launcher → generic target advice. With no apktool on PATH (or REA_APKTOOL_COMMAND=/nonexistent/apktool), both inspect-apktool-client and decode-android-resources return:

{"code":"capability_unavailable","category":"unsupported_provider",
 "message":"This analysis is unavailable for the current target. Choose another analysis or target.",
 "remediation":{"action":"This analysis is unavailable for the current target. Choose another analysis or target."},
 "details":{"provider_id":"apktool","operation":"decode_android_resources",
  "reason":"The selected apktool launcher was not found: apktool Set REA_APKTOOL_COMMAND to an absolute apktool launcher (the upstream wrapper or a java -jar script)"}}

The message tells the user to choose another target, but the target is not the problem; the actual reason is only in details.reason. ApktoolProvider builds AnalysisCapabilityUnavailableError without userMessage, unlike JADX (JadxConfiguration.ts, JadxProvider.ts) and the adapters fixed in #1224.

Relative REA_APKTOOL_COMMAND → UNKNOWN. REA_APKTOOL_COMMAND=relative/apktool rea decode-android-resources x.apk --format json prints:
```
{"code":"UNKNOWN","message":"REA_APKTOOL_COMMAND must be an absolute path to the apktool launcher"}
```
resolveApktoolCommand throws ApktoolConfigurationFailure("not_absolute"), but ApktoolProvider#execute and #inspectAvailability call this.selection() before the try that maps configuration failures, so the failure escapes untyped.

The existing tests/boundary/cli/apktoolCli.test.ts case only checks that stdout contains REA_APKTOOL_COMMAND somewhere, which details.reason satisfies.

Reproduction

On macOS or Linux without apktool, using main 12ee785e5:

rea decode-android-resources ./missing.apk --format json
REA_APKTOOL_COMMAND=relative/apktool rea decode-android-resources ./missing.apk --format json

Expected behavior

Both cases return capability_unavailable, and the message and remediation name the apktool configuration problem (missing launcher, or a non-absolute REA_APKTOOL_COMMAND), as JADX refusals do.

Originally created by @kaoru0822-kitauji on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1945 ### Observed behavior Host/tool refusals from the apktool provider don't tell the user what to fix. 1. **Missing launcher → generic target advice.** With no apktool on `PATH` (or `REA_APKTOOL_COMMAND=/nonexistent/apktool`), both `inspect-apktool-client` and `decode-android-resources` return: ```json {"code":"capability_unavailable","category":"unsupported_provider", "message":"This analysis is unavailable for the current target. Choose another analysis or target.", "remediation":{"action":"This analysis is unavailable for the current target. Choose another analysis or target."}, "details":{"provider_id":"apktool","operation":"decode_android_resources", "reason":"The selected apktool launcher was not found: apktool Set REA_APKTOOL_COMMAND to an absolute apktool launcher (the upstream wrapper or a java -jar script)"}} ``` The message tells the user to choose another target, but the target is not the problem; the actual reason is only in `details.reason`. `ApktoolProvider` builds `AnalysisCapabilityUnavailableError` without `userMessage`, unlike JADX (`JadxConfiguration.ts`, `JadxProvider.ts`) and the adapters fixed in #1224. 2. **Relative `REA_APKTOOL_COMMAND` → `UNKNOWN`.** `REA_APKTOOL_COMMAND=relative/apktool rea decode-android-resources x.apk --format json` prints: ```json {"code":"UNKNOWN","message":"REA_APKTOOL_COMMAND must be an absolute path to the apktool launcher"} ``` `resolveApktoolCommand` throws `ApktoolConfigurationFailure("not_absolute")`, but `ApktoolProvider#execute` and `#inspectAvailability` call `this.selection()` before the `try` that maps configuration failures, so the failure escapes untyped. The existing `tests/boundary/cli/apktoolCli.test.ts` case only checks that stdout contains `REA_APKTOOL_COMMAND` somewhere, which `details.reason` satisfies. ### Reproduction On macOS or Linux without apktool, using main `12ee785e5`: ```sh rea decode-android-resources ./missing.apk --format json REA_APKTOOL_COMMAND=relative/apktool rea decode-android-resources ./missing.apk --format json ``` ### Expected behavior Both cases return `capability_unavailable`, and the message and remediation name the apktool configuration problem (missing launcher, or a non-absolute `REA_APKTOOL_COMMAND`), as JADX refusals do.

bsakaguchi

2026-10-15 18:26:54 +00:00

closed this issue
added the
bug
label

bsakaguchi referenced this issue

2026-10-16 21:14:49 +00:00

[PR #655] [MERGED] docs: correct CLI examples and documentation checks #2141

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#648

No description provided.

Rows
Columns