Theory
Java on a battery
You write FestConnect in Java. But the standard Java Virtual Machine was built for desktops and servers with lots of memory and mains power. A phone in 2008 had a fraction of that and a battery that drained fast.
So Google did not use the ordinary JVM. It built its own runtime, the Dalvik Virtual Machine (DVM), tuned for a small, battery-powered device. Knowing why it is different, and what replaced it, is a favourite exam topic.
Theory
A scooter, not a truck
A delivery truck (the JVM) is powerful but heavy and thirsty, perfect for a warehouse, wasteful for a quick city errand. A scooter (Dalvik) carries less at once but sips fuel and darts through traffic. For a phone, tight on memory and battery, you want the scooter. Dalvik was Google's scooter: a leaner VM shaped for mobile constraints, not raw server power.
Theory
How your code runs
The path for FestConnect:
- Java source compiles to Java bytecode (
.class). - A tool converts that to Dalvik bytecode (`.dex`), which is smaller.
- The DVM executes the
.dex.
What made DVM mobile-friendly:
- Register-based (the JVM is stack-based), which suits limited CPUs.
- Small memory footprint.
- Each app runs in its own DVM instance / process, so one crashing app cannot corrupt another (sandboxing).
From Android 5.0, ART replaced Dalvik.
At a glance
Dalvik vs the standard JVM
| Aspect | Dalvik VM | Standard JVM |
|---|---|---|
| Architecture | register-based | stack-based |
| Runs | .dex bytecode | .class bytecode |
| Built for | low-memory mobiles | desktops/servers |
| Per app | own VM instance | shared typically |
Think first
Why give each app its own VM?
On Android, FestConnect and a game each run in their own separate VM instance. What does that isolation buy you if the game has a nasty bug and crashes? Think before tapping.
Show the answer
Because each app runs in its own VM and process, the game's crash is contained: it does not take down FestConnect, the OS, or other apps. This sandboxing also improves security, since one app cannot freely read another's memory. The cost is a little more overhead per app, but on a multi-app phone the stability and safety are well worth it. Isolation is a core Android design choice.
Quiz
Which pair correctly describes the Dalvik VM compared with the standard JVM?
- Dalvik is register-based and runs .dex; the JVM is stack-based and runs .class
- Dalvik is stack-based and runs .class; the JVM is register-based
- Both are identical; Dalvik is just a rename of the JVM
- Dalvik runs .java source files directly with no compilation
Show the answer
Dalvik is register-based and runs .dex; the JVM is stack-based and runs .class
Dalvik is register-based and executes .dex bytecode, while the standard JVM is stack-based and executes .class bytecode (A). Option B swaps the two. Dalvik is a distinct VM built for mobile, not a JVM rename (C). And no VM runs .java source directly (D): source is always compiled first (to .class, then converted to .dex). The register-based, .dex facts are the exam favourites.
Watch out
DVM traps
1. 'Dalvik is the JVM': no. It is Google's own, register-based VM running .dex, designed for mobile.
2. Forgetting ART: since Android 5.0, ART (Android Runtime) replaced Dalvik, using AOT (ahead-of-time) compilation at install for faster launches. If asked 'what replaced Dalvik?', the answer is ART.
3. Skipping the .class to .dex step: Java compiles to .class first, then converts to .dex; it is not one step.
Theory
You will not run the VM by hand
Happily, you never invoke Dalvik or ART yourself: Android Studio compiles, converts, and deploys your FestConnect code automatically. But understanding the runtime explains why Android apps are Java/Kotlin yet feel native, and why install can take a moment (ART compiling ahead of time). Next you install the tools that do all this: JDK, Android Studio, and the SDK.
Summary
Key takeaways
- The Dalvik VM ran Android apps: Java compiles to .class, converts to .dex, and Dalvik executes the .dex.
- Dalvik is register-based (the JVM is stack-based) and has a small footprint, tuned for low-memory, battery phones.
- Each app runs in its own VM instance/process, giving isolation (sandboxing) and stability.
- ART (Android Runtime) replaced Dalvik from Android 5.0, using ahead-of-time (AOT) compilation.
- You never run the VM manually; the tools handle compile, convert, and deploy.
- Memory hook: a scooter, not a truck, register-based and .dex.