Introduction

The Android emulator usually fails with "invalid command-line parameter" because the emulator binary received an option it no longer understands, or because Android Studio is pointing at mismatched SDK tools. The fix is rarely in your app code; it is usually in the emulator command, the SDK installation, or the virtual device definition.

Confirm the Emulator Command and SDK Paths

Start by checking which emulator binary you are actually running. Old blog posts often show flags that worked years ago but are now ignored or rejected by newer emulator builds.

$ANDROID_HOME/emulator/emulator -list-avds
$ANDROID_HOME/emulator/emulator -avd Pixel_8_API_34

If the second command works from the terminal, the emulator itself is fine and the problem is likely in Android Studio configuration. If it fails, inspect the exact command-line flags.

You can also verify that the path points to the modern emulator package rather than an outdated tools directory:

echo "$ANDROID_HOME"
ls "$ANDROID_HOME/emulator"
ls "$ANDROID_HOME/platform-tools"

Historically, developers launched the emulator from locations such as tools/ or reused shell aliases with stale arguments. Current installations expect the binary under emulator/.

Remove Unsupported Flags and Recreate the AVD

An AVD can carry forward settings from older SDK versions. When the emulator parses those settings, it may surface the generic "invalid command-line parameter" message even though the real issue is an obsolete option.

Use the CLI to create a clean device and launch it with the minimum required arguments:

sdkmanager --install "system-images;android-34;google_apis;x86_64"
avdmanager create avd -n TestDevice34 -k "system-images;android-34;google_apis;x86_64"
$ANDROID_HOME/emulator/emulator -avd TestDevice34

If the clean AVD starts, the original device definition is the problem. Deleting and recreating the old AVD is usually faster than trying to patch every saved property.

When Android Studio launches the emulator, check the generated command in the IDE logs. On macOS and Linux, the logs often reveal the full invocation and make the bad flag obvious.

Update the SDK Tools as a Unit

This error also appears when the emulator package, platform tools, and command-line tools are out of sync. Updating only one part can leave Android Studio invoking a newer emulator against older metadata.

Use sdkmanager to update the main pieces together:

sdkmanager --update
sdkmanager --install "emulator" "platform-tools" "cmdline-tools;latest"

After the update, restart Android Studio and confirm the SDK location in the IDE matches the directory you updated from the terminal.

On Apple Silicon and some Windows setups, architecture mismatches can cause confusing startup errors too. Make sure the system image matches your machine and virtualization support. For example, launching an x86_64 image on unsupported hardware may fail long before your app ever boots.

Check Environment and Local Configuration

If you launch from scripts or CI tasks, inspect environment variables before assuming the local SDK is correct:

echo "$ANDROID_HOME"
echo "$ANDROID_SDK_ROOT"
which emulator

If which emulator points somewhere unexpected, a global shell alias or older SDK installation may be shadowing the intended binary.

In Android Studio, also confirm:

• The SDK path is the same one you use on the command line.
• The selected device image is installed and not partially downloaded.
• Hardware acceleration is enabled in the host system.

These checks are mundane, but they resolve a surprising number of emulator startup failures.

Common Pitfalls

The first pitfall is copying legacy emulator flags from forum posts. Options change over time, and the emulator is not shy about rejecting unknown parameters.

Another common mistake is maintaining multiple SDK installations. Android Studio may use one SDK while the terminal uses another, leading to confusing results where a command works in one place and fails in the other.

Developers also spend too long debugging the app instead of the device definition. If a fresh AVD boots cleanly, the app is not the root cause.

A partially updated SDK is another repeat offender. Updating only platform-tools without updating the emulator or command-line tools can leave incompatible versions on disk.

Finally, do not ignore architecture and virtualization support. A correctly formed command can still fail if the host machine cannot run the selected image efficiently.

Summary

• The error usually means the emulator binary received an unsupported or outdated option.
• Verify the actual emulator path and launch a device from the terminal first.
• Recreate the AVD if a clean device works and the original one does not.
• Update emulator, platform-tools, and command-line tools together.
• Check for multiple SDK installations, stale shell aliases, and host virtualization issues.