The Android Emulator, bundled with Android Studio, is usually the first thing to set up when testing an app across different device sizes and Android versions without owning a physical device for each.
Creating a virtual device
Android Studio → Device Manager → Create Device:
- Pick a hardware profile (Pixel 8, Pixel Tablet, etc.) — this determines screen size and resolution.
- Pick a system image — the Android version to run. Choosing one with Google Play included (not just "Google APIs") matters if your app depends on Play Services, or if you want to test installing from the Play Store itself.
- Name the AVD (Android Virtual Device) and finish.
# Or list/create from the command line
avdmanager list avd
avdmanager create avd -n Pixel8_API34 -k "system-images;android-34;google_apis_playstore;x86_64"Enabling hardware acceleration
The single biggest factor in emulator performance. On Intel/AMD machines, this means having Intel HAXM (older) or, on modern setups, the OS's built-in virtualization (Hyper-V on Windows, or the native hypervisor framework on macOS) enabled. Android Studio's Device Manager will warn you if acceleration isn't active — don't ignore that warning, since an unaccelerated emulator can be 5-10x slower.
On Apple Silicon Macs, use an arm64 system image rather than x86_64 — running x86 images requires translation and is noticeably slower than a native ARM image.
Common day-to-day commands
emulator -list-avds # list available virtual devices
emulator -avd Pixel8_API34 # launch a specific one
adb devices # confirm it's connected
adb install app-debug.apk # install an APK onto the running emulator
adb logcat # stream device logsSimulating real-world conditions
The emulator's Extended Controls panel (the "..." icon in the emulator toolbar) lets you simulate:
- GPS location changes — useful for testing location-based features without physically moving.
- Network conditions — throttle to simulate 3G speeds or high latency, surfacing loading-state bugs that only show up on slow connections.
- Battery state — test how the app behaves on low battery or while charging.
- Phone calls and SMS — simulate incoming calls/texts to test how the app handles interruptions.
When a physical device is still worth it
The emulator can't fully replicate manufacturer-specific behavior (especially on heavily customized Android skins), real camera/sensor input, actual touch latency, or genuine battery/thermal behavior. For final testing before a release — particularly anything involving the camera, biometrics, or performance under real-world conditions — testing on at least one or two physical devices catches issues the emulator won't.
A practical setup
For everyday development: one mid-range emulator profile (a Pixel with a recent-but-not-bleeding-edge API level) for fast iteration, plus one or two emulators at the extremes — the oldest API level you still support, and the newest — to catch version-specific behavior before it reaches a physical device or a release.
