Create a disposable Android lab

An Android emulator gives you a disposable Android target for early read-only observations. This lesson creates one through Android Studio's graphical interface, boots it, checks that ADB can see it, records what was selected, and stops it. It does not build AOSP, unlock a bootloader, flash an image, enable root, or modify a physical phone. An emulator is useful evidence about that virtual image—not proof of how a vendor phone behaves.

Before you start#

Read Workstation setup, Terminal and Git, Linux files and processes, and Bytes, hex, and trust. You need Android Studio installed, an internet connection for first-time SDK downloads, enough free disk/RAM for the selected image, and permission to use hardware virtualization where required. The browser-only path below is valid if you cannot install Studio or your host cannot run an emulator.

Learning goals#

By the end, you can create an Android Virtual Device (AVD) with a clearly selected API level and system-image type, boot and stop it from Device Manager, explain host versus guest and ADB serial selection, and distinguish an AOSP/debug-capable image from a Google Play image without assuming root capability. You can also report a blocker without trying risky host/device changes.

What is being emulated?

An AVD is a configuration: a hardware profile plus an Android system image and virtual device data. Android Emulator runs that virtual device on your workstation. The workstation is the host; Android inside the emulator is the guest. ADB's client and server run on the host, and the Android guest runs adbd. In this course, “emulator” means Android Studio's Android Emulator, not Cuttlefish; Cuttlefish is a different virtual-device workflow often paired with AOSP platform builds. Android Developers describes AVDs and Device Manager; AOSP documents Cuttlefish separately.

For a small first observation, select API 34 (Android 14 platform page) so the runtime target aligns with the course's historical source baseline where possible. Android Studio's package availability and image labels can change. Choose a phone hardware profile and an API 34 image that is available to your host. A standard Google APIs image is sufficient for the read-only ADB checks in the next lesson; Google Play is not required. An AOSP system image is a different choice useful for some platform-oriented/debug work. A Google Play image includes Play Store and is signed as a release image; Android documentation says elevated privileges are unavailable on those images. Do not assume an AOSP image supports adb root either: build type, image configuration, and tools matter. Root is not needed here. AVD image types and creation flow

Emulator speed depends on host CPU architecture, graphics, and virtualization support. On current Android Emulator versions, acceleration is provided through the platform's available hypervisor; Linux commonly uses KVM, Windows commonly uses Windows Hypervisor Platform, and macOS uses Hypervisor.framework. Exact prerequisites depend on OS, CPU, SDK tools, and image architecture. Do not follow old generic HAXM advice: Intel HAXM is deprecated, and starting with emulator 36.2 the Android Emulator no longer uses it. Check the current official acceleration requirements for your host rather than changing BIOS settings or disabling security features by guesswork. A compatible ARM image on Apple silicon may work even though the host architecture differs from the x86-64 reference host; image availability/performance vary. Linux examples elsewhere in the course use Ubuntu 22.04 x86-64 as a reference, not a certification that all hardware or virtualized hosts are supported.

Create and boot using the graphical interface

1. Start Android Studio. From the welcome screen, open More Actions → Virtual Device Manager (menu labels can vary slightly by Studio version). If a project is already open, use View → Tool Windows → Device Manager.
2. Choose Create Device or the plus button, select a phone profile, and continue.
3. Select an API 34 system image suitable for this observation. If it is not installed, use its download control in Studio. Choose Google APIs or AOSP deliberately; do not select Google Play because a tutorial calls it “the emulator.” If API 34 is unavailable or unsupported on your host, stop and record the offered image/API instead of silently pretending you used Android 14.
4. Review the configuration summary: device profile, API/system-image label, ABI/architecture, and AVD name. Keep ordinary defaults unless a documented host issue requires a change. Finish and wait for image setup to complete.
5. In Device Manager, press the AVD's Launch control. The first boot can take longer; wait until Android's home screen appears. Later starts may restore a snapshot. A cold boot starts afresh from powered-off state and can help diagnose a corrupted/stale snapshot, but it is not the first response to every slow boot. Use the cold-boot option in Device Manager's AVD menu only when there is a reason to retry from a clean start (menu labels may vary; the AVD docs define cold boot as powering up from the device-off state).
6. When done, choose Stop in Device Manager or close the emulator window normally. Stopping powers off this virtual instance; it does not uninstall Android Studio or remove the AVD. Do not choose Wipe Data unless you intentionally want to erase the virtual device's state. Snapshots store a saved state for faster starts; treat them as convenience, not as a backup or recovery plan. Official create/run/stop and snapshot guidance · Emulator snapshots

Avoid command-line AVD creation in a first lesson: SDK paths and package state differ by installation. Android Studio's Device Manager is the supported, visible route here. Do not guess ANDROID_HOME, filesystem paths, emulator names, or an emulator -avd command. Once the GUI launch succeeds, use ADB only to inspect the connection in the next exercise.

Practice#

Virtual-target exercise; no physical device changes. Create and launch one AVD using the steps above. In Android Studio, open Tools → SDK Manager → SDK Tools and confirm Android SDK Platform-Tools is installed. The SDK Location shown in the SDK Manager is the parent directory; adb is inside its platform-tools subdirectory. Follow Workstation setup for safe PATH setup, then open a new terminal. Do not replace your PATH with a guessed SDK path or copy one from another person's computer. Check which executable your terminal resolves before querying the target:

command -v adb
adb version
adb devices -l

On Windows PowerShell, use where.exe adb instead of command -v adb. Expected: the resolved path points to the Platform-Tools installation you intended; adb version prints a version banner. If the path is empty or points to an unintended older copy, stop and resolve PATH using the workstation guide before proceeding. Android Developers publishes Platform-Tools through the official download and release page.

The device list includes a row whose serial often looks like emulator-5554 and whose state is device; the exact serial and description vary. The header List of devices attached with no row means the emulator is not currently visible to this ADB server. device is a connection state, not proof that boot is complete or that the guest shell is root. If several rows appear, record the emulator's serial and select it explicitly for any next observation using adb -s SERIAL shell id (replace SERIAL with the actual serial). The ADB client/server run on the workstation; the command after shell runs in the Android guest. ADB official reference: client/server/daemon, device states, and serial selection

Do not run install, push, settings, reboot, unlock, root, or flash commands for this first lab. The target should be a virtual guest you created; do not assume a host shell command runs inside Android unless it is explicitly prefixed with adb shell. Do not attach a daily-use physical phone to make an empty list go away.

If something does not work

• No emulator row: confirm the AVD is visibly booted, then run adb devices -l again. Confirm SDK Manager has Android SDK Platform-Tools installed and command -v adb (or where.exe adb in PowerShell) resolves to the intended installation. If still absent, stop and record the Studio version, host OS/CPU architecture, image/API label, and exact non-sensitive output. Do not guess a second ADB binary or randomly kill/restart host processes.
• offline: allow the guest boot to finish and recheck once. If it remains offline, stop the AVD normally and start it once from Device Manager; do not issue reset, wipe, or unlock operations. Preserve the exact state/output for troubleshooting.
• unauthorized: this is the ADB state name for a target that has not authorized this workstation (AOSP adb to_string(ConnectionState)); it normally describes a physical-device authorization state, not the expected initial local-AVD path. Do not approve a prompt for an unknown device; identify the serial and confirm which target it belongs to. If it is your own authorized phone, use the device owner's consent and official ADB guidance; otherwise disconnect/stop and do not proceed.
• Emulator cannot accelerate or is very slow: check the official host-specific acceleration page and Studio's diagnostic message. Stop rather than enabling virtualization, changing firmware settings, disabling Hyper-V/security features, or installing an old hypervisor driver without understanding the effect. In a virtual machine, nested virtualization may be unavailable.
• No compatible host / browser-only: continue with source-only reading: inspect the AVD setup and ADB documentation linked below, then annotate an example adb devices listing with host, guest, serial, and state. Mark runtime observation “not yet evidenced.” This is a valid learning route, not a failed lesson.

Windows note: Android Studio and Emulator run on the Windows host. If you use WSL for other course shell examples, WSL's adb may not automatically see an emulator started by Android Studio on Windows. For this lab, open a Windows terminal or Android Studio's terminal with the SDK Platform-Tools path configured for the same host installation; do not install a second copy or assume WSL has host ADB visibility. The exact bridge depends on setup and is intentionally outside this beginner exercise.

Artifact: record the host OS/architecture, Android Studio version, AVD name, API level and exact system-image label/ABI, whether boot reached the home screen, exact ADB serial/state (or exact blocker), and confirmation that you stopped it. Redact usernames and local paths if sharing the note.

Knowledge check#

Without looking below, draw a two-column host/guest map and place Android Studio, ADB client/server, adbd, the AVD configuration, and Android's home screen. AVD A is a Google Play image; AVD B is an AOSP image. Which one is required for this read-only lab? Does either label alone establish root eligibility? If adb devices -l shows two device rows, what should you do before directing a command at one? If a Windows-hosted emulator does not appear to WSL's ADB, what is the safe next step?

Answers#

Android Studio, AVD files/configuration, and ADB client/server are on the host; the running Android guest contains Android's UI and adbd. Neither Play nor AOSP is required specifically: choose a suitable available API 34 image; Play is unnecessary. Google Play images do not provide elevated privileges according to Android's AVD docs, while an AOSP label alone does not guarantee the image/build supports root. When multiple targets exist, identify the emulator serial and use adb -s SERIAL for explicit targeting. On Windows, try the host terminal/Studio environment where that SDK is installed, then record an unresolved integration issue; don't guess WSL paths or install duplicates.

Checkpoint#

Ready: your artifact identifies the actual image and host/guest boundary, and the ADB state is tied to a specific serial or honestly marked not run. Revise: if you cannot distinguish Google Play, Google APIs, and AOSP labels, reopen the AVD documentation and write down the exact selected system image rather than saying only “Android emulator.” Not yet evidenced: if you used the browser-only path or virtualization is blocked, your source annotation is useful but not runtime proof; keep the blocker and continue to the ADB lesson's source-reading route. No checkpoint here establishes compatibility with a physical handset, root capability, or AOSP build support.

Sources#

• Install Android Studio — official download and current system requirements; labels and UI may evolve.
• Create and manage AVDs — official Device Manager flow, hardware profile/system-image distinctions, AOSP vs Play image notes (Play images are release-signed; AOSP images allow adb root), and cold versus quick boot.
• Android 14 platform page — the Android 14 release page, which links API 33 to API 34 changes; supports the API 34 label.
• Run Android Emulator — official overview of emulator usage.
• Configure Emulator acceleration — current host-specific VM acceleration guidance, including KVM, Windows Hypervisor Platform, Apple Hypervisor Framework, and HAXM deprecation; check live requirements for your machine.
• ADB — official host client/server and guest daemon architecture, device states, and serial selection.
• SDK Platform-Tools — official package source and release notes for adb; use Studio's SDK Manager rather than an unknown bundle.
• Cuttlefish — separate AOSP virtual-device environment, not the Android Studio AVD setup taught here.
• ADB and a Safe Lab — next lesson uses the virtual target for bounded, read-only observations and retains explicit safety boundaries.