Skip to content

fix(android): map adb serials to mobilecli device IDs#383

Open
Cosm1cAC wants to merge 17 commits into
mobile-next:mainfrom
Cosm1cAC:codex/fix-android-mobilecli-device-id
Open

fix(android): map adb serials to mobilecli device IDs#383
Cosm1cAC wants to merge 17 commits into
mobile-next:mainfrom
Cosm1cAC:codex/fix-android-mobilecli-device-id

Conversation

@Cosm1cAC

@Cosm1cAC Cosm1cAC commented Jul 13, 2026

Copy link
Copy Markdown

Problem

Android MCP tools expose ADB serials such as emulator-5554, while mobilecli identifies the same emulator by its AVD ID, such as Codex_API_36. Passing the ADB serial to crash and screen-recording commands returns device not found. The recording tool also reported success before the mobilecli process confirmed startup. On Windows, the ADB path check used process.env.platform, which could prevent AVD-name lookup when ANDROID_HOME was set.

Fix

  • Resolve Android emulator serials to mobilecli AVD IDs before crash and recording calls.
  • Preserve physical-device serials and fall back to the normalized AVD name when discovery has no match.
  • Wait for mobilecli's recording-ready signal; surface errors, early exits, and startup timeouts.
  • Use process.platform to select adb.exe on Windows.
  • Skip Android device discovery entirely for non-emulator IDs.
  • Document the new device-resolution and recording-startup contracts.
  • Add focused regression tests.

Verification

  • 16 focused regression tests pass with 0 skipped and 0 failed.
  • TypeScript type-checking and targeted ESLint pass.
  • The official MCP release fails the crash-list call; the patched server succeeds.
  • A real emulator recording start/stop succeeds through the patched MCP server.
  • Full discovery on the current Windows host with no devices attached: 35 passed, 18 hardware/platform tests skipped, 0 failed.

Fixes #359

Translate adb emulator serials to the AVD IDs expected by mobilecli for crash and screen-recording commands. Fall back to a sanitized AVD name when discovery has no match, preserve physical-device serials, and select adb.exe on Windows when ANDROID_HOME is configured.

Addresses mobile-next#359.
@coderabbitai

coderabbitai Bot commented Jul 13, 2026

Copy link
Copy Markdown

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

Updates ADB executable selection to use process.platform and adds test access for platform mapping. Adds mobilecli emulator ID detection, Android device ID resolution, and sentinel-based screen-recording startup with failure handling. Updates server recording and crash operations to resolve Android emulator IDs before invoking mobilecli. Adds tests for executable naming and Android device resolution.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title is concise and accurately reflects the main change: mapping adb serials to mobilecli device IDs for Android.
Description check ✅ Passed The description is on-topic and summarizes the same Android device-ID and recording fixes.
Linked Issues check ✅ Passed The PR remaps emulator serials for crash and recording paths, waits for recording readiness, and preserves physical-device behavior, matching the issue's core requirements.
Out of Scope Changes check ✅ Passed The changes stay within the Android/mobilecli fix and tests; no clearly unrelated edits are evident.
✨ 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.

@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/server.ts (1)

166-174: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Add emulator pattern guard before getConnectedDevicesWithDetails().

getMobilecliDeviceId calls getConnectedDevicesWithDetails() (which runs adb devices plus 3 adb shell getprop calls per device) for every crash and screen-recording operation, including physical Android devices and iOS devices. Since resolveAndroidDeviceId returns the original ID for non-emulator IDs, these adb calls are wasted for non-emulator devices. Adding the same regex check before the expensive call avoids unnecessary I/O on every invocation.

♻️ Suggested optimization
 const getMobilecliDeviceId = (deviceId: string): string => {
+	if (!/^emulator-\d+$/.test(deviceId)) {
+		return deviceId;
+	}
 	const androidDevice = new AndroidDeviceManager()
 		.getConnectedDevicesWithDetails()
 		.find(device => device.deviceId === deviceId);
 	return androidDevice
 		? mobilecli.resolveAndroidDeviceId(deviceId, androidDevice.name)
 		: deviceId;
 };
🤖 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/server.ts` around lines 166 - 174, Update getMobilecliDeviceId to detect
emulator-style device IDs with the existing emulator pattern before constructing
AndroidDeviceManager or calling getConnectedDevicesWithDetails. Return the
original deviceId immediately for non-emulator IDs, while preserving the current
lookup and resolveAndroidDeviceId behavior for matching emulator IDs.
🤖 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/server.ts`:
- Around line 166-174: Update getMobilecliDeviceId to detect emulator-style
device IDs with the existing emulator pattern before constructing
AndroidDeviceManager or calling getConnectedDevicesWithDetails. Return the
original deviceId immediately for non-emulator IDs, while preserving the current
lookup and resolveAndroidDeviceId behavior for matching emulator IDs.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c8807c95-6d86-420c-b273-6e1a7a56eabf

📥 Commits

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

📒 Files selected for processing (5)
  • src/android.ts
  • src/mobilecli.ts
  • src/server.ts
  • test/android-path.test.ts
  • test/mobilecli.test.ts

Wait for mobilecli's screen-recording readiness signal before reporting success. Propagate process errors, early exits, and startup timeouts to the MCP caller.
@Cosm1cAC

Copy link
Copy Markdown
Author

Addressed the linked-issue warning in 0a8a828. mobile_start_screen_recording now waits for mobilecli to emit its recording-ready signal and returns process errors, early exits, or startup timeouts instead of reporting success. Added regression tests for both early failure and confirmed startup, plus a real emulator start/stop check.

Cosm1cAC added 5 commits July 16, 2026 01:08
Use a local adb-reversed page, handle Chrome first-run prompts, and assert display and screenshot properties that are stable across emulator configurations.
Classify adb emulator serials once and return physical Android and iOS identifiers before expensive Android device discovery.
Describe the new ADB naming, emulator mapping, and recording startup functions so their contracts are explicit and automated documentation coverage remains above threshold.
Use standard multiline JSDoc with parameter and return tags so automated docstring coverage can recognize every function added by the pull request.
@Cosm1cAC

Copy link
Copy Markdown
Author

@coderabbitai The Docstring Coverage pre-merge check still reports 0.00%, but every named function and method added by this PR now has standard multiline TypeScript JSDoc with @param and @returns tags, including the nested recording callbacks. Please re-evaluate the check and list the exact functions it still considers undocumented.

@coderabbitai

coderabbitai Bot commented Jul 16, 2026

Copy link
Copy Markdown
🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

fd . -e ts | xargs -I{} echo {} | grep -E 'android.ts|mobilecli.ts|server.ts' || true

echo "---- android.ts ----"
rg -n "^\s*(export\s+)?(async\s+)?function|=>|/\*\*" src/android.ts | head -80

echo "---- mobilecli.ts ----"
rg -n "^\s*(export\s+)?(async\s+)?(function|class|public|private)|/\*\*" src/mobilecli.ts | head -150

echo "---- server.ts (relevant) ----"
rg -n "getMobilecliDeviceId|/\*\*" src/server.ts | head -50

Length of output: 3482


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "---- android.ts lines 25-45 ----"
sed -n '25,45p' src/android.ts

echo "---- mobilecli.ts lines 55-270 ----"
sed -n '55,270p' src/mobilecli.ts

echo "---- server.ts lines 155-180 ----"
sed -n '155,180p' src/server.ts

Length of output: 8542


⚙️ CodeRabbit configuration inspected

Length of output: 5318


Hi Cosm1cAC — good question. A few clarifications on how this works:

  1. It's non-blocking. The docstrings pre-merge check in this repo is configured as mode: warning with a threshold of 80%, so it can't block the merge on its own — it's advisory.

  2. Scope isn't limited to newly added lines. The coverage metric is generally computed over the public function/method surface of the touched files, not strictly the diff-added functions. So even though every genuinely new function you added (adbExecutableName, normalizeDeviceName, mobilecliAvdId, isAdbEmulatorId, startScreenRecording, its inner fail/onData callbacks, resolveAndroidDeviceId, and getMobilecliDeviceId) does have complete JSDoc with @param/@returns, several pre-existing functions/methods in the same touched files are still undocumented and can pull the score down:

    • src/mobilecli.ts: getPath, executeCommand, executeCommandBuffer, getMobilecliPath, getVersion, remoteListDevices, remoteAllocate, remoteRelease, crashesList, crashesGet
    • src/android.ts: getAdbPath and other pre-existing exported helpers
    • src/server.ts: ensureMobilecliAvailable
  3. Stale result. A 0.00% reading despite the clearly-JSDoc'd additions in commit 0a8a828 suggests the check simply hasn't been recomputed against the latest commit yet. I'll trigger a fresh review pass now so it re-evaluates against the current diff.

If the score is still off after the recompute, the most likely explanation is the "whole touched-file surface" scope described above rather than a parsing issue with your JSDoc — in that case, adding brief docstrings to the pre-existing methods listed above would raise the percentage. Since this check is warning-only, you can also choose to leave it as-is without blocking the merge.


✏️ Learnings added
Learnt from: Cosm1cAC
URL: https://github.com/mobile-next/mobile-mcp/pull/383

Timestamp: 2026-07-16T04:23:24.983Z
Learning: In the mobile-mcp repository, the CodeRabbit "docstrings" pre-merge check is configured with mode "warning" and threshold 80 (non-blocking). Its coverage percentage appears to be computed over the public function/method surface of touched files broadly, not strictly newly-added functions in the diff, so pre-existing undocumented methods in touched files (e.g., in src/mobilecli.ts, src/android.ts, src/server.ts) can lower the reported score even when all new functions have complete JSDoc.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

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

Labels

None yet

Projects

None yet

1 participant