Emulators skip the USB driver problem entirely since there is no physical hardware to enumerate, but connecting ADB to one still trips people up in different ways — usually a port conflict between two emulator tools running at once, or ADB seeing an emulator that never actually finished booting. Here is how the connection actually works under the hood for the two most common emulator setups.
When you launch a virtual device from Android Studio's AVD Manager, the emulator process automatically registers itself with the ADB server running on your machine over a localhost TCP connection — no manual adb connect step is needed. Confirm it registered correctly:
adb devicesA running AVD shows up with an identifier like emulator-5554 rather than a hardware serial number. The number is the console port; the ADB port for the same instance is always one higher (5555 in this example), and both are reserved automatically for that emulator session.
If adb devices shows nothing while the emulator window is clearly open and booted, the ADB server that Android Studio's internal tooling talks to may be a different instance than the one your terminal is using. Kill and restart the server to force both to sync to one instance:
adb kill-server
adb start-serverGenymotion runs each virtual device inside VirtualBox or its own hypervisor layer rather than the AOSP emulator Android Studio uses, and in some configurations it does not auto-register with your existing ADB server the way an AVD does. If adb devices does not show a running Genymotion instance, connect manually using the IP address Genymotion assigns the virtual device, visible in its own device list:
adb connect 192.168.56.101:5555Genymotion virtual devices typically get an IP on a host-only VirtualBox network (commonly in the 192.168.56.x range), which is why the address looks like a LAN IP rather than a plain localhost port — from ADB's perspective it is a networked device, not fundamentally different from connecting to a physical phone over Wi-Fi.
Each additional AVD instance claims the next available even-numbered port pair (5554/5555, then 5556/5557, and so on), so adb devices can list several emulators simultaneously without conflict as long as each was launched cleanly. Problems appear when a previous emulator session crashed without releasing its port; the next launch attempt may fail to bind or silently reuse a stale port association. Running adb kill-server followed by adb start-server generally clears this without needing to reboot the host machine.
Both tools share the same system ADB server by default (there is only one ADB server per machine unless you explicitly configure otherwise), so running an AVD and a Genymotion instance at the same time works fine as long as their port ranges do not collide, which is rare since Genymotion's networked IP addresses are distinct from the AVD's port-based emulator-XXXX identifiers. If you do hit a conflict, target the specific instance explicitly rather than troubleshooting blind:
adb -s emulator-5554 shell
adb -s 192.168.56.101:5555 shellAn emulator lets you validate ADB-driven automation scripts, screenshot pipelines, or install/uninstall flows without needing a physical device or fighting a manufacturer's USB driver at all. It is also the only practical way to test against Android versions or screen configurations you do not own hardware for, since AVD images cover a much wider matrix of API levels and form factors than any single physical device collection would.
Because both connection paths use TCP over localhost or a virtual network adapter, a strict firewall or antivirus product on the host machine can silently block the emulator's ADB port even though nothing about the ADB or emulator configuration itself is wrong. This shows up as an emulator that boots and displays fine but never appears in adb devices, and no error message points at the actual cause. If a fresh AVD refuses to register while an older one on the same machine worked previously, check whether a security tool was installed or updated in between, and add an exception for the ADB and emulator executables rather than disabling the firewall outright.
Genymotion typically relies on VirtualBox or a hardware virtualization layer, and on Windows this can conflict with Hyper-V-based tools, including the Android Studio emulator's own accelerated backend, when both try to claim the CPU's virtualization extensions at once. Symptoms range from one emulator refusing to start while the other is running, to a Genymotion instance booting extremely slowly because it fell back to unaccelerated emulation. If you regularly switch between the two, check which virtualization backend is currently active before assuming an ADB connection problem when the real issue is the emulator failing to boot correctly at all.
An AVD resumed from a saved snapshot registers with ADB much faster than one performing a full cold boot, sometimes fast enough that a script issuing adb devices immediately after launch still sees nothing because the registration has not completed yet. Scripts driving emulator startup should poll with a short retry loop rather than assuming the device is available the instant the launch command returns, since the emulator process starting is not the same moment as the ADB daemon inside it becoming reachable.