[Android-development] QT Android bindings for Service

Cory Slep ARA/SED cslep at ara.com
Tue Mar 31 16:00:36 CEST 2015


All,

I've got a mostly-working solution for Android Services in the android sense. Natively, most things appear to work except for one major obstacle: whenever a signal is "emit"ted, if there is at least one slot receiving the signal then the thread executing that emit appears to hang/block.

The evidence I have of this is from tracing QApplication's event loop in the main thread, and also having a separate spawned QThread that was emitting a signal to a slot on a QWidget.

In the QApplication, when the event loop sleeps since it does not have any more events to process, it emits aboutToBlock (from QAbstractEventDispatcher) successfully since I don't have any slots attached in my test app. Later the path of execution leads to a QTimer call "emit timeout(QPrivateSignal())" which does exhibit a hanging-like behavior.

The separate spawned (non-gui) QThread repeatedly emitting a signal connected to a slot on a QWidget exhibits the same behavior, leading me to suspect it is an issue in the implementation of signal/slots and not just a particular signal/slot pair. I have tried reading into the generated MOC files and looking for places where this could hang, but am stuck on what the root issue could be. Building this same sample application as an Activity does not yield any of these behaviors. I have looked at the native platform integration code and I don't see anything obvious that I've missed in hooking up.

I also have tried the three connection types (direct, queued, blocking queued) and they all exhibit this same hanging behavior.

I'd greatly appreciate any insight into the signal/slot system

From: android-development-bounces+cslep=ara.com at qt-project.org [mailto:android-development-bounces+cslep=ara.com at qt-project.org] On Behalf Of Eskil Abrahamsen Blomfeldt
Sent: Monday, March 02, 2015 9:46 AM
To: android-development at qt-project.org
Subject: Re: [Android-development] QT Android bindings for Service

On 03/02/2015 03:46 PM, Cory Slep ARA/SED wrote:
Hello all,

I am part of a team porting a Qt 5.4 Windows/Linux augmented reality application to Android. We have successfully ported it as an Activity rendering to the device screen. However, we have a requirement to render to an external display only (not the device display) because we need to have a third-party application running on and rendering to the device at the same time. Thus our application needs to run in the background but with Qt actively rendering.

Currently there seems to only be bindings for QtApplication and QtActivity, though searching yielded other attempts such as https://github.com/think-free/qt-android-helper/tree/master/android/src/org/qtproject/qt5/android/addons/qtserviceapp which contains two bindings in particular we are interested in: QtService and QtServiceBroadcastReceiver. I realize having an Android Service do rendering may be an unusual use case but having this capability is critical for us.

Since this is an issue on our team that we must overcome, it would be nice to not have a hacked-up-kludge on our end. Has anyone else given thought on supporting bindings for Services? Would it be in the Qt project's interest to have this capability? Is there interest in coordinating to develop this capability?

A very cursory glance over the archives does not yield an obvious previous discussion about this.

Hi,

I've looked a bit at this already, but would not mind if someone else picked it up. The main issue will be the case where you have both an activity and a service running with Qt, and either of them (or both) can be active at any time. For your use case it sounds like you will only have the service running in the process, which means this will be more straight-forward, I think.

Bug report with discussion etc. here: https://bugreports.qt.io/browse/QTBUG-37221

-- Eskil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/android-development/attachments/20150331/11f3e4de/attachment.html>


More information about the Android-development mailing list