The emulator, and running on your own phone

Your app needs something to run on, and you have two choices: a virtual phone inside your computer, or the real phone in your pocket. You will use both, for different reasons, and the most expensive mistake of the module is trusting only the first one. This lesson sets up each, shows you adb, the tool underneath both, and then makes the emulator deliberately worse.

Emulator or phone?

	Emulator	Your own phone
Costs you	RAM (it is a whole second OS), 3 to 9 GB of disk per device	A data-capable USB cable, or Wi-Fi
Good for	Any Android version, any screen size, rotating and resizing, faking location	Real speed, real touch, real network, real manufacturer quirks
Bad at	Telling you how a cheap phone performs	Testing versions or sizes you do not own

With 8 GB of RAM, start with your phone. With 16 GB or more, use both.

Creating a virtual device

You made one with the defaults at the end of the installation lesson. Here is what each step of that wizard was deciding, so the next one you make is chosen rather than accepted.

Virtual devices are called AVDs (Android Virtual Devices), and you manage them in the Device Manager. With a project open, use View → Tool Windows → Device Manager, click + and choose to create a virtual device. The wizard has three steps; the names on the buttons shift a little between Android Studio releases, but the steps do not.

Hardware profile. Pick a phone, such as a recent Pixel. This sets screen size, resolution and default RAM. Profiles marked with the Play Store logo can use images that include Google Play.
System image. The Android operating system the device will boot (lesson 2's "what you run on"). Images with a download icon are not installed yet; downloading one is 2 to 4 GB, so do it on a good connection.
Configuration. Name the device, choose the startup orientation, and, under the advanced settings, adjust RAM, storage and network speed. Leave the defaults for now; you change them deliberately at the end of this lesson.

Choosing a system image

Three choices hide in that list, and two of them matter.

The processor type (ABI) must match your computer. On an Apple silicon Mac, choose an arm64-v8a image. On an Intel or AMD machine, choose x86_64. The emulator runs the image directly on your processor with hardware acceleration; an image for the other architecture is either refused or painfully slow. The Recommended tab usually picks correctly, but check.

On Windows and Linux, acceleration also needs virtualisation (Intel VT-x or AMD-V) enabled in the BIOS. Many laptops ship with it off. If the emulator complains about acceleration, that is almost always why.

Google Play, Google APIs or plain Android. A Google Play image has the Play Store and Google Play services, like a real phone. A Google APIs image has Play services without the store. A plain AOSP image has neither, but lets you become root. For this course, a Google Play image is the right default.

The API level must be at least your minSdk (26). Start with a recent one. Later you will add a second device at API 26 so you can see the oldest phone you support.

Press the play button next to the device in the Device Manager to start it. The first boot takes a minute or two; after that, quick boot restores a saved snapshot and is much faster.

adb: the bridge underneath

Whether the device is virtual or real, Android Studio talks to it through adb, the Android Debug Bridge, from the SDK's platform-tools folder. Put that folder on your PATH now (on a Mac it is ~/Library/Android/sdk/platform-tools; the SDK Manager shows your SDK location), because every Android developer ends up reaching for adb from a terminal.

The first command to learn lists what is connected:

adb devices -l

With one emulator running, the real output was:

List of devices attached
emulator-5554          device product:sdk_gphone64_arm64 model:sdk_gphone64_arm64 device:emu64a transport_id:4

The first column is the serial: emulator-5554 for the first emulator, a hardware serial or an ip:port for a phone. The second is the state, and it is the column to read when something is wrong:

State	Meaning	What to do
`device`	Connected and authorised	Nothing; it works
`unauthorized`	Connected, but you have not accepted the debugging prompt on the phone	Unlock the phone and tap Allow
`offline`	Seen but not responding	Unplug and replug, or restart the emulator
(not listed)	Not seen at all	Cable, USB debugging, or a missing Windows driver

With more than one device connected, every adb command needs to know which one, using -s:

adb -s emulator-5554 shell getprop ro.build.version.release
adb -s emulator-5554 shell getprop ro.build.version.sdk
adb -s emulator-5554 shell getprop ro.product.cpu.abi

16
36
arm64-v8a

That is Android 16, API level 36, on an ARM 64-bit image. Run the same three commands against your phone and you have its version, API level and processor without opening Settings.

Running on your own phone over USB

1. Turn on Developer options. They are hidden until you unlock them. Find Build number and tap it seven times, until the phone says you are now a developer. Where Build number lives depends on the manufacturer:

Phone	Path
Google Pixel	Settings → About phone → Build number
Samsung Galaxy	Settings → About phone → Software information → Build number
OnePlus	Settings → About phone → Build number
Anything else	Search Settings for "Build number"

2. Turn on USB debugging in the new Developer options screen (usually under Settings → System).

3. Connect with a data cable. Many cheap cables only charge. If the phone charges but never appears in adb devices, try another cable before anything else. On Windows you may also need the manufacturer's USB driver; macOS needs nothing extra.

4. Accept the prompt. The phone asks whether to allow USB debugging from this computer, showing its key fingerprint. Tap Allow. Until you do, adb devices reports unauthorized.

The phone now appears in Android Studio's device menu. Pick it and press Run.

Wireless debugging

On Android 11 and later you can drop the cable. The phone and computer must be on the same Wi-Fi network.

In Developer options, turn on Wireless debugging.
In Android Studio, open the device menu and choose Pair Devices Using Wi-Fi.
Pair either by scanning the QR code it shows from the phone's Wireless debugging screen, or by choosing to pair with a code, which shows a six-digit code on the phone to type into Studio.

You pair once; after that, the two reconnect when they are on the same network. From a terminal the equivalent is adb pair with the address and code the phone shows, then adb connect.

What it costs: the phone's battery drains faster, connections drop on busy networks, and on public or office Wi-Fi it is an open door into your phone. Turn Wireless debugging off when you are not using it.

The trap: testing only on a fast emulator

Here is a cold start of Mandi Bhav on an emulator on a fast laptop:

LaunchState: COLD
TotalTime: 722

Under a second, for a screen with one line of text. On the same emulator, other cold starts of the same app that afternoon reported 989 ms, 1194 ms and 1210 ms. Even the fast setup varies by half a second, and none of those numbers tells you anything about Arjun's phone. An emulator on an M-series Mac or a recent desktop has more CPU, more memory and faster storage than a budget phone will ever have, and its network is your broadband.

So make it worse, on purpose. In the Device Manager, edit the device and open the advanced settings:

RAM: lower it towards what a budget phone has.
Multi-core CPU: give it fewer cores.
Network speed and latency: change the default (full speed) to a slow mobile setting such as EDGE or GPRS. Those are the speeds a phone falls back to at the edge of a mandi yard.

Then do the thing nothing replaces: borrow the oldest, cheapest Android phone in your family and run the app on it. Over the course you will measure on it again and again. When a later module adds network calls, caching and lists, this is the device that tells you whether you got it right.

Check your work

Which system image do you need on an Apple silicon Mac? On an Intel laptop? arm64-v8a; x86_64.

What is the difference between a platform and a system image? You compile against the platform; the emulator boots the system image.

adb devices shows your phone as unauthorized. What now? Unlock the phone and accept the USB debugging prompt.

Your phone charges but never appears in adb devices. First suspect? A charge-only cable. Then USB debugging, then (on Windows) the driver.

What do you need for wireless debugging? Android 11 or later, Wireless debugging on, and the same Wi-Fi network; pair once.

Why is a fast TotalTime on the emulator not good news? It measures your laptop, not your users' phones.

Practice

Create an AVD with a Google Play image of the right ABI for your machine. Boot it and run Mandi Bhav on it.
Run adb devices -l and identify the serial and state.
Run the three getprop commands against the emulator. Then enable Developer options and USB debugging on your phone, connect it, and run them against the phone with -s and its serial.
Run Mandi Bhav on your phone from Android Studio.
Set up wireless debugging if your phone runs Android 11 or later. Unplug the cable and run the app again. Then turn Wireless debugging off.
Break it on purpose: with the phone connected, revoke the debugging authorisations in Developer options and run adb devices again. Read the state, then accept the prompt to fix it.
Harder: create a second AVD at API 26 with a slow network setting and reduced RAM. Cold-start Mandi Bhav on both devices with adb -s <serial> shell am start -W -n com.riztechacademy.mandibhav/.MainActivity (force-stop the app first with adb -s <serial> shell am force-stop com.riztechacademy.mandibhav, or it will not be a cold start). Run each three times and compare the TotalTime values.

Official documentation

Create and manage virtual devices — Every AVD setting, including the advanced network speed, RAM and CPU options used above.
Run apps on a hardware device — USB and Wi-Fi setup, the Windows driver, and the connection troubleshooting assistant.
Configure on-device developer options — Where Build number lives on more brands, and what the other developer options do.
Android Debug Bridge (adb) — The full command reference, including pairing and connecting over Wi-Fi from a terminal.

Next: finding your way around Android Studio.