Skip to content

feat: support app launch arguments and feature flags - #388

Open
wxxion wants to merge 1 commit into
mobile-next:mainfrom
wxxion:feature/launch-app-arguments
Open

feat: support app launch arguments and feature flags#388
wxxion wants to merge 1 commit into
mobile-next:mainfrom
wxxion:feature/launch-app-arguments

Conversation

@wxxion

@wxxion wxxion commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

Add an optional launchArgs parameter to mobile_launch_app while preserving existing launch behavior when arguments are absent.

  • pass argument pairs through Android intent extras, go-ios, and simctl
  • keep mobilecli for normal simulator launches and use simctl only for non-empty launch arguments
  • validate inputs before side effects, reject NUL values, and quote Android remote-shell values
  • cover Android, iOS, simulator, and MCP launch boundaries

Relates to #370

Add an optional launchArgs parameter to mobile_launch_app while preserving existing launch behavior when arguments are absent.

- pass argument pairs through Android intent extras, go-ios, and simctl
- keep mobilecli for normal simulator launches and use simctl only for non-empty launch arguments
- validate inputs before side effects, reject NUL values, and quote Android remote-shell values
- cover Android, iOS, simulator, and MCP launch boundaries

Relates to mobile-next#370
@coderabbitai

coderabbitai Bot commented Jul 19, 2026

Copy link
Copy Markdown

Walkthrough

Adds optional string launch arguments to the Robot interface and MCP mobile_launch_app tool, with validation for keys and NUL-containing values. Android uses explicit launcher activity commands with quoted string extras when arguments are present, while iOS and simulators append platform-specific arguments. MobileDevice delegates argument-bearing launches to Simctl. Server dependency injection supports overriding robot resolution. Tests cover validation, command construction, routing, error propagation, and MCP behavior.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title matches the main change by describing support for app launch arguments, though "feature flags" is not reflected in the diff.
Description check ✅ Passed The description clearly matches the changes by explaining launchArgs support, validation, platform handling, and tests.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@wxxion
wxxion marked this pull request as ready for review July 21, 2026 06:17

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
src/android.ts (1)

181-200: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

resolveLauncherActivity throws on any ambiguity, unlike the monkey-based fallback.

Apps with more than one LAUNCHER-category activity/alias (multiple icons, deep-link aliases) launch fine via monkey (used when no launchArgs), but will now fail with "Could not resolve a launchable activity" as soon as launchArgs are supplied, since am start -n requires exactly one match here.

Consider falling back to the first resolved component instead of throwing when there are multiple candidates, to keep behavior closer to the monkey path.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/android.ts` around lines 181 - 200, Update resolveLauncherActivity to
return the first valid component when multiple launcher activities are resolved,
instead of throwing for components.length greater than one. Continue throwing
the existing ActionableError when no valid components are found, and preserve
the current command-error handling.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/android.ts`:
- Around line 181-200: Update resolveLauncherActivity to return the first valid
component when multiple launcher activities are resolved, instead of throwing
for components.length greater than one. Continue throwing the existing
ActionableError when no valid components are found, and preserve the current
command-error handling.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8844df6e-6006-492c-ad1d-7dc71db87260

📥 Commits

Reviewing files that changed from the base of the PR and between f084553 and f69fe50.

📒 Files selected for processing (9)
  • README.md
  • src/android.ts
  • src/ios.ts
  • src/iphone-simulator.ts
  • src/mobile-device.ts
  • src/robot.ts
  • src/server.ts
  • src/utils.ts
  • test/launch-args.test.ts

@gmegidish

Copy link
Copy Markdown
Member

@wxxion great prs! all three, I'll review them in the next few days and I'll merge. thank you so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants