Existuje hromada technik, jak řešit přenositelný kód. Nemyslím, že by kompilace v zařízení byla sama o sobě takový problém. (Nemyslím dokonce ani, že by JIT měl nějakou principielní výhodu oproti AOT. Existují koneckonců prostředí, ve kterých tyhle věci tak nějak splývají, jako je třeba Common Lisp - kompilace od úrovně funkce přes soubor/modul až po uložení celého programu do mmap(2)ovatelného image. A existují i JIT implementace pro Javu, co umějí zkompilovaný kód cachovat. Ale to je zase na jinou diskusi.)

Pokud jde o AOT a kompilaci u spotřebitele, tak třeba už v polovině 90. let vypracoval Michael Franz koncept "slim binaries", což je vlastně přenositelný mezikód, který se kompiluje při instalaci nebo při zavádění. Přitom odložené generování nativního kódu je právě že docela žádoucí: umožňuje například vynechat masivní inlining statických knihoven a místo toho přenášet aplikaci v kompaktní formě, ze které se nejprve vygeneruje počáteční binárka, která spoustu optimalizací odloží na dobu, než se ukáže (profiling feedback), že jsou vůbec užitečné (spousta optimalizačních kroků totiž vede na kód, který může být buď rychlejší, nebo pomalejší, a často se to nedozvíte, dokud to nezměříte). Náročnější rekompilace kódu (jakmile má runtime změřené hotspoty) se dají provádět třeba v době, kdy máte mobilní zařízení v nabíječce. Navíc různá zařízení mohou mít různé verze nebo sestavení operačního systému, takže buď bude repozitář poskytovat optimalizované binárky pro každou verzi OS zvlášť, nebo je třeba rezignovat na optimalizace rozhraní mezi aplikací a systémovými knihovnami a jít pesimisticky přes calling conventions dynamických knihoven (což kus výkonu ubere), nebo se aplikace přenese v přenosném mezijazyku a sestaví s místní verzí knihoven až v zařízení. Nemůžu si pomoci, ale po technologické stránce se mi ta poslední možnost z mnoha důvodů jeví jako nejrozumnější. Viz paper "Continuous Program Optimization: A Case Study" od Franze a Kistlera.

Tyhle věci šly rozumně dělat i v devadesátých letech (a to tehdejší typický počítač byl mnohem pomalejší, než dnešní mobilní telefon), tak nechápu, proč by to nemělo jít dnes. Jako základní problém Androidu vidím, že přinejmenším ve starších verzích musely nativní aplikace jít přes JNI, když by to správně mělo být přesně naopak: rozhraní pro nativní aplikace by provozovalo nativní aplikace, a pokud někdo chce psát v Javě, byla by to prostě knihovna navíc, která by z javovské aplikace (po mírné transformaci) udělala nativní binárku.

"A bezpecnost a sandbox sa da v pohode vyriesit aj bez VM. Prave naopak podla mna VM vytvara iluziu pocitu bezpecnosti pritom aj tam sa to da zneuzit."

Chráněný mód vašeho procesoru, který izoluje jednotlivé procesy není nic jiného než forma VM. A kdyby Google chtěl, určitě by mohl do Androidu napasovat něco na způsob PNaCl: možnost přenositelně provozovat většinu současných jazyků v plné šíři jejich funkčnosti (s výjimkou těch, které rády generují kód za chodu, takže vývojové prostředí pro Lisp nebo Smalltalk byste na tom nespustil, ale hotové programy v jazycích od Cčka přes C++, C#, Javu až třeba k Ocamlu nebo Haskellu by nebyly sebemenší problém), a to bez nějakých obětí na výkonu.

Priama podpora Javy, teda Jazelle je v ARMoch. Lenze posledne modely ARMov ju sice maju ale skor papierovo. Ako pise wiki - nove jadra maju len trivialnu implementaciu ktora neprida ziadnu hw akceleraciu. A niesom si isty ale to co vyprodukuje Google compiler, dex, asi nebude binarne kompatibilne s javovskym bajtkodom. A ak je to tak, tak je docela mozne ze by Jazelle ani nijak nepomohlo dalvikovskej binarke.
Ano v Qt vidim slusny pokrok a dufam ze do roka, ked uz bude trochu stabilnejsie a bude mat vsetky podstatne featury, nahradi vyvoj multiplatformovych aplikacii a aj to ulahci. Xamarin s ich Monom je stale dost rozbity a je to furt boj. Mimochodom sposob ako Google zvolil tvorbu obrazoviek (aktivit) v androide, mi pride do dnes zahadou. Robenie gui v androide je jeden velky pain in the ass.