I haven't seen any final version of ART yet, all just beta and preview versions. Even the version included in the latest emulator image (labeled "Android 5.0 / API 21") is at least a month old, or at least didn't include some of the commits of the master branch. Speaking of source code: It's still changing a lot. I wasn't able to build libart.so from source for the emulator as the included commit range is unclear (actually their Lollipop branch might be different from master, so knowning a date might not be enough). It's pretty hard to shoot such a fast-moving target. I hope that once a final version is out and the source code for is published (with a proper branch), changes will slow down a bit - and hopefully, vendors will use it pretty much unmodified.



I think I mentioned before that I had an early proof of concept for ART working in December. As I expected, many things had to be changed for the first L preview, and even then it didn't work. ART != ART. You may also have noticed that I haven't been here and didn't work on Xposd for the past three months for various reasons. I still don't have time and motivation to work on Xposed as I used to, but I'm slowly starting again (no promises though).



Last weekend, I started to try out a different approach, where I would make a few changes in the ART source code directly. This seems to be working much better and cleaner than trying to hack it from outside (especially because ART is much more complex and using many classes, templates etc. which are hard or impossible to work with). It also ensures control over the many variants it can be compiled with. The downside is that this would require replacing libart.so and libart-compiler.so on the system, and nobody knows whether vendors will build their ROMs with source code that is similar enough to AOSP to make this exchange possible. Then again, a library compiled against AOSP source probably wouldn't work with those ROMs either, as offsets etc. would be different.



Keep in mind that most of you are mainly interested in getting Xposed for Lollipop. ART is not the only new thing there, also SELinux is much stricter there, blocking many things required for Xposed. Not sure if there will be a different solution than disabling SELinux or exchanging the policy, both of which would probably require flashing a custom bootimage/kernel. But I'm not even thinking about this in detail yet, nor about different ways of installing Xposed (might be rather manually for the beginning). And I have no plans to use the Material Design anytime soon.



When I find the time and motivation, I will try to work on ART support. I will probably not be here and report about it though. When I think the time is right, I will publish my work-in-progress source code for others to help me (which requires a good understanding of advanced topics such as assembler/bytecode, so I'm afraid there won't be many people who can help). I consider everything I have done with ART so far as training - getting familiar with the source code, experimenting a lot, getting frustrated because it doesn't work most of the time. On Kitkat, ART is more or less a gimmick, most important it's optional. I might build an Xposed version that supports ART on Kitkat later if it can be maintained with little additional effort. If it's too different from the final ART, it will stay a proof of concept.





So in short: Wait until the final images and source code drop. Then wait again until it's ready. I can't give any estimation when that will be the case, it depends much on my personal situation. Chance are pretty low that it will be within a month after Lollipop release, and will get higher once I start thinking about flashing a Lollipop ROM myself (which would probably be CM12, and I think these guys won't give us a timeline either, for good reasons). I'm still not 100% sure Xposed for Lollipop will work, but I hope that in some way it will, even if it might not be as compatible with most ROMs and as easy to install as it is for Android 4.x.