Dalvik and ART are the Android runtime environments that execute app code compiled into DEX bytecode. Dalvik was the earlier register-based virtual machine, while ART uses ahead-of-time and just-in-time compilation to run Android applications on the device.
Android runtime execution model
Dalvik and ART are the execution layer for Android apps, so the important security question is not the bytecode format alone but how code is loaded, compiled, isolated, and allowed to interact with the device. That runtime layer shapes attack surface, performance, and the degree to which malformed or tampered app code can be observed or contained.
Because the runtime sits between app code and the operating system, it also influences how quickly security fixes are enforced across devices. Changes in runtime behaviour can alter exploitability, crash patterns, and the consistency of security controls across app versions and Android releases.
Dalvik versus ART
Dalvik was Android’s earlier register-based virtual machine, while ART became the newer runtime and changed how apps are executed on device. The practical distinction is that ART relies on ahead-of-time and just-in-time compilation, which changes startup behaviour, optimisation, and the way code reaches native execution paths.
For defenders and app developers, that shift matters because the same application can behave differently across runtime generations. Issues that are mostly theoretical in one runtime may become operational in another if compilation, optimisation, or caching changes how code is reached and monitored.
Android runtime differences are therefore a compatibility and security concern, not just an implementation detail. The runtime is one reason Java and Spring Security Guide is relevant to Android-adjacent Java code, because developers often underestimate how platform execution semantics affect security assumptions.
Security implications of the runtime layer
The runtime directly affects how app code is translated into executable instructions, which means it can influence exploit reliability, reverse engineering effort, and the visibility of malicious behaviour. If an attacker can tamper with app packages, inject code, or abuse runtime-loading features, the runtime becomes part of the trust boundary.
Runtime security is also tied to platform hardening, because Android inherits much of its control model from the surrounding system, device policy, and application sandbox. The runtime does not replace those controls, but it can strengthen or weaken their practical effect depending on how code execution paths are managed.
For broader virtualisation and isolation concepts, Hypervisor and Virtualisation Security Guide helps frame why execution environments matter, while Confidential Computing Guide shows how stronger isolation changes the trust placed in code and memory.
Operational considerations for Android developers and defenders
From an operational perspective, Dalvik and ART are important when troubleshooting app compatibility, performance regressions, and security testing outcomes. A control or detection technique that works against one execution path may behave differently once code is compiled or optimised by ART.
That means security teams should treat runtime behaviour as part of their application assurance process, especially for mobile applications that handle sensitive data, signed content, or embedded authentication flows. The runtime can affect whether malicious modifications are caught early, late, or not at all.
Testing guidance for controlled environments is still useful here, especially where runtime changes affect validation, instrumentation, or lab setup. Kali Linux for Authorised Testing Guide is relevant where practitioners need a safe, authorised environment to inspect Android behaviour and compare execution characteristics.
Risk and Threat Considerations
Runtime environments are attractive to attackers because they sit close to code execution, app behaviour, and sometimes sensitive in-memory state. If a device runs tampered app code, or if an attacker can exploit a weakness in an execution path, the runtime can become a foothold for persistence, evasion, or abuse of trusted app behaviour.
Failure mechanism: Malicious code, repackaged apps, or runtime abuse can alter what an Android app executes or observes, especially when defenders assume bytecode or compilation alone guarantees safety.
Impact: The result can be data theft, bypassed controls, misleading telemetry, or a compromised app trust model across many devices running the same software.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Runtime execution environments must resist malicious or altered app code. |
| SC-39 — Process Isolation | Dalvik and ART depend on isolation between app processes and the OS. | |
| Recommendation — Scan Android app code and update channels for tampering before execution. Enforce process isolation so one Android app cannot interfere with another. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Android runtime behaviour affects how application code is executed and trusted. |
| Recommendation — Design Android apps to avoid relying on runtime behaviour for security guarantees. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Runtime-layer abuse and repackaged apps are malware-adjacent execution risks. |
| Recommendation — Deploy malware defenses that inspect mobile executables and suspicious runtime behaviour. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity Verification | Android runtime security depends on verifying code integrity before execution. |
| Recommendation — Verify app package integrity before allowing execution on managed devices. | ||
Related resources from NHI Mgmt Group
- What breaks when virtual machine backup is too dependent on agents inside the workload?
- How should security teams replace standing access with just-in-time access in cloud and virtual machine environments?
- What are the signs that virtual machine based abuse is distorting fraud detection signals?
- How should security teams apply service mesh controls to virtual machine workloads in hybrid environments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org