Run Your App on the Android Emulator

You built an app in lesson 03. Today it comes alive. You will create a virtual phone inside your computer, install your app on it, tap it with your mouse, and learn the controls that make the Android Emulator a serious development tool: rotating the screen, faking a GPS location, draining the battery, taking snapshots and more.

An emulator is like a flight simulator for apps. A pilot trainee does not crash a real aeroplane to learn; they crash a simulator. You can test your app on a tiny old phone, a huge tablet and a foldable without owning any of them. The price you pay is computer resources, and many learners in Nigeria and elsewhere work on modest laptops, so this lesson is honest about RAM, storage and the alternatives when an emulator is too heavy.

By the end of this lesson you will be able to:

• Explain what an AVD (Android Virtual Device) is and what a system image is.
• Explain ABI, x86_64 and arm64-v8a, and choose the right system image for your computer.
• Create an AVD in the Device Manager and run your app on it.
• Use the emulator toolbar and the Extended controls (location, battery, cellular, sensors and more).
• Understand Quick Boot, cold boot and snapshots.
• Check that hardware acceleration works on Windows, macOS or Linux.
• Start emulators from the command line and confirm them with adb devices.
• Choose low-RAM alternatives when your computer is struggling.
• Diagnose the most common emulator problems.

How this fits the bigger picture: This lesson matches the Run your first app on the Android Emulator codelab in Unit 1 (the Set up Android Studio pathway) of Google's official Android Basics with Compose course. The codelab shows the basic clicks. We add the reasons behind the choices and the controls and troubleshooting you will need every week. The official pathway link is at the end.

1. A project that builds

You need a project from lesson 03 (for example Hello Techbase) that syncs and builds. If your Gradle sync is failing, fix that first.

2. What a CPU architecture is

A processor understands a fixed set of instructions called its instruction set. Two families matter to Android developers:

• x86 family (Intel and AMD processors in most Windows and Linux laptops, and older Macs).
• ARM family (almost every phone, Apple Silicon Macs, and some Windows laptops).

A program built for one family cannot run directly on the other. The name for "which instruction set a piece of machine code targets" is the ABI (application binary interface). You will see this word in system image names.

3. What a virtual machine is

A virtual machine is a pretend computer running as a program inside your real computer. The emulator runs a full Android operating system inside one. If the pretend computer and the real computer use the same instruction set, the processor can run Android's instructions almost directly, which is fast. If they differ, every instruction must be translated one at a time, which is painfully slow.

4. What adb is

adb (Android Debug Bridge) is a command-line tool that talks to devices and emulators. Android Studio uses it behind the scenes to install and start your app. You will use it yourself in lesson 05.

5. Your computer's RAM and disk

Look up how much memory your computer has before you start (on Windows: Task Manager > Performance; macOS: Apple menu > About This Mac; Linux: free -h). Google's emulator guidance lists 16 GB of RAM and about 16 GB of free disk space as system requirements, and warns that newer Android versions and large-screen devices may need more. Many people succeed with less by using the tips in this lesson, but you should know your numbers.

Three words get mixed up constantly. Here is the difference.

          Hardware profile  +  System image  +  Settings
          (screen, sensors)    (Android N, ABI)  (RAM, graphics)
                    \              |               /
                     `-------> AVD (saved config) <-----'
                                   |
                                   v
                          Android Emulator (runs it)
                                   |
                                   v
                       Your app installed via adb

The three flavours of system image

When you pick a system image, the official documentation explains three flavours:

Pick the Google APIs or Google Play type for most Compose apps in this course. Only profiles marked with the Play Store logo in the hardware list can use Play Store images.

ABIs: x86_64 versus arm64-v8a

An ABI names the CPU family and word size. The two that matter to you today:

The golden rule from the official hardware-acceleration guide:

• On an x86_64 computer (most Windows and Linux PCs and older Macs), use x86 or x86_64 system images. ARM images work but cannot use hardware virtualisation and are very slow.
• On an ARM64 computer (Apple Silicon Macs and similar), use arm64-v8a images.

Rule of thumb: Match the system image to your computer's CPU, not to the phone you imagine. Your app will still run on ARM phones in real life, because Kotlin code compiled to DEX is the same on every CPU. Only apps that include native C/C++ code need separate builds per ABI.

If you are unsure which CPU you have: on Windows, Settings > System > About shows the processor name; on macOS, About This Mac says "Apple M…" or "Intel"; on Linux run uname -m (x86_64 means Intel/AMD, aarch64 means ARM64).

API levels in system images

Each system image is tied to an API level, the number that identifies an Android version (lesson 01). An app cannot run on an image whose API level is below its minSdk (lesson 03). Official advice is to test on images covering the range your app supports, but today you need only one: a recent stable image.

Menu names move between versions, so match by meaning. Official documentation opens the Device Manager through the Welcome screen (More Actions > Virtual Device Manager) or, when a project is open, View > Tool Windows > Device Manager.

Step 1: Open the Device Manager

Open your Hello Techbase project and choose View > Tool Windows > Device Manager. It lists devices, with a Virtual tab for emulators and a Physical tab for real phones. If you installed a default emulator image with Android Studio you may already see one.

Step 2: Create a device

Click Create Device (the plus icon).

1. Select Hardware. Choose a phone profile. A Pixel profile with a Play Store icon is a good, common choice. Predefined profiles cannot be edited, but you can clone one and change the copy (the Clone Device button), or define your own with New Hardware Profile. Click Next.
2. System Image. The tabs show recommended images, other releases, and the x86 Images or ARM Images list depending on your computer. Pick a recent stable API level that matches your computer's architecture. An entry with a Download icon is not installed; click it and accept the licence. The download can be a gigabyte or more, so use Wi-Fi if you are on a limited data plan. Click Next.
3. Verify Configuration (sometimes called Android Virtual Device). Give the AVD a clear name such as Pixel_Phone_API_Recent. Click Show Advanced Settings to see more options (we explain them below). Click Finish.

The advanced settings that matter

Click Finish. Your AVD appears in the Virtual tab.

Step 3: Run your app

In the toolbar at the top of Android Studio you will see a target device menu (it may say "No Devices" at first) and a green Run button. Choose your new AVD from the menu and click Run. Android Studio will:

1. Build the app (as in lesson 03).
2. Start the emulator if it is not already running. The first start is always a cold boot and can take a minute or more on a modest laptop.
3. Install the APK on the virtual phone through adb.
4. Launch your MainActivity.

When it works, the emulator shows Android's home screen and then your app with the text from lesson 03.

Where does the emulator appear? In recent Android Studio versions the emulator appears inside the IDE in the Running Devices tool window. In older settings it opens as a separate floating window. A setting under Settings > Tools > Emulator (the label has been something like Launch in the Running Devices tool window) chooses between them. Some emulator features are only available in the standalone window, according to the official extended-controls guide.

Make the app tell us where it runs

To prove to yourself what the emulator really is, change the greeting so it prints facts from the virtual device. Replace the Greeting composable in MainActivity.kt:

import android.os.Build
import androidx.compose.foundation.layout.Column
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
@Composable
fun DeviceFacts(modifier: Modifier = Modifier) {
 Column(modifier = modifier) {
 Text("Model: ${Build.MODEL}")
 Text("Android API level: ${Build.VERSION.SDK_INT}")
 Text("Supported ABIs: ${Build.SUPPORTED_ABIS.joinToString()}")
 }
}

Then call DeviceFacts(modifier = Modifier.padding(innerPadding)) inside the Scaffold in setContent instead of Greeting. The Build class is part of the Android SDK and reports information about the device it runs on. Run the app on the emulator. You will see something like this (your values depend on your AVD):

Model: sdk_gphone64_x86_64
Android API level: 35
Supported ABIs: x86_64, arm64-v8a

Notice that the emulator may list more than one ABI because newer x86_64 images include a translation layer so that some ARM-only native apps can still run. Your own screen will show the ABI of the image you chose.

Stopping and restarting

• Click the Stop square in the toolbar to stop the app.
• To close the emulator, close its window or use Stop from the AVD's row in the Device Manager. When you close it, a Quick Boot snapshot is normally saved so that next time it starts quickly (see below).
• Leaving the emulator running between runs is a big time saver. Pressing Run again on a running emulator only reinstalls your app.

The emulator has a narrow toolbar. The icons differ by version, but the common ones are:

Useful mouse and keyboard behaviours:

• Click is a tap. Click-and-drag is a swipe. Hold Ctrl (or Cmd on macOS) and drag to simulate a pinch in many versions.
• The keyboard types into text fields.
• Press F1 (Command + / on macOS) in the standalone emulator to open the Help pane with the list of keyboard shortcuts. The shortcuts work when the Send keyboard shortcuts to setting is on Emulator controls, which is the default.

Extended controls

Open More (the three dots at the bottom of the emulator toolbar). The extended controls window has many panes. The official guide lists these, and your version may add or rename some:

Try this: open Location, search for a place or click on the map, press Set location, then open a map app in the emulator (if your image has one) and watch the blue dot move to Ibadan or wherever you chose.

Booting Android from nothing takes a long time. A snapshot saves the entire state of the virtual phone (memory, settings, app data) so that it can resume where it left off, like waking a sleeping phone instead of switching it on.

From the official snapshots documentation:

• Each AVD has one Quick Boot snapshot and any number of general snapshots.
• By default the emulator saves the Quick Boot snapshot when you close it and loads it when you start. The first start is always a cold boot. The documentation says Quick Boot can start an AVD up to ten times faster than a cold boot.
• To take your own named snapshot, open the Snapshots pane (in the emulator toolbar in Android Studio, or in Extended controls in the standalone window) and click Take snapshot. You can later select a snapshot and load it, rename it, or delete it.
• Cold Boot can be requested once from the AVD's menu in the Device Manager, or turned on permanently in the AVD's advanced settings (Emulated Performance > Boot option).
• Holding Shift while closing the emulator skips the Quick Boot save for that session.

When snapshots become invalid

A snapshot belongs to the exact combination of system image, AVD configuration and emulator version that saved it. If you edit the AVD or update the emulator or system image, the snapshots become invalid and the next start is a cold boot. This is normal.

Snapshot cautions

• Saving and loading snapshots needs memory. With little free RAM the process can crawl, so close heavy programs first.
• The official guide notes that snapshots are unreliable with software graphics, so keep graphics on Hardware or Automatic if you rely on them.
• If an emulator fails to start from a snapshot, use Cold Boot from the AVD menu.
• Snapshots use real disk space. If your disk fills up, delete snapshots you do not need, or use Wipe Data from the AVD menu to reset a virtual phone to a clean state.

A useful testing trick

Take a snapshot called clean-install right after you install and sign in to the apps you need. Whenever your test data gets messy, load that snapshot and you are back at a known state within seconds.

Emulator speed depends mostly on hardware acceleration, in two parts:

• VM acceleration: the CPU runs the virtual phone's instructions directly through a hypervisor (this requires matching architectures and virtualisation turned on).
• Graphics acceleration: the graphics card draws the virtual screen.

Without VM acceleration the emulator is extremely slow, which is the main reason people say "the emulator is unusable".

Step 1: Enable virtualisation in firmware

Intel computers call it VT-x, AMD computers call it AMD-V or SVM. Many computers ship with it disabled. If acceleration fails you may need to restart, enter the BIOS or UEFI setup (usually by pressing F2, F10, Del or Esc during startup; this varies by maker) and enable it. Do not change other firmware settings you do not understand.

Step 2: The operating-system layer

The official guide has more to say, which is worth knowing: on Windows there used to be an Intel HAXM driver, but it is deprecated and should not be used on current versions, and an alternative driver (the Android Emulator hypervisor driver, AEHD) is documented as scheduled for removal at the end of 2026, so WHPX is the choice to learn. Also, you cannot run a hardware-accelerated emulator inside another virtual machine such as VirtualBox or VMware.

Step 3: Check that it works

The emulator has a built-in checker. From the SDK's emulator folder, run it in a terminal. (Android Studio's Settings > Languages & Frameworks > Android SDK shows your SDK path.)

# macOS or Linux
~/Android/Sdk/emulator/emulator -accel-check

# Windows (PowerShell), adjust the path to your SDK location
& "$env:LOCALAPPDATA\Android\Sdk\emulator\emulator.exe" -accel-check

The official guide shows outputs like these (details differ by machine):

WHPX(10.0.22631) is installed and usable.
Hypervisor.Framework OS X Version 13.2
KVM (version 12) is installed and usable.

On Linux, two extra checks help:

egrep -c '(vmx|svm)' /proc/cpuinfo # 1 or more means the CPU supports virtualisation
sudo kvm-ok # from the cpu-checker package

If you see a message that no hypervisor is available, re-check the firmware setting, the Windows feature, the Linux KVM permissions, or whether an incompatible tool (other virtualisation software, some anti-cheat or antivirus tools) is interfering.

Graphics settings

If the emulator shows a black screen, crashes or has glitches, edit the AVD and change Graphics from Automatic to Software as a test. On the command line the flag -gpu selects a mode. Official documentation warns that forcing a mode your computer does not support can cause crashes or wrong images, so use Automatic when you can.

Not everyone has a 16 GB machine. Here is an honest ladder of options, from lightest to heaviest.

Practical habits that make a real difference on a modest computer:

1. Close your browser tabs and other heavy applications while the emulator runs.
2. Keep one emulator open all day instead of restarting it.
3. Do UI work in the Preview, then confirm on the emulator or a phone.
4. Do not leave several AVDs running at once.
5. Keep at least some GBs of free disk space; a full disk makes everything crash.
6. Increase the memory available to Android Studio only if you have spare RAM (see lesson 02); do not starve the emulator.
7. Reboot your computer if it has been running for days. This genuinely helps.

If you cannot run an emulator at all, you can still complete almost every lesson in this course using Previews plus a real phone. The official advice is the same.

Android Studio starts the emulator for you, but it is useful to know the tools underneath. Commands below assume the SDK's emulator and platform-tools folders are on your PATH; if not, run them from inside those folders using their full paths.

emulator -list-avds # names of AVDs you have created
emulator -avd Pixel_Phone_API_Recent # start one by name
emulator -avd Pixel_Phone_API_Recent -no-snapshot-load # start with a cold boot, one time
emulator -avd Pixel_Phone_API_Recent -wipe-data # reset it to a fresh state

While an emulator is running, check it from another terminal:

adb devices

You should see something like this (the serial is emulator- plus a port number):

List of devices attached
emulator-5554 device

The state device means ready. If it says offline, the emulator is still booting or adb lost it; wait, or restart the adb server with adb kill-server and then adb start-server. The official adb guide warns that an adb server started before the emulator can sometimes hide it, so starting the server after the emulator avoids the problem.

With one emulator and one real phone connected, a plain adb install fails with "more than one device". Choose a target with -e (the only emulator), -d (the only real device) or -s serial:

adb -e install app/build/outputs/apk/debug/app-debug.apk

Lesson 05 covers more adb commands.

Where is the AVD stored? By default in a hidden .android/avd folder in your user directory. View Details and Show on Disk in the AVD menu help you find it. When you delete an AVD from the Device Manager, the files go too, which frees space.

Mistake #1: Choosing an ARM system image on an Intel or AMD computer. The symptom: the emulator takes many minutes to boot and every tap lags. The problem: the CPU must translate each instruction because it cannot virtualise a different architecture. The fix: create a new AVD with an x86_64 image. Apple Silicon users do the opposite and choose arm64-v8a.

Mistake #2: Skipping hardware acceleration setup. The symptom: "emulator: ERROR: x86 emulation currently requires hardware acceleration". The fix: enable VT-x/AMD-V in the BIOS, turn on Windows Hypervisor Platform on Windows (or ensure KVM permissions on Linux), then run emulator -accel-check until it reports a usable hypervisor.

Mistake #3: Closing the emulator after every run. The problem: each start is slow and uses RAM and disk for the boot. The fix: leave it running while you code. Pressing Run on an open emulator just reinstalls the app.

Mistake #4: Running several emulators at once on a small laptop. The symptom: freezing and swapping. The fix: run one, and use Previews for most UI work.

Mistake #5: Giving the AVD huge RAM and storage "to be fast". The problem: your computer, not the virtual phone, runs out of memory and everything slows. The fix: use moderate values. More emulator RAM does not make a starved computer faster.

Mistake #6: Testing only on the newest Android. The problem: your app may crash on the older versions your minSdk promises to support. The fix: create a second AVD at or near your minSdk and test there before you publish (lesson 49).

Mistake #7: Confusing "stop the app" with "stop the emulator". The symptom: the emulator is still eating RAM after your session. The fix: close the emulator window, or use Stop in the Device Manager.

Mistake #8: Ignoring the first error in the Run window. The symptom: a wall of red text. The fix: read the first line. Typical first lines: "No connected devices" (nothing selected in the target menu), "INSTALL_FAILED_..." (installation problem such as low storage or a version conflict), or a Gradle error from lesson 03.

Answer each question in your head (or on paper), then reveal the answer.

Question 1. What is the difference between an AVD, a system image and a hardware profile?

Question 2. You have an Intel laptop. Which ABI should your system image use, and why?

Question 3. What is the difference between a cold boot and a Quick Boot?

Question 4. Name two things the Extended controls let you simulate and one reason each is useful.

Question 5. What command lists connected devices and emulators, and what does the state offline mean?

Go deeper: official resources

• Android Basics with Compose, Unit 1: Set up Android Studio: the official pathway this lesson is based on.
• Run apps on the Android Emulator: requirements and running an AVD.
• Create and manage virtual devices: hardware profiles, system images, graphics and boot options.
• Configure hardware acceleration: WHPX, Hypervisor.framework, KVM and -accel-check.
• Use emulator snapshots: Quick Boot and snapshots.
• Use the extended controls: every pane explained.