Qt Creator 3.0.1 Building to Android Virtual Problem
-
Hello everyone,
I seem to be having a problem deploying my program to a Virtual Android Device. I don't get any compile errors, and when it asks me to pick a device it boots up properly. But the virtual machine just sits there and eventually Qt creator throws an error:
Error while building/deploying project untitled7 (kit: Android for armeabi-v7a (GCC 4.8, Qt 5.2.1))
When executing step 'Deploy to Android device'It was suggested on a different answer to wait for the emulator to fully boot up, so I did that. But when I hit run again and pick the same device it just boots up that device as a second emulation changing nothing.
I'd appreciate any advice. Thanks
-
My suggestion is : installing (via Android SDK Manager on Eclipse) the Intel x86 images and the Intel x86 Emulator Accelerator (HAXM). Then, on Qt Creator, select Android for x86 kit for building and deploying (just for emulation). You can create AVDs for the x86 processor, which will run much faster than using armeabi-v7a. The default Android emulator is very very very slow. For deploying your Apps in a real Android device, use the armeabi-v7a kit.
-
-
Same here. I narrowed it down to the point where it does not create apk files.
Took me some while to figure it out that QtCreator does not call androiddeployqt.
After calling it from the command shell I finally got an apk to deploy (with some more hazzles to be solved).
My current assumption is that QtCreator has issues with the latest NDK . -
Yes. you're right. Try downgrading the Android SDK to version 22.3 :
(1) Download the SDK r22.3 from (one of the links below)
http://dl.google.com/android/android-sdk_r22.3-windows.zip
http://dl.google.com/android/android-sdk_r22.3-macosx.zip
https://dl.google.com/android/android-sdk_r22.3-linux.tgz
(2) Uncompress one of this files to a temporary folder
(3) Locate the "sdk/tools" folder of your current ADT installation and rename it (to sdk/tools1, for example)
(4) Copy the "tools" folder of the SDK r22.3 to the "sdk" folder of your current ADT installation.It's likely that this will solve the building issue.
note: a helpful link is http://stackoverflow.com/questions/9555337/how-to-downgrade-my-sdk-version
-
bq. On a related note the current NDK is prefixing the platform name with default/ which leads the AVD to fail with “incompatible device” messages.
Dear Groucho,
It fixes by manual from cezmen in previous message.
Anyway, you can find workaround "here":http://stackoverflow.com/questions/22238649/qt5-for-android-incompatible-abi#22392690. -
-
Dear Oleg, that's how it works for me :
(1) have you checked the Deploy Configurations of your project under Qt Creator :
- Projects -> Android for armeabi-v7a -> Run -> Deploy Configurations -> Details
- You must create a keystore, and check "sign package"
- Under Advanced Actions, select "open package location after build"
- Under Qt Deployment, select "Bundle Qt libraries in APK"
(2) Have a real Android device plugged via USB cable. Just after the build process, a new window is opened showing the path for the APK file.
I don't know if these steps work while deploying to a Virtual Android Device (AVD). Probably not in my case, because I usually use x86 AVDs (which run faster).
-
Dear cezmen,
thanks a lot for your answer.
I've been completed all steps which you described. However, I can't get .apk after build/deploy. It's the same for x86 AVD.
Probably, anything else need to be configured in my environment?
Also I have reviewed Qt Project JIRA related to deploy and call for androiddeployqt. So I couldn’t find any issue regarding this problem. Is exist such issue which reported to Qt?
Best regards,
Oleg. -
Problem was solved.
bq. Probably, anything else need to be configured in my environment?
This is not an environment issue, it's a bug in Qt Creator, but it fixed in 3.1. See details in "QTCREATORBUG-12001":https://bugreports.qt-project.org/browse/QTCREATORBUG-12001.
Moreover, if update Qt Creator 3.0.1 up to Qt Creator 3.1.0 RC1 (3.0.84) - problem will be solved.
With Qt Creator 3.1.0 RC1 (3.0.84) there is no need to use any workarounds which described here (i.e. it's no need to define env variable, replace sdk/tools, etc).
Best regards,
Oleg.