In the Android world, behind the simple operation of each app lies a complex architecture of files and processes that often goes unnoticed by most users. One of the key elements, especially for those who delve into the inner workings of the operating system or develop applications, are the .art files linked to the Android Runtime (ART). Although at first glance they may seem like a distant, technical aspect, understanding their function and why they exist is fundamental to knowing how Android works internally and how it has evolved to be faster, more efficient, and more secure.
From the first Android phones to the most recent versions, the execution system and the file formats that apps manage have changed a lot . If you want to know what .art files are for, how they differ from the old ODEX files, what role ELF files play, or simply understand what happens every time you install or open an app, this article will explain everything clearly and without unnecessary technical jargon . Even if you're a curious user with no development experience, you're going to discover a lot of details that are sure to surprise you!
What is Android Runtime (ART) and how did it come about?
Up until approximately Android 4.4 KitKat, Google's operating system used Dalvik as its primary virtual machine, responsible for interpreting and running applications developed in Java. However, Dalvik had some limitations in performance and efficiency, especially when compiling each app's code 'just in time' (JIT) every time it was opened. Android Runtime, known by its acronym ART, is the runtime environment that replaced Dalvik starting with Android 5.0 Lollipop, although it was already optional in the later stages of KitKat.
ART introduces a revolution in how Android applications are compiled and run: the system moves from Just-in-Time (JIT) compilation to Ahead-of-Time (AOT) pre-compilation, generating device-specific machine code files during app installation . This way, when you open an application under ART, the system already has the generated native code and doesn't have to compile important parts on the fly, resulting in less processor usage, much faster execution, and significant battery savings.
Furthermore, ART is backward compatible with Dalvik's .dex bytecode format , so apps packaged in APKs and designed for the previous virtual machine still work, but the internal process of conversion, execution, and optimization changes radically.
What is an .art file and how does it fit into this architecture?
To truly understand what Android Runtime .art files are for, you first need to put them in the context of the structure of every Android app:
- The source code of the apps (Java or Kotlin) is compiled to Java bytecode, generating .class files.
- All of that bytecode is transformed and compressed into the .dex (Dalvik Executable) format, which is the 'classes.dex' file included in each APK (the standard Android app installer).
- The APK, therefore, is a compressed package that includes the .dex, resources, images, manifest, and other components.
- Depending on how the system works, with Dalvik, the .dex is continuously recompiled through the JIT process and generates .odex files to store the 'optimized' code.
- However, ART uses a different strategy: during app installation, the system compiles the .dex to native machine code and creates files in .oat and/or .art format (depending on the Android version)., which contain the optimized code and data structures needed for the app to run directly, without further real-time compilation.
Specifically, the .art (Android Runtime) files are the files resulting from that previous compilation, generated by the dex2oat tool , and can contain both the executable code in ELF (Executable and Linkable Format) format, as well as the additional information of the virtual machine image and the data of the precompiled classes.
What are .art files used for and how do they benefit both the user and the developer?
The existence of .art files has several direct consequences and advantages for both Android users and developers :
- Better app performance: Thanks to the AOT compilation that occurs during the installation of each application, the startup and execution of all functions is much faster, since the code is already ready to run on your device's architecture (ARM, x86, etc.).
- Lower resource and battery consumption: By eliminating the need to constantly compile code during use, as Dalvik did, the processor works less, generating less heat and using less power.
- Reduced latency when opening or switching between apps: The operating system does not have to wait for parts of the bytecode to be recompiled, which improves the experience and fluidity.
- Greater security and control: ART implements much stricter code verification than Dalvik, reducing the possibility of executing malicious or invalid code.
- Better debugging and error tracing: Because the code is already analyzed and compiled, Android Runtime can provide clearer and more detailed traces and error messages.
However, on the other hand, .art and .oat files take up more internal storage space because they already contain all the machine code, and the app installation process may take a little longer than in older versions of Android, although nowadays it is imperceptible to almost all users.
Differences between .art, .oat, .odex, .dex, and ELF files: What does each mean?
Perhaps one of the most common questions when exploring Android Runtime is the distinction between the various file formats that can appear in the system. Let's clarify this in a simple way:
- .dex (Dalvik Executable): This is the intermediate format that contains the bytecode for Java/Kotlin apps. Every APK includes at least one .dex (usually 'classes.dex').
- .odex (Optimized Dalvik Executable): Files generated by Dalvik during app optimization and execution, storing pre-compiled code fragments to speed up startup on subsequent runs. These were especially important on pre-Lollipop systems and were removed with the arrival of ART.
- .oat (Optimized Android Art): The format introduced by ART, the modern equivalent of .odex, which can contain both native code in ELF format and optimized metadata and class structures. These are found in modern versions of the system, especially in /data/dalvik-cache directories or app folders.
- .art: This is the Android Runtime virtual machine image file. It's usually found in system directories like /system/framework and contains the precompiled classes and frameworks needed for the virtual machine to run and boot faster.
- ELF (Executable and Linkable Format): is a standard executable format on Linux/Android systems. In ART, the machine code generated during app installation is stored in ELF files embedded in .oat or other files.
While ODEX disappears in ART, OAT and ART (image) files become fundamental for the startup and efficient execution of any app on Android Lollipop and later.
How does the process work from when you program an app to when it runs on Android?
Let's look at the exact steps an Android application follows from the moment you write it until you can open it on your mobile, differentiating what happens in Dalvik and ART :
- The code is written in Java or Kotlin, usually in Android Studio.
- The Java compiler generates files .class with standard Java bytecode.
- The Android build system (Gradle and build tools) transforms all .class files into the .dex file .
- The aapt (Android Asset Packaging Tool) packager combines the .dex, resources, manifest, and other files into a APK signed and aligned.
- When you install that APK on your device:
- If you run Dalvik (Android 4.4 or earlier), the system decompresses the .dex and, each time you open the application, it partially compiles it to machine code, generating an .odex (Optimized Dalvik Executable) file for caching.
- If you run ART (Android 5.0 or higher), during installation the tool dex2oat It generates .oat and .art files, compiles all the bytecode into native code for your processor, and stores it in ELF format within the .oat file, along with the structures necessary for execution. This way, the next time you open the app, This will start almost instantly and be ready to go..
This change in workflow allows for much more optimized operation, smarter memory usage, and the ability to page (move to disk) less frequently used parts of the code, something that Dalvik could not do as efficiently.
Where are the .art and .oat files located on the device?
If you've ever navigated through Android's internal paths (with root permissions or in emulators), you've probably seen directories like /data/dalvik-cache or /system/framework. That's where most of the .art and .oat files generated by the system reside . Each app has its own corresponding cache file, with names and paths derived from the original APK.
In more recent Android systems, .art files typically contain the runtime image, while .oat files contain the optimized machine code, both in ELF format. These files are crucial for the ART virtual machine to boot quickly and for apps to run smoothly without bottlenecks.
Main advantages and disadvantages of ART compared to Dalvik and ODEX
The switch from Dalvik to ART marked a turning point in the history of Android. Let's take a clear look at the benefits and challenges this change brought :
- performance and efficiencyART drastically reduces app startup times and achieves more stable and fluid execution. Dalvik, using JIT compilation, was a speed penalty every time an app had to be launched, especially if it had many functions or classes.
- Energy consumption: The reduced need to compile on the fly saves battery life and generates less heat on the device, unlike Dalvik.
- More disk spaceBy storing pre-generated native code, apps end up taking up more internal space on your phone or tablet. It's estimated that this increases by up to 20% on average compared to older systems.
- Slower installationThe full analysis and compilation process during app installation may take a few seconds longer than before, especially on older devices. However, this time is spent only once and then recouped with each use.
- Enhanced verification and securityART disallows certain programming practices that Dalvik tolerated, improving the overall robustness of the system. For example, it rejects invalid bytecode generated by incompatible obfuscation tools or risky practices, forcing developers to follow good practices.