fix(android): support Windows hosts

[V3RON]

What is this?

Harness can now run the Android platform from a Windows host. Previously it failed before reaching a device, reporting "Android command-line tools are missing" even with a correctly installed SDK. The Android package assumed POSIX file names, used bash pipelines, and built paths from $HOME.

Fixes #191, fixes #183.

How does it work?

Harness already runs every command through nano-spawn, which resolves PATHEXT and runs .bat files through cmd.exe. That means Windows needs only one check, in the SDK binary path helpers:

• On win32, adb and emulator resolve to .exe, and sdkmanager and avdmanager resolve to .bat. Existence checks now look for the real files.
• When neither ANDROID_HOME nor ANDROID_SDK_ROOT is set, the default SDK location on Windows is %LOCALAPPDATA%\Android\Sdk.

The rest of the change removes POSIX-only code rather than adding branches for Windows:

• Answering prompts: yes | sdkmanager … and printf 'no\n' | avdmanager … now start the tool directly and write the answers to its stdin. This also removes the hand-rolled shell quoting.
• Writing AVD files: the .ini file and the config.ini additions are written with fs.writeFile / fs.appendFile instead of printf redirection.
• AVD paths: they are built with path.join(os.homedir(), '.android', 'avd') behind one shared helper instead of ${process.env.HOME}/….

Automatically downloading the command-line tools on Windows is still unsupported and keeps its existing "set ANDROID_HOME" error.

Why is this useful?

Teams developing on Windows can run Harness Android tests locally against physical devices and emulators. On macOS and Linux, SDK and AVD management no longer depends on bash being available.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
react-native-harness	Ready	Preview	Sep 14, 2026 6:03am UTC

[V3RON]

Hey @StasDoskalenko 👋
You own a Windows machine. Could you please run this PR locally to see if it really solves the linked issues? I would be very, very grateful 🙏

[StasDoskalenko]

Hey @V3RON, sure, will do 👍

[StasDoskalenko]

Tested this on a real Windows machine (Windows 11, JDK 21, Android SDK installed the normal way through Android Studio). Good news and a new finding.

What's fixed

I ran the built platform-android package straight from this branch against a clean environment (no ANDROID_HOME or ANDROID_SDK_ROOT set, cmdline-tools genuinely installed):

• getDefaultUnixAndroidSdkRoot correctly falls back to %LOCALAPPDATA%\Android\Sdk on win32.
• adb, emulator, sdkmanager and avdmanager binary paths correctly resolve to .exe / .bat.
• With cmdline-tools actually present, the environment check no longer throws "Android command-line tools are missing." It gets past that check.

That's exactly what #191 and #183 describe, and it's fixed.

What's still broken

Once past that check, harness tries to install missing SDK packages through sdkmanager / avdmanager, and that step fails on Windows with a different, much more confusing error.

Repro with ensureAndroidEmulatorEnvironment from this branch, no ANDROID_HOME set, a device profile that needs a package that isn't installed yet:

HARNESS Installing missing Android SDK packages: platforms;android-37, system-images;android-37;default;x86_64

Command failed with exit code 255: 'C:\...\Sdk\cmdline-tools\latest\bin\sdkmanager.bat' '--sdk_root=C:\...\Sdk' --licenses
stderr:
=C:\...\Sdk""=="" goto show_help_error was unexpected at this time.

It isn't specific to that one argument. Calling avdmanager.bat with no arguments that need escaping at all fails the same way:

import nanoSpawn from 'nano-spawn';
await nanoSpawn('C:\\...\\Sdk\\cmdline-tools\\latest\\bin\\avdmanager.bat', ['list', 'avd']);
// exit 255: "The syntax of the command is incorrect."

Why

Since a Node security fix (CVE-2024-27980), child_process.spawn refuses to run .bat files directly, it throws EINVAL unless you pass shell: true. nano-spawn, which @react-native-harness/tools's spawn wraps, works around that by detecting the .bat extension and re-routing through cmd.exe itself, escaping the file and arguments by hand (source/windows.js, escapeFile is applied twice to build the quoted command line).

That hand escaping does not survive Android's own sdkmanager.bat / avdmanager.bat, which are themselves multi-layer batch launchers that forward %* into another batch or jar call. The result is garbled syntax by the time it reaches the actual launcher, regardless of what arguments were passed.

I checked whether this is just a stale nano-spawn version. It's pinned at 1.0.2 here, latest is 2.1.0, but the Windows escaping code (source/windows.js) is byte for byte identical between the two, so bumping it would not help.

Practically, this means the two things #191 calls out explicitly, accepting SDK licenses / installing packages, and avdmanager create avd, are still broken on Windows after this PR. The error is just much more opaque now (a batch syntax error) than the old one.

Suggestion

I don't think this is fixable by adjusting how the arguments are built (I tried both a combined --sdk_root=X and split --sdk_root X, both fail the same way, and a bare no-argument call fails too). The more reliable fix is probably to stop going through the .bat launchers for these two tools on Windows and invoke the underlying jar directly with java -cp, which sidesteps the nested-batch escaping problem entirely. Happy to help test anything here, I have a Windows box with a real SDK, emulator and AVD set up.

Update: tried the java-direct fix locally, it works

Went ahead and prototyped this locally (not pushed anywhere, happy to open it as a real PR against your branch if you want it that way instead).

Both sdkmanager.bat and avdmanager.bat turn out to be thin launchers. avdmanager.bat on every cmdline-tools version I checked is just java -classpath <toolsdir>\lib\avdmanager-classpath.jar com.android.sdklib.tool.AvdManagerCli %*. sdkmanager.bat on older cmdline-tools is the same pattern with a different jar and class; on the newest cmdline-tools release it has been replaced with a shim that calls a real android.exe binary that ships right next to it.

On win32, instead of spawning the .bat, I spawn java.exe (or android.exe when present) directly with the same arguments. Both are real executables, so nano-spawn spawns them with no shell and no escaping at all, which sidesteps the whole nested-batch problem rather than trying to fix the escaping.

Validated end to end on the same machine, cold SDK state each time:

• avdmanager list device, avdmanager list avd: clean, exit 0, correct output.
• sdkmanager package install through ensureAndroidAvdProvisioningAvailable: downloaded and installed platforms;android-34 + system-images;android-34;default;x86_64 (and separately API 33) for real, verified the files landed on disk.
• createAvd, the exact code path from Android platform fails on Windows hosts #191/Windows Android SDK path not found #183 including the stdin: 'no\n' answer to the custom-hardware-profile prompt: created a real AVD, then deleted it, no errors.
• A genuinely missing/invalid package (mismatched system image tag) still fails with a clear "Android SDK packages are still missing after installation: ..." instead of either the old missing-tools error or the new batch garbage.
• All 57 existing platform-android unit tests still pass unchanged, since this is gated behind process.platform === 'win32'.

One more thing I ran into and worked around: the new android.exe exits with a native-crash-looking code (3221226505, i.e. 0xC0000409) even on a fully successful install, when its output is piped rather than a real console, which is exactly how harness spawns everything. Packages land on disk correctly regardless. Since ensureAndroidSdkPackages already re-checks what's actually missing right after the install call, I just let that recheck be the source of truth here instead of trusting android.exe's exit code, so a real failure still surfaces a clear error and a cosmetic one doesn't.

Rough diff of the approach (packages/platform-android/src/environment.ts and the two call sites in adb.ts that used getAvdManagerBinaryPath() directly):

// environment.ts
const getJavaBinaryPath = (): string => {
  const javaHome = process.env.JAVA_HOME;
  const exeName = process.platform === 'win32' ? 'java.exe' : 'java';
  return javaHome ? path.join(javaHome, 'bin', exeName) : exeName;
};

const getCmdlineToolsDir = (sdkRoot: string): string =>
  path.join(sdkRoot, ...CMDLINE_TOOLS_PATH_SEGMENTS);

const runAvdManagerWindows = (sdkRoot, args, spawnOptions) => {
  const classpath = path.join(getCmdlineToolsDir(sdkRoot), 'lib', 'avdmanager-classpath.jar');
  return spawn(
    getJavaBinaryPath(),
    [
      '-Dcom.android.sdkmanager.toolsdir=' + getCmdlineToolsDir(sdkRoot),
      '-classpath', classpath,
      'com.android.sdklib.tool.AvdManagerCli',
      ...args,
    ],
    spawnOptions,
  );
};

export const runAvdManager = (args, spawnOptions, sdkRoot = getRequiredAndroidSdkRoot()) =>
  process.platform === 'win32'
    ? runAvdManagerWindows(sdkRoot, args, spawnOptions)
    : spawn(getAvdManagerBinaryPath(sdkRoot), args, spawnOptions);

// sdkmanager: same idea, falls back to the classic `sdkmanager-classpath.jar`
// + `com.android.sdklib.tool.sdkmanager.SdkManagerCli` when present, otherwise
// calls `android.exe --sdk=<root> sdk install <packages>` directly.

I know this is a fair bit more surface area than the current PR, so entirely your call whether you want it folded in here, as a follow-up, or done differently. Let me know if you want the actual patch.