The AVD Manager & Running on Real Devices

Android Studio: The IDE Itself

Chapter 6 · The AVD Manager & Running on Real Devices

Chapter 3 mentioned the emulator only in passing, as the slower step the Preview pane lets you defer. This chapter covers it directly, alongside its real alternative: running the app on a genuine physical device.

The AVD Manager: Creating a Virtual Device

An Android Virtual Device (AVD) is configured from two separate choices: a device definition (screen size and density, mimicking a specific phone or tablet form factor) and a system image (a specific Android version, and whether it includes Google Play services). System images come in two architectures: x86/x86_64 images run fast, with genuine hardware acceleration on a typical development machine's own CPU; ARM images run through slower emulation, but are necessary specifically when testing native code compiled for ARM, since an x86 image can't run that code natively at all.

Running on a Real Device via ADB

# From a terminal, the raw view of what's connected:
adb devices

Running on a physical device requires enabling Developer Options and USB debugging on the device itself. Underneath both the emulator and a physical device connection is the same underlying tool: ADB (Android Debug Bridge), the actual communication protocol Android Studio's own friendly device dropdown is simply a UI layer over. Running adb devices directly in a terminal shows the same raw list of connected devices the IDE's own dropdown is built from — genuinely useful for confirming a device is actually detected when the IDE's own UI seems stuck or empty.

Emulator vs. Real Device: When Each One Is Actually Necessary

The emulator's own real strengths: fast iteration without needing to physically connect anything, easy access to many different OS versions and screen sizes without owning the corresponding hardware, and snapshots that let a virtual device restart quickly rather than fully rebooting each time. A real device becomes genuinely necessary — not just nicer to have — for true hardware sensors (an actual camera, real GPS, a real accelerometer) that go meaningfully beyond an emulator's own simulated versions, real-world performance characteristics an emulator can't fully replicate, and testing against a specific manufacturer's own modified Android build rather than the stock system images the AVD Manager provides.

Aspect	Emulator	Real Device
Iteration speed	Fast, snapshots available	Slower to set up per session
OS/screen-size coverage	Easy — any image, any definition	Limited to owned hardware
Real sensors	Simulated only	Genuine hardware
Real performance	Not fully representative	Accurate
OEM-specific builds	Not available	Only way to test this

A real caveat for Chapter 5's own Profiler

Profiling results captured on an emulator can be meaningfully different from a real device's own actual performance, since emulator hardware acceleration doesn't perfectly mirror a real phone's CPU, GPU, or thermal behavior. Chapter 5's own CPU/Memory/Network Profiler tools are still useful on an emulator for finding obvious problems, but a final performance read should come from a real device, not an emulator's own numbers alone.

Working well on the emulator doesn't guarantee the same on a real device

It's tempting to treat good emulator performance as proof the app performs well, period. The emulator typically runs on the development machine's own far more powerful CPU and RAM than a real phone has, and it doesn't replicate a real device's thermal throttling under sustained load, background-app memory pressure, or its actual sensor hardware. Genuine performance and behavior differences between emulator and real device are common enough that testing on at least one real device before release is a standard, necessary practice — not excessive caution.

Hands-On Exercises

Exercise 1

A developer needs to test native code compiled specifically for ARM processors. Explain why an x86_64 system image in the AVD Manager wouldn't be an appropriate choice here, even though it would run faster.

📄 View solution

Exercise 2

An app performs smoothly on the emulator during development, and the team considers performance testing complete as a result, skipping real-device testing before release. Using this chapter's own warning box, explain the risk in this decision.

📄 View solution

Exercise 3

A physical device connected via USB doesn't appear in Android Studio's own device dropdown. Using this chapter's own material, describe a troubleshooting step that goes beneath the IDE's own UI to check what's actually connected.

📄 View solution

Chapter 6 Quick Reference

An AVD combines a device definition (screen size/density) and a system image (Android version); x86/x86_64 is fast, ARM is needed for native ARM code
ADB is the actual protocol underneath both emulator and real-device connections — Android Studio's device dropdown is a UI over it; adb devices shows the raw list
The emulator wins on iteration speed and OS/screen coverage; a real device is necessary for true sensors, real performance, and OEM-specific builds
Good emulator performance is not proof of real-device performance — thermal behavior, memory pressure, and real hardware genuinely differ