Important: Please read the Qt Code of Conduct -

Qt5.1 QWidget application on Android 4 - Refresh problems

  • Hello to all,
    I'm porting a simple QWidget application that already run fine compiled with QT5 on Windows, GNU/Linux and MacOSX , to Android.

    I was surprised it run without touch a line of C++ code, but...there are some blocking problem and I can't understand if there is something I can do or if there are still severe bugs in the Qt5 for android framework.

    After some test it seems that there are serious GUI refresh problems (at least with QWidget).

    Sometimes, when a new dialog is opened, the GUI does not update it's look.
    I said "It’s look", because the dialogs open correctly: clicking (touching) on it give the expected effect over the (not-showed) dialogs.

    Is a refresh problem, in fact, if you minimize and maximize the application using the classic home-applications Android buttons, it refresh to the correct look.

    This is really weird…I try to add some xxxx->show(); but it does not work.

    I reproduced the problem on an arm physical Android tablet as well as in an atom X86 simulator.

    Someone, have similar problems?
    It is a known issue?
    How it could be fixed?

    Another things I noticed, but do not know how to reproduce, is that when my application start, the QActions are shown in the toolbar of the window as well as in the option menu that is opened from the bottom Android bar but…after open and close some dialog, not know why, QAction(s) disappear from the Android menu.

    Another question: Is there a way to distinguish the platform where the application is running?
    If not at runtimes, what is the correct way to to distinguish platform at compile time?
    I’ve found the macro: Q_OS_*
    But I do not find one that is Android specific.
    Around in the Internet I saw that Q_OS_ANDROID was used in the past but I'm not sure if it's still the right compile time check.

    I see a similar topic whiout response:

    Thank you, Fabio.

  • Yep, i have the same issues.... Does anybody has an idea how tio fix that?
    Thanks, Frime

  • is a bug so I reported it a while atraz still in version 5.1.0 rc2.
    Stay again amazed at the lancemrnto qt5.1.1 still contain this bug.

    as far as I know has not as tidy. joke but it seems to have a really silly bug in the GUI. On the other hand qtquick seems to work well.

    The bogdan, was better only in the project.

    But I cheer for the solution.

  • [quote author="Flavio Portela" date="1374019471"]is a bug so I reported it a while atraz still in version 5.1.0 rc2.

    Thank you Flavio, does exist a bug report for this issue where I can add my entry?

    BTW, I do some attept to workaround the issue, but with QWidget seems that there are way more than this single problem!

    My simple QWidget application has a QMainWindows, some QAction in the menu and toolbar, a central widget, and you can open a simple application configuration dialog. Sometime I open a QMessageBox and a QProgressDialog. This is all I do, but for now there isn'y a widget without some issue.
    The QMainWindows does not resize to the availableGeometry,
    QMessageBox yes, but there is the refresh problem. The same for the QProgressDialog: I change It's aspect without hide or destroy it, such as
    // Added for Android test:

    But the progressDialog remain the same.

    Knowing the fact that Android have not a "standard" windows manager I tryied also some WindowsFlags on all the type of widget mentioned above, and different combinations. For example, one test for the QMainWindow:

        QMainWindow(NULL, Qt::Dialog |
                          Qt::BypassWindowManagerHint |
                          Qt::X11BypassWindowManagerHint |
                          //Qt::WindowStaysOnTopHint |
                          Qt::FramelessWindowHint |

    And outside, after construction, to resize it:
    const QRect rectd = QApplication::desktop()->availableGeometry();
    mainWindows->setSizePolicy(QSizePolicy::Fixed, QSizePolicy::Fixed);

    And obviously I try to call
    at several point but no luck.

    The only think that worked is the resize to QApplication::desktop()->availableGeometry();
    for the QMessageBox...but only if the messagebox contain a QButton. :-(

    QtQuick is not an option: the application is QWidget, rewrite the GUI in QtQuick is not only a waste of time but, for me, is unwanted as well.
    I prefer C++, and I prefer my code rely only on what is guarantee to be under the LGPL.

    I really hope all this hype about QtQuick, and also the weird bugs leaved in QWidget are not a conseguence of a commercial strategy.

    Hope it is only a conseguence of a lack of time due to the huge amount of work to do.

    But those bugs are blocking, so, for now, I must defer the Android port indefinitely.

    If somone have some news or hint/workarond please let me know.

    Best regards

  • If it helps you, you can use the Qt5.1 QtNecessitas4.8.2 out instead.
    the version estave stable enough to provide security for me. I launch my product within 2 years.
    you can download at:

  • waiting for the version with Qt5.2, I believe it will take time to leave, but will have a fix for these bugs fools.

    And now I know why launched as a preview, not able to stabilize.

    I am sad because Qt with innovations in favor of technologies is always the last to get in the race of new platatormas. When this occurs Qt will be better for almost everything

  • [quote author="Flavio Portela" date="1374195649"]If it helps you, you can use the Qt5.1 QtNecessitas4.8.2 out instead.
    [...] [/quote]

    I've already make some code modification for Qt5 that are no more compatible with Qt4.x, I'll wait for Qt5.2 and hope bugs will be fixed.

  • [quote author="Flavio Portela" date="1374019471"]is a bug so I reported it a while atraz still in version 5.1.0 rc2.

    Can you post a link to the bug?

  • Here is mine seems to be the same problem:

  • I'm experiencing similar problems and tried compiling Qt5.2.0 alpha to see if they've been fixed. Assuming it's not a mistake on my end, it appears to run the same as Qt5.1.1, with screens not maximizing or refreshing when they should/did with Necessitas and Qt4.8.x. Any updates on the progress of this bug?

  • The bug report says it needs more information.

  • BTW, the issue I've had with 4.8.2 is that I'd prefer to package the Qt libraries inside the APK, so I can distribute my app on hundreds of Android tablets at a time without manually updating/installing the libraries via Ministro.

  • Assuming you mean libraries and not drivers, you can package the libraries in the apk now using qt creator.

  • I have this refresh problem also. When i open a modal dialog and then hide it, it still appears on top of the other widget but i can click and do things with the other widget which indicates that the modal dialog is really closed. The problem is with samsung device. In the emulator it was working ok I think and the same code is working good in iphone device.
    Is there bug report for this exact thing or some workaround?

  • I believe this is connected to this bug:

    My device does the same thing and I've noticed that if I rotate the screen 90 degrees and back, it refreshes/resizes the screen correctly.

    I'm using a RockChip (rk30sdk) device on Android 4.1.1.

  • [quote author="steno" date="1381190135"]Assuming you mean libraries and not drivers, you can package the libraries in the apk now using qt creator.[/quote]

    Sorry, I did mean libraries. Is it possible to package the libraries using Qt4, to avoid this windowing issue with Qt5?

    The dilemma I have is that I'd like to package the libraries, which I'm not able to do via Necessitas and Qt4, but the windowing issues of Qt5 prevent me from a production solution.

  • [quote author="landrew" date="1381244319"]
    Is it possible to package the libraries using Qt4, to avoid this windowing issue with Qt5?

    I am not sure because I have never tried. I know creator 2.8.1 gives the option of how to package the libraries. You can still use minestro, or package them in the apk.

  • By the way, I believe this was resolved with 5.2.0.

Log in to reply