Then delete the application from your device and install it again. Do not just re-run your application, nuke it from the device before starting it again.

Hi,

Do you mean the most recent version you can build on it ?

Sorry, I couldn't test.

Since there has been new releases in between can you check with them ? 5.7.1 is out and 5.8 Beta also.

just for the record: This here works really well https://forum.qt.io/topic/41071/solved-how-to-store-a-qimage-to-ios-camera-roll-photo-album/4

Has anyone found a suitable solution for an embedded device on eglfs? I want to use a natively portrait display in landscape orientation, for displaying Qt5 Widget applications

Take a look at the Graperain, or Raspberry PI. There's plenty of info on Qt Labs about how to get Qt up and running on a Raspberry PI, and I know that there are some people interested in working with the Graperain embedded hardware design, so there should shortly be a good amount of information about that.

My Board is MINI6935 - Atmel ARM9 AT91SAM9x35 based Single Board Computer Quad Core
Atmel ARM926EJ-S™ 32-bit processor running at up to 400MHz
Linux2.6.39 operating system
Linux QT graphic
Supporting multiple filesystems such as ROM/CRAM/EXT2/EXT3/FAT/NFS/JFFS2/YAFFS2/UBIFS

@raven-worx Thanks for your reply. I am targeting both iOS and Android. Will follow your link. Thanks!

I had similar issue, but on TK1 board. You should use libjpeg from NVidia. Usually, this library is in /lib/nvidia (or in something else directory). Just use, e.g. LD_LIBRARY_PATH=<path/to/nvidia/libjpeg> directly, before starting of your application.

@MartinD
since the Activity and the Service are different processes and thus do not share the same memory space a pointer wouldn't help you.
You need to use any IPC technique or if you are more familiar with it use Android Intents to communicate your data.

We also ran into this problem and found an easy workaround.

Instead of providing the input device as a environment variable, the input device can be set at runtime. We use a QFileSystemWatcher to register that the node does not exists anymore and in that case, close the keyboard. It is also possible to register a new input device and then set it as the default keyboard.

In our case the only keyboard may be at node /dev/input/event1 so the following code snipped (incomplete) works out well for us:

//Initialization of QFileSystemWatcher somewhere after startup { pFileSystemWatcher = new QFileSystemWatcher(this); pFileSystemWatcher->addPath("/dev/input/"); connect(pFileSystemWatcher, SIGNAL(directoryChanged(QString)), this, SLOT(on_fileSystemWatcher_directoryChanged(QString))); closeKeyboard(); on_fileSystemWatcher_directoryChanged(QString()); } // Slot to receive a removed or added input device void on_fileSystemWatcher_directoryChanged(const QString& path) { QFileInfo eventFile("/dev/input/event1"); if (!keyboardPresent && eventFile.exists()) { setKeyboard(); } else if (keyboardPresent && !eventFile.exists()) { closeKeyboard(); } } void setKeyboard() { QWSKeyboardHandler *pKeyboardHandler = QKbdDriverFactory::create("LinuxInput", "/dev/input/event1"); QWSServer* pQwsServer = QWSServer::instance(); pQwsServer->setKeyboardHandler(pKeyboardHandler); keyboardPresent = true; } void closeKeyboard() { QWSServer* pQwsServer = QWSServer::instance(); pQwsServer->closeKeyboard(); keyboardPresent = false; }

Thanks, I have asked the question there. When I have some time, I will see about checking for sure that this is the code path that is followed in the plugin, but dont have a debug build of Qt at present to step through.

Thanks. Path of least resistance was build OpenSSL for Android and deploy with our app.

@jsulm
OK. Thanks for clarifying this. Sometimes, I'm a little bit slow...^^
In any case, reporting a problem like this seems perfectly valid to me, from a "user" point of view.
Cheers.

@raven-worx : I've got an answer from BogDan Vatra, in fact Ministro does not support Qt 5.7.x
This is why nothing works when generating APK with Ministro.

Qt5.7.x support will be added some time later. This is a bad news for me... I can't wait for a Ministro update.

So I found a workaround, I give it here, perhaps this could help someone else.

I have create a APK with Qt lib included, in release mode but not signed.
From this APK, which is in fact a ZIP archive, I've extract all Qt specific stuff:

assets/--Added-by-androiddeployqt--/* lib/armeabi-v7a/libplugins_* lib/armeabi-v7a/libqml_* lib/armeabi-v7a/libQt5* lib/armeabi-v7a/libgnustl_shared

I copy those files on device, into internal storage.
Then, I generate new APK (same configuration: release, with Qt libs and not signed).
To generate the update APK, I remove from this the Qt specific stuff (so APK size is now less than 2MB).
I transfer this APK on device, on device side I insert missed Qt libs into.
Then I start APK installation on device.

This a very dirty way to do it, but it WorksForMe(TM)