There must be a metric that defines the ratio of how important something is compared to how obscure it is. If this ratio is not named yet, I am claiming it. And using this new D2D ratio, I want to point to a Google announcement last week that is off that scale. In an out-of-the-way posting on the Android Developer site, Google now has a posting called “Introducing ART.”

This is a site for developers, and it has links to source code. So it is not a place to expect marketing spin, or even explanation. Here is the code, make of it what you will. They do not even explain what ART stands for, although it seems likely to be “Android Run Time”.

And so begins what we think is going to someday be a major shift for Android and its developers.

So let’s back up a bit. What is a run-time and what is going on? Phones have chips in them, those chips operate with 1’s and 0’s. As very few humans speak binary, modern computing systems have operating systems (OS) that run on top of the chips. Humans type in some programming language, and the OS translates that into binary. Sounds simple, but this is actually a layered process. Once you add one programming language, you can then add more on top of that, so that one language translates into a second “lower” language which then translates into binary. There are a variety of reasons for doing this, which essentially boil down to a trade-off between ease of use and efficiency, with a few other factors to weigh.

The Android OS is one of those multi-layer things. Programmers write their apps in Java. This Java code then runs on one of those middle layers where it is translated into “bytecode”, and this in turn is translated into machine readable language for the chips to execute. In Android that middle layer is called Dalvik which was created when Android was just getting started, before Google acquired them. The idea behind Dalvik dates back to the days when there were no common OS for phones. Every phone (and we are talking about mostly feature phones back then) had its own OS. For instance, Motorola had something like 20 OS. We call these an operating system, but really they were much more basic than a true OS, they were just virtual shells which executed code. That is just one, albeit important, piece of an OS which we call a run-time. And the idea was programmers could write code to execute in Dalvik, and then someone else would handle the part that translates Dalvik bytecode into code that runs on each phone’s different run-time.

Fast forward ten years, and Android is pretty much everywhere (except where there is Apple’s iOS) and Dalvik is showing its age. Developers have never really liked Dalvik. It is one of those small but annoying things about coding for Android, not enough to keep people away but trouble enough that Android apps just do not look as good as iOS apps. To their credit, Google has made steps to fix this problem. They released a JIT compiler and the PDK a few years back, which were a layer on top and a layer below Dalvik respectively, but neither really solved the underlying issue.

With ART, Google looks to be getting ready to someday entirely get replace Dalvik. The ART site describes today’s code as “experimental” which we interpret as an Alpha version, or even a pre-Alpha, so there is still a long way to go. But that should be taken with a degree of caution. Google looks at engineering differently, they pioneered the practice of software that evolves quickly. It may be experimental today, but in the not too distant future it will be real, and has the potential to be very important.

Google has said nothing about ART other than what is on the link above. We think there are three possibilities as to why they are launching this. First, this could be a legal maneuver. Dalvik was part of the Oracle lawsuit, and some people think it infringes on Oracle’s Java intellectual property (although a jury saw it differently). So by replacing Dalvik with ART, Google may be attempting to un-encumber Android from one of the many legal fronts it is now fighting on. I think this may be a factor, but is probably not the main objective.

A second possibility, is that Google is looking to optimize Android and improve the underlying OS in many ways – make it faster, easier to use, etc. This should help developers in the long-run, but it will be an uncomfortable transition. I see this is the base case, the very least of what they are trying to achieve. So far there has been very little discussion of ART on Twitter or in the blogosphere, but the consensus in those communities seems to hold that the objective of ART is deliver faster code execution. GigaOm and Android Police both posted good overviews of ART. They both highlighted that with ART, apps are compiled or translated when they are created. Currently apps are translated into bytecode when they are opened by the user, so compiling ahead of time saves that intermediate step and speeds up the app.

This makes sense, but we think there is a third possibility here. This could very well be Google’s attempt to move to a much more web-based world. As readers of this site may have seen, the idea of web-tools or HTML5 eventually supplanting ‘native’ code is something that is much talked about in the industry, but has proven very hard to deliver in practical terms. There are hints that this is where ART is going. This would blur the difference between a web page and an app much further, and conceivably make web pages as responsive and useful as apps are today. One person with in the web tools community we spoke to about ART instantly jumped to this conclusion. It seems very possible that this is the ultimate destination for ART. And quite possibly, along this path, Google will be able to merge its Chrome web and Android operating sytems.

If this is true, it will mark a major transition in the industry. Again, developers will struggle with this. It will require them to re-write all their Android apps, and open up the debate about how much backward support they will have to provide to older versions of their Android apps. The ART posting warns of this:

“Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.”

Our opinion is that Google has always been deeply ambivalent about app developers. They recognize they need them for Android to succeed, but they do not like native apps like you see in iOS. There are both philosophical and strategic reasons for this, but ART as a web run-time would speak loudly to their true intentions.

Now this could go nowhere. Google has tried this before, and they are being very low-key about this which may something about their confidence in ART’s prospects. But it could equally mean that they know big changes are coming and they want to start early and small to get people prepared for the big transition ahead. We could make the analogy with a work of modern art, it’s always hard to tell what is a major work and what is just a red square painted on a canvas, but that analogy is too easy to make.

Instead, we would just caution everyone to pay attention to this. The future of mobile, of the web, and of computing itself, will be fought like this in small announcements in obscure corners. That will not dampen their eventual impact.