*If* I ever support ART on KitKat, then I wouldn't want to maintain two totally different codebases.
I agree with @tonyp
that sharing uncompiled code source for other development is a good idea, actually quite clever (fends off the hungry trolls - "if you give a mouse a cookie..."
well same goes for some users, except its a much longer book and has the same characters saying saying similar or identical things only pages apart.
A benefit of this is that you may be able to find peoole willing to act as maintainers after a working compilation is created for the kk ART.
kind of like a port-friendly version for the devices that don't get developed officially or not past 4.4.
This would benefit in more than one way, users of devices that will not see development development past kitkat, while freeing you from too much overload if you were to covrer dalvik, kk ART AND
the hopefully final runtime in the next official release.
I actually never knew L's runtime differed from the ART on KitKat, i thought kk's runtime was experimental in that they wanted to prepare developers for its future implenentation, rather than it was in experimental form its self (even though i read the cautionary explanation when switching to it in dev options) are there differences in dalvik runtimes between builds, as well?
---------- Post added at 11:52 AM ---------- Previous post was at 11:42 AM ----------
Originally Posted by Bronto9
Why don't you keep L as a secondary rom(with MultiROM)? By doing so you can test xposed on L, and then switch to kitkat when you need your phone.
Seems a little too easy to me...
from what I've read and experienced, nothing is ever easy
when it comes to debasing, not even testing...plus multirom is another variable that isn't necessarily stable and "L" can be a pain in the arse as a secondary rom with 4.4.4, as the user data can conflict with 4.4 when using L.