* fix(android): name the JADX deadline and recover apktool decode
JADX operation timeouts now name REA_JADX_OPERATION_TIMEOUT_MS, the
effective milliseconds, the 1..2147483647 range, and that a change applies
on the next process start. Apktool decode accepts decode_timeout_ms,
omitted means 600000, and a timeout names that key. ADB deadlines and
apktool and Java version probes stay fixed and say there is no runtime
override.
Refs #5910
Co-authored-by: morluto <morluto@users.noreply.github.com>
* fix(android): derive capture recovery from the fixed allowance
Main now stores a fixed allowance instead of a prebuilt remediation
string. Apktool and adb capture refusals keep the no-runtime-override
sentence in that allowance name, including that decode_timeout_ms does
not raise the apktool output cap.
Co-authored-by: morluto <morluto@users.noreply.github.com>
* test(apktool): observe a real decode deadline and process cleanup
A hanging interpreter launcher and its pipe-holding child stay alive
until decode_timeout_ms elapses. The provider then reports
provider_timeout with completed cleanup, and both processes are gone.
Co-authored-by: morluto <morluto@users.noreply.github.com>
---------
Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: morluto <morluto@users.noreply.github.com>
Carry the selected host into the version owner, disclose the Windows follow-up before 2.9.3, and bound the 3.0.x resource type-name validation warning before 3.0.2. Share warning formatting and preserve reported spelling, prerelease semantics and exact dirty-release handling.
Verify the upstream producing-boundary patch instead of assuming a file-writer sanitizer. Explicitly label inclusion of the tagged 3.0.0 release line as source-derived; version and host guidance do not establish engine contents or backports. Retain warnings with completed Evidence during cancellation and failed cleanup.
Validation: 222 focused tests in 15 files, 16 baseline controls fail, static/docs checks and two source reviews. Twelve tiny actual MCP workflows and six CLI controls with authored launchers; no real Apktool/JVM, native Windows, exploit or true cold verification.
Fixes#4818
Parse the launcher version once to own both compatibility and CVE-2024-21633 advisory facts. Inspection and decoding consume those facts, including completed Evidence retained during cancellation. Preserve source spelling, exact dirty-release handling, prerelease semantics, and existing version-only failure diagnostics.
Adapt the Apktool warning policy from PR #3440. State that a reported version does not establish engine contents or downstream backports; avoid recommending 2.9.2+ as generally safe. Other advisory applicability and release-range questions are tracked in #4818.
Validation: 194 focused tests in 15 files; final 87 source checks; five baseline controls fail; static/docs checks; two source reviews. Twelve tiny actual MCP workflow comparisons and four CLI controls; authored launcher only, no real Apktool/JVM/Windows or exploit verification.
Fixes#3438
Co-authored-by: Govindu Sasanka <31107592+GovinduSasanka@users.noreply.github.com>
Carry caller-selected target identity separately from launcher selection. Only fully collected ordinary nonzero decode exits represent target refusals; startup, preparation, capture and signal failures retain provider attribution. Reuse one command/preparation output projection for probe and decode errors.
Adapt the target-path correction from PR #3462 (08d3d0d3a0) and extend its producer-boundary classification and regression coverage.
Validation: 131 focused tests in 12 files, final 50 source checks, build, typecheck/lint and docs. Ten regression controls fail on baseline 4844ae812. Twenty-four tiny actual CLI/stdio MCP refusal tasks preserve every projected field except the corrected message/path. Authored launchers only; no real Apktool/JVM or native Windows claim. Heavy stress/profiling remained stopped.
Closes#3340
Co-authored-by: Peter <304086198+peter-research@users.noreply.github.com>
Admit provider operations through one command resource scope, retain exact process and preparation-helper cleanup capabilities, and bind original failures to their live cleanup leases. Keep unknown recovery capabilities unresolved and fence their workspaces.
Interpret version output at command completion, preserve opaque cancellation and compiler output, and attribute prerequisite failures to the consuming operation. Prepare Darwin ownership outside the short version deadline.
Validation: 106 focused tests across 11 files; final 44 source regressions; build, typecheck/lint, docs and test discovery. Eight new controls fail on the clean baseline. Tiny authored launchers exercise process cleanup and public CLI/stdio MCP; actual Apktool/JVM and native Windows remain unverified. Heavy stress/profiling remained stopped.
Closes#4808
* fix(apktool): own the version probe's process group and keep its timeout typed
The version probe ran its launcher through execFileOutput, which waits
for every inherited output pipe to close. A shell launcher's child that
holds those pipes outlived the stop request, so the probe stayed pending
past its deadline and its grace period, and cancellation hung the same
way. An expired probe also surfaced as a non-retryable unusable-version
refusal.
Run the probe through runOwnedCommand like the decode run, so the owned
process group is stopped with its children. Report its deadline as
AnalysisTimeoutError with timeout_ms and retain an unresolved cleanup
owner for close. Apktool launchers are interpreter scripts, so both the
probe and the decode run prove ownership by run token instead of the
launcher's argv prefix. A close with unresolved process cleanup reports
a typed ProviderCleanupError instead of an untyped AggregateError.
Fixes#3342Fixes#3347Fixes#3337
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(apktool): carry unresolved probe cleanup through both provider entry points
A probe failure other than cancellation or timeout, such as an output
overflow whose launcher child survives, now keeps its cleanup reason and
resources on ApktoolConfigurationFailure. inspectAvailability and execute
report it as ProviderCleanupError instead of ordinary unavailability or
capability_unavailable.
Add a real-process lifecycle test: an interpreter launcher starts a child
that holds the inherited output pipes, the probe is cancelled after
launch, and both processes must be stopped within the bound.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* test(apktool): ignore zombies and always clean up the probe lifecycle fixture
Treat a zombie as exited when checking the launcher and child, bound the
cancellation wait so a regressed probe still reaches cleanup, and stop
any remaining fixture processes in a finally block.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* test(apktool): treat a failed process inspection as unknown, not stopped
Only ESRCH, a zombie state or ps reporting no match counts as exited; a
ps launch failure leaves the process presumed live so the assertion
fails and the finally block still stops it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Probe the selected clients through their owning providers and expose current host availability through binary_session. Keep device/serial and target applicability separate. Reject unrecognized successful version output; retain the bounded producer output and original version spelling. Apply the documented Apktool floor, including the verified Debian dirty build.
Validation: provider/version tests and public MCP grouped availability; no real Android device or APK provider verification claimed.
Fixes#3067Fixes#3068
Related: #3077
Co-authored-by: Taksh <takshkothari09@gmail.com>
* fix(apktool): resolve Windows PATH launchers before invocation
Resolve the default launcher through the selected PATH/PATHEXT before choosing native process creation or the existing conservative cmd.exe wrapper. Reuse the resulting selection and one canonical environment for the version probe and decode.
Follow-up to the release #1693 review of #1777. Source inspected and formatted; tests, builds, check reruns and real Windows Apktool execution were skipped at maintainer request.
* fix(apktool): bound lookup and retain only selected environment
Source inspection and targeted formatting only. Tests, builds, lint, typechecks and provider workloads were not run at the user's explicit request.
* fix(apktool): use supported timeout diagnostics
Retain lookup phase through AnalysisErrorOptions diagnostics while preserving the operation and timeout identity. Source inspection and targeted formatting only; tests, checks, builds and provider workloads were skipped at the user request.
---------
Co-authored-by: morluto <morluto@users.noreply.github.com>
On Windows, Node refuses to spawn .bat and .cmd files without a shell
(CVE-2024-27980), so REA_APKTOOL_COMMAND pointing at Chocolatey's
apktool.bat or a java -jar wrapper failed its version probe with EINVAL,
reported as "did not report a usable version".
Move Ghidra's conservative cmd.exe invocation (no AutoRun, no delayed
expansion, every token quoted, interpreter metacharacters rejected) into
src/process/WindowsBatchCommand.ts. Ghidra keeps its error type, wording
and length limit. apktool now uses it for both the version probe and the
decode run when the launcher is a batch file on Windows. A launcher that
cmd.exe would reinterpret reports launcher_unsupported (not_configured)
with remediation instead of version_unresolved.
Fixes#1774
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* feat(apktool): decode Android resource tables through a caller-supplied launcher
Add an Apktool family with two operations over the caller's apktool
launcher (REA_APKTOOL_COMMAND, absolute, or apktool on PATH):
- inspect_apktool_client: resolved launcher, selection source, and
version; decodes nothing.
- decode_android_resources: apktool d --no-src in a provider-owned
workspace that is removed before the result returns. Projects the
decoded AndroidManifest.xml (bounded at 512 KiB), apktool.yml version
and SDK facts exactly as printed, string resources verbatim (default or
one locale, bounded at 2000 entries, nested-markup entries counted as
unparsed), available string locales, and the decoded file count with a
hard cap. The target APK is digested with SHA-256 before decoding so
Evidence binds the observation to the exact input.
Smali production is skipped by design: Java-source recovery belongs to
the JADX family. Workspace cleanup happens before results return; an
unremovable workspace is named in the limitations instead of abandoned.
Verified against apktool 2.7.0-dirty (Debian packaging) on Linux with
OpenJDK 25 against a signed aapt2-built probe APK with two resource
locales: launcher version, on-disk digest agreement, metadata projection,
manifest package agreement, and both string tables (default and de).
Parser goldens come from the same decode. READMEs carry the new
'Android resources' row in every supported language.
* fix(apktool): own snapshots and bound decoded resource reads
* docs(apktool): describe owned resources and bounded projection
---------
Co-authored-by: REA Contributor <contributor@rea.tools>
Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>
morluto