Re: [Interest] QProcess::execute never returning (5.4/5.5 behaviour change)
El Tuesday 28 July 2015, Thiago Macieira escribió: https://github.com/osxfuse/fuse/blob/06018fa9d5cee5ee3e8fb7057e568f5bc811 5f5 b/lib/mount_darwin.c#L589 Oh, yeah, that's totally broken. My earlier recommendation stands then: Shoot the library in the head. :-) Thank you for the advice. I'll report the issues upstream, and I'll see how to work around them (for now system() is decent enough). Fun fact: resorting to calling umount/fusermount -u it's because fuse_unmount has other issues. Remembers me of some build systems that don't support make uninstall. It's a feature for achieving total world domination. :) -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [ Android ] Creating task that runs in background when app not in foreground or device sleeping?
On Wed, Jul 29, 2015 at 8:01 PM, Edward Sutton edward.sut...@subsite.com wrote: My Qt widget app has Bluetooth connection that broadcasts GPS NMEA data to a connected device. How can I maintain this connection streaming GPS data when app is not in foreground or device is in sleep? Is it even possible to run Qt C++ code on Android in the background? Does Qt have any example for this? Is a Background Service what I need? Creating a Background Service https://developer.android.com/training/run-background-service/create-service.html Thanks in advance for any tips or direction, Yes, Qt application for android is a normal android application, so you really need service. I was trying to do something like that last year, the most convenient way I've found was to open the builded project in Android Studio, fix the gradle errors, then change all you need to make it a service. But by that time you need your Qt part already working. I was stuck on the front-end side though, so dropped the idea to use Qt for normal applications. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [ Android ] Creating task that runs in background when app not in foreground or device sleeping?
On Jul 30, 2015, at 7:27 AM, Stanislav Baiduzhyi baiduzhyi.de...@gmail.com wrote: On Thu, Jul 30, 2015 at 2:24 PM, Edward Sutton edward.sut...@subsite.com wrote: I was hoping I could use the QBluetoothSocket connection. However it sounds like a background service that does the Bluetooth communications must be pure java? No Qt, no C++. Why, it can use Qt and C++, it's only QtCreator capabilities are not enough at the moment to create the service apk. The build stage of QtCreator prepares something similar to Android Studio gradle project, which you can then open in Android Studio and finish the job. Can an APK that installs my Qt widget app also install a background service on Android? -Ed This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [ Android ] Creating task that runs in background when app not in foreground or device sleeping?
I was hoping I could use the QBluetoothSocket connection. However it sounds like a background service that does the Bluetooth communications must be pure java? No Qt, no C++. -Ed On Jul 30, 2015, at 6:53 AM, Stanislav Baiduzhyi baiduzhyi.de...@gmail.commailto:baiduzhyi.de...@gmail.com wrote: On Wed, Jul 29, 2015 at 8:01 PM, Edward Sutton edward.sut...@subsite.commailto:edward.sut...@subsite.com wrote: My Qt widget app has Bluetooth connection that broadcasts GPS NMEA data to a connected device. How can I maintain this connection streaming GPS data when app is not in foreground or device is in sleep? Is it even possible to run Qt C++ code on Android in the background? Does Qt have any example for this? Is a Background Service what I need? Creating a Background Service https://developer.android.com/training/run-background-service/create-service.html Thanks in advance for any tips or direction, Yes, Qt application for android is a normal android application, so you really need service. I was trying to do something like that last year, the most convenient way I've found was to open the builded project in Android Studio, fix the gradle errors, then change all you need to make it a service. But by that time you need your Qt part already working. I was stuck on the front-end side though, so dropped the idea to use Qt for normal applications. ___ Interest mailing list Interest@qt-project.orgmailto:Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QThread sleep on QMutex
And my question is just theoretical: is this approach good or such sleep() implementation not so good and why? I.e. will such sleep() release processor's time for another thread or not? Using sleep() will allow the processor to work on a different thread. The issue is that sleep() will most likely over sleep and make your code run slower. Also, under Windows, there is a 15ms penalty for blocking a thread (put to sleep) by calling sleep() or using a mutex to lock. That means if you want your thread to sleep for 5ms, it will sleep for at least 15ms. (This is from my measurements on Windows XP and Windows 7 about five years ago. It may be outdated.) Best practices are to not to lock a thread for optimal performance. If you need to block for synchronization purposes, it is best to use a condition variable (QWaitCondition). This makes blocking a thread event driven by using a different thread (the one you are waiting on) wake up the original thread only at the proper time. In this way, your thread will never over sleep but instead block for the minimum amount of time. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Release Binary Builds
On Thursday 30 July 2015 13:00:57 m...@rpzdesign.com wrote: Thiago: I kind of messed up. You once replied with the location on github or somewhere where the binary build commands for configure on the product releases was located. OSX ./configure bla-bla-bla When I search back through all my past emails, I could NOT find that kind message you forwarded. Do you think you could pass along the binary build command url location? Somewhere in http://code.qt.io/cgit/qtsdk/qtsdk.git/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QProcess::execute never returning (5.4/5.5 behaviour change)
On 28.07.2015 18:35, Thiago Macieira wrote: On Tuesday 28 July 2015 10:36:11 Alejandro Exojo wrote: I probably wasn't clear enough: this is on a Mac, so I should have written OSXFUSE instead of FUSE. The library is still based in Linux's, but current stable OSXFUSE uses an old libfuse. And some parts might be different. This is the use of signal(2) that I've found: https://github.com/osxfuse/fuse/blob/06018fa9d5cee5ee3e8fb7057e568f5bc8115f5 b/lib/mount_darwin.c#L589 Oh, yeah, that's totally broken. My earlier recommendation stands then: Shoot the library in the head. (Or, if you're not inclined to, apply the sigprocmask solution from the Linux code. And, of course, hope that like on Linux sigprocmask works in the threaded case. POSIX does not guarantee it does) One thing I'm wondering with all the SIGCHLD magic. How you make sure the signal handlers do not mess around and spread EINTR in your third-party components. And I'm not just worried about Qt's 3rd party libs. Greetings, FRank -- Cyblogic Web.: gplus.to/frankencode ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt 5.5.0 OSX Simulator fail
Hello List: Yosemite 10.10.2 - Xcode 6.1.1 (also on Xcode 6.2) - Qt 5.5.0 Trying to run on the IOS simulator and get a big fail. The simulator starts up but then the applicaiton output gets the following message on a basic project. Anybody come across this? Debugging starts Session could not be started: Unable to run app in Simulator Unable to remove simlink at `/Users/md/Library/Developer/CoreSimulator/Devices/68424D04-B842-4C71-AE77-6F141822D7E3/data/var/folders/9s/l_fngwkx5rz_fjy85dns7rjwgn/T/ios-sim-stderr-pipe-1438292236' Unable to remove simlink at `/Users/md/Library/Developer/CoreSimulator/Devices/68424D04-B842-4C71-AE77-6F141822D7E3/data/var/folders/9s/l_fngwkx5rz_fjy85dns7rjwgn/T/ios-sim-stdout-pipe-1438292236'Run ended.Debugging has failed Debugging has finished Thanks, md ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QProcess::execute never returning (5.4/5.5 behaviour change)
On Friday 31 July 2015 00:45:38 Frank Mertens wrote: One thing I'm wondering with all the SIGCHLD magic. How you make sure the signal handlers do not mess around and spread EINTR in your third-party components. And I'm not just worried about Qt's 3rd party libs. You don't. You simply hope that everyone has implemented signal handlers properly and hope that everyone has written code to handle EINTR properly too. Qt code handles EINTR properly and installs signal handlers properly. You must hold everyone else to the same standard. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.5.0 OSX Simulator fail
Hello List IOS Maintainer Tor Arne: (tor.arne.ves...@theqtcompany.com) I would like to suggest some hard lessons learned today. I upgraded to 5.5.0 and was primarily getting my code running on OSX to make sure it basically worked. I could then deploy to IOS Simulator/IOS and android to validate the code worked there. I tried using Qt 5.5.0 on Yosemite 10.10.2 and Xcode 6.1.1 / 6.2 but that turned out to be a disaster. When I moved back to Qt 5.4.2, I gained IMMEDIATE relief. All of the strange xcodebuild errors went away. The basic project I tried for HOURS to get running on IOS and IOS simulator under Qt 5.5.0/Xcode 6.1.1 immediately WORKED on Qt 5.4.2 on Xcode 6.1.1 So I went to start looking at the CI system with an eye for knowing what combinations of OSX, Qt 5.x.x, and Xcode 6.x are safe combinations and which are explosive. https://wiki.qt.io/CI_Configurations http://testresults.qt.io/qtmetrics/metricspageci.php What I found was that the CI system is only running OSX Mavericks and I was not able to determine what sort of simulator or IOS device tests were being run. Maybe the IOS maintainer and the Continuous Integrator CI maintainer might allow me to make sense of which combinations of Xcode/OSX/Qt/IOS are best kept together. I know the upcoming patch of Qt 5.5.1 for Windows 10 support is a good pairing, but what is a good XCode to pair with Qt 5.5.1? Cheers, md On Thu, Jul 30, 2015 at 2:45 PM, mark diener rpzrpz...@gmail.com wrote: Hello List: Yosemite 10.10.2 - Xcode 6.1.1 (also on Xcode 6.2) - Qt 5.5.0 Trying to run on the IOS simulator and get a big fail. The simulator starts up but then the applicaiton output gets the following message on a basic project. Anybody come across this? Debugging starts Session could not be started: Unable to run app in Simulator Unable to remove simlink at `/Users/md/Library/Developer/CoreSimulator/Devices/68424D04-B842-4C71-AE77-6F141822D7E3/data/var/folders/9s/l_fngwkx5rz_fjy85dns7rjwgn/T/ios-sim-stderr-pipe-1438292236' Unable to remove simlink at `/Users/md/Library/Developer/CoreSimulator/Devices/68424D04-B842-4C71-AE77-6F141822D7E3/data/var/folders/9s/l_fngwkx5rz_fjy85dns7rjwgn/T/ios-sim-stdout-pipe-1438292236'Run ended.Debugging has failed Debugging has finished Thanks, md ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] SIGBUS Android Qt 5.5.0
Thiago: You were right. string.h - Correct For SIGBUS exceptions, I had some structure members that did NOT end on even 4 byte boundaries. I had to specifically set some memory variables to pass on 4 byte alignments. Don't yet know why the NDK C++ compiler won't align on byte boundaries automatically. Thanks, md On 7/29/2015 10:58 PM, Thiago Macieira wrote: On Wednesday 29 July 2015 21:20:27 mark diener wrote: Hello List: Ran into Android compiler NDK C++/C issue today. NDK r10e-osx SDK Tools 24.3.3 Api 19 (4.4.2) Code runs great on OSX and IOS. But dies with SIGBUS (7) on Android 4.x. And there are issues of implicit declarations of memcpy and memset that #include string.h Does not matter if Debug (O0) or Release (02) As I begin to deep dive this tomorrow, maybe someone has come across this? Sorry, there's really not enough information in your description. All I can say right now is there's a bug in your code. This has to be a compiler setting issues since armv7 on android fails while armv7/arm64 on IOS 7 ipad mini 1st gen works OK. Buggy code can work as you'd expect it to, under some circumstances. -- No spell checkers were harmed during the creation of this message. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmake Library VERSION issues on Windows
On Thursday 30 July 2015 07:58:15 Carel Combrink wrote: How does the Linux side know which version to link to, I am assuming this is then a feature of gcc/make and not qmake? No, it's really qmake. It creates symlinks. When you pass -lXXX, the linker searches for libXXX.so and then libXXX.a. qmake creates a symlink from libXXX.so to the actual file. I can't see that my dependent lib knows the version of the base lib because the VERSION variable is set in the PRO file, but my dependent lib links against the PRI file that does not contain this information. It is then probably because I normally build them together? If it is not qmake related then I understand if you do not have more information on this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QThread sleep on QMutex
Igor wrote: Because in Qt 4 QThread::sleep is protected. You can unprotect it by deriving your own class from QThread and making whichever static methods public! As long as you are aware of the pitfalls (don't sleep in main thread, etc.), and much easier than messing with locks just to gain access to sleep. Regards, Tony ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How does Google Play validates Android binaries?
On 29/07/2015 19:51, Nuno Santos wrote: Hi, I’m having a serious issue with Android deployment and this is something recent. I’m starting to think that this was not happening on previous versions of Qt. I’m currently using Qt 5.4.2 and when I deploy to Google Play, on some devices the app is not compatible (the pattern seems to be high resolution devices). On my app manifest min SDK is 14 and target SDK is 21. I also have a support-screens directive with the following: supports-screens android:smallScreens=false android:normalScreens=true android:largeScreens=true android:xlargeScreens=true/ The most awkward issue here is that a couple of months ago, the same app was available to the same device and now it isn’t. There are some possibilities in my list: - Google Play bug - Android build tools incompatibility - Qt behaviour change on androiddeployqt However I’m completely in the dark. I’m tired of making experimental builds and uploads with no positive results. Does any one knows how does Google Play analyses APK’s in order to determine if they are OK or not? The only thing Google tells me is: unsupported native platform: armeabi, armeabi-v7a” However, APK’s were built for armeabi-v7a and x86, with a superior version number for x86. You should not have armeabi as supported if you are building for armeabi-v7a. Where does that come from? The .apk works on development but isn’t allowed thru Google Play. Is anyone here experiencing the same problem? I haven't built a new android version for a few months, but when I did I was using some snapshot of 5.5 dev. Do you use ant or Gradle for the build? Harri ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QThread sleep on QMutex
On 2015-07-30 01:43, Igor Mironchik wrote: On 30.07.2015 00:06, Matthew Woehlke wrote: Why are you doing this? If the intent is just to make the thread sleep, why not use QThread::msleep? Because in Qt 4 QThread::sleep is protected. You failed to mention that you are using Qt 4.x :-). If you *need* to sleep, I'd go with Tony's solution; just derive some class from QThread and unprotect the relevant methods. I've done this in my own projects. You don't need to know what thread you're in; sleep() and friends are static methods. Just write: MyThread::msleep(interval); That said, see also Keith and Thiago's replies :-). -- Matthew ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Release Binary Builds
Thiago: I kind of messed up. You once replied with the location on github or somewhere where the binary build commands for configure on the product releases was located. OSX ./configure bla-bla-bla When I search back through all my past emails, I could NOT find that kind message you forwarded. Do you think you could pass along the binary build command url location? Thank you, md -- No spell checkers were harmed during the creation of this message. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How does Google Play validates Android binaries?
Before I had the support-screens directive, then I have changed to compatible screens, and I think the problem started there. Before I also had the required min dpi attribute on support-screens and now I have completely removed it. So, I ended with this only: supports-screens android:smallScreens=false android:normalScreens=true android:largeScreens=true android:xlargeScreens=true”/ Nuno Santos Founder / CEO / CTO www.imaginando.pt +351 91 621 69 62 On 30 Jul 2015, at 10:13, Daniel França daniel.fra...@gmail.com wrote: Hi Nuno, Sorry, I didn't get what you changed to make it work. Could you explain? Em qui, 30 de jul de 2015 às 10:58, Nuno Santos nunosan...@imaginando.pt mailto:nunosan...@imaginando.pt escreveu: Harri, Yesterday, I have finally managed to solve the problem with the help of a user. One of the biggest issues was the misleading information provided by Google Play Developer support about the unsupported platforms. The problem was actually derived from the support-screens. My last try was: supports-screens android:smallScreens=false android:normalScreens=true android:largeScreens=true android:xlargeScreens=true”/ And it is now working for both apps. No problems with Qt, Android-SDK, Android-NDK or so ever. I’m glad this is solved as a lot of users couldn’t install from the store. Thanks for your feedback. Nuno On 30 Jul 2015, at 09:51, Harri Pasanen ha...@mpaja.com mailto:ha...@mpaja.com wrote: On 29/07/2015 19:51, Nuno Santos wrote: Hi, I’m having a serious issue with Android deployment and this is something recent. I’m starting to think that this was not happening on previous versions of Qt. I’m currently using Qt 5.4.2 and when I deploy to Google Play, on some devices the app is not compatible (the pattern seems to be high resolution devices). On my app manifest min SDK is 14 and target SDK is 21. I also have a support-screens directive with the following: supports-screens android:smallScreens=false android:normalScreens=true android:largeScreens=true android:xlargeScreens=true/ The most awkward issue here is that a couple of months ago, the same app was available to the same device and now it isn’t. There are some possibilities in my list: - Google Play bug - Android build tools incompatibility - Qt behaviour change on androiddeployqt However I’m completely in the dark. I’m tired of making experimental builds and uploads with no positive results. Does any one knows how does Google Play analyses APK’s in order to determine if they are OK or not? The only thing Google tells me is: unsupported native platform: armeabi, armeabi-v7a” However, APK’s were built for armeabi-v7a and x86, with a superior version number for x86. You should not have armeabi as supported if you are building for armeabi-v7a. Where does that come from? The .apk works on development but isn’t allowed thru Google Play. Is anyone here experiencing the same problem? I haven't built a new android version for a few months, but when I did I was using some snapshot of 5.5 dev. Do you use ant or Gradle for the build? Harri ___ Interest mailing list Interest@qt-project.org mailto:Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org mailto:Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QThread sleep on QMutex
Hi, On 30.07.2015 11:31, Tony Rietwyk wrote: Igor wrote: Because in Qt 4 QThread::sleep is protected. You can unprotect it by deriving your own class from QThread and making whichever static methods public! As long as you are aware of the pitfalls (don't sleep in main thread, etc.), and much easier than messing with locks just to gain access to sleep. Thank you guys for your answers. You are right and I know about all this approaches. But I have to say that sleep() needed in object that doesn't know anything about his thread. And my question is just theoretical: is this approach good or such sleep() implementation not so good and why? I.e. will such sleep() release processor's time for another thread or not? -- Best Regards, Igor Mironchik. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How does Google Play validates Android binaries?
Harri, Yesterday, I have finally managed to solve the problem with the help of a user. One of the biggest issues was the misleading information provided by Google Play Developer support about the unsupported platforms. The problem was actually derived from the support-screens. My last try was: supports-screens android:smallScreens=false android:normalScreens=true android:largeScreens=true android:xlargeScreens=true”/ And it is now working for both apps. No problems with Qt, Android-SDK, Android-NDK or so ever. I’m glad this is solved as a lot of users couldn’t install from the store. Thanks for your feedback. Nuno On 30 Jul 2015, at 09:51, Harri Pasanen ha...@mpaja.com wrote: On 29/07/2015 19:51, Nuno Santos wrote: Hi, I’m having a serious issue with Android deployment and this is something recent. I’m starting to think that this was not happening on previous versions of Qt. I’m currently using Qt 5.4.2 and when I deploy to Google Play, on some devices the app is not compatible (the pattern seems to be high resolution devices). On my app manifest min SDK is 14 and target SDK is 21. I also have a support-screens directive with the following: supports-screens android:smallScreens=false android:normalScreens=true android:largeScreens=true android:xlargeScreens=true/ The most awkward issue here is that a couple of months ago, the same app was available to the same device and now it isn’t. There are some possibilities in my list: - Google Play bug - Android build tools incompatibility - Qt behaviour change on androiddeployqt However I’m completely in the dark. I’m tired of making experimental builds and uploads with no positive results. Does any one knows how does Google Play analyses APK’s in order to determine if they are OK or not? The only thing Google tells me is: unsupported native platform: armeabi, armeabi-v7a” However, APK’s were built for armeabi-v7a and x86, with a superior version number for x86. You should not have armeabi as supported if you are building for armeabi-v7a. Where does that come from? The .apk works on development but isn’t allowed thru Google Play. Is anyone here experiencing the same problem? I haven't built a new android version for a few months, but when I did I was using some snapshot of 5.5 dev. Do you use ant or Gradle for the build? Harri ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How does Google Play validates Android binaries?
Hi Nuno, Sorry, I didn't get what you changed to make it work. Could you explain? Em qui, 30 de jul de 2015 às 10:58, Nuno Santos nunosan...@imaginando.pt escreveu: Harri, Yesterday, I have finally managed to solve the problem with the help of a user. One of the biggest issues was the misleading information provided by Google Play Developer support about the unsupported platforms. The problem was actually derived from the support-screens. My last try was: supports-screens android:smallScreens=false android:normalScreens=true android:largeScreens=true android:xlargeScreens=true”/ And it is now working for both apps. No problems with Qt, Android-SDK, Android-NDK or so ever. I’m glad this is solved as a lot of users couldn’t install from the store. Thanks for your feedback. Nuno On 30 Jul 2015, at 09:51, Harri Pasanen ha...@mpaja.com wrote: On 29/07/2015 19:51, Nuno Santos wrote: Hi, I’m having a serious issue with Android deployment and this is something recent. I’m starting to think that this was not happening on previous versions of Qt. I’m currently using Qt 5.4.2 and when I deploy to Google Play, on some devices the app is not compatible (the pattern seems to be high resolution devices). On my app manifest min SDK is 14 and target SDK is 21. I also have a support-screens directive with the following: supports-screens android:smallScreens=false android:normalScreens=true android:largeScreens=true android:xlargeScreens=true/ The most awkward issue here is that a couple of months ago, the same app was available to the same device and now it isn’t. There are some possibilities in my list: - Google Play bug - Android build tools incompatibility - Qt behaviour change on androiddeployqt However I’m completely in the dark. I’m tired of making experimental builds and uploads with no positive results. Does any one knows how does Google Play analyses APK’s in order to determine if they are OK or not? The only thing Google tells me is: unsupported native platform: armeabi, armeabi-v7a” However, APK’s were built for armeabi-v7a and x86, with a superior version number for x86. You should not have armeabi as supported if you are building for armeabi-v7a. Where does that come from? The .apk works on development but isn’t allowed thru Google Play. Is anyone here experiencing the same problem? I haven't built a new android version for a few months, but when I did I was using some snapshot of 5.5 dev. Do you use ant or Gradle for the build? Harri ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
