Qt on Android ep 2

132 views
Skip to first unread message

BogDan

unread,
Feb 17, 2010, 5:19:21 PM2/17/10
to android-ndk
Hi,

I'd like to show you some videos with current status of Qt for Android
port.

* Full touch (mouse) & screen events.
Qt animated tiles (ep. 2): http://blip.tv/file/3232378

* Full HARDWARE keyboard support.
Qt wiggly example (ep. 2): http://blip.tv/file/3232386
Qt graphics-dojo raycasting example: http://blip.tv/file/3232414 (A
big thanks to Ariya Hidayat who give me the tip).

* Port of QtScript module
Qt context2s script example: http://blip.tv/file/3232407

What's next:
* OpenGL support.
* Declarative UI.

For more informations please use android-lighthouse project page,
http://code.google.com/p/android-lighthouse/

Cheers,
BogDan,

Doug Schaefer

unread,
Feb 17, 2010, 11:10:10 PM2/17/10
to andro...@googlegroups.com
Cool!

One question, though. Reading your readme it looks like you need your custom NDK to make this work. Is that correct?


--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.


BogDan

unread,
Feb 18, 2010, 1:50:28 AM2/18/10
to android-ndk
Yes, my "custom" ndk is made from official ndk + some libs from eclair
branch. Only 3rdparty lib you'll find there is stl port.

If you want to try it take a look to http://code.google.com/p/android-lighthouse/wiki/Compile

BogDan.

On Feb 18, 6:10 am, Doug Schaefer <cdtd...@gmail.com> wrote:
> Cool!
>
> One question, though. Reading your readme it looks like you need your custom
> NDK to make this work. Is that correct?
>

> On Wed, Feb 17, 2010 at 5:19 PM, BogDan <taipanroma...@gmail.com> wrote:
> > Hi,
>
> > I'd like to show you some videos with current status of Qt for Android
> > port.
>
> > * Full touch (mouse) & screen events.
> > Qt animated tiles (ep. 2):http://blip.tv/file/3232378
>
> > * Full HARDWARE keyboard support.
> > Qt wiggly example (ep. 2): http://blip.tv/file/3232386
> > Qt graphics-dojo raycasting example:http://blip.tv/file/3232414(A
> > big thanks to Ariya Hidayat who give me the tip).
>
> > * Port of QtScript module
> > Qt context2s script example:http://blip.tv/file/3232407
>
> > What's next:
> > * OpenGL support.
> > * Declarative UI.
>
> > For more informations please use android-lighthouse project page,
> >http://code.google.com/p/android-lighthouse/
>
> > Cheers,
> > BogDan,
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>

Dianne Hackborn

unread,
Feb 18, 2010, 3:23:24 AM2/18/10
to andro...@googlegroups.com
On Wed, Feb 17, 2010 at 10:50 PM, BogDan <taipan...@gmail.com> wrote:
Yes, my "custom" ndk is made from official ndk + some libs from eclair
branch.

Sorry to continue to harp on this, but if my interpretation is correct then what you are using is -not- the NDK, and should not be advertised as have any relation to the NDK, since any use of it will result in applications that break randomly on different devices and versions of the platform.

It's a cool project.  But if you are using APIs that are not part of the NDK, I would really ask that you be very clear that there is no NDK here, this is non-standard stuff, not supported, and should not be used in anything that will appear on Market.

If what you are saying is something different and you are only using NDK APIs, then ignore all that. :)

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

Doug Schaefer

unread,
Feb 18, 2010, 7:47:18 AM2/18/10
to andro...@googlegroups.com
On Thu, Feb 18, 2010 at 3:23 AM, Dianne Hackborn <hac...@android.com> wrote:
On Wed, Feb 17, 2010 at 10:50 PM, BogDan <taipan...@gmail.com> wrote:
Yes, my "custom" ndk is made from official ndk + some libs from eclair
branch.

Sorry to continue to harp on this, but if my interpretation is correct then what you are using is -not- the NDK, and should not be advertised as have any relation to the NDK, since any use of it will result in applications that break randomly on different devices and versions of the platform.

It's a cool project.  But if you are using APIs that are not part of the NDK, I would really ask that you be very clear that there is no NDK here, this is non-standard stuff, not supported, and should not be used in anything that will appear on Market.

If what you are saying is something different and you are only using NDK APIs, then ignore all that. :)

Yes, I think you got a lot of people's hopes up that we could actually use Qt for Android apps but you are clearly violating the NDK API rules. And that only makes sense with the kinds of things that Qt supports. We thought it was too good to be true. It is.

Having said that, this is exactly the kind of thing native app developers need. It would be awesome if Qt became part of the platform. But given Qt's LGPL license, that appears unlikely. But something like this would be awesome.
 

BogDan

unread,
Feb 18, 2010, 7:48:19 AM2/18/10
to android-ndk
On Feb 18, 10:23 am, Dianne Hackborn <hack...@android.com> wrote:

> On Wed, Feb 17, 2010 at 10:50 PM, BogDan <taipanroma...@gmail.com> wrote:
> > Yes, my "custom" ndk is made from official ndk + some libs from eclair
> > branch.
>
> Sorry to continue to harp on this, but if my interpretation is correct then
> what you are using is -not- the NDK, and should not be advertised as have
> any relation to the NDK, since any use of it will result in applications
> that break randomly on different devices and versions of the platform.
>

Sorry I didn't want to confuse anybody, no is not the official NDK, I
need to add it some libs form eclair branch, this libs are not
official supported but you will find them in every android
distribution, In fact I use all this libs and header for only 1 header
(<ui/Surface.h>), 1 structure (android::Surface::SurfaceInfo) and 2
methods from 1 class (android::Surface, lock and unlockAndPost). I use
this class because I didn't find a faster way to copy an image form c/c
++ to screen, if I'll use the "official" workaround, it will be 3-4
times slower draw an image. Yes I know you change the API/ABI for this
class when you go to 2.0 but you see I have to choose between speed
and compatibility, for now I choose speed. The stl port is a static
library and it should not create problems.

Also Qt can be compiled/used with official NDK but you'll need to
create your own JAVA <== JNI ==> C/C++ connections.


> It's a cool project.

Thank you very much !

> But if you are using APIs that are not part of the
> NDK, I would really ask that you be very clear that there is no NDK here,
> this is non-standard stuff, not supported, and should not be used in
> anything that will appear on Market.

I think it's a long way before Qt will hit the market. It need much
more work, I need to find a way to use Qt as shared library, now I'm
use it as static library. Until then, maybe, you will fix the linker
to let me use Qt as shared library, maybe you'll release a NDK with a
faster way to put an image to a surface(an official
android::Surface :D ), multimedia api, stl, exceptions, rtti.

Also, if Qt is compiled with official NDK, it can be used to create
stuff and to put them on Market.


> If what you are saying is something different and you are only using NDK
> APIs, then ignore all that. :)

I'll change the name for my CUSTOM NDK ASAP. QDK is ok for you? :-P

> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

Dianne Hackborn

unread,
Feb 18, 2010, 2:58:12 PM2/18/10
to andro...@googlegroups.com
On Thu, Feb 18, 2010 at 4:48 AM, BogDan <taipan...@gmail.com> wrote:
Sorry I didn't want to confuse anybody, no is not the official NDK, I
need to add it some libs form eclair branch, this libs are not
official supported but you will find them in every android
distribution, In fact I use all this libs and header for only 1 header
(<ui/Surface.h>), 1 structure (android::Surface::SurfaceInfo) and 2
methods from 1 class (android::Surface, lock and unlockAndPost). I use
this class because I didn't find a faster way to copy an image form c/c
++ to screen, if I'll use the "official" workaround, it will be 3-4
times slower draw an image. Yes I know you change the API/ABI for this
class when you go to 2.0 but you see I have to choose between speed
and compatibility, for now I choose speed. The stl port is a static
library and it should not create problems.

"have no other choice" != "correct".

These kinds of APIs change all the time between platform releases...  and even small maintenance updates.  And manufacturers can freely change this as well...  maybe none have no, but there are no guarantees there won't be a device with them changed that goes on sale tomorrow.

> If what you are saying is something different and you are only using NDK
> APIs, then ignore all that. :)
I'll change the name for my CUSTOM NDK ASAP. QDK is ok for you? :-P

Thanks.  Feel free to call it whatever you want, I just want to make sure people understand the issues they can run into if they use it.  I am just getting pretty sensitive to this because how many complaints about compatibility problems come down to people using non-SDK APIs (sometimes without even knowing it because they are using code someone else gave them).

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Alex

unread,
Feb 19, 2010, 3:06:06 PM2/19/10
to android-ndk
Regarding potential future API changes, if and when those changes are
made, the library source code can be updated to work with the new
version of the APIs. I just do not see this as serious concern,
frankly.

I have an application written in C++ using the Qt libraries that I
wanted to get running on Android. As I have an Android 1.5 phone I
really wanted to get GUI working on Cupcake, but could not do so. I'm
not sure what is the problem, maybe this could be looked into?
However, I was able to get it working in the emulator using Android
2.0. The results were very good, but unfortunately, the app comes out
looking like it was designed for the desktop it just does not work
optimally on a mobile device.

A technical issue with the current approach is the size of the
resulting binaries. Statically linking against QtGui creates a binary
over 10MB in size. This is quite large, especially when you consider
that only about 200 MB is available for app storage on the flaghship
Nexus One, and even less on older devices. It's not practical to
distribute such large applications when even the largest apps on the
Marketplace do not exceed three megabytes.

It would be better if dynamic linking could be implemented somehow,
perhaps through a third-party app taking place of package manger such
as the ones in Linux to download libraries on demand. Also, I think
size could be reduced by using thumb mode during compilation, and
possibly removing some of the statically compiled graphics embedded in
the binary.

For these reasons, I decide to reuse my existing C++ Qt codebase for
most of the logic and rewrite the GUI in Java. Linking against QtCore,
QtXml, and QtNetwork created a 3.5 MB executable. This is large for
Android, but manageable. However, this approach is necessitates
interfacing between the Java and Qt event threads, which is
inconvenient.

--Aleksandr Dobkin

On Feb 18, 1:58 pm, Dianne Hackborn <hack...@android.com> wrote:

> hack...@android.com

David Turner

unread,
Feb 20, 2010, 10:57:54 AM2/20/10
to andro...@googlegroups.com
On Fri, Feb 19, 2010 at 12:06 PM, Alex <ado...@gmail.com> wrote:
Regarding potential future API changes, if and when those changes are
made, the library source code can be updated to work with the new
version of the APIs. I just do not see this as serious concern,
frankly.


The concern is that all installed binaries will suddenly break when the system
is updated through an OTA which contains changes to these platform libraries.
 
Or it will simply not run on a new device that comes to market, containing a
system image that has been customized by an OEM, for some valid reason, but
still capable of perfectly running apps written with the official NDK and SDK.

(And I would add a device that is not available in the app developer's market,
so chances that you could debug that or provide an alternative version are slim).

In such situation, be assured that typical users will think things like "Android
broke my app" or "The platform is fragmented, what a load of crap", while in
reality it was just a crappy application to begin with !

That, dear sir, is the reason why we really don't like when people do stupid
stuff like linking to non-stable platform libraries.

We have been relatively cool at the moment about this. We could add many
installation and runtime checks to prevent such apps from running/linking
or even being listed on Android Market. Please don't force us to implement this !

And that is not to say that we don't plan to expose more useful interfaces
to native code. It's just that doing this properly takes time. Also keep in mind
that many parts of the system may never be exposed at all (a good example
is libwebkit, since even upstream developers don't care about ABI stability
for this code, and we tend to stick close to upstream for this component).

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

Cameron Ross

unread,
Feb 20, 2010, 3:51:25 PM2/20/10
to andro...@googlegroups.com
Hi David,

Your cautions re: linking to libraries not supported by the NDK are pragmatic.  It would be extremely valuable to establish an NDK roadmap so that thirdparty developers can plan.  Could I suggest that someone on the Android team lead the effort to work with this community to prioritize such a roadmap.  It would surely  be of value to those of us looking to commercialize Android apps.

Cheers,
Cameron Ross.

Sent from my iPhone

Doug Schaefer

unread,
Feb 20, 2010, 6:44:19 PM2/20/10
to andro...@googlegroups.com
I have to echo that. David, we understand your worry and frustration. This Qt thing in particular is scary. It might not even work on existing devices.

But I do hope you and the other Android developers understand our frustration. We want to make sure we can bring the best content we can to the Android platform. The economics will dictate that we'll need to be able to bring apps to both iPhone and Android, just like we do for the game consoles and PCs. The NDK needs to be much richer to be able to pull that off. And with the traditional lack of insight into Google's plans, it's making it very difficult for us plan investment in Android. And I do believe Android needs this content to ensure it can succeed against ever increasing competition. The device vendors hopefully agree with that. And I do hope that is what you are planning.

BogDan

unread,
Feb 21, 2010, 1:25:08 PM2/21/10
to android-ndk
On Feb 18, 9:58 pm, Dianne Hackborn <hack...@android.com> wrote:

> On Thu, Feb 18, 2010 at 4:48 AM, BogDan <taipanroma...@gmail.com> wrote:
> > Sorry I didn't want to confuse anybody, no is not the official NDK, I
> > need to add it some libs form eclair branch, this libs are not
> > official supported but you will find them in every android
> > distribution, In fact I use all this libs and header for only 1 header
> > (<ui/Surface.h>), 1 structure (android::Surface::SurfaceInfo) and 2
> > methods from 1 class (android::Surface, lock and unlockAndPost). I use
> > this class because I didn't find a faster way to copy an image form c/c
> > ++ to screen, if I'll use the "official" workaround, it will be 3-4
> > times slower draw an image. Yes I know you change the API/ABI for this
> > class when you go to 2.0 but you see I have to choose between speed
> > and compatibility, for now I choose speed. The stl port is a static
> > library and it should not create problems.
>
> "have no other choice" != "correct".
>

"avoiding problems" != "solution" ;-)

>
> These kinds of APIs change all the time between platform releases... and
> even small maintenance updates. And manufacturers can freely change this as
> well... maybe none have no, but there are no guarantees there won't be a
> device with them changed that goes on sale tomorrow.
>

The API for android::Surface was modified twice, between 1.0 and 1.5,
and between 1.6 and 2.0 (for 1.5 and 1.6) see it's history
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=history;f=include/ui/Surface.h;h=70303cdb8c8f5c7c2dde353664efcc26c3bff87d;hb=HEAD
To me it looks stable enough.

>
> > If what you are saying is something different and you are only using NDK
> > > APIs, then ignore all that. :)
> > I'll change the name for my CUSTOM NDK ASAP. QDK is ok for you? :-P
>
>
> Thanks. Feel free to call it whatever you want, I just want to make sure
> people understand the issues they can run into if they use it. I am just
> getting pretty sensitive to this because how many complaints about
> compatibility problems come down to people using non-SDK APIs (sometimes
> without even knowing it because they are using code someone else gave them).
>

Done. I also added a warning.

> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

BogDan

unread,
Feb 21, 2010, 1:39:30 PM2/21/10
to android-ndk
On Feb 19, 10:06 pm, Alex <adob...@gmail.com> wrote:
> Regarding potential future API changes, if and when those changes are
> made, the library source code can be updated to work with the new
> version of the APIs. I just do not see this as serious concern,
> frankly.
>

Here I like to comment. Qt library DON'T require any unsupported API
only the android plugin.
This plugin makes the connections between c/c++ and Java.
So you can safely use qt in your app if you don't use android plugin.

>
> I have an application written in C++ using the Qt libraries that I
> wanted to get running on Android. As I have an Android 1.5 phone I
> really wanted to get GUI working on Cupcake, but could not do so. I'm
> not sure what is the problem, maybe this could be looked into?
> However, I was able to get it working in the emulator using Android
> 2.0. The results were very good, but unfortunately, the app comes out
> looking like it was designed for the desktop it just does not work
> optimally on a mobile device.
>

Yes the style needs more love. Is not very difficult to do it.

>
> A technical issue with the current approach is the size of the
> resulting binaries. Statically linking against QtGui creates a binary
> over 10MB in size. This is quite large, especially when you consider
> that only about 200 MB is available for app storage on the flaghship
> Nexus One, and even less on older devices. It's not practical to
> distribute such large applications when even the largest apps on the
> Marketplace do not exceed three megabytes.
>
>
> It would be better if dynamic linking could be implemented somehow,
> perhaps through a third-party app taking place of package manger such
> as the ones in Linux to download libraries on demand. Also, I think
> size could be reduced by using thumb mode during compilation, and
> possibly removing some of the statically compiled graphics embedded in
> the binary.
>

Dynamic linking is my biggest concern, I didn't find a solution for
this. I tried to set the LD_LIBRARY_PATH variable with another library
before I load the main library no luck, I also tried to hardcode the
qt libraries path using "-rpath" flag but
it seems it's ignored by the linker. A "solution" seems to be in this
thread: http://groups.google.com/group/android-ndk/browse_thread/thread/da2cb8cdeca854a5/77fb7dd33bb376f7?lnk=raot#77fb7dd33bb376f7

BogDan

unread,
Feb 21, 2010, 2:10:49 PM2/21/10
to android-ndk
On Feb 20, 5:57 pm, David Turner <di...@android.com> wrote:

> On Fri, Feb 19, 2010 at 12:06 PM, Alex <adob...@gmail.com> wrote:
> > Regarding potential future API changes, if and when those changes are
> > made, the library source code can be updated to work with the new
> > version of the APIs. I just do not see this as serious concern,
> > frankly.
>
> The concern is that all installed binaries will *suddenly* break when the

> system
> is updated through an OTA which contains changes to these platform
> libraries.
>
> Or it will simply *not run* on a new device that comes to market, containing

> a
> system image that has been customized by an OEM, for some valid reason, but
> still capable of perfectly running apps written with the official NDK and
> SDK.
>
> (And I would add a device that is not available in the app developer's
> market,
> so chances that you could debug that or provide an alternative version are
> slim).
>
> In such situation, be assured that typical users will think things like "*
> Android*
> *broke my app*" or "*The platform is fragmented, what a load of crap*",
> while in
> reality it was just *a crappy application* to begin with !

>
> That, dear sir, is the reason why we really don't like when people do stupid
> stuff like linking to non-stable platform libraries.
>

Thank you very much. You are so kind.

>
> We have been relatively cool at the moment about this. We could add many
> installation and runtime checks to prevent such apps from running/linking
> or even being listed on Android Market. Please don't force us to implement
> this !
>

Why don't you try to give developer what they need? like an API to
draw an image to screen, to use sound, stl, exceptions, rtti, etc.
IMHO this is what we need, not more restrictions.

>
> And that is not to say that we don't plan to expose more useful interfaces
> to native code. It's just that doing this properly takes time. Also keep in
> mind
> that many parts of the system may never be exposed at all (a good example
> is libwebkit, since even upstream developers don't care about ABI stability
> for this code, and we tend to stick close to upstream for this component).
>

You talk about webkit and we can't put a pixel to screen :))
This is like a stone age man dreaming to walk to moon. I don't want to
be impolite, but when I'm using you official NDK I'm felling like in
90's when I start using C/C++ using BC 3.1 on DOS ( BTW there I have
direct access to screen ;-) ).

I really hope in NDK 2.0 you will find a way to give us something
more. We need more, this is the reality, that way I'm forced to do
stupid things.

> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>

krin lenv

unread,
Feb 22, 2010, 4:03:40 AM2/22/10
to android-ndk
Hi,

Great work, BogDan.
I was able to run animatedtiles example on my HTC Hero. Looks awesome
http://www.youtube.com/watch?v=2ytCENR8YrM(sorry for quality).
Thank you.
Waiting for declarative.

> > > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr­oups.com>

MitchDC

unread,
Apr 7, 2010, 5:21:18 PM4/7/10
to android-ndk
Is QtNetwork fully supported by android-lighthouse?
Reply all
Reply to author
Forward
0 new messages