From its origins, Android had been based on DalvikAnd for a long time, this was the virtual machine used by the operating system, but with Android KitKat came ART o Android Runtime as an alternative, and became the definitive substitute from Android LollipopBut what exactly is it? It's about application runtime environment of the Android operating system.
ART or Android Runtime is Android's virtual machine, your application execution environment. With Dalvik, starting with Android 2.2 Froyo, the operating system used JIT (Just-In-Time) for code compilation on each execution of an application. ART, however, replaced this technology with the use of AOT (Ahead-Of-Time). And the difference is that this technology creates a build file after installing an application. This way, the file is used when the application is run, and you don't have to be constantly compiling when it is executed. You can read How to use the ART virtual machine on your device.
ART or Android Runtime and the benefits on operating system performance
Thanks to this important change, Android does not carry out such a large amount of compilations for each application. The result is as simple as the CPU usage is significantly reduced by increasing performance for the same hardware, and the battery saving It is also considerable. But also, compared to the previous Dalvik virtual machine, ART It introduces other performance improvements such as debugging and profiling apps and a garbage collection more efficient. The user doesn't notice any change between one application runtime environment and the other at a visual level, but the internal differences are really significant.
The problem that Google faced, in the switch from Dalvik to ARTIt's in the compatibility, something that affected models like the Samsung Galaxy S5For this, they designed ART using the same bytecode input than Dalvik, supplied by standard .dex files about APKsWhat was modified were the .odex files, which were replaced by ELF files. Why? Because when compiling an app with ART on the device, it runs from the compiled ELF specifically for the device architecture.
Although all this implies a extra time For compilation during application installation, this represents a significant reduction in costs related to Dalvik's own JIT compilation. Another 'collateral damage' is that, due to this change, the installed applications have a top weight to the one they had with Dalvik. But, as is evident, most of the changes are Advantages of ART or Android Runtime in front of the Dalvik virtual machine.
Dalvik and ART within the Android architecture
To understand why Dalvik and ART are so relevant, it is helpful to place them within the context of complete android architectureAlthough the user only sees the layer of applicationsBelow that is stacked a large number of components and layers that make it all work.
At the top are the Android applicationsThese are the apps the user uses daily (messaging apps, social media, games, etc.). Below is the Android FrameworkThis layer exposes the APIs that developers work with: window management, notifications, sensors, camera, etc. This layer is responsible for abstracting the complexity and translating app requests to lower levels.
Below the framework we find the native libraries in C/C++These efficiently implement critical functions (graphics, audio, video, databases, etc.). Developers can access them through the NDK when they need to work at a low level, but it's more common to do so via frameworks.
At the same level is located the Android Runtimewhich is where Dalvik and ART come into play. This layer includes both the Java language libraries such as the virtual machine or runtime environment on which each application runs. All apps rely on this runtime to translate bytecode into machine instructions that can be executed by the hardware.
Below the runtime lies the mechanism of Binder IPC (Inter-Process Communication), which allows the different processes and services of the system to communicate with each other in a secure and structured way. Through Binder, the framework can call the Android system services, which manage functionalities such as windows, notifications, media or telephony.
Under these services appears the hardware abstraction layer (HAL)which offers a standard interface for accessing device drivers. Finally, everything relies on a Linux kernelresponsible for managing memory, processes, security, network, and controllers. At a lower level are assembler, firmware, and physical hardware.
Bytecode, DEX, ODEX and ELF: how an app runs
In programming, the bytecode It is the result of processing and optimizing the source code before it is executed by a virtual machine. This bytecode is portable across architectures, and the virtual machine is responsible for translating it into machine code specific to the device where it is running.
In Android, programs are typically written in Java and first compiled to standard Java bytecode. They are then converted to Android-specific bytecode packaged in the format DEX (Dalvik Executable Format). Each APK usually contains a file classes.dex with all classes compiled. This file is hardware independent and must be translated into machine code to be executed.
With Dalvik, that translation materializes in files ODEX (Optimized DEX). Each time an application runs, Dalvik dynamically translates the necessary parts of the DEX file and stores them in the ODEX. As more code is used, the ODEX file is populated. This task is performed by the tool dexopt.
With ART, the approach changes. Instead of compiling at runtime, the tool dex2oat It takes the DEX file during application installation and fully translates it into an executable in the format ELF (Executable and Linkable Format), typical of Linux systems. The ELF contains the machine code already prepared for the device's hardware, so it is not necessary to continue compiling during execution.
This difference in workflow (ODEX vs ELF) is key: with Dalvik, compilation is done JIT during execution, whereas with ART it is done AUGUST during installation. In return, the apps take up more space in storage, but they offer faster starts and lower CPU and energy consumption.
From source code to APK: how to build an Android application
The process of building an Android app combines the Java JDK and the Android SDK tools, typically orchestrated by gradle From Android Studio, the system compiles the code, processes the resources, signs the application, and prepares it for distribution as a file. APK.
This workflow involves several specialized tools. The usefulness apt It compiles the AndroidManifest.xml file and the XML resources, generating the R.java file that allows them to be referenced from the code. The tool aidl transforms .aidl interfaces into Java code for inter-process communication.
After the Java compiler It takes all the source code, including R.java and the classes generated by aidl, and produces .class files. Then the tool comes into play. dex, which converts those .class files (and associated libraries) into a single optimized DEX file, removing duplicate strings and constants to save space.
In specific scenarios, especially with emulators and older versions of Dalvik, the tool dexopt You can pre-generate an ODEX AOT file to speed up execution. Finally, apkbuilder It packages the DEX along with the compiled and uncompiled resources in the final APK, which is signed with jarsigner and aligns with zipalign to improve resource access performance.
The resulting APK contains the DEX file, the compiled resources (XML, manifest, layouts), the uncompiled resources (images, audio, video), and the signature. The ELF file used by ART is not included in the APK; it is generated later on the device itself using dex2oat when the user installs the application.
Installation, optimization, and caching: what the system does when installing an app
When an APK is installed, the DEX file it contains is in a state pre-dexoptAt that point, the system performs various optimizations on the bytecode: it adjusts the data format according to the processor architecture (endianness), creates Data structures simpler, it links inline library functions and even applies shortcuts like short-circuit for empty classrooms.
If the device uses ARTDuring installation, the tool is invoked dex2oatwhich transforms the DEX into a fully compiled ELF executable. If the device is based on Dalvikthe system can create a file ODEX initial, which will be completed with JIT execution.
One curious thing that many users have noticed is that, after certain system updates, Android displays a message like this: “optimizing applications”That process corresponds precisely to the compilation or optimization of DEX bytecodes of the installed apps, either by generating new ELF for ART or refreshing the ODEX in Dalvik.
Dalvik: The original Android virtual machine and its JIT build
Dalvik is a virtual machine developed by Google Specifically for Android. Although inspired by the Java Virtual Machine, it introduces changes to adapt to devices with limited resources: it takes up less space, uses 16-bit instruction sets, and simplifies the constant table with 32-bit indices.
Its defining feature is the Just-In-Time (JIT) compilationEach time an application is run, the Dalvik compiler translates the DEX bytecode into machine code in real time with the help of the tool dexoptThe result is stored in an ODEX file, usually within the directory dalvik-cacheto avoid always recompiling the same parts.
Each application runs on its own own instance of the virtual machineThis provides isolation: if one app fails, it doesn't affect the others. When Dalvik opens an APK, it extracts the DEX, creates or updates the ODEX if permissions allow, and executes the compiled code from there.
Just-in-time (JIT) compilation has important advantages: it allows you to adapt the code to the... Specific CPU and operating systemIt collects execution statistics to apply dynamic optimizations and benefit from global optimizations without sacrificing dynamic linking of shared libraries. However, it also entails CPU latencies and consumption by compiling during execution, which results in less autonomy and more heat in some scenarios.
Dexopt tool and internal Dalvik optimizations
The tool dexopt It is responsible for verifying and optimizing the classes in the DEX file. It performs abbreviated initialization of the virtual machine, loads the necessary DEX files from the bootstrap class path, and analyzes all instructions to detect illegal sequences. Only verified classes are optimized, and a flag is set. flag in the ODEX to avoid repeated checks.
Dalvik optimizations include replacing virtual method indices with indexes of vtable, replace field indices with byte offsets, merge multiple types into a 32-bit form, perform inlining It eliminates very frequent calls (for example, String.length()) and empty methods. It also adds pre-calculated data to speed up future executions.
These optimizations have some complications. The vtable indexes and offsets can change if the virtual machine or the DEX file of a superclass in another package is updated, requiring ODEX to be regenerated. Furthermore, the directory dalvik-cache and their permissions vary between development and production environments, conditioning when and how ODEXs can be generated.
ART, AOT compilation, and improvements over Dalvik
ART introduces the Ahead-Of-Time (AOT) compilationThis involves converting the DEX bytecode into machine code before the program runs, typically during APK installation. The tool dex2oat This generates a complete ELF executable.
The reasons for opting for AOT on mobile devices are clear: reduce the number of runtime builds, decrease the CPU usage, save battery and accelerate the application launchHaving the program and its libraries already compiled reduces startup time and makes more efficient use of RAM.
ART also brings improvements to the garbage collectorwhich becomes more predictable and less intrusive, reducing noticeable performance interruptions in some resource-intensive apps. It also offers improved tools for debugging and performance analysisThis helps developers to find bottlenecks and bugs more accurately.
Another significant advantage is that ART does not need a JIT code cache at runtime, which simplifies memory management and allows for better code paging, since these are conventional ELF executables loaded by the system. Furthermore, the runtime can preinitialize class sets at compile time, further improving RAM usage efficiency.
The cost of all this is that the dex2oat tool takes longer than dexopt to compile DEX to ELF. However, this investment is made only once (per installation or upgrade), compared to the multiple partial compilations of Dalvik. You gain execution performance in exchange for... installation time y storage space extra.
Advantages and disadvantages of ART versus Dalvik on Android
On a practical level, most users perceive that with ART the applications They open fasterMultitasking is smoother and the system responds better under load. Many testimonials indicate a noticeable improvement in the interface smoothness and in battery life when the environment is well optimized and the apps are compatible.
Among the main advantages of ART In contrast to Dalvik, the following stand out:
- Better overall performance of the system and applications, thanks to the complete AOT compilation.
- Lower energy consumptionby reducing runtime compilation work and intensive CPU usage.
- More efficient garbage collector, with fewer noticeable pauses in demanding apps.
- improved tools for debugging, profiling, and performance analysis during development.
- No JIT cache runningThis simplifies memory management and improves paging.
Just like disadvantages of ART Opposite Dalvik, we find:
- Longer installation or update time of applications, due to the complete compilation from DEX to ELF.
- Larger storage capacity of the installed apps, by saving the ELF executable along with the APK and its resources.
- Possible incompatibilities initial versions with certain modified ROMs or apps that depended on very specific Dalvik behaviors.
- Less margin for some dynamic optimizations very advanced that in theory could exploit a pure JIT, although in practice the benefits of AOT are usually greater in mobile.
Despite these disadvantages, Android maintains the backward compatibility by continuing to use .dex bytecode as the input format, so that an app designed for ART can also run on Dalvik in older versions, provided the system and the app allow it.
ART, Dalvik and custom ROMs: deodex, odex and kitchens
In the world of Custom ROMsConcepts like ODEX, deodex, Dalvik cache, and ART have a direct impact. Dalvik generates ODEX based on the system image, the BOOTCLASSPATH and other APKs or JARs of the framework, so each ODEX file depends heavily on the exact combination of files with which it was created.
For ROM "cooks," this presents a difficulty: if they modify an already installed APK without updating its ODEX file, errors may appear. errors and forced closuresThat's why many choose to “deodexing” ROMs, that is, integrating the content of the ODEX into the APK itself to eliminate external dependencies and facilitate modifications.
In a deodexed ROM, the first time an application runs, it usually takes longer because Dalvik has to regenerate the ODEX in the cache, but after that, the behavior normalizes. In contrast, in odexed ROMs, app startup can be somewhat faster initially, at the cost of greater inflexibility when modifying the system.
With ART, the role of ODEX disappears in favor of the ELF executablesThis simplifies some aspects but introduces other challenges for ROM developers, as the AOT compilation process, ELF management, and framework relationships must be considered when creating or modifying custom system images.
This new feature in KitKat is one of the most interesting it brings, and yet it received very little attention at the time. Many users tried it when it was still an experimental option, noticing greater fluidity and speed in multitaskingHowever, some popular apps, such as messaging services, took time to become fully compatible.
Today, ART has established itself as the standard runtime environment, while Dalvik remains the historical reference technology. Understanding the technical differences between the twoUnderstanding their advantages, disadvantages, and how they fit into the Android architecture helps to better understand why the same hardware can offer such different sensations depending on the runtime it uses.
Thanks to this paradigm shift from JIT to AOT, Android has been able to offer Higher performance, better memory management, and longer battery life, maintaining compatibility with the existing application ecosystem and allowing both users and developers to benefit from a more robust technical foundation.
