Here is my solution:
I have created a new app from the template of Qt Creator and compared it with the example project for Qt Android:
I conclude, that I have to modify the .pro file. First of all I had to add the following line:
ANDROID_PACKAGE_SOURCE_DIR = $$PWD/android-sources
Then I had to replace DISTFILES, that is automatically added by Qt Creator, if I create a Java class:
OTHER_FILES += \
Finally I had to edit the AndroidManifest.xml, that I have copied from the exmaple project, in the text editor mode:
<activity android:configChanges="orientation|uiMode|screenLayout|screenSize|smallestScreenSize|locale|fontScale|keyboard|keyboardHidden|navigation" android:name="com.hello.android.Backend" android:label="Hello Android" android:screenOrientation="unspecified">
The last step was not necessary in the project of my initial question.
I found a workaround by myself. Actually the problem lies in the multilanguage feature, which needs some Qt tools for configuring it correctly with cmake. One Workaround is just install one binary of Qt 5.14.0 e.g. msvc2017 32 bit and assigne CMAKE_PREFIX_PATH to the location where the missing cmake file is located e.g. CMAKE_PREFIX_PATH:INTERNAL=C:\Qt\5.14.0\msvc2017\lib\cmake\Qt5. After that, cmake is then running to the end giving some warnings, but this can be ignored and all demos can be build and flashed on the target board.
@SGaist said in cpputest issue with QTest to show the widget on embedded linux:
Something is not clear. You say that the test is running on your desktop machine but the same test fails on the target ?
Yes the same test fails on target which works on ubuntu desktop. Only difference is that we run the same test on target with -qws, though for the unit tests, event loop is not being run both on ubuntu and target..
I noticed in Qt 4.8, we cannot start event loop with QSignalSpy unlike in Qt 5.0 https://doc.qt.io/qt-5/qsignalspy.html.
It got to do with event loop being run until signal is received,right?
Basically the test is to check resizeEvent() being invoked after calling widget->show() followed by widget->resize(100,100).
Only when the widget is visible, the resize() calls will cause the resizeEvent() handler to be called.
Can I run event loop in ui unit test main() or per only one test to determine if this is the reason on target?
int main(int argc, char *argv)
QApplication app( argc, argv );
@daljit97 I've a similar problem here. In my case, the qmake generated android-*-deployment-settings.json contains the wrong path for qmake_qmake_qm_files.qrc.
Hi. Bluetooth (in my modest opinion), is similar at a tcp connection so you can't define baud rate and it is not necessary.
You can define your custom protocol without any problem.
In the past I have implemented bluetooth connection in Linux, Windows (not necessaary because after pairing you will have a virtual com port so you can use the device easely using the standar com port object) and Android.
I haven't use the Qt bluetooth stack, I have created a component in java for Android and a wrapper for bluetooth library for Linux.
It was more easely than use the Qt cluetooth stack.
I experienced the same issue. I solved it by re-running "./sysroot-relativelinks.py sysroot". I caused it by changing some of my paths after calling "./sysroot-relativelinks.py sysroot".
Hope this helps.
@nataliejohn said in android specified library:
Open the module-level build.gradle file.
Delete the line for the applicationId. Only an Android app module can define this.
Thanks for the great feedback.
@Ramakanth said in Qt4.8 memory leak in QLineEdit::setReadOnly(true):
Any suggestions on how to fix the same as it causes segmentation fault on target?
I don't think that this will cause a segfault - it's allocated once at application startup but not released during destruction which is not good but also not a big deal.
Looks like by this blog that qt just isn't producing the correct android_deployment_settings.json
Might have to do it manually for now.
@JoeBot said in Cross compile Qt 5.12.5 for raspberry pi 4:
Can you please provide a link to the tutorial regarding the substitution of " -lEGL and -LGLESv2
I guess he followed this tutorial, pay attention to step #6.
qmake -project generates a .pro file but it does not do deep inspection so you have to check its content and add the parts that it does not know about. For example the modules that you are going to use beside the defaults.
@Nando As far as I know, Apple recently marked a couple of API's as private. and Qt's WebView is using some of those.
A rather random move from Apple, but it happens. AFAIK no workaround as of jet, but as @SGaist said, bring this the the mailing list, there people should be able to help/inform you more
@Kucchan Too late with the answer, but this works for me on a RPi3 with Raspbian:
msgBox.setWindowFlags( ( Qt::Window | Qt::CustomizeWindowHint ) &~
( Qt::WindowTitleHint | Qt::WindowSystemMenuHint |
Qt::WindowMinimizeButtonHint | Qt::WindowCloseButtonHint ) );
someone else could be looking for the same answer as I did.
I've found the solution on my own:
The dtoverlay=i2c-rtc,ds3231 entry in the Boot2Qt boot partition enables a device tree overlay for the i2c interface real-time clock driver to have the abilities of the DS3231 RTC. This had nothing to do with synchronizing the RTC to the system clock or vice-versa.
Synchronization happens with the hwclock-set.sh script that is present in the Raspbian OS images but not the Qt built Boot2Qt Yocto OS images (installable with any particular Qt version).
To enable the synchronization, I've copied the hwclock-set.sh script from a Raspbian image into /etc/init.d/hwclock-set.sh in the Yocto running OS via WinSCP and changed its attributes to be executable. But, there are a couple of additional items to do:
Comment out the following lines:
#if [ -d /run/udev ] || [ -d /dev/.udev ]; then
because /run/udev will exist as a directory and therefore since the script exits with the return 0, your synchronization will not execute.
Don't forget to run this command to add hwclock-set.sh as a script to run at startup / shutdown, etc.:
update-rc.d hwclock-set.sh defaults
The hwclock-set.sh file makes use of the /lib/lsb/init-functions helper scripts, which also do not exist in the Boot2Qt Yocto image. So, do the same thing, copy from the Raspbian image:
No modifications are necessary for these files. Just make sure they have the execution attribute.
There are several files referenced within hwclock-set.sh which do not exists and they are useful to have for auto-adjustments of RTC time drift and selection between UTC / LOCAL time represented by the hardware clock. The filenames to copy or create are:
Here is the content of the /etc/default/hwclock file:
# Defaults for the hwclock init script. See hwclock(5) and hwclock(8).
# This is used to specify that the hardware clock incapable of storing
# years outside the range of 1994-1999. Set to yes if the hardware is
# broken or no if working correctly.
# Set this to yes if it is possible to access the hardware clock,
# or no if it is not.
# Set this to any options you might need to give to hwclock, such
# as machine hardware clock type for Alphas.
# Set this to the hardware clock device you want to use, it should
# probably match the CONFIG_RTC_HCTOSYS_DEVICE kernel config option.
As you can see, I didn't have to update anything in this file because all of these variables are already set correctly in the hwclock-set.sh file, and this file is just used to override those variables (if I want to in the future).
Here's another referenced file within the hwclock-set.sh script:
Here is the content that I put into this file:
You can read more about the purpose and content of this file here:
And the last referenced file within hwclock-set.sh is:
If you don't have this file, the hwclock-set.sh script will create it for you with the default content:
0.0 0 0.0
This file is used to adjust the hardware clock time drift automatically over time. You can read more about this file and its content here:
And this information on the hwclock utility is particularly useful in understanding that you really want to keep your hardware clock set with UTC time and not local time:
Look for the section labeled: LOCAL vs UTC
and read up on why.
I've set UTC=yes in the /etc/default/rcS file and UTC in the /etc/adjtime file. This allows me to keep the hardware clock in UTC time so it isn't affected by time changes due to a timezone. Your system clock can use the TZ environment variable and/or the usual symbolic link of one of the files in /usr/share/zoneinfo as /etc/localtime.
A Linux OS will automatically update the system time when time changes within a timezone, but will leave the hardware clock in UTC time without any time changes. When the hwclock-set.sh script is executed during shutdown or restart, the hardware clock will be updated with the system clock date/time. The hwclock utility automatically uses the UTC setting in the /etc/adjtime file to know how to translate the system time into UTC time when reading from and writing to the hardware clock.