Uh... I just did. Turns out that the function which was missing for me was not really necessary so I removed it. So in that sense it's the same solution you used.
As far as I know there are 2 proper solutions:
recompile Qt with custom (static) OpenSSL build and use it to build your project (make sure you only link to OpenSSL statically)
create a custom wrapper for OpenSSL functions you need, link it statically to OpenSSL and to your app
Note that the Android folks have a tendency to make new releases that are adding/removing/moving stuff around and are breaking things here and there thus the documentation might not be accurate because of that.
@GrecKo I found that it is a bug that is affecting all platforms with certain screen resolutions. Some developers may not notice this issue but the end user may be using a certain screen resolution and be affected by the issue! You can login to https://bugreports.qt.io/ and Vote THIS bug if you also want this bug to be resolved.
@torpeanders I always use just one resource file per project, and although not completely sure, it looks like having RESOURCES += ...
is intended for just one resource file.
I'm not sure if you need two resource files, I'd ask what is your use case for that, please remember that you can have subfolders to split just in case; i.e. I usually have a subfolder images for the icons and a subfolder translations and then it's a question of using the proper path
So if even this trick cannot avoid you having two resource files, please have a look at the documentation as it explains how to create/deal with external resource files (it'll be your 2nd one).
Having the name property set while loading a font by source is no problem under macOS but under Android, one Devanagari font started to dominate all instances, where Devanagari symbols appeared and all logic, how fonts are applied falls apart.
I am not sure if this is possible at all. It is quite a long time back when I used MSVC. However, I am having no good feelings when I read your post.
I had started recently compiling for Android. Since a couple of years I am using Qt creator and MinGW compiler. The Android compiling process is GCC-based as MinGW is. That is taking some ambiguities out. Therefore my recommendation you may save time and conserve some hair, when you are going directly to Qt creator when starting Qt for Android.
The error message you are presenting is probably because of the mix MSVC and GCC-make, which might errornously recognized as linux version. I might be wrong there, but this looks fishy.
In case you decide to follow my advice, also go directly to Qt 5.9.0 (at least). There seem to be recent change also on the Android side, which was not really helpful in getting started. I had struggled quite a bit when trying to follow the different advices and tutorials. "gradle" seems to have replaced "ant" already on Android. At the end I had decided to go directly to newest Qt5.9.0 at that time instead of fiddling around with the previous stuff. That went much easier.
Found some workarounds.
The alignment of keyboard input marker with dialog is exectable for maximized dialogs.
Editable comboxes are unusable. Therefore, basically switching them to use of QLineEdit with additional button. Could be more elegant, but it works.
However, I am not completely sure why. The system has now 16 GB instead of 8 GB, but task manager shows a little less than 8GB used. Probably some parts used by win 10 are not properly listed respectively my interpretation is not completely correct.
Anyway, the system has been simply 8GB memory added. There were no other changes required and suddenly the AVD start succeeded. This is despite the fact that I still have an error message
The command "C:\Users\...\AppData\Local\Android\sdk\platform-tools\adb.exe" terminated with exit code 1.
This is an AVD for ARM as I require for my Google phone. It consumes a 1.2 GB and has a reserved 2 GB according to task manager.
@ekkescorner@jpnurmi reminds me that there's a problem if you're using multi-line Text inside Flickable.
He's right: as long as the TextArea has focus if you try to scroll the selection will be changed instead of scrolling the page.
If you're outside the field scrolling works well
I'll create a bugreport on this soon.
my workaround: I'm placing a small button (w icon) besides the field to toggle word-selection-mode. just tested. this works.
In most cases my TextFields are single line text where selection works well so I can live with this.