art thumb

It's fair to say that Android went through some chaotic years in the beginning. The pace of development was frantic as the operating system grew at an unprecedented rate. An as-yet undetermined future led to decisions that were made to conform to existing hardware and architectures, the available development tools, and the basic need to ship working code on tight deadlines. Now that the OS has matured, the Android team has been giving more attention to some of the components that haven't aged quite as well. One of the oldest pieces of the Android puzzle is the Dalvik runtime, the software responsible for making most of your apps run. That's why Google's developers have been working for over 2 years on ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience.


What Is ART?

ART, which stands for Android Runtime, handles app execution in a fundamentally different way from Dalvik. The current runtime relies on a Just-In-Time (JIT) compiler to interpret bytecode, a generic version of the original application code. In a manner of speaking, apps are only partially compiled by developers, then the resulting code must go through an interpreter on a user's device each and every time it is run. The process involves a lot of overhead and isn't particularly efficient, but the mechanism makes it easy for apps to run on a variety of hardware and architectures. ART is set to change this process by pre-compiling that bytecode into machine language when apps are first installed, turning them into truly native apps. This process is called Ahead-Of-Time (AOT) compilation. By removing the need to spin up a new virtual machine or run interpreted code, startup times can be cut down immensely and ongoing execution will become faster, as well.


At present, Google is treating ART as an experimental preview, something for developers and hardware partners to try out. Google's own introduction of ART clearly warns that changing the default runtime can risk breaking apps and causing system instability. ART may not be completely ready for prime time, but the Android team obviously feels like it should see the light of day. If you're interested in trying out ART for yourself, go to Settings -> Developer options -> Select runtime. Activating it requires a restart to switch from libdvm.so to libart.so, but be prepared to wait about 10 minutes on the first boot-up while your installed apps are prepared for the new runtime. Warning: Do not try this with the Paranoid Android (or other AOSP) build right now. There is an incompatibility with the current gapps package that causes rapid crashing, making the interface unusable.

How Much Better Is It?

For now, the potential gains in efficiency are difficult to gauge based on the version of ART currently shipping with KitKat, so it isn't representative of what will be possible once it has been extensively optimized. Thus far, estimates and some benchmarks suggest that the new runtime is already capable of cutting execution time in half for most applications. This means that long-running, processor-intensive tasks will be able to finish faster, allowing the system to idle more often and for longer. Regular applications will also benefit from smoother animations and more instantaneous responses to touch and other sensor data. Additionally, now that the typical device contains a quad-core (or greater) processor, many situations will call for activating fewer cores, and it may be possible to make even better use of the lower-powered cores in ARM's big.LITTLE architecture. How much this improves battery life and performance will vary quite a bit based on usage scenarios and hardware, but the results could be substantial.

What Are The Compromises?

There are a couple of drawbacks to using AOT compilation, but they are negligible compared to the advantages. To begin with, fully compiled machine code will usually consume more storage space than that of bytecode. This is because each symbol in bytecode is representative of several instructions in machine code. Of course, the increase in size isn't going to be particularly significant, not usually more than 10%-20% larger. That might sound like a lot when APKs can get pretty large, but the executable code only makes up a fraction of the size in most apps. For example, the latest Google+ APK with the new video editing features is 28.3 MB, but the code is only 6.9 MB. The other likely notable drawback will come in the form of a longer install time for apps - the side effect of performing the AOT compilation. How much longer? Well, it depends on the app; small utilities probably won't even be noticed, but the more complex apps like Facebook and Google+ are going to keep you waiting. A few apps at a time probably won't bother you, but converting more than 100 apps when you first switch to ART is a serious test of patience. This isn't entirely bad, as it allows the AOT compiler to work a little harder to find even more optimizations than the JIT compiler ever had the opportunity to look for. All in all, these are sacrifices I'm perfectly happy to make if it will bring an otherwise more fluid experience and increased battery life.

Overall, ART sounds like a pretty amazing project, one that I hope to see as a regular part of Android sooner rather than later. The improvements are likely to be pretty amazing while the drawbacks should be virtually undetectable. There is a lot more than I could cover in just this post alone, including details on how it works, benchmarks, and a lot more. I'll be diving quite a bit deeper into ART over the next few days, so keep an eye out!

Special thanks to Bart Tiemersma for his contributions!

Cody Toombs
Cody is a Software Engineer and Writer with a mildly overwhelming obsession with smartphones and the mobile world. If he’s been pulled away from the computer for any length of time, you might find him talking about cocktails and movies, sometimes resulting in the consumption of both.

  • Kenny O

    Damn, the N5 is blazing fast as it is........this will make it even faster?

    • http://www.androidpolice.com/ David Ruddock

      I turned it on and the difference, if there, seems negligible. Granted, this is still basically developer preview status, so there's a long road of optimizations ahead for both Google and app developers I'm sure.

      • Kenny O

        Sounds very promising. I'm game to give it a try, rebooting now :-)

        • Lars Jeppesen

          .. aannnnd that was the last we heard from you.. :)

      • http://www.androidpolice.com/ Artem Russakovskii

        Maybe the improvements aren't as noticeable yet in UI but the Nexus 5 is blazing fast as it is, so it's a lot harder for you to compare something super fast with something even faster at this point.

        I bet it would make a lot of difference in certain situations though, and I'm hoping the Android team gets a lot more vocal about the benefits soon.

        • Shamu

          AP has exposed them!!! They will talk

        • TY

          The biggest noticeable difference would be battery life.

          • h_f_m

            speaking of that, has anyone tested battery life differences with ART vs JIT?

      • Gus70

        I don't think turning it on does anything other than enable applications that are written to take advantage of it. So you aren't going to notice anything yet. It is for developers to use in future apps.

        • http://riteshtripathy.wordpress.com/ Ritesh

          I don't think you read the article up there.

          • Gus70

            I read the article. I just think there is not enough information. So existing apps may not benefit from having this turned on is all I'm saying. I should have been more clear that I am speculating.

          • http://riteshtripathy.wordpress.com/ Ritesh

            The runtime is different. Almost every app benefits from the AOT compiling. Overall system efficiency is significantly increased. I'd say read it again.

          • http://www.androidpolice.com/author/cody-toombs/ Cody Toombs

            Apps don't have to be written for or modified to take advantage of ART. It's automatic. There may be some future optimizations or tweaks that developers can eventually use, but it's all completely behind the scenes at the moment.

      • Stacey Liu

        One of the guys from Linaro has said that according to some Google engineers he's spoken to, ART is basically finished for every device except the Nexus 5.

  • thezero4

    I turned ART on on my Nexus 4, running a Nexus 5 ROM port. And I was very impressed. Scrolling in applications, and especially Chrome are so fast and one to one. I've had it turned on for two days now and have yet to experience any breaking. I sugest trying it out.

    • http://riteshtripathy.wordpress.com/ Ritesh

      Breaks Whatsapp for sure.

      • http://www.facebook.com/danieltye88 Tungmeister

        That's the only reason I turned it off sadly.

      • cyberkeeper1

        when you enable the ART, you need to clear its cache. all of it. initiate a dalvik wipe and it should rebuild all the cache. if that fails. remove your downloaded apps with the cache cleared, and reinstall all the apps with ART already enabled. do NOT set it as the default runtime or you WILL break your phone. That being said, enabling it is just fine. try to get things working in that order and you should be up and running with all of your apps. ALSO... using titanium backup to restore apps breaks the app while under ART. when restoring using TB, **ONLY** restore the data. you need to manually reinstall the app via play store, else set TB to interactively prompt you to install each app using the classic APK app installer.

    • Matt

      One warning for rooted users that it doesn't appear to play well with rooted apps (I'm not technically proficient enough to know whether that has something to do with root permissions in general or simply the apps I have installed). That said, Titanium Backup, Greenify, etc. all get a little crashy if you choose to try ART.

      • http://flavors.me/sabret00the sabret00the

        Ah, well that sucks. But thanks for the info.

    • NF

      So this also improves touch responsiveness?

      • thezero4

        I wouldn't say responsiveness, but scrolling got better in a couple apps. Facebook, my reddit App and chrome all feel much better when it comes to scrolling.

      • cyberkeeper1

        overall reliability and usage capability are increased up to about 40%. The reason is because currently, android currently uses Dalvik-VM and it compiles data to the VM AS SOON AS the data is being accessed (which causes slower load times), and its called Just-In-Time(JIT). With ART(Android Runtime), the data to be interpreted by the CPU is compiled "Ahead-of-Time" (known as AOT), and this is done as you install any APK.

        • cyberkeeper1

          Also, if you have an older phone, do not expect much, as you WILL be disappointed. Second, if you have an old phone, kit-kat should not be run on your phone, and if its forced on and isn't officially supported or is being pushed as an OTA, then i do regard that as your problem.

          (my source is that i am an expert in android software and Linux-based code.)

    • Kshitij Parajuli

      I tried the same thing today. The first bootup after switching took a while because it was doing the whole "Upgrading Android - App X out of X" procedure. But after that, it felt faster. Didn't know if it was a placebo effect or if it was just faster.

    • Geno Tuni

      is touch responce in chrome one to one with ART? like on iphone and ipad?

      • thezero4

        It's close, it is still a little laggy while loading a page. After that though the experience is very close to iPhone scrolling. It is certainly the best scrolling I've seen in android.

  • http://www.ronakg.com/ Ronak Gandhi

    This is the single most underrated (partial) introduction among all KitKat features.

    • ProductFRED

      Seriously, this may get rid of or noticeably mitigate the lag/inefficiency issues (micro-stutters, etc). I mean, it's pretty weird that, for example, Windows Phone runs on older hardware (in terms of bleeding edge) and is much smoother, even if you argue that it's doing a lot less than Android in the background. Hopefully this brings us that level of efficiency. It's probably a big part of why KitKat is set to tackle the issue of running Android on older/lower-end hardware.

      • mikeym0p

        Kitkat on it's own got rid of a lot of lag. In my experience with using ART (since source dropped) it reduces the opening time of applications. Cold booted applications dont show the grey space, they just open instanly.

        The device did still have stutters when using ART, the best example I know is Play Music. I just got a small update for it a few days ago and now it is truly lag free, I cannot make it stutter.

        Therefore, I believe ART can help in CPU bottleneck situations, however most of the lag on 4.x on high end phones is from extensive gpu draw calls. This is something that is being worked on everyday, Facebook's app being a prime culprit.

        • Ashwath Ravee

          I get almost zero stutter when using ART on my Nexus 4. Even Facebook's app has finally stopped stuttering for me. That's pretty huge.

          • syxbit

            Facebook is native code built against the NDK (and therefore uses neither Dalvik nor ART).

          • Ashwath Ravee

            Oh I didn't know that but I haven't used the official Facebook app in a long time. I just installed it to do a quick test since I remembered it as one of the most laggy apps I had come across.

          • Bart Tiemersma

            I don't think so. Facebook is "Android native", which means it is built using Android API's, instead of using HTML5. The iOS app used to be very slow too, until they rebuilt it using iOS API's.

          • syxbit

            er.... no.

          • Bart Tiemersma
          • syxbit

            You're right. I must have misunderstood when I read one of facebook's posts a few months ago, and read 'native' as actually native C code, rather than 'Android native', which means Java.

          • http://limbanibhavik.com/ Limani Bhavik
          • asdf

            How is that native: http://m.facebook.com/

          • Sly Cooper

            Nothing on Android uses HTML apart from cordova...

            Android layouts are XML, code is Java. Unless you go native, that's the end of the story.

          • janellavew231

            мʏ вυɖɖʏ'ѕ αυɴт мαĸɛѕ $66 ɛʋɛʀʏ нօυʀ օɴ тнɛ ιɴтɛʀɴɛт. ѕнɛ нαѕ вɛɛɴ ʟαιɖ օғғ ғօʀ 9 мօɴтнѕ вυт ʟαѕт мօɴтн нɛʀ քαʏ աαѕ $17421 ʝυѕт աօʀĸιɴɢ օɴ тнɛ ιɴтɛʀɴɛт ғօʀ α ғɛա нօυʀѕ. тʀʏ тнιѕ աɛвѕιтɛ fox200&#46com

          • mikeym0p

            That's not because of ART which affects CPU execution. Open GL Es 2.0 and a few other graphics improvements are what are helping that. Facebook, wouldn't surprise me if it was heavily CPU bound as well which would be why you noticed an improvement. I however use it in a web browser.

            The point I'm stressing is ART isn't the catch all be all of 4.4's speed improvements. You wont miss out on much if you're using Dalvik still (wider compatibility).
            There were a lot of optimizations going not only into the OS, but into Applications; with more Google apps getting optimized, I dont even see stutter anymore on my nexus 4. It's really awesome.

        • sataniccrow

          atm art is still a work in progress. Many apps wont work with that runtime (e.g. whatsapp)

          • wouter

            New version of whatsapp seems ART-compatible

      • Ashwath Ravee

        In my experience, all microstuttering is gone now with ART. This was the first thing I noticed. Dalvik with high end hardware is pretty smooth these days, no doubt... but once I turned on art, it just felt a lot more solid and well rounded. The occasional stutters that you'd get here and there on Dalvik especially during heavy multitasking seem to have disappeared on my Nexus 4.

        • HoboJerky

          Do a controlled study. Have your friend do a boot of each compiler, and hand you the phone. See if you can get it right more than 50%.

          • Ashwath Ravee

            Good idea but switching from Dalvik to ART can take over 10 minutes each time. I don't know if I had any friends who are patient enough to do this.

        • ocovarr112

          and what ROM are you using, cuz I have aosp and it just keep crashing when I use ART.

          • SigonLegacy

            It says in the article to NOT use AOSP based builds.

          • ocovarr112

            Thats why Im asking what ROM is he using.

          • Sharique Abdullah

            Stock Android direct from Google. Isn't that a straightforward guess?

          • ocovarr112

            Is not because there is not stock android 4.4 for nexus 4.

          • Sharique Abdullah

            I think OTA update for most Nexus 4s has already been pushed, and others are getting the updates soon. No?

          • ocovarr112

            OTA 4.4 is available just for nexus 7 and 10, and even if there is for nexus 4 (but there is not) at the time of this post was made there was not, so no, he was not using stock android.

          • Sharique Abdullah

            Ahan, then it would be Nexus 5 stock ROMs ported for Nexus 4.

      • socalnighter

        You can't compare this to Windows phone as Windows Phone OS also runs on different hardware platform so for sure WP also does something what Dalvik does. The best comparison is iOS which runs on a pre-known hardware platform. Running apps through Dalvik is already fast enough, imagine how it could be when the apps start in machine's native code, it's mind blowing

        • didibus

          Why can't we compare it to Windows Phone? I thought Windows Phone ran a VM using JIT compiling, just like Dalvik, so all this time I assumed that they had just better optimized the JIT compiler and their code in general. Now I'm wondering if Windows Phone doesn't already do something like ART, because it is really fast for the hardware it runs on.

          • Sebastiano

            AFAIK .Net has always had tools like ngen, that do AOT compiling. I have no idea about what goes on on WP, but I have worked for years on computers with .Net and the CLR (.Net's equivalent of the JVM/Dalvik)..

          • CDurrr

            Windows Phone already does this. Windows Phone apps when submitted to the Windows store is compiled into MDIL (Machine dependent intermediate language) and when installed on the phone, is further compiled into native code. The cloud compilation reduces time for native code generation on installation. You can read more at http://www.silverlightshow.net/items/Windows-Phone-8-Compile-in-the-Cloud.aspx

          • didibus

            Awesome, thank you, just the info I wanted to know!

        • ProductFRED

          It doesn't run on a different hardware platform. Windows Phone runs on ARM CPU's, such as the Snapdragon S4 Pro, dual and quad, which is even used on newer Blackberry devices (Q10, Z10, etc).

      • hot_spare

        I don't agree on the WP part. I have used a few WP devices recently (low/med like 625/720 etc.,) and I wasn't that impressed with the speed. For example, opening various options within the Settings option would take much longer than expected. This wasn't expected as I was just opening display or volume options within the settings. Saw this with 2 phones. The app launch times with normal apps like Facebook, Whatsapp weren't good either. They were decent, but it felt sluggish compared to Android phones i used. Yes scrolling on WP is smooth. That's the only thing I can say as a positive for WP.

        • Nilay

          Opening time on WP varies on multiple parameters. Most important is isolated storage and serialization/de-serialization part associated with it. Most apps on WP store data on isolated storage (more like disk space) which require serialization of data (rather objects). And serializing and de-serializing data to object generally takes time. Also consider Mutex and object locking as WP supports asynchronization only.

      • Milind

        I'll have to see this for myself. But I don't think it's going to do much for lags and stutters - with one caveat. Startup time for Android apps is not something I see people clamoring about. At least I don't think any app takes too long to startup. JIT compiles code to machine code so when you see lags and stuttering, it's compiled machine code that's running. So any perceived smoothness is I think a placebo effect. The stuttering and lag comes from other stuff like touch sensitivity which this does not fix. The one big caveat to this is garbage collection. If the VM is doing garbage collection, it's going to freeze everything else. So the lags from garbage collection could possibly go away. But I'm not sure how that's going to work, because there is no explicit destruction of objects, so "garbage collection" still has to happen somewhere. I don't know how/where it's happening in ART.

        The Netflix App used to be unbelievably laggy on scrolling while Google Music was silky smooth. Switching from Dalvik to ART is not going to fix that. And I think the general consensus is that so far at least there doesn't seem to be much difference in performance. I expect that this will continue to be the case. It's going to take things like Project Butter and improved touch sensitivity to fix lag and stutter in Android.

        • ari_free

          It should do a lot for battery life though

          • Michael Smith

            ART does not just improve startup time. Keep in mind that the code is not compiled to native until you "execute" that byte code. What this means is you can be using your app for 30 minutes then select an option and bam STUTTER. Select another option or do something different, and bam STUTTER. Some applications worse than others. Apps can be designed to reduce this by artificially trigger executions of methods but why put this on the honus of the developer?

          • Milind

            I agree. But the thing is that most stuttering is not on code that's not been loaded. It happens when scrolling in lists in some apps. The code's already been compiled here. It happens when there is IO happening. The Transformer Prime was simply awful because of it. The Nexus 7 lagged to the point of being unusable until 4.3 fixed fstrim. Project Butter's vsync timing and triple buffering did a lot to reduce the jankiness. I have no doubt that pre-compiled code will be great for start-up times for some games. But it's going to do nothing for the times that I click in a TextBox and the keyboard doesn't show up until a second or two later. I hope I'm wrong, but I don't think this is any kind of a silver bullet. This will be one amongst many things that will continue to make Android smoother. But I suspect it's not going to have as much of an impact as it appears in the stories being bandied around - including this article.

          • Sharique Abdullah

            The scrolling issue in most apps is because of overloaded drawables layers stacked onto each other in each of their list item. Its probably a badly designed app AFAIK.

    • Chris Caldwell

      its intended to be underrated, or everyone will enable it and its not ready for that. Its there for folks who know what they are doing and will enable it with some tolerance for 'experimental' features.

    • zamroni

      I guess it is underrated by Google it slef because it is still in beta stage.
      Still waiting official Kitkat for Nexus 4.

    • Programmer

      Your future is my past. I'm an old school programmer and things I'm seeing now in mobile and web development are things I was working with 20 years ago. Even better than this. Real fast optimizing compilers and linkers, visual design, integrated code and design, proper debuggers, profilers and other tools that a programmer need.

      When I see today's development for mobile and web, it's like stone age compared to what we already had. I mean, some of the most popular languages today, Java and Javascript, don't even have properties. Sucks, ha? I had that in Object Pascal before most of Android users were even born.

      To mobile and web programmers these old things are now "new and amazing". Just like a remake of an old song that is "new" to kids. It makes me smile. But it's not a bad thing. Better to reinvent old things that were good (and possibly improve them), than to use new things that suck.

    • Fulaman1984

      100% agree, I use it and have not run into any problems thus far.

  • Sven Enterlein

    Thank you for this very informative article. I'm already excited to see what the custom ROM devs will do with this new toy because I'm not hopeful that my Note II will ever see Kitkat.

    • http://www.androidpolice.com/ Artem Russakovskii

      I'm eagerly awaiting Cody's next pieces further exploring ART.

    • cyberkeeper1

      check out the CM (cyanogenMOD) team in their latest kit-kat build, already up to 4.4.1 android. i'm using it in the d2vzw, and its fairly stable. using art has made things stop working but i am working to correct that and submit it to the CM team. :D

  • Shamu

    Can i always revert back to dalvik? Also...anybody have battery life stats for it yet?

    • http://www.androidpolice.com/ Artem Russakovskii

      Yes, you can. Just use the same menu.

      • Shamu

        this pleases me greatly, I guess there is no big risk here, definitely will enable when I get my n5

        • Kenny O

          Make sure you have a few minutes, they were not lying about the reboot taking about 10 minutes......even more if you have a lot of more apps :-)

          • http://www.androidpolice.com/ Artem Russakovskii

            Seriously. ART one-time optimization is probably 5-6 slower than Dalvik.

          • brkshr

            Took me about 5 - 6 minutes with 136 apps.

          • http://riteshtripathy.wordpress.com/ Ritesh

            Took me about 8 mins with 142 apps.

          • Shamu


    • http://riteshtripathy.wordpress.com/ Ritesh

      Yes, you can.

    • brkshr

      I would think it would be hard for anyone to have good battery life stats yet. Most people recieved their N5s on Monday. So their batteries aren't even broken in yet. Then they would need to be on dalvik for at least a week, then on ART for a week, to be able to draw a comparison. It will take some time.

    • Shamu

      It has also occured to me, if I'm using this and I go into a custom recovery, how do you clear your dalvik cache?

      • http://www.androidpolice.com/ Artem Russakovskii

        You mean ART cache? This will be up to custom recovery developers to implement.

        • Shamu

          thats what i figured would happen. Not going to worry about it for now since I'm going to hold off flashing roms until later

        • Robert Alex Kibler

          Hopefully they just tie the two together so there's a 'clear runtime cache' or something like that which would clear both ART and Dalvik.

  • http://riteshtripathy.wordpress.com/ Ritesh

    This will actually "revolutionise" Android as we know it. I can't wait to see what happens in the next few months now that they've acquired FlexyCore too. Android 4.5 with ART as default anyone? :)

    • Ricardo Kummel

      Hopefully.. :)

    • brkshr

      FlexyCore was bought a year ago. So we should have the benefits from them already.

      • http://riteshtripathy.wordpress.com/ Ritesh

        A year ago?

        • http://www.androidpolice.com/ Artem Russakovskii

          Within a year. But we have no evidence of them working on ART. Maybe they are, or maybe they aren't.

          • http://riteshtripathy.wordpress.com/ Ritesh

            But ART commits were being made long before FlexyCore was pulled in.

          • http://www.androidpolice.com/ Artem Russakovskii

            Right. Clearly, Flexycore members haven't started the ART project within Google, but for all we know they could be working on it now. Or not.

          • Chris

            I see what you did there

          • Sirajuddin

            If they aren't then with ART already significantly reducing lag and what FlexyCore will do along with the power of Google Now, Touchscreens will become obsolete, as Android phones become Prescient!! Hahaha.

        • brkshr

          Yep. It was only discovered recently.

      • Jimas

        Yeah this sounds a lot like what FlexyCore's technology was about...

        • Matt

          From what I've read, the most relevant commits to ART in AOSP actually happened before Google's acquisition of FlexyCore. So FlexyCore may be unrelated to this.

          • http://www.androidpolice.com/ Artem Russakovskii


      • Knowles2

        From what I read the deal was only concluded in the last month.It unlikely Google would incorporate their code before fully acquiring the company.

    • http://turbofool.com Jarrett Lennon Kaufman

      I had read elsewhere that this IS the FlexyCore technology.

      • http://www.androidpolice.com/ Artem Russakovskii

        This is false.

        • Whyzor

          Is this wishful thinking? It's entirely possible different parties started down the same technology path, then Google was impressed with FlexyCore's progress and bought them to work together. I doubt FlexyCore will have new revolutionary performance gains on top of ART.

      • http://riteshtripathy.wordpress.com/ Ritesh

        No. This is NOT FlexyCore tech. As it clearly says; Google has been working on this for over 2 years now.

    • Slawootsky

      I'd prefer 5.0 ;)

      • http://riteshtripathy.wordpress.com/ Ritesh

        5.0 will have beam-me-up. Gotta wait a bit longer for that!

        • Slawootsky

          What is it?

          • http://riteshtripathy.wordpress.com/ Ritesh

            Beam-me-up Scotty? :P

          • Slawootsky

            Oh. Looks like we're not going to live to the day of 5.0 release. :(

    • Mike Reid


      Now what about "ACT" ? IE At compile time, by the dev ?

      ACT would put a serious crimp into reverse engineering apps and thus piracy via app modification, to disable licensing checks.

      But sometimes I think piracy is a "feature" of Android which has helped Google dominate mobile OS's.

      • guy

        There are simply too many architectures to support. For instance, we may start to see Android running phones with x86 Atom processors. This is the whole reason of using a VM in the first place, just as Windows Phone does. The reason iOS can get away with this is they only have to support their own hardware.

        • Airbag888

          using a VM is way too inefficient. Good riddance. People are already reporting great results with what's essentially a beta runtime

        • ari_free

          Nobody really cares about x86 mobile except for Intel. So why should everyone else suffer with a non-ARM optimized Android just so that we can demo Android on things nobody will ever use?

          • Bruce Lin

            Everyone should. It will increase competition which is good for the consumers.

          • ari_free

            Competition is great within ARM space, much more than x86. Nothing is stopping Intel from making their own ARM chips but x86 just isn't a good arch for mobile. What mobile needs is a battery optimized arch and you don't help it with software that kills battery to compile apps on your phone in order in order for it to be easier for people on battery killing archs.

      • Sebastiano

        Doing ACT optimizations would just lose all the "code once, run everywhere" (borrowing from Java's motto) advantage.

        • leomax999

          I dont think so. They are just moving from JIT to AOT.

          • Sebastiano

            I think you misread, Mike was talking about ACT. In fact, JIT and AOT are actually not that different from this perspective, the optimization is done on the device.

          • Jonny

            You are not fully understand what ART does, but...
            who cares

          • Sebastiano

            I'm afraid that, since my job is customising Android, it's not that likely.

            I know exactly what Dalvik is and does, and I have a pretty clear idea of what ART is and does (confirmed by this article). It seems to me that most people doesn't, though, and this generates all kinds of misunderstandings.

            I don't know how much you know about Android, Dalvik, and those related arguments (I'm not talking about AP articles, but rather about IT theory and stuff). Maybe I'm just unable to explain myself properly.

        • Airbag888

          Why? The code is compiled on the target machine. So it's still able to run anywhere with the ART compiler

          • Sebastiano

            With ACT no, it's not. That's the difference between AOT (bytecode is compiled to semi-native code when the app is deployed to the target device), that is what ART does, and ACT (bytecode is compiled to semi-native code when the app is first built on the developer's computer).

            With ATC you'd either have only one target platform (the native code depends on the CPU architecture), or you'd have to build one different APK for each CPU architecture, when compiling the app on a computer. And of course you'd have to test each of those variants.

            You'd then lose the advantage that Android apps have (those that don't use native code, anyway), which is that you don't need to write/build different variants of the app depending on the target platform, but the same APK will work on ARM, x86 and MIPS without any recompilation. With ART you keep this advantage, since it's the device itself that does the actual bytecode translation to the correct target native code.

          • ari_free

            "With ART you keep this advantage, since it's the device itself that does
            the actual bytecode translation to the correct target native code."

            But that takes time for the user. Users would much rather download apps specifically compiled for ARM

          • mrseanpaul81

            We are talking about a couple of 10s of seconds, if even...wow big deal!
            User is already under the impression that the phone will not be as fast as a computer and even computer installation takes a few minutes. So i think 20 to 30 seconds install time is ok.

          • ari_free

            Not if we're talking about big games. Besides, there's no benefit for the extra time so why have it? Just to make Intel happy?

        • Lucas

          Native, ACP, JIT, AOT... I propose a new one: AGS "at Google Servers"!!

          Kidding about the name, but I wonder if the ART engine couldn't run in the Google servers to compile the bytecode to the most used architectures's native code and play Store would download the appropriate version for each one.

          It would still be AOT, but without the increased install time

        • Sharique Abdullah

          Though you are right. But I think sooner or later this is going to happen. Also, with dalvik replacing JVM and then common use of NDK, the write once run anywhere concept is very applicable in most cases.

          The best way of doing this (and not risking the write once run everywhere moto) would probably be to do this on the google servers beforehand and also offer platform-independent versions as well. In other words, if you are downloading app from Google Play, it is going to be pre-ARTed version and everywhere else, you get platform-independent dalvik version. Makes sense?

  • Magneira

    This is great news, I imagine this will debut full time on Android 5.0 hopefully june/july next year with the new nexus 7 :)

  • Gaja

    Explain difference between ART and JNI? I've seen benchmarks that show JNI to be even faster than ART? Does that mean ART is not fully native?

    • http://kennydude.me/ Joe Simpson

      JNI is an interface to native code from Java. ART will have JNI capabilities

    • http://www.androidpolice.com/author/cody-toombs/ Cody Toombs

      I'm already working on a post where I'll be discussing this in greater detail, but the key point to take away is that this is still just doing the jitter's work in advance. JNI is for calling on code that was written to be native from the start, and therefore enjoys further optimization. Obviously, I'm simplifying quite a bit, but this is the basic premise.

  • NF

    I wonder what happened to app ops? Well, this is one more thing to look forward to on Android 4.5, but I think kit Kat is good enough for now.

  • Matthew Fry

    I thought the VM was how they were doing sandboxing.

    • Jordan Thoms

      Actually, the sandboxing is handled by the user permissions system + the kernel, the VM has no impact on that. If it was the VM, you'd be able to bypass the sandbox by running NDK code.

    • http://kennydude.me/ Joe Simpson

      No. They basically create a separate user along with permissions and SELinux.

      (otherwise your native libraries could just bypass it)

  • http://turbofool.com Jarrett Lennon Kaufman

    Anyone have specific experience with apps broken? Or maybe a forum thread somewhere tracking them? I'd really like to try this out, but I'd love to know what I'm getting into first.

    • nebula

      WhatsApp doesn't work with ART :(

      • http://riteshtripathy.wordpress.com/ Ritesh

        And some root apps behave bad.

      • AK

        I noticed massive improvements with ART. In particular my banking apps from HSBC started up much faster than I was used to. However, WhatsApp not working is a deal breaker. Looks promising though.

  • Albin Hermansson

    I like the part of the header that says this is only part 1.

    • Ricardo

      I hope it is. I tried to look at the code but I've got more questions than answers. There's a portable runtime and a quick one, and you can enable other things too.

  • Chris

    I remember how exciting it was getting JIT on my rooted G1...hahaha

    • http://riteshtripathy.wordpress.com/ Ritesh

      LOL. Same here.

    • Bluewall

      The good old time :D

    • http://youtube.com/spelrutan Jens Törnblad

      Haha, good memories! I remember it being huge news for my SGS as well. :)

    • squiddy20

      Samsung Moment here. And man did that thing need it...

  • Walkop

    Touch Latency. I was talking about this on Google+ a while ago, and how KitKat could very well improve it. Is this it? The king of all touch-latency optimizations?

    • grandautotheft5

      Touch latency was improved a lot on 4.3.

      • cyberkeeper1

        to further this along, touch latency was corrected an implemented in even 4.2.2 due to ROW I/O Scheduler mixed with the INTERACTIVE CPU Governor.. This worked by spiking the CPU to max performance as soon as the screen was touched or the device being woke.

  • Testraindrop

    Thanks for the detailed article(s), I like that Google finally tries to significantly improve the parts of the code that are responsible for fast execution and fluid UI, instead of just releasing a new theme... (Apple...) ;)

    • Gaja

      Yeah, but Apple has been fast and fluid since iOS 1...

      • Testraindrop

        True, but only because they have only icons... ;-)

        (Don't want to start a flamewar, competition is good)

        • Gaja

          I'm not starting a flame war either, I'm an Android fan, but it's a fact that iOS runs only native code, and doesn't use VM like Android, which makes it much smoother and faster, and less heavy on hardware.. I mean, iOS7 flies on 1GB RAM, while SGS4 struggles on 2GB..

          I really hope ART is going to "fix" Android in that aspect..

          • Testraindrop

            Agree and I think there are a few more points of optimization available, like better wakelock handling etc.

            At least they introduced collecting alarms in a bunch so that the device doesn't need to wake every second if the alarm is not important.
            Unfortunately this works only if the app is API level 19+ :(

          • Jsilvermist

            I know, I was sad when I heard that about alarms.

            I wish they would allow batching in 4.4 for all apps with API 18 or lower, so that all the old apps which have a type of set() would be batched.

            I understand this may break some things, but it would be an easy fix, and this would also prevent developers from simply not updating their apps to API 19 which would cause the end user to not benefit from the new AlarmManager API's in any way.

          • cyberkeeper1

            yes and even on my SGS3, wakelock time is way faster. most of the time in the device stock OS, it takes up to 2 seconds for the screen to come on. with CM 11.0, its immediate

      • cyberkeeper1

        yes and to be fair, even though iOS 7 looks like android, its really really fast and smooth no matter how many apps you have open. the main UI gets the thread priority and so the entire device is always smooth. so no arguing about who's faster, because right now its Apple, and i don't even like the OS, but i can't say anything bad about its performance overall.

    • http://riteshtripathy.wordpress.com/ Ritesh

      No. Stop that right now. We do not want a meaningful discussion thread getting derailed with this crap!

  • idlukakas

    I'm afraid about smali decompiling and edit. With new ART will be impossible to decompile? Anyway dex code are in .apk, so no worries I think.

    • Bart Tiemersma

      You will still download an .apk file. This file is compiled to something ART-compatible on the device.

    • HebeGuess

      I was thinking about it while reading the first paragraph, but not after.. ART compiling bytecode into machine language on devices while installing. It means an APK is still shipping out bytecode (.dex).

  • firesoul453

    Dang! Android 5.0 is going to be epic!

  • http://www.androidpolice.com/ Artem Russakovskii

    Anyone want to try the NFL app with ART? It performs absolutely awfully usually. The scrolling behavior is abysmal.

    • Tony

      Just tried it, slow and laggy as usual.

      • http://www.androidpolice.com/ Artem Russakovskii


      • J-Hop2o6

        I've been wondering about this. Why is scrolling so damn laggy? Wonder how ART didn't help it a bit. Is it not using Android native code (ex. old Facebook app)?

    • J-Hop2o6

      I've been wondering about this. Why is scrolling so damn laggy?? Wonder
      how ART didn't help it a bit. Is it not using Android native code (ex.
      old Facebook app)?

      • http://www.androidpolice.com/ Artem Russakovskii

        Yeah, I'm pretty sure the NFL app is all web views, and horribly implemented ones as well, if that's possible. It's the worst performing app I've seen in a while.

        • cyberkeeper1

          the NFL app has always been bad and i have to say... it needs to be put back to formula. taken down, all its innards cut out and reordered. Better yet, get a brand new code base for it. start from scratch. :)

  • Rarelyamson

    So how to fix WhatsApp?

    • http://riteshtripathy.wordpress.com/ Ritesh

      The (super lazy) developer of Whatsapp has to make a decision to suck a little less. That's how. Sorry, but I hate that app so much..

      • Ben Miller

        Well the developer will be left out in the cold when 5.0 comes along and the app no longer works :D

  • http://blog.tonysarju.com/ Tony Sarju

    Half way through the article the first thought in my head was "This is the major change that will be featured in Android 5.0 and is why we're still on 4.x releases"

    • Robert Alex Kibler

      That was my exact thought as well. They've been sticking with 4.x because it's still terribly slow and they didn't want to drop a new x.0 release until they had something groundbreaking and incredible. Well here it is. I can't wait to get my Nexus 5 and test out the ART.

      • Bluewall

        "incredibly slow" is not what I would call KitKat on my Nexus 5, even if it can be even better with ART :p

        • Abhijeet Mishra

          Try taking the example of a lesser powered device. On the high-end, Android is no longer terribly slow. :-P

        • tylerbrainerd

          Right, but performance is fast on the nexus 5 because it's powerful hardware, not because of the software. The software is still rather slow and inefficient.

      • http://blog.tonysarju.com/ Tony Sarju

        My Nexus 5 is waiting for me at home right now after getting delivered this morning. Maybe I'll give ART a try before loading up all my apps.

        • Scott

          Let us know how it is!

          • Drome

            I switched over to ART.. I feel like it had to settle and run for a little but after I launch an app once, it may take awhile to load an first but the second time and every time after you launch that app with will have translated its code ahead of time and it opens instantly. No apps have FC'd on me yet, going to leave it on until I find a reason not to. This has huge potential.

          • John Whitworth

            I didn't think that was supposed to be the case. The process happens when booting up (switching to ART), not when launching an app. Apps that are already open are always instantly opened b/c they're in RAM. This is true for the Nexus 4, 5, and any other fairly recent hardware. Are you sure it's not in your mind? :)

          • Drome

            for instance. when I opened FB, it took me to the splash screen and loaded for awhile. After i saw the feed, I closed to the app in the recent apps viewer and opened it again. It opened much quicker next time.

            It is possible it is in my head or that it simply was still booting up and after the phone settled it ran smoother.

          • Nomaan

            Its your internet that took time.

          • Lars Jeppesen

            The Facebook app uses the splash screen to download essential stuff to your phone for local caching. That is why it was slow the first time. After that, many of the information is cached on the device.

      • dhruva

        i am thinking 4.x to 5.x will happen when google has a visual refresh..thats been the tradition from 2.x to 3.x to now 4.x, we might still see 4.5

  • Abhijeet Mishra

    Wait, does this also mean that those that write their apps in C/C++ won't have the memory overhead that Java apps do, AND their apps will run fast because it'll be turned into native code by ART? if yes, then we could technically achieve near/as good as iOS performance? Please say it is so, pretty please.

    • http://www.gameosaur.com/ neoKushan

      C++ is already turned into native code. What it means is that those who write their app in Java will get some similar benefits to those who write apps in C++. In other words, not just C++ apps but ALL apps should hopefully run close to native code.

    • Bart Tiemersma

      No. If a developer writes a performance critical app, he can choose to write part of his app in C/C++. This code is invoked via the Java Native Interface (JNI). The piece of C/C++ code already runs native, so there is no VM overhead, but it is platform specific.

      ART only changes how the Java side of the app is executed. The Java code will be run "closer to native", with less run-time overhead and more aggressive optimizations, while still being platform independent. This increases performance, latency and energy efficiency.

      • Walkop

        Exactly. According to XDA charts, ART finds itself almost exactly between totally native code and Dalvik JIT.

        Still, a MAJOR improvement!

  • tymalo

    Would the way ART installs app's effect the way you fetch updates on Google Play? Right now it only gets the diffs, making your download smaller. Would ART make it so you have to download the full app when there are minor changes?

    • http://www.gameosaur.com/ neoKushan

      Unlikely. the .apk will probably remain on your system, so what will happen is the diff for that APK will be downloaded as usual, then the whole application will be rebuilt

      • http://www.androidpolice.com/ Artem Russakovskii

        That sounds about right - the optimization is done on the device. The apk is preserved, so the delta could be applied to it just as it is right now.

  • hyperbolic

    Great article and well explained @Cody Toombs !

  • smartguy05

    I read the 'dont try this on AOSP roms' after I had already changed it and the reboot had occurred. I hope everything goes ok.

  • dhruva

    anyone think go language will on android at some point?

    • Kenton Douglas

      Good point. How about DART also though? That is probably a better fit. The DartVM can work with Chrome and Android and cross-compile JavaScript as well as native DART code. Looks like ART is the beginning of a project to replace Java with JavaScript and/or DART ... it's also a way to get 1m Android apps onto Chrome.

  • h_f_m

    Has anyone noticed better battery life using ART vs JIT?

    Is there a list of high profile apps that don't work?

    • natabbotts

      Battery life would be a side effect of the CPU doing less work, so yes, there would be an improvement.

      • h_f_m

        I expected that to be the case I was just wondering if anyone has quantified it.

        • cyberkeeper1

          i have. but no logs or screenshots yet as i have not been able to provide my phone with a completely full charge to 4300mAh + for verification.

          • h_f_m

            I'm definitely seeing good results during sleep as I suspected, but due to radio and panel power draw, it's not a huge difference during usage. Perhaps a small amount but variations of auto-brightness depending on the environment I am in negate any gut reactions I have. I'm happy overall.

    • cyberkeeper1

      swiftkey keyboard app seems a bit broken. it works, but only while typing, and then when its time for it to disappear, it crashes. and a trip to the home screen and back into the app you need to type in is needed. this is likely my fault though as i enabled ART after restoring all the apps and data that were backed up using TB while on Dalvik.

  • Andreas Marconi

    I tried running ART and it was quicker than lubed up eel in a vacuum, but unfortunately it broke all my notifications (especially Gmail and Hangouts), which is kind of a deal breaker. Anyone else noticed this, or was I just unlucky?

  • didibus

    Doesn't Dalvik makes it possible for programmers to use fancy things like weak typing and reflection? Will those disappear, and code that use it need to be changed, or can art deal with them?

    Also curious, is this what Microsoft did with WinRT for Windows Phone?

    • SterlingMaloryArcher

      Using ART as a target for your compilation means that you're not limited to Java and other JVM languages. Not sure where you're getting the weak typing from (weak references maybe? Java is strongly typed.) and reflection is just another feature of Java.

      My guess is that any language with an LLVM front end could be used. I'm especially excited about this.

      It's similar to Microsoft's Windows Phone system, yes, but probably closer to Google's own Native Client (NaCl) for Chrome and no doubt RenderScript for Android.

      • didibus

        Well, I know that java is strongly typed, I guess I was more talking for the future, that means no weakly typed languages would ever be able to run over ART, since it's not JITted. I was asking the question, because I'm not the expert on these things, so I'm actually not sure if Run-Time compilation is required for Weakly Typed languages, I thought it was.

        With Reflection, I was wondering for things like Run-Time compilation. Take a string that contains code, and execute it. Stuff like that.

  • Brian Tehan

    Anyone try this with a 4.4 ROM on a galaxy nexus?

  • didibus

    I did a bit of research, and this seems to be a strategy that Microsoft employs on Windows Phone using what they call Ngen, which pre-compiles .Net code. Microsoft seems to be taking it a step further though, using cloud compilation, so that the precompilation is 4 to 5 time faster than if done with Ngen on the user's machine. Have a read here: http://www.zdnet.com/microsoft-details-its-strategy-for-compiling-windows-phone-apps-in-the-cloud-7000007185/

    It be nice if Cody could look into it, and see if Google might eventually do something similar with the cloud.

    • SterlingMaloryArcher

      It's mostly just plain old Ahead-Of-Time (which is just programmer speak for At-Install-Time) compilation. You kind of ship a "partially compiled" version of your code, and then Android finishes off the compilation on install, taking advantage of exactly what the local hardware has to offer (armv7/armv7s/arm64 architecture, hardware acceleration, extra compute units, etc).

      MS's cloud compilation strategy is a bit easier when you're only supporting a few specific chipsets, but I wouldn't rule it out. The cloud service might need a specific machine profile for each Android device out there... yikes.

      • didibus

        It seems Microsoft's Ngen tool for AOT compilation only helps cold start and hot start performances. Meaning your apps load faster, and code is loaded faster, but they don't talk about making code execute faster. I wonder if this will be similar for ART, or Google is actually turning the code base into close to native code, which would have drastic performance impact.

      • renegadedroid

        OK, I got all that, but what happens if the downloaded partially compiled app doesn't properly compile on the target device at instalation time (I e. errors) How would a developer test for that? Maybe a comprehensive emulator maintained by Google requiring any OEM with plans to supply parts for an Android device to contribute to the compiler. .

  • Dany Bouffard

    A Question about ART, can you turn it on or off by individual app.

    • SterlingMaloryArcher

      It's full-OS, requiring a restart and a re-optimization of all apps on boot.

    • jurrabi

      This would bean the need for both run time in memory at the same time, and I'm gonna guess this will never be an option.

    • Andrea

      I'm almost sure that you can't.

    • natabbotts

      No, it's all or nothing currently.

  • meelyg

    This is all that I could think of while reading this article

  • Peter Blanco

    Serious question. With my limited knowledge in Android development, does that mean we are going to be wiping ART Cache or something of the like from now on? IE flashing roms?

    • jurrabi

      I would say you will keep wipping DVK cache, since probably ART will use the same area for cache (and recovery rooms won't have name changed).
      Probably (talking without first hand info about it but guessing how it should work) ART will use the missing brother room to store his stuff.
      So with new rom you will have to clean that room to allow all stuff there correctly adjusted to the new rom.

  • simms22

    the incompatibility that you wrote about while using current aosp code, and gapps, is fixed if you use odexed gapps. stock roms run odexed gapps. and many android custom roms ask for deodexed gapps because they save space and can be themed. if you switch to odexed gapps, ART runs fine on aosp.

  • motoridersd

    I tried this on my Nexus 5 and my phone got stuck in a boot loop after. Looking at logcat I noticed some errors about mm-camera exiting, along with mediaplayer and others. Over and over. I flashed the stock system.img to the system partition and that got me back online. Not sure why this happened. Does anyone know how to switch the runtime back without having to re-flash the system partition (and without being able to boot)?

    • http://stevenhuang.ca/ Steven Huang

      What modifications if any were made to your Nexus 5 prior switching the runtime?

      • motoridersd

        I had TWRP and I was rooted. Flashed TWRP into recovery, and used SuperSu's latest zip to root. That was it. When I flashed the system partition again, I did boot in ART mode. Whatsapp was crasing so I switched back to Dalvik and all went well.

        • jurrabi

          mmmm. I wonder why.

          If I was to test this (I don't have a N5 :( ) I would start with a clear factory rom (nothing installed and of course no hacks).

          Then If success (hope so if the option made the cut to the rom) I would go and install my apps one by one from store. No root, no superSu, no advanced stuff...

          Just mundane stuff.

          I would say you cant have yout kick-ass full optimized daily use phone ready to go with this experimental new heart of android.

    • Luis Paredes

      Hi... I have the same problem. Can you please tell me where did you get the stock system.img. Thank you

  • BrianLipp

    Im going to guess that this is one of the things that Google is waiting for before they give Android the big 5.0 update, which is why KitKat is still 4.4.

    • jurrabi

      So true.
      With google taking out everything from android into play apps, the things android itself might improve where getting less and less.

      This is the "REAL BIG THING" that 5.0 will have.

    • cyberkeeper1

      i fully agree. :)

  • ConCal

    This is why I love this site the most. In depth!

    • Brandon Watkins

      so true!

  • paul4id

    Can't believe it isn't like this already. Never ever saw the point in JIT, right back since the start when Java was the in new thing in the late 90s.

    • jurrabi

      If you asked me, I never thought java would be what it is today.

      But I guess portability won the war against performance. I guess everybody said "we'll have faster machines, so who cares about performance?"

      For me having a machine code programmer background I find it very hard to buy... So I'm happy to see this kind of steps.

      • dnebdal

        JIT works well on long-running processes, though - and I would guess that describes most of the java code written today.

  • Dioma Paul Puyat

    How did you enable that? I can't find it in the developer's options.

    • jurrabi

      Only for 4.4 eyes.

  • Matthew Morrison

    But... but... 4.4 just came out (I can finally go on with my life without checking about it every 5 minutes) and you guys are already trying to hype 5.0? The cycle never ends : (

    • http://stevenhuang.ca/ Steven Huang

      ART is a different runtime than the Dalvik interpreter that is currently used in android devices. Anyone can try this runtime out on 4.4 kitkat.

  • ανώνυμος

    Curious, once 4.4 comes out for the Moto X, would it, if not already, run apps as efficiently as some of its quad-core competitiors?

  • Joseph Lee

    Can report that Titanium Backup is force closing after switching, anybody else experience this?

    • Adam

      Yes, also Whatsapp does not work :/

    • cyberkeeper1

      i can confirm that TB does work if you manually install it from the play store AFTER clearing all caches and enabling ART, followed by rebooting TWICE. Trust me it works. i use an SGS 3 from VZW.

  • Jason Bailey

    Maybe AOSP Roms have problems at the moment because they haven't been build using to use ART


    "Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and the ART (libart.so). A device can be built using either or both. (You can dual boot from Developer options if both are installed.)"

  • http://CatReligion.org/ Bast Hotep

    "ART is set to change this process by pre-compiling that bytecode into
    machine language when apps are first installed, turning them into truly
    native apps. This process is called Ahead-Of-Time (AOT) compilation."

    I would call that compilation. period.

    • SterlingMaloryArcher

      Well AOT is definitely what we call it in the biz. It's just one of those things.

      In general order from fastest and least flexible to slowest yet most flexible:
      Pre-Compiled (on the dev's machine - iOS), Ahead-Of-Time (on the client before running - ART), Just-In-Time (on the client at runtime - Android 2.2+), Interpreted (never compiled - old Android).

      I think AOT really hits the sweet spot for the Android ecosystem.

      • jurrabi

        I don't totally agree with your classification.

        Pre-Compiled and AOT are nearly the same.

        The only difference is the time to do it. In the first case developer compile before distribution time and with AOT is the phone.

        The tools and resuts will be the same for 99% of the apps/developers.
        The only difference will be in the compiling options/optimizations selected by the developer (if done) that can be tutored to get the best possible result in a particular applictaion.

        But those compile time options are:
        1. Used by very few developers that know what they are doing.
        2. The compiler tendency is to leave those decisions to compiler "intelligence" to identify best options for each app, and that can be said for equally for pre-compilers or AOT compilers.

        So while I guess being totally purist your distinction between what pre-compile and AOT compile would generate can be distinguished in terms of performance on some (very few) cases, on the general case they won't.

        • dnebdal

          Keep in mind that android runs on multiple architectures - 32bit ARM is by far the most common, but there are MIPS and x86 phones out there, and I expect 64-bit ARM will start showing up soon.

          AOT frees the developer from having to compile for all current and future archs, while precompiling would require very fat binaries.

          • jurrabi

            Or transparent download options in the play store ;)

          • dnebdal

            Well, sure - but then you increase the amount of packaging and signing required. (And the developer still has to compile for everything, including platforms that might not yet exist.)

          • jurrabi

            True. I guess that's not a real option.

          • dnebdal

            Well, it works well enough for apple - but it'd be kind of a waste to lose the architecture independence. :)

        • apomk2

          There is a difference for developers, because handling binary dependencies on iOS for all required architectures (x86, 32bit, 64bit) can be quite a bit of a pain already.

          There are also considerable advantages to delaying compilation as much as possible, which is why JIT is still king on servers. It allows you to recompile your code at runtime depending on its runtime behaviour, which is something Java (but probably not Dalvik) makes heavy use of. For example, you can inline virtual functions you normally wouldn't be allowed to inline, because you know how the function is actually used, not just how it is defined.

        • ari_free

          Install time also matters and people will still complain that it's slower on Android. For what? For the 5 people with x86 phones? I just don't see the point.

          • jurrabi

            The point is having all (except installs) going much faster...
            I would trade install time for launch/use time with my eyes closed anytime...

    • jurrabi

      And you would be right. But the term AOT comes to differentiate the classic precompilation to JIT (just in time) Compilation.
      And I think it is a necessary term.

  • kpbird

    What is core agenda of moving JIT/DVM to ART/AOP? Is it business decision or technical ? Is google reducing dependency from JAVA ? Is it because of issues with Oracle ?
    Does any one know the real purpose of moving to ART/AOP ?

    • jurrabi

      I would say no.

      Apps will still be developed in Java and distributed as Java bytecode in apks. So no separation from Oracle technologies there.

      This is just the next logical step when Google realized that there is no way to keep improving performance while on a Interpreted paradigm.
      Compilation is the way to go if you want noticeable improvement in performance (and battery life).

      • Oletros

        Apps are not distributed as Java bytecode, they are distributed as Dalvik bytecode

        • jurrabi

          Thanks for the clarification.

      • kpbird

        Let assume that ART/AOP become mature after some time. What will be the next logical step ? Will google keep Java bytecode /dex in APKs? I think after maturing ART/AOP format Google will provide tool in sdk that will directly generate ART/AOP compiled code which distributed in APK. Right ? It's clearly indicate that Google is removing dependency from Java, they take bottom up approach.

  • AmazonOffer
  • Sir Perro

    If google manages to get ART running by default in Android, and the system updates are modular, available through Play Store, effectively avoiding fragmentation, iOS and Windows Phone would howl for hours at the full moon out of desperation.

  • Chris Caldwell

    Im running this now on my N5, and its fantastic. Id like to see a re-test with the guys that tested touch response times in android phones and iphones. The iphones did better but the assumption was that its because the app they made to run it was native while android is interpreted, but with AOT compiling it would be interesting to see.

    • animaonline

      Current versions of dalvik VMs are not interpreted, they JIT compile the code when the application is launched

      • Sir Perro

        They still run over the Dalvik VM. I guess ART does AOT compilation to native code, otherwise it wouldn't be ART, it would be a Dalvik optimization.

  • Antartica

    I supose that this is related to last year Google acquisition of FlexiCore (the makers of DroidBooster).

  • Android Developer

    Does it mean that for each APK, it will take both the original code AND the compiled one?
    Does it change the APK file in any way, or does it create some files on the system that will be launched (like what is saved as the bytecode) ?

    If so, it means that backups and sharing of APKs are still ok, yet apps would take more space than needed, right?
    Now that I think about it, there is the code inside the APK, and the bytecode that was converted, so if the bytecode is replaced with real native code, wouldn't it mean that the change in size is negligible ?

    • jurrabi

      I would imagine (without real insight of the actual decisions made by google) that apks won't be touched, since that is signed with private keys the phone doesn't have (and shouldn't).

      I would bet that compiled code will be stored in the phone on some other place and the process to lauch the app with search for that and (if not found) compile at that poinng.

      The fact that android will do a frist all-compile or after-install compile is just to avoid a longer first launch of each installed application.

      But verification that apk-compiled binary correspond I'm guessing must me done on each launch, to avoid corruption or possible attacks.

      But again, this is just guessing on my part.

      • Android Developer

        I see, but talking about storage, isn't it about the same size already? i mean, on the current state, each time you run an app for the first time, android does some kind of optimization and creates its own files for running it (hence we have "dalvik cache"), no?

        Also, i wonder if it will be possible for developers/users to choose which apps to optimize this way and which won't.

        • jurrabi

          Dalvik cache is that, a cache. By definition that means that anything put there can be wiped to make room for some other stuff (another app that needs to run) so when you run again the original app the JIT compiler acts again.
          I would think that ART wont work this way and store complied apps in a more permanent fashion, aka the more space needed.

          But again I wouldn't (and I won't) worry about that. It's not all the app size that will be compiled.

          • Android Developer

            but it's a cache of the dex files, which are bytecode of dalvik , no? look at /data/dalvik-cache . they are already pretty large for the large apps.

          • Björn Lundén

            It's a cache of odex files, the result of DexOpt. They will remain until the dex file they were compiled from is updated.

          • Android Developer

            why would you need them if ART compiles the code to native one ?

    • jurrabi

      Forgot to say: what I'm sure they wouldn't do in any case is replace bytecode files with binary files.
      Those are different things and will have different extensions.

    • Björn Lundén

      No, the APK will remain unchanged. The OAT step is more like DexOpt (the step that produces odex files) in that regard. It runs during boot and compiles the dex files to oat files which contain both the dex file and the newly compiled code inside them. These files are stored in /cache as far as I know.

      • Android Developer

        ok, but now we have those dex files, and if we use the new ART method, it will be replaced with real compiled files, so it will take about the same size (and maybe even less) , right?

        • Björn Lundén

          No, none of the files in the apk can be replaced since that will break the signature. It would also remove the ability to do the incremental app updates in the Play Store that Google rolled out some time ago.

          The oat files will be created and placed somewhere else where ART will look for it and use it instead of the dex file, just like how odex files work for Dalvik.

          • Android Developer

            i didn't say it will replace the files within the apk. currently for each app, android just decompresses the dex files and optimizes them , and put them into its cache. if ART will be used, those dex files aren't needed anymore and can be replaced with ART files.

          • Björn Lundén

            Right. I misinterpreted what you wrote it seems. :)

          • Android Developer

            OK. no problems.

          • NoonianAtall

            No, they can still do delta updates to the APKs, but the entire APK will have to be recompiled afterwards.

          • Björn Lundén

            It would break the signature. Regardless, APKs installed on the device are never modified after install (except by updates). Any form of operation like DexOpt or OAT conversion just generates an optimized copy.

  • Dave

    Ahahaha Awesome! The trolls born with lag ion their head will finally be gone!

  • jurrabi

    One other (of the few) drawbacks of AOT Compiling is that developers will start to get bug reports that they can't reproduce due to issues with compiling for a specific architecture. So developers will need to test apps on even more scenarios.

    But again, and from my perspective, this approach is the real way to go. Java, while great for portability, is a really hard sell when it comes to the power required to run.

    Java (JVM in fact) is to blame when your 4 core ultra power cpu powered phone takes an eternity to launch each app.

    ART will for sure help with that and general phone smoothness. And 1 time tasks (like installing or initial compiling of all installed apps) taking longer is (in my opinion) a good compromise to get all-time tasks (daily phone use) smoother...

    • NoonianAtall

      My understanding is that this is basically running the JIT ahead of time on all of the code at once. I don't think architecture-specific bugs will be a problem, because the JIT already does that, just not upon app install.

      • jurrabi

        I don't think it is the same. JIT compilation has to be ultra-fast, so no time for complex optimizer algorithms that a general compiler (not so constrained by compiling time) can have. And this same optimizations (some times very architecture dependent) are the ones I think can cause architecture-specific trouble.

      • cyberkeeper1

        yes and no. The only issue with JIT is that it compiles data to the interpreter all the time, every time, and the dalvik cache is used yes, but is always being modified as code changes (or you blink at it... haha) or the app is updated. For AOT, this is not happening nearly as much, if at all. the code should only change if an app update specifically calls that function. This is why AOT is more long term reliable. As far as arc-specific bugs, most devices (if not all) run the ARM processing type, not x86. so really worrying about a specific type of bug isnt really an issue. The issue is most always chipset based and where each physical memory block device is mapped to and so on. every device has their specific physical mount point in the /dev/block or respective area. :)

  • bL4Ck

    Switching now to ART, let's see how it perform on my brand new Nexus 5.

  • Jeffrey Smith

    Does anyone know, or can someone check if this works in the emulator?

  • http://www.techyclick.com/ Techyclick

    The most popular apps for android for year 2013 check this out for more info on techyclick guys http://www.techyclick.com/the-most-popular-apps-for-android/

  • Just Another Nexus Owner

    Google Play should be able to pre-AOT large popular apps for popular devices. Or maybe just Nexus devices... :-)

  • mgamerz

    The nice part of this is that it will likely work pretty well for existing apps. Since it likely will compile in the same way Dalvik does, just with further optimizations, so the code should run near the exact same as it does now (nothing devs should have to do to make ART work better), just better. Wonder if this will make the NDK useless?

  • http://www.facebook.com/profile.php?id=1375644377 Dave Bucci

    My first thought was that this was targeted at non-phone devices ... part of the drive for less resources. Has there been any discussion of the impact on such use cases?

    When running Android on the front panel of my fridge, anything that can reduce the excess CPU heat is welcome :-)

  • http://wigasanggak.tumblr.com/ Wigas Angga K

    I hope someday google integrate greenify feature into android.

  • Knowles2

    Google ART sound good, Couldn't many of its shortcomings be solve by using JIT Davik when the app is initially installed and switching it over to ART AOT when the device/app is idle and not being use?

  • pentiger

    I switched to ART on my Nexus 5 and I now regret it. Before in Antutu I had 29555 after switching to ART I benchmark-ed at 15500 I was disappointed and actually I noticed lag and skips when scrolling webpages on ART so I switched back to Dalvik and now benchmark shows 16200. WTF!!!!

    I will have to do factory reset now.

    So if anyone plans to do it on their nexus I highly NOT recommend it.

    • HotelQuebec

      Clear your cache from recovery before doing a factory reset.

      • pentiger

        I did not install custom recovery. I don't know if I can do it in regular recovery. besides I already restored it.

        • cyberkeeper1

          stock android recovery (3e) does have a clear cache and factory reset option. pressing volume up + volume down enables the otherwise hidden menu when accessing recovery.

  • Luka

    Tried starting my Nexus 5 with ART and Dalvik startup time was exactly 20 seconds on both

    • cyberkeeper1

      startup time isnt affected. its apps that are affected.

  • Lucas

    I was thinking about the increase in install time and then I wondered if Google wouldn't be able to pre-compile the apps for the most used architectures and deliver specific apk files for each different device.
    Actually that's how NDK apps work, I guess. The same way a x86 PC can compile C++ to ARM and PowerPC through NDK tools, I guess Google could run the ART engine in its servers to compile dakvik bytecode to ARM, PowerPC, x86 and all their (most used) variants.
    If my assumption is wrong, please correct me.

  • Simon Hall

    I think your estimate of 10-20% overhead due to native vs. byte code is misleading. In particular, the byte codes must be kept around (otherwise you wouldn't be able to switch back to Dalvik without re-downloading all installed apps), so the overhead is more like 110-120%. And having worked on the .NET Runtime for 13 years, which has a similar technology called NGen, I suspect the size increase in the native code will be greater.

  • Emanuele Ricci

    Is it just me or Whatsapp crash when you switch to ART?

  • Dey Anand

    am unable to use ART :( My gapps are crashing....help pls !

  • Nitinart Nunthong

    very good article. I can't wait for a factory image of android 4.4 for a nexus 4. Wonder when will it be released

  • batmobil

    Funny, since when JIT was introduced long time ago, all developers where so enthusiastic about how that would make code run even faster than precompiled code, since the JIT compiler would know more about the state of the program upon compilation. Now all developers are enthusiastic about going back to basic again, for the same reasons... :)

    Personally, as a developer, I always favored precompiled code, and I am glad to see this is becoming a viable option for Java on Android.

    • jurrabi

      Not all the developers where enthusiastic about JIT. Here's one.

    • cyberkeeper1

      as both as user and creator, i also prefer precompiled. i extremely dislike building native code... >_<

  • cmshephardms23

    new lag free android is coming, can't wait for it

  • Sharique Abdullah

    Don't you think this would bring some implications for app developers; for example on Debugging (breakpoints, watch, debugging code etc), as well as stack traces, and error reports? And for the same reason I think when enabling ART, instead of the whole OS entering ART mode, it should be applications entering ART mode. Thus my debug app does not enter ART mode. No?

    • cyberkeeper1

      its still java and will still have all that info. its just that its not compiled on the fly. its during app install. this means that any errors are logged without the compiler running. that also means it can log faster if problems occur.

      • Sharique Abdullah

        Hmmm may be. But I have a little bit of doubt on that. Cuz it's either Java or pre-compiled native code; It can't be both. No?

  • http://aidan.info.tm/ Zack Casey

    My biggest criticism about Android is finally being answered. Honestly, I tend to prefer the native route as much as possible. So to hear Google is finally answering this issue is a breath of fresh air.

  • Kent

    I turned ART on for my Nexus 5 (16GB), let it optimize, reboot, and then it promptly crashed two of my apps: Whatsapp and Battery Booster. Can I still turn it back to Dalvik? Thanks!

    • cyberkeeper1

      battery booster is a battery waster. so is ALL other task killers out there. it takes CPU power to gain CPU space and memory available. you're spinning your tires and not moving if you use those kind of apps. it really does not save any battery. in fact, some of them have caused a worse battery life. whatsapp just sucks anyhow and the developer needs a swift kick to get him or her to make it work. there isnt a whole lot to the app.

  • HotelQuebec

    ART offers a significant performance boost and is the future. I've enabled it on a Nexus device and giving up a few apps that aren't compatible with it while pushing those developers to make it compatible with ART.

  • Memphis May [S]unjay

    My apps crashed in Cyanogenmod 11

  • AJ Salazar

    I'm using art right now on my Samsung s3 using hellfire kitkat rom. Working great so far

  • Neoliberal Agenda

    Om vi vore lite smarta så skulle vi avskaffa kapital- och bolagskatter så vi lockar till oss företag från andra länder.

    Idag drar staten in ca 120 miljarder via dessa skatter. En hel del skulle staten få tillbaka direkt vid ett avskaffande. Pengarna rinner inte ut ur systemet, de tas bara in genom andra skatter. Det underskott som trots allt skulle uppstå (innan fler jobb och ökad produktivitet slår igenom) kan lösas genom att staten säljer ut en del statliga företag och slutar subventionera a-kassan.

    • cyberkeeper1

      i cannot read this language...

  • MrKitten

    I have android 4.4.2 on my Nexus 4 And I want to change to ART. After rebooting my phone nothing changes, I have still the Dalvik.. Anybody can resolve this issue? Btw, sorry for my bad English :)

  • LiTTle

    I am using CyanogenMod ROM with ART. Every time I update the ROM to a new nightly is painful because ART is recreating the binaries and I have to wait a lot.

    This guide saves a lot of time at each update:


  • Faiz Rocketeer Ahmed

    Check this video out it is only 3 and so minutes to learn more about ART!

  • sirinath

    How about optimisation of the current runtime

  • Deepak S

    Awesome thread :) I just switched to ART, hopefully :D

  • JayQ330

    I just updated to Android 4.4.3 on a nexus 5 & it took 5 minutes to turn 69 app's to ART, I also noticed that Android 4.4.3's converted all my apps to ART on it's own. So I'm wondering if Google had already decided that ART is ready to be used as it's native runtime, I always left it to use Dalvik *I went ahead & read some comments about how some users Android ui "jitters" I never had that problem on my nexus 5 but did on previous phones, but that's a thing of the past for the last 7 months I'm my experience* until it was confirmed ready for primetime, so would 4.4.3 using ART by default mean just that our am I the only one that the update decided to use ART? anyone that updated to 4.3 please tell me if you were still on Dalvik or changed to ART. Thanks!

  • Ayi

    I'd try ART in my LG D325 last night but but it doesn't work,I don't know why?now I have a problem because I don't know what to get back to DALVIK .i can't use my android phone now?pls tell me what to do?thanks

  • Bill

    ART is set to change this process by pre-compiling that bytecode into machine language when apps are first installed, turning them into truly native apps. This process is called Ahead-Of-Time (AOT) compilation.

    Uh.... Isn't this kind of a no-brainer? Why have they been doing it in a convoluted inefficient way for so long?

  • http://limbanibhavik.com/ Limani Bhavik

    All the aspects of KitKat cover..
    And also this is very good knowledge for beginners...

    If any one want an PPT for Presentation of that DEX vs ART then ...
    Visite Slideshare... :- http://www.slideshare.net/limaniBhavik/artaot-vs-dalvikjit
    Visite : - http://www.limbanibhavik.com/2014/10/art-aot-vs-dalvik-jit.html

  • http://limbanibhavik.com/ Limani Bhavik

    ART really better then Dalvik..... if we worked on both....