Android virtual machine

An Android Virtual Machine is a runtime environment that executes the code of Android applications. Rather than running compiled code directly on device hardware, Android apps run inside a virtualized layer that abstracts the underlying hardware, translates bytecode into machine-executable instructions, and manages memory, security sandboxing, and garbage collection.

The term covers two distinct but related concepts:

The in-device runtime VM — the execution environment built into every Android operating system that runs app code. This has evolved from Dalvik through ART (Android Runtime) to the current system.

The Android Virtual Device (AVD) — a simulated Android device created using the Android Emulator in Android Studio, used for development and testing. Android Emulator runs the Android operating system in a virtual machine called an Android Virtual Device (AVD). Each AVD contains the full Android software stack, and it runs as if it were on a physical device.

Both are referred to as Android Virtual Machines in different contexts. This entry covers both.

The History: From Dalvik to ART

Dalvik Virtual Machine (DVM)

Dalvik Virtual Machine is a process virtual machine in Android that executes applications written in Java. Unlike the standard Java Virtual Machine (JVM), Dalvik was designed specifically for mobile devices with limited memory and CPU power. Dalvik runs files in the Dalvik Executable (.dex) format, which is optimized for minimal memory usage. It uses a register-based architecture instead of stack-based like JVM, improving performance on mobile CPUs. Dalvik was introduced in Android 1.0 and was the default runtime until Android 4.4.

Dalvik works by converting Java class files into .dex files during app compilation. These .dex files are then executed by the Dalvik VM on the device. The VM manages memory, runs the app code, and handles garbage collection to free unused resources. It also isolates apps for security and stability.

Dalvik used Just-In-Time (JIT) compilation — converting frequently executed bytecode into native machine code at runtime. This worked well for resource-constrained early Android devices but had limitations as apps and devices became more complex.

Android Runtime (ART) — The Current Standard

ART replaced Dalvik as Android’s default runtime in Android 5.0 (Lollipop) in 2014. The fundamental difference is compilation strategy.

ART includes a JIT compiler (with code profiling). The JIT compiler complements new AOT compiler and improves runtime performance, speed up apps and system updates.

ART uses Ahead-of-Time (AOT) compilation — apps are compiled to native machine code at installation time rather than at runtime. This means faster app launch times and better sustained performance, at the cost of slightly longer installation and more storage space.

ART also introduced significantly improved garbage collection, better debugging support, and improved battery efficiency through reduced CPU work at runtime.

Android Virtual Device (AVD) for Development and Testing

The Android Emulator uses AVDs to simulate physical Android devices on a developer’s computer. This capability allows developers to run and test applications across various Android versions and device configurations without needing multiple physical devices, reducing costs and complexity. VMs enhance the development process by offering the ability to quickly revert to previous snapshots or states. This feature is invaluable for testing unstable builds or applications that modify system settings, allowing developers to maintain productivity without time-consuming reconfiguration.

Each AVD is configured with a specific Android version, device profile (screen size, RAM, storage), and hardware settings. Developers can test how their app behaves on an old Android 8 budget phone and a new Android 15 flagship without owning either.

The Android Virtualization Framework (AVF)

Android 13 introduced a more advanced system: the Android Virtualization Framework (AVF), which makes virtual machines a core construct of the Android OS itself.

With AVF, virtual machines become a core construct of the Android operating system, similar to the way Android utilizes Linux processes. Developers have the flexibility to choose the level of isolation for a virtual machine.

pKVM is built on top of the industry standard Kernel-based Virtual Machine (KVM) in Linux. Isolated virtual machines are invisible to Android — any process running in Android cannot inspect, see, tamper with the content of such a virtual machine.

This enables powerful use cases: running secure, isolated workloads entirely separate from the main Android OS. Financial apps, enterprise security tools, and sensitive computation can run in isolated VMs that even the Android host system cannot inspect.

Android Virtual Machines vs. Android Emulators vs. Cloud Phones

These three concepts are often confused but serve different purposes:

Android Virtual Machine (in-device ART runtime): The execution environment for apps on every real Android device. Not something users interact with directly — it’s the layer that makes Android apps run.

Android Virtual Device (AVD/Emulator): A software simulation of an Android device on a developer’s PC, used for development and testing. Runs in software on your computer’s hardware. Detection systems can identify emulator environments.

Cloud Phones: Real Android hardware hosted in the cloud and accessed remotely. Not software simulation — actual manufactured devices with genuine hardware identifiers including real IMEI numbers, authentic sensor data, and hardware-accurate GPU rendering.

The distinction between emulators (software) and Cloud Phones (real hardware) matters significantly for platform detection. Apps that check for virtualization artifacts — inconsistencies in build configuration, GPU rendering patterns, or sensor data — can identify emulator environments. Multilogin Cloud Phones are physical devices, so they pass these checks because there’s nothing to detect. For a detailed comparison, see cloud phone vs Android emulator.

Why Android Virtual Machines Matter for Multi-Account Management

Understanding how Android virtual machines work is directly relevant to anyone managing multiple Android accounts — whether for social media management, app testing, or multi-account operations.

The IMEI (International Mobile Equipment Identity) is a hardware-level identifier stored in every physical Android device. The Android ID is a software identifier generated during device setup. Both are read by apps like TikTok, Instagram, and Facebook to identify devices. On a real Android device running ART, these identifiers are genuine. On an emulator (AVD), these identifiers are either simulated values or spoofed — which detection systems can flag.

This is why Multilogin Cloud Phones run on real Android hardware rather than emulators. Each Cloud Phone has a genuine IMEI, a real Android ID, and hardware fingerprints that match the declared device model — because it is a real device running a standard Android runtime environment, not a software simulation of one.

For mobile testing and QA automation scenarios where Android VMs or emulators are appropriate, the considerations are different — developers testing their own apps don’t need to worry about platform detection in the same way.

Key Terms

Bytecode: The intermediate code that Android apps compile to, which the Android runtime then converts to native machine code.

.dex (Dalvik Executable): The bytecode format optimized for Android’s Dalvik VM and retained for compatibility in ART.

JIT (Just-In-Time) compilation: Converts bytecode to machine code at runtime, as needed. Used by Dalvik and retained as a complement to AOT in ART.

AOT (Ahead-of-Time) compilation: Converts bytecode to machine code at installation time. ART’s primary compilation strategy.

AVD (Android Virtual Device): A configured emulator instance representing a specific Android device, used in Android Studio for testing.

AVF (Android Virtualization Framework): Google’s framework for running isolated virtual machines as a native Android OS feature, introduced in Android 13.

pKVM: Protected KVM — the hypervisor layer underpinning AVF that provides hardware-enforced isolation between Android and guest VMs.