Dalvik and ART both generate native code. ART does it at app install time and Dalvik, being a JIT, does it at app runtime. He was speculating about quality of the generated native code, not its existence.

Google has been very quiet about ART generated code quality. I haven't found any benchmarks that would compliment its performance either. It's probably better than Dalvik but worse than mature optimizing compilers.

I don't think they have been very quiet about ART. They had a whole I/O session and they recently dedicated a whole dev backstage podcast to ART and its future evolution (btw, some nice things are planned : suppression of the 65k limit, code hot-swap, ...).

Native does not always (or even often) equal optimal. Plenty will still be left on the table.

20 or more years ago there was a peephole optimizer that looked at generated Turbo Pascal (and other not so advanced (for their time) compilers) and rearranged instructions, removed holes, replaced instructions with better set (turns out some of the "macro"-instructions were not that fast).

Nowadays calling a .so/.dylib/.dll function, or accessing a thread-local variable also generates lots of cruft code that could possibly get optimized once the data is loaded. It won't always work (shared libraries can't be unloaded, but with enough hints, or assumptions that this would never be done, one can gain some benefits). On the negative this may reduce the code-sharing across processes.

Some people have problems to distinguish between languages and the multiple ways they can be implemented.

The fact that ART makes use of dex bytecode as portable executable format[0] complicates the matter for those not versed in compiler design.

So people see bytecode and think managed, when a bytecode format doesn't have anything to do with being interpreted or compiled to native code.

[0] An old idea that goes back to the mainframe days and used by quite a few other languages.