Mobile and Embedded

Hi, What more ideas ? Did you check that you have the library I mentioned for your target ?

Great ! Thanks for sharing ! Since you have it working now, please mark the thread as solved using the "Topic Tools" button so that other forum users may know a solution has been found :-)

I think it is because the QT_QUICK_BACKEND is set to softwarecontext by default. please unset it.

@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. [image: f30e18ef-cf18-4b17-a547-77fa43739ef7.PNG] 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.

Thanks! Using begin()/end() indeed compiles fine! Thanks also for pointing out the (unintended) copy. I've switched to const-reference

I am seeing the same issue. Did you ever get this sorted?

Thank you so much @sierdzio for the answer. It's clear now!

try this: in your header QAndroidJniEnvironment *_jniEnv; ::firebase::App* _app; ::firebase::ModuleInitializer _initializer; QAndroidJniObject _jniObj; in your .cpp file: _jniEnv = new QAndroidJniEnvironment(); QAndroidJniObject jniObject = QtAndroid::androidActivity(); ::firebase::App *instance = ::firebase::App::GetInstance(); if (instance) { _app = instance; } else { jniObject = QtAndroid::androidActivity(); _app = ::firebase::App::Create(*_jniEnv, jniObject.object<jobject>()); } }

Hi, 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.

@no_1imit Check what @KroMignon wrote

@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

@no_1imit then take a look here https://doc.qt.io/qt-5/android-getting-started.html Anything below 5.12 requires android ndk r10e

@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 #return 0 #fi 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 And: 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: /lib/lsb/init-functions /lib/lsb/init-functions.d 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: /etc/default/hwclock 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. #BADYEAR=no # Set this to yes if it is possible to access the hardware clock, # or no if it is not. #HWCLOCKACCESS=yes # Set this to any options you might need to give to hwclock, such # as machine hardware clock type for Alphas. #HWCLOCKPARS= # Set this to the hardware clock device you want to use, it should # probably match the CONFIG_RTC_HCTOSYS_DEVICE kernel config option. #HCTOSYS_DEVICE=rtc0 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: /etc/default/rcS Here is the content that I put into this file: UTC=yes VERBOSE=no You can read more about the purpose and content of this file here: http://manpages.ubuntu.com/manpages/trusty/man5/rcS.5.html And the last referenced file within hwclock-set.sh is: /etc/adjtime 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 0 UTC 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: http://man7.org/linux/man-pages/man5/adjtime.5.html 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: http://man7.org/linux/man-pages/man8/hwclock.8.html 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.

@SGaist Ok thank you very much for your reply, I think I will do it another way...