ART Runtime Quiz
ANDROID › System
Which statement best describes how ART replaced Dalvik in terms of code execution?
- ART removed DEX bytecode entirely and instead ships precompiled native code in the APK
- ART runs the same DEX bytecode but adds AOT compilation with JIT and interpretation
- ART switched apps from DEX over to standard JVM .class files at build
- ART is interpreter-only, having dropped Dalvik's original JIT compiler
Answer: ART runs the same DEX bytecode but adds AOT compilation with JIT and interpretation
ART and Dalvik both execute DEX bytecode; ART's key addition was ahead-of-time compilation via dex2oat, layered with JIT and interpretation.
On Android 7+ with profile-guided compilation, when does dex2oat typically AOT-compile an app's hot methods?
- Eagerly on each cold start, before the app draws its first frame
- Only after the developer manually starts a compile job in-app
- In the background when idle and charging, using the profile
- Never, because Android 7 removed all AOT compilation entirely
Answer: In the background when idle and charging, using the profile
Post-Android 7 ART installs apps quickly, profiles hot methods at runtime, and compiles them during idle/charging background dexopt rather than at install time.
What is the primary startup benefit of shipping a Baseline Profile?
- Critical startup methods are AOT-compiled at install time.
- It disables garbage collection during startup to speed first launch.
- It compresses the APK so it downloads faster on the user’s device.
- It moves all app code onto a background thread automatically at startup.
Answer: Critical startup methods are AOT-compiled at install time.
A Baseline Profile tells ART which methods to AOT-compile at install, so hot startup paths run as compiled code immediately, cutting cold start by roughly 30%.
How do Cloud Profiles differ from Baseline Profiles?
- Cloud Profiles are written by hand while Baseline Profiles are auto-generated by Play
- Cloud Profiles replace the ART runtime entirely, removing on-device compilation steps
- Cloud Profiles apply only to debug builds during local development, never to releases
- Cloud Profiles are Play-aggregated from usage; Baseline Profiles apply at install
Answer: Cloud Profiles are Play-aggregated from usage; Baseline Profiles apply at install
Cloud Profiles are crowd-sourced from real usage (Android 9+) and delivered hours-to-days later; Baseline Profiles are bundled in the APK/AAB and take effect immediately at install.
What is the 64K limit that multidex addresses?
- A maximum of 65,536 lines of Kotlin code in one module
- A maximum of 65,536 method references in one DEX file
- A 64 KB cap on the total APK size after packaging
- A limit of 65,536 concurrent threads in ART runtime
Answer: A maximum of 65,536 method references in one DEX file
A single DEX file can address at most 65,536 method references; multidex splits the app across multiple DEX files to exceed it (automatic for minSdk 21+).
Which is an accurate description of ART's garbage collection?
- It is fully stop-the-world and freezes the app for the whole GC scan
- It performs no compaction and never moves any objects around
- Mostly concurrent, with one short pause independent of heap size
- It runs GC only after the app goes to the background
Answer: Mostly concurrent, with one short pause independent of heap size
ART uses a mostly-concurrent collector with typically a single short pause and concurrent copying, and the pause length does not grow with heap size.
Why does AOT-compiled code generally outperform interpreted or freshly-JITed code at startup?
- Because native code is already in an OAT file and runs with no JIT warmup
- Because it skips garbage collection, so the runtime does less work overall
- Because interpretation needs a network connection, while AOT runs offline
- Because it uses a faster bytecode format than DEX, which the CPU prefers
Answer: Because native code is already in an OAT file and runs with no JIT warmup
dex2oat produces native machine code stored in an OAT binary that the CPU runs directly, avoiding the interpreter's per-instruction overhead and the runtime warmup cost of JIT compilation.
In the Android build pipeline, what is the difference between D8 and R8?
- D8 compiles .class bytecode to DEX; R8 also shrinks, optimizes, obfuscates
- D8 obfuscates and shrinks the code while R8 merely renames classes and fields
- D8 is ART's ahead-of-time compiler while R8 serves as its on-device JIT compiler
- Both D8 and R8 run on-device inside ART during app installation and later updates
Answer: D8 compiles .class bytecode to DEX; R8 also shrinks, optimizes, obfuscates
D8 is the dexer that turns compiled .class bytecode into DEX; R8 is the superset tool that also performs tree-shaking, optimization, and obfuscation while emitting DEX, replacing the old ProGuard plus D8 flow.
How does Android typically launch a new app process to cut startup cost and memory use?
- Each app boots a fresh, isolated JVM instance with no shared framework state or classes
- ART re-runs dex2oat to recompile the entire framework on every single app launch
- The Zygote preloads framework classes, then forks apps that share memory copy-on-write
- Each app downloads the ART runtime fresh from Google Play before it is allowed to start
Answer: The Zygote preloads framework classes, then forks apps that share memory copy-on-write
Android forks app processes from the Zygote, which has preloaded and initialized common framework classes and resources, so forked apps start faster and share that memory via copy-on-write.
Since Android 12, how is the ART runtime itself updated on supported devices?
- Only through a complete OS or vendor firmware update that reflashes the system partition
- Through the Play Store as an ordinary installable app that users update by hand
- It is frozen at the factory-shipped version and can never be updated after release
- As an updatable Mainline module (com.android.art APEX) shipped via Play updates
Answer: As an updatable Mainline module (com.android.art APEX) shipped via Play updates
ART became an updatable Mainline module packaged as the com.android.art APEX, so runtime and compiler fixes ship via Google Play system updates independently of full OS releases.
What does ART's default 'speed-profile' compilation filter do during background dexopt?
- Ahead-of-time compiles every method in the app, whether used or not
- AOT-compiles only methods in the app's profile, leaving the rest
- Only verifies the DEX and compiles nothing to native code at all
- Disables AOT entirely and forces the interpreter for the whole app
Answer: AOT-compiles only methods in the app's profile, leaving the rest
speed-profile is profile-guided: dex2oat AOT-compiles the methods recorded in the profile and leaves cold code to run interpreted or JIT-compiled, balancing compile time, storage, and runtime speed.
Why do apps that ship a Baseline Profile usually also include the androidx.profileinstaller library?
- It compresses the baseline profile so the packaged APK download stays much smaller
- It uploads runtime usage telemetry to Google Play so it can help build Cloud Profiles
- It writes the bundled baseline profile into ART's profile store for AOT compilation
- It enables ART's JIT compiler, which would otherwise stay fully disabled by default
Answer: It writes the bundled baseline profile into ART's profile store for AOT compilation
ProfileInstaller copies the app's bundled baseline.prof into the location ART reads, ensuring the profiled methods are actually picked up and AOT-compiled rather than ignored on devices that would not install it automatically.
What GC improvement did Android 10 add to ART's concurrent copying collector?
- A generational mode that collects young, short-lived objects more often and cheaply
- It removed automatic garbage collection in favor of manual malloc/free memory management
- It made every collection fully stop-the-world, pausing all app threads to simplify timing
- It offloaded all garbage-collection work to a remote cloud server for background processing
Answer: A generational mode that collects young, short-lived objects more often and cheaply
Android 10 introduced generational concurrent copying, letting ART collect the young generation of short-lived objects more often and cheaply, which reduces overall GC cost and improves throughput.
What happens when an app's heap usage exceeds the per-app heap limit ART enforces?
- ART automatically borrows spare RAM from other background apps to keep the process running
- The whole device reboots to reclaim the leaked memory and restore free heap space to apps
- Nothing happens, because ART heaps are effectively unbounded on modern high-RAM devices
- It throws OutOfMemoryError even on high-RAM devices unless android:largeHeap is set
Answer: It throws OutOfMemoryError even on high-RAM devices unless android:largeHeap is set
ART caps each app's heap at a device-defined limit regardless of total RAM, so crossing it raises OutOfMemoryError; android:largeHeap can request a bigger cap but is discouraged and not guaranteed.