Why Android Lollipop OS Consuming More Internal Storage for apps?

Rajesh K      android

We know that Android Lollipop OS consumes more Internal storage for Android Apps than older Android Operating systems. If we analyze, we come to know that it happens because of android runtime change in Lollipop.

Android Apps, written in Java, converted to byte code, packaged as apk and run on Runtime. That runtime can be either DVM or ART.

ART and its predecessor Dalvik were originally created specifically for the Android project. ART as the runtime executes the Dalvik Executable format and Dex bytecode specification.

ART and Dalvik are compatible runtimes running Dex bytecode, so apps developed for Dalvik should work when running with ART.

ART was first included in Android KitKat, but isn't yet enabled by default. You can enable it via Settings>Developer options>Select runtime>Use ART.Untill Kitkat DVM is the Default Runtime.


From Android L (5.0) ART has been made as the default runtime (ART has completely replaced Dalvik).


ART(Android RunTime) is the next version of Dalvik. Dalvik is the runtime, bytecode, and VM used by the Android system for running Android applications.

ART has two main features compared to Dalvik:

  • Ahead-of-Time (AOT) compilation, which improves speed (particularly startup time) and reduces memory footprint (no JIT)

  • Improved Garbage Collection (GC)

AOT means your apps are compiled to native code once. What is stored on your phone and run is effectively native, not bytecode. This differs from the traditional VM model, which interprets bytecode. Interpreters are slow, so VM developers added a technology called Just-in-Time(JIT) compilation, which compiles (and hopefully optimizes) your code to native code on-the-fly. Dalvik is a JIT'ing VM. The downside to JIT is that the JIT compiler runs while you are using your app, adding latency and memory pressure. The upside is that the JIT compiler can look athowyou are using your code to perform profile-directed optimizations.

AOT is like JIT, but it runs once—say, at app installation time. While it lacks the ability to perform profile-directed optimizations, it is possible to perform more extensive optimizations since the compilation is less time sensitive. AOT is useful on systems, such as mobile devices, where JIT adds an unacceptable latency or memory cost to running apps. I think AOT is the right step for Android and ART looks quite impressive.

Advantages of ART over Dalvik

1. The apps launch speed is amazingly fast incase of ART since nothing is compiled at execution.
2. Boot speed is faster than dalvik since nothing is executed from dalvik partition as in case of odexed ROM in dalvik
3. Increases battery backup by reducing CPU work due to absence of compilation work on apps execution.

4. As JIT is not in the picture no on the fly compilation and native code storage. This significantly reduces memory footprint(less RAM is required for application to run).

Some disadvantages of ART

1. Since ART precompiles apps on installation, it takes 10-20% more space upon installation than dalvik. But this can be simply solved by using apps like apps2sd/link2sd/gl2sd when your apps storage partition is full

2. As dex bytecodes are converted to native machine code on installation itself,installation takes more time.

As the native machine code generated on installation it is stored in internal storage,more internal storage is required.