When Visual Studio can’t list your AVD, the fix is usually a missing emulator package, a wrong SDK path, or an ADB mismatch.
You hit Run, open the device drop-down, and the emulator you swear is installed just isn’t there. It’s annoying because you can’t tell if the problem is Visual Studio, the Android SDK, or the emulator itself.
The good news is that this issue tends to follow a few repeat patterns. Once you check them in an order, you stop guessing and you get back to shipping today.
Why The Emulator Vanishes In Visual Studio
Visual Studio doesn’t “own” the emulator. It discovers devices by reading Android SDK locations, finding the right command-line utilities, and asking ADB for a list of connected devices. If any link in that chain points at the wrong folder or the wrong version, the emulator can run and still stay invisible inside the IDE.
Two setups also get mixed up all the time. The retired “Visual Studio Emulator for Android” was deprecated, and most current workflows rely on the Google Android Emulator (the same one Android Studio uses). If you have old pieces left behind, Visual Studio can end up checking the wrong place.
| Quick Check | Where To Look | What It Usually Means |
|---|---|---|
| Android menu is missing | Visual Studio top menu | The Android workload isn’t installed |
| No AVDs listed | Tools > Android > Android Device Manager | SDK or emulator packages are missing |
| Emulator runs, VS shows nothing | ADB device list | ADB is pointed at a different SDK |
| Emulator won’t start | Windows virtualization settings | Hardware acceleration isn’t active |
If you take away one idea, make it this. Get Visual Studio, the Android SDK, and ADB all reading from the same SDK folder. That single alignment fixes a big chunk of “missing emulator” cases.
Android Emulator Not Showing In Visual Studio
If you’re seeing android emulator not showing in visual studio, start with the simplest check: can Visual Studio open the Android Device Manager? It’s the front door for AVD creation and discovery.
If the menu is there, your next move is to confirm the Android SDK and emulator packages exist where Visual Studio expects them. If those pieces are missing, Visual Studio may show an empty list even when your project builds.
- Open Android Device Manager — In Visual Studio, go to Tools > Android > Android Device Manager and see if any virtual devices appear.
- Verify SDK Location — Check that the Android SDK directory is a real folder with subfolders like platforms, platform-tools, and emulator.
- Install Emulator Package — In Tools > Android > Android SDK Manager, use the Tools tab to install or update the Android Emulator component.
- Create One Fresh AVD — Add a new virtual device from the Device Manager so you test discovery on a new entry.
If Visual Studio can’t open the manager at all, or the Android menu is missing, treat that as a setup issue, not an emulator issue. You’ll get more mileage by fixing workloads first than by reinstalling random SDK pieces.
Android Emulator Missing In Visual Studio After An Update
Updates can shuffle paths and versions. A Visual Studio update can refresh its Android tooling, an Android SDK update can move packages, and a Windows update can change virtualization settings. The result looks like a sudden break: the emulator worked yesterday, now it’s gone.
Start with a quick sanity check on your Visual Studio version and workloads. If you’re on an older install, the Android tooling integration can be incomplete, and the device list can act flaky.
- Repair The Visual Studio Install — Run Visual Studio Installer, choose Modify, confirm the Android-related workload you use is selected, then run Repair if things look out of sync.
- Recheck The SDK Path — Make sure Visual Studio points to the same Android SDK folder after updates, not to a stale folder left by an older install.
- Update The Emulator Component — In the SDK Manager Tools tab, update the emulator package, since emulator bugs get fixed by emulator updates.
A common “after update” trap is a second Android SDK install. You can end up with one SDK from Android Studio and one SDK from Visual Studio, each with its own ADB. If Visual Studio points at one and the running emulator uses the other, the device list looks empty even while the emulator window is open.
Fix The SDK, JDK, And Android Workload Setup
Visual Studio can run Android workloads in a few stacks, such as .NET MAUI, Xamarin-based projects, or plain Android-targeting projects. The core pieces stay the same: a JDK, the Android SDK, and the build tools that match your project.
If your paths don’t line up with where you installed things, device discovery and builds both start to wobble. That’s why this section is about aligning files first, not chasing random errors.
Confirm The Workload And Tools Menus
When the Android workload is installed, Visual Studio surfaces an Android menu. If you don’t see Tools > Android at all, the workload selection is the first fix. Many “missing SDK manager” cases trace back to that single checkbox in the installer.
- Install The Right Workload — In Visual Studio Installer, select Mobile development with .NET or the Android workload that matches your project type.
- Install SDK Platform Tools — In SDK Manager, install Platform-Tools so ADB lives in platform-tools.
- Install At Least One Platform — Add an Android API level that your project targets so the build has a real platform folder.
Keep One SDK Folder As The Source Of Truth
Pick one Android SDK folder and stick to it. Your exact folders can differ, yet the rule stays the same: Visual Studio, ADB, and the emulator should all reference the same root.
- Find The SDK Root — Locate the folder that contains platform-tools and emulator.
- Point Visual Studio To It — In Visual Studio’s Android tooling screens, set the SDK path to that root.
- Check ADB From That SDK — Run the adb inside that SDK’s platform-tools folder, not a random one found on your PC.
If you have multiple SDKs, you can keep both installed. The trick is to stop mixing them. If you want Visual Studio to be the driver, set Visual Studio to its SDK and use that ADB for troubleshooting.
Repair Device Discovery In Visual Studio And ADB
Once the SDK pieces are in place, device discovery comes down to ADB. Visual Studio asks ADB for a device list. If ADB is stuck, you’ll see a blank menu even when an emulator is running.
Visual Studio has a built-in ADB restart option in the Android menu, and it’s a fast first move when devices vanish. It clears a lot of “it was there, now it’s not” moments.
- Restart The ADB Server — Use Tools > Android > Restart Adb Server, then reopen the device drop-down.
- Kill Stale ADB Processes — Close Visual Studio, then end any adb.exe processes, and start Visual Studio again.
- Confirm Devices From A Terminal — Run adb devices -l from the SDK you chose and check whether the emulator shows up.
Fix ADB Path Conflicts
If the terminal shows no devices while the emulator window is open, you’re often calling the wrong ADB. This happens when Windows PATH points to an older SDK. The simplest fix is to run ADB by full path from the SDK folder you want, so there’s no confusion.
- Run ADB From Platform-Tools — Open the SDK’s platform-tools folder and run adb devices -l from there.
- Check The Emulator Uses The Same SDK — In Android Device Manager, start the AVD from inside Visual Studio so the IDE owns the launch path.
- Reset The Device List — Stop the emulator, restart ADB, then start the emulator again and recheck the list.
If you keep seeing android emulator not showing in visual studio after these steps, zero in on what Visual Studio is reading at launch. ADB and the emulator can be correct, yet Visual Studio can still be pointed at a different SDK. Fixing that mismatch is the fastest path out of the loop.
When The Emulator Runs But Visual Studio Still Won’t List It
At this point, you’ve aligned SDK paths and you’ve refreshed ADB. If the emulator still doesn’t appear, the remaining causes tend to be the AVD itself, a broken emulator package, or Windows virtualization limits.
Rebuild The AVD Cleanly
AVDs are files on disk. They can get corrupted after failed updates or disk cleanups. The clean fix is to delete the AVD and create a new one with a plain ASCII name. Android’s own emulator troubleshooting notes include Windows cases where Unicode in the AVD name can break launch for certain emulator versions, and updating the emulator fixes it. A safe habit is to name AVDs with simple letters and numbers.
- Delete The Old AVD — In Android Device Manager, remove the virtual device that won’t show.
- Create A New AVD — Pick a common device profile, choose a system image, and keep the name simple.
- Cold Boot Once — Start the AVD with a cold boot so it rebuilds state files from scratch.
Check Hardware Acceleration
On Windows, the emulator needs hardware acceleration to be usable. If acceleration is missing, the emulator may fail to start or crash early, and Visual Studio won’t have a device to list.
- Confirm Virtualization Is On — Enable CPU virtualization in BIOS/UEFI, then restart Windows.
- Install The Acceleration Driver — In SDK Manager’s Tools tab, install the recommended acceleration package for your setup.
- Pick One Virtualization Stack — If you use Hyper-V, keep the emulator on the Hyper-V path; if you use another hypervisor, avoid mixing stacks.
Know When To Use Android Studio For One Step
Visual Studio can manage AVDs, yet the Google emulator is still the Google emulator. If you suspect a broken system image or emulator install, it can help to open Android Studio’s SDK Manager once, update the emulator and system images, and then go back to Visual Studio. This works best when both IDEs point at the same SDK folder.
When everything is lined up, your emulator shows in the device list, your deploy button stops being a gamble, and you can treat the emulator like a reliable test device again.
Sources checked Dec 29, 2025:
learn.microsoft.com .NET MAUI Android Device Manager and hardware acceleration docs,
developer.android.com emulator troubleshooting and release notes.
