Thanks!
ok, so now i am more confused than before...

Well, i guess QtQuick 2 is not a "superset" of QtQuick 1, so if i use QtQuick 1 it's going to work magicly on QtQuick 2 platforms... right? It's more like the Qt3 -> Qt4 migration, where "it worked, but soon had to be fixed" (maybe without the Qt3Support compatibility layer, in this case).

Ok, i will quickly fix a working stubb UI with widgets, just to get the core going, besides automated tests which do not need any UI. It should take very little time (like half day). Later on i will try to figure out how to implement some more complete UI prototypes using QtQuick 1 and do some real world testing on Symbian/MeeGo.

The widget stubb should work also for initial android integration, i guess.

Then a decision will have to be made: develop a QtQuick 2.0 port alongside the 1.0 or go Java UI. I agree, it's not easy or nice, but if properly planned even JNI can be smoothed out a bit...

To be honest, at the moment i have a port of the older release on Android using Necessitas. Ministro is a pain (99% of my android users complained about ministro and downloading Qt libs, they either do not understand what is going on OR plainly believe it's a malaware trying to take over the phone. And they are focused users who got the "beta" android release directly from my own private email! i shudder at releasing something like that on Google Play! it would be KILLED by bad reviews without even having started the application). So i would prefer going with embedded libs, but this means a huge download, and more drawbacks.

I don't know, yet, what is best. A native UI with a plain C++ core would be better for the users... worse for me of course.