Well, continuing to run legacy apps efficiently is almost certainly a requirement. Presumably it's also a requirement for them that the Java semantics easily and efficiently map to their program representation.
An AoT compiler instantly makes everyone's favorite Android apps start faster, and many of them run faster, without having to wait for (sometimes defunct) publishers to re-compile the apps.
A static single assignment representation that matches the Java semantics, such as Michael Franz's SafeTSA, would be better than Dalvik bytecode if they're going to do install-time generation of native code.
In any case, I hope they continue to promote architecture-independent distribution formats for apps and libraries. I've said for a while that I think compiling directly to native code is going to eventually be treated like we now treat hand-written assembly... a last resort for small pieces of code that need speed and have been found to not be efficiently served by more abstract tools.
An AoT compiler instantly makes everyone's favorite Android apps start faster, and many of them run faster, without having to wait for (sometimes defunct) publishers to re-compile the apps.
A static single assignment representation that matches the Java semantics, such as Michael Franz's SafeTSA, would be better than Dalvik bytecode if they're going to do install-time generation of native code.
In any case, I hope they continue to promote architecture-independent distribution formats for apps and libraries. I've said for a while that I think compiling directly to native code is going to eventually be treated like we now treat hand-written assembly... a last resort for small pieces of code that need speed and have been found to not be efficiently served by more abstract tools.