But with that in mind, it is unclear from the posts I've seen why the list of available apps is currently so small and why working closely with Google is required to get your app up and running right now, perhaps this is just due to the runtime being very much in active development and not supporting the entire set of Android APIs yet.
> perhaps this is just due to the runtime being very much in active development and not supporting the entire set of Android APIs yet.
Probably this: its in beta, so they are probably working with individual, high-demand apps to assure that they work (and by doing so validate the runtime itself) to manage the scope of potential consumer-facing bugs.
My guess is that some app manifests might have to set tighter compatibility restrictions, and would run, but poorly, on this environment.
Non-game, non-SDK apps that don't have required accelerated visual transitions are probably the best candidates. But that's not a situation most developers are explicitly coding and testing for.
Based on the apps listed, and on some other surmises, I'm guessing that apps that don't use the NDK and don't use 3D graphics will run pretty easily, and many of them should Just Work.
I was involved in a project that did somewhat similar things. I think Google got it right by doing a release that restricts apps to ones that use certain capabilities, particularly since, in Android apps, those capabilities are declared and can be filtered using the app manifest. Making GPU acceleration work in a system with a "hybrid graphics stack" instead of layering Android's 2D graphics on a native substrate is a ton of work for an incremental (albeit an important increment) gain.
It is not a rewrite, according to the I/O keynote it is the native Android app (maybe with some minor changes).
I would be curious to know how it works exactly. Did Google write a port of Dalvik/ART that runs on ChromeOS ?
