By 
The writing for the Dalvik runtime (the runtime that handles the real-time decompilation of all Android apps) has been on the wall for quite a bit now. Hints that ART — which is said to be a lot more efficient than Dalvik — would soon be replacing Dalvik as the standard runtime have been dropped in code commits and comments ever since Google introduced the new development a while back.
But this is the first time they’ve made a clear declaration that the first iteration of ART is ready for primetime. Code commits 98553 and 98618 mention the change, and in typical Google fashion they inserted some harmless comments to drive the point home:
Dalvik is dead, long live Dalvik!
So what does this mean from here on out? We’re not sure. ART received a lot of criticism throughout its preview period due to compatibility issues with certain apps. The fixes to make apps compatible were relatively easy, however Google has made it a point to make ART backwards compatible instead of forcing developers to make changes.
The road through the ART preview was bumpy, but things could very well change once Google officially marks a stable release (which we imagine would be in the next major version of Android, whenever that’s due).
Even with an official release there will probably be some hurdles to jump, however if Google is confident enough to make such a big change to their world-leading mobile operating system then we should give them the benefit of doubt. Let’s hope we hear something more at Google I/O.
[via XDA]
So the headline is just a guess. Ok.
An educated guess
It’s not a guess, full ART support has already been pushed to the AOSP-master github. Many developers have already confirmed this on G+
The words quoted are referring to the fact that both compilers run Dalvik byte code. Back in Android 2.2, Dalvik was updated to use JIT, or Just In Time compilation. Now it uses AOT, or Ahead Of Time. This is still very much Dalvik, but a rename was appropriate.
Also keep in mind that not all apps use these runtimes. Native apps don’t have to be recompiled.
I switched to ART on both my GNex and M8 and my battery started diminishing much more rapidly. I switched back to Dalvik pretty soon after. Anyone else experience this?
I used ART on my Nexus 5 ever since I got it back in December. No issues with battery life using it. Just enabled it on my GS5 to see if anything is different.
I heard great things about battery life with ART on the N5, so I switched to it on the GNex and my battery life saw an incredibly sharp reduction. I figured I’d give it another shot when I got the M8 and again had decreased battery life, but not as drastic. I’m interested to hear how it works out on the GS5.
Battery life on my GS5 running ART hasn’t changed at all. Still showing good battery life. Had a power outage at home yesterday so I played some games & browsed the web on LTE for a bit. Plugged it in last night with 70% left and 1 1/2 hours screen on time.
Well, maybe I’ll have to give it another shot. Thanks for the info!
What does this do for performance?
You have some people telling you it makes your phone faster, others that say it’s placebo. Probably a little bit of both.
Or maybe the users have no idea which apps are optimized to art. So they say its placebo. I have no conclusion yet.
Some people say the sun rises in the East. Others say the sun rises in the West. The truth probably lies somewhere in between.
Why spend a great deal of money and engineering on a placebo? IMHO, the people who suggest this do not understand what is going on. A change like this is a huge project and investment. The installation procedure is changed. An improved compiler is developed. The OS upgrade procedure is changed because all apps on the device can get recompiled during an OS update. And other changes. Wouldn’t it seem like the placebo idea is silly on its face?
It’s not much different. Sometimes apps open a little faster on ART, at least it feels like they do.
When working properly, here’s a very basic representation of what happens.
App is written for Android as native code – no re-compiling by Dalvik/ART is done.
App is written in JAVA, run in Dalvik compiler – App is compiled when launched (just in time compilation)
App is written in JAVA, run in ART compiler – App is compiled at installation (ahead of time compilation).
Differences between Dalvik/ART – Because the app is compiled at installation in ART, the application will take up more storage space than when using Dalvik. However, performance will be the same as a native application because there is no extra overhead before/during running to compile the app. This results in fewer CPU cycles being used to run the app, which also results in better battery life. For background applications runn, fewer CPU cycles also means less interruption (stuttering) for the foreground application.
Summary – better performance, less overhead, less battery wasted. However, it doesn’t fix poor code. A poorly coded app will still be a poorly performing app.
Nice summary.
I would add that app installation takes a little longer each time as the apps are compiled upon install. And OS upgrades takes a lot longer, as each app can be recompiled during the app ‘optimization’ phase of the upgrade.
One thing I would add, since ART does the compilation Ahead Of Time (AOT) at installation rather than on each launch of the application, a different compiler can spend more time and generate better code. The only negative effect of this is that an install seems to take seconds longer.
There is one thing I could see Google doing someday. But they might not. Have the play store use a highly optimizing compiler and compile it within the store, for each possible target. Then when you install the app, a binary matching your target is what is downloaded and installed. That moves the native code compilation even further back.
So we went from interpreted Dalvik code to JIT (just in time) compiled Dalvik to native. Now to AOT (ahead of time, at install time) compiled Dalvik to native code. So why not someday to AOT (ahead of time, in the cloud) compiled Dalvik to native code?
The naming of this Dalvik vs ART is very unfortunate. The code in an APK file is still Dalvik. The difference is how the Dalvik is run:
1. was interpreted at one time
2. then was JIT compiled at app launch time
3. now will be AOT compiled at install time
They should have termed this AOT vs JIT instead of ART vs Dalvik. It’s still Dalvik code being compiled. And the two older runtimes (interpreted and JIT) were also Android Runtimes, just different ones, so ART is a poor choice of name.
decompilation? do you know what this means?