[PR #6841] [CLOSED] fix(adb): pass integer intent extras as decimal #7423

Closed
opened 2026-11-01 21:47:45 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/6841
Author: @bercedev
Created: 10/23/2026
Status: ❌ Closed

Base: main ← Head: fix/adb-int-extras-decimal


📝 Commits (1)

  • 09b9cae fix(adb): pass integer intent extras as decimal

📊 Changes

2 files changed (+52 additions, -1 deletions)

View changed files

📝 src/adb/AdbProvider.test.ts (+47 -0)
📝 src/adb/AdbProvider.ts (+5 -1)

📄 Description

Summary

Fixes #6807.

start_adb_activity accepts int extras as signed decimal text, but the argument builder passed the string to am start --ei unchanged. Android's am reads --ei with Integer.decode, so 010 became 8, -010 became -8 and 08 failed to parse. Integer and long extras now go out without leading zeros, so 010 reaches Android as 10.

Problem and expected behavior

The schema (adbInputSchemas.start_adb_activity) documents the value as "signed decimal text" and accepts ^-?\d+$. AdbProvider.startActivity forwarded extra.value as the operand of --ei/--el, where a leading 0 is an octal prefix for --ei. Expected (from the issue): the decimal value the caller wrote.

Change and scope

In the extras flatMap, int and long values drop leading zeros before a digit (/^(-?)0+(?=\d)/ → $1), so 010 → 10, -010 → -10, 08 → 8, while 0 stays 0. long gets the same treatment so both decimal types behave the same; string, boolean and float extras are untouched.

Follow the contribution scope. Unresolved scope, authority, side effects, or required verification block integration. Ordinary fix within existing boundaries: not applicable.

Contract and boundary impact

  • Semantic owner and earliest changed stage: argument construction in AdbProvider.startActivity (src/adb/AdbProvider.ts).
  • Contribution scope fit and linked maintainer decision: ordinary fix, not applicable.
  • CLI and MCP/tool-catalog contract: no schema change; the documented decimal meaning now reaches the device.
  • Provider, bridge, target-format, or platform compatibility: ADB provider only.
  • Evidence, artifact, provenance, or reconstruction contract: none.
  • Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable.
  • Generated metadata (docs/public/product-catalog.json), package, or installation impact: none.

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

  • Read existing files or captured data.
  • Launch or attach to a process.
  • Inject instrumentation or run scripts/code.
  • Change process memory, registers, files, or configuration.
  • Contact network services.
  • Recover protected code or work around protections.
  • Documentation or usability only; no target interaction.
  • Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

  • Tests added or updated: AdbProvider.test.ts, "passes integer extras with leading zeros as decimal": 010, -010, 08, 0 (int), 007 (long) and 007 (string) through the adb stub; the logged argv has 10, -10, 8, 0, 7 and the string unchanged.
  • Base reproduction or other evidence: on main the new test fails with 010, -010, 08 passed through.
  • User-visible CLI/MCP output (if applicable): not captured; the change is in the argv sent to adb.
  • Remaining proof gaps: no device or emulator was run; the Android side (Integer.decode) is as described in the issue.

Validation performed

In a Node 24 container with no network, after npm ci --ignore-scripts:

  • npx vitest run src/adb/AdbProvider.test.ts: 97 passed.
  • node scripts/run-typescript.mjs --noEmit: no errors.
  • oxlint on the changed files: 30 warnings, 0 errors, the same 30 as on main.
  • oxfmt --check on the changed files: clean.
  • npm run verify:module-boundaries: passed.

Compatibility, safety, and release

  • Breaking changes or migration steps: none; a caller who meant octal could not express it through the decimal schema anyway.
  • Real Hopper/Ghidra, browser, or OS coverage: none needed.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: same argv vector, only the numeric text changes.

Author readiness

Human owner: @bercedev

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/6841 **Author:** [@bercedev](https://github.com/bercedev) **Created:** 10/23/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/adb-int-extras-decimal` --- ### 📝 Commits (1) - [`09b9cae`](https://github.com/morluto/rea/commit/09b9cae8eecf6e97283e3790ce6dc69352aa857b) fix(adb): pass integer intent extras as decimal ### 📊 Changes **2 files changed** (+52 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `src/adb/AdbProvider.test.ts` (+47 -0) 📝 `src/adb/AdbProvider.ts` (+5 -1) </details> ### 📄 Description ## Summary Fixes #6807. `start_adb_activity` accepts `int` extras as signed decimal text, but the argument builder passed the string to `am start --ei` unchanged. Android's `am` reads `--ei` with `Integer.decode`, so `010` became 8, `-010` became -8 and `08` failed to parse. Integer and long extras now go out without leading zeros, so `010` reaches Android as `10`. ## Problem and expected behavior The schema (`adbInputSchemas.start_adb_activity`) documents the value as "signed decimal text" and accepts `^-?\d+$`. `AdbProvider.startActivity` forwarded `extra.value` as the operand of `--ei`/`--el`, where a leading `0` is an octal prefix for `--ei`. Expected (from the issue): the decimal value the caller wrote. ## Change and scope In the extras `flatMap`, `int` and `long` values drop leading zeros before a digit (`/^(-?)0+(?=\d)/` → `$1`), so `010` → `10`, `-010` → `-10`, `08` → `8`, while `0` stays `0`. `long` gets the same treatment so both decimal types behave the same; string, boolean and float extras are untouched. Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope). Unresolved scope, authority, side effects, or required verification block integration. Ordinary fix within existing boundaries: not applicable. ## Contract and boundary impact - Semantic owner and earliest changed stage: argument construction in `AdbProvider.startActivity` (`src/adb/AdbProvider.ts`). - Contribution scope fit and linked maintainer decision: ordinary fix, not applicable. - CLI and MCP/tool-catalog contract: no schema change; the documented decimal meaning now reaches the device. - Provider, bridge, target-format, or platform compatibility: ADB provider only. - Evidence, artifact, provenance, or reconstruction contract: none. - Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: none. Expected effects (check known effects; use documentation-only on its own). Unchecked items do not establish absence; leave uncertainties visible. - [ ] Read existing files or captured data. - [x] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: `AdbProvider.test.ts`, "passes integer extras with leading zeros as decimal": `010`, `-010`, `08`, `0` (int), `007` (long) and `007` (string) through the adb stub; the logged argv has `10`, `-10`, `8`, `0`, `7` and the string unchanged. - Base reproduction or other evidence: on `main` the new test fails with `010`, `-010`, `08` passed through. - User-visible CLI/MCP output (if applicable): not captured; the change is in the argv sent to `adb`. - Remaining proof gaps: no device or emulator was run; the Android side (`Integer.decode`) is as described in the issue. ## Validation performed In a Node 24 container with no network, after `npm ci --ignore-scripts`: - `npx vitest run src/adb/AdbProvider.test.ts`: 97 passed. - `node scripts/run-typescript.mjs --noEmit`: no errors. - `oxlint` on the changed files: 30 warnings, 0 errors, the same 30 as on `main`. - `oxfmt --check` on the changed files: clean. - `npm run verify:module-boundaries`: passed. ## Compatibility, safety, and release - Breaking changes or migration steps: none; a caller who meant octal could not express it through the decimal schema anyway. - Real Hopper/Ghidra, browser, or OS coverage: none needed. - Package or release metadata impact: none. - Security, privacy, process, or containment review: same argv vector, only the numeric text changes. ## Author readiness <!-- The human owner completes these declarations before requesting review. The PR author is the owner by default. A different owner must explicitly accept ownership on this PR. AI agents must leave these declarations to a human to dictate to them or there could be catastrophic consequences for many users of REA. Draft PRs may leave them unchecked. These declarations record initial readiness when opening the PR for review; later pushes do not require a new human sign-off. Keep the description and validation evidence current as the work changes. See CONTRIBUTING.md#pull-request-ownership-and-readiness. --> Human owner: @bercedev - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge <!-- Draft PRs may leave pending items unchecked. Resolve material scope and authority questions before integration. --> - [ ] This PR addresses a concrete problem or an agreed enhancement. - [ ] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [ ] The PR has one focused outcome and the title follows `type(scope): outcome`. - [ ] Related issue is linked, or the reason for not linking one is stated above. - [ ] Tests cover changed observable behavior and meaningful failure paths. - [ ] Owning docs, contracts, and generated metadata are updated where needed. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-11-01 21:47:45 +00:00
Sign in to join this conversation.
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#7423
No description provided.