If you are building Qt-based Android applications that need network access, you need to take care of bundling OpenSSL yourself. That has always been the case, however with Qt 5.13.1 (or later), there’s a crucial change that might require you to update your OpenSSL bundling. Users of the KDE Android SDK Docker image are luckily not affected by this, but if you have a manual setup this is likely relevant for you.
There’s several reasons why the OpenSSL handling in Qt in general and for Qt on Android in particular is a bit special:
OpenSSL is a hard dependency for Qt networking. Such dependencies are usually linked against by Qt libraries. While possible for OpenSSL too, the default build option is to dlopen it at runtime, and that’s also what the official Qt binaries do. This has the side-effect or moving the error handling of missing or wrong OpenSSL libraries to much later in the applications lifetime. (This is where the custom-built Qt in the KDE Android SDK differs, that treats OpenSSL as a linked dependency).
OpenSSL is not bundled with Qt, unlike most other hard dependencies. Qt does this in source for some dependencies, as well as for some binaries in the official installer. OpenSSL is the exception due to license compatibility concerns, which is also the reason for the dlopen hack.
Different OpenSSL versions aren’t entirely ABI compatible as far as Qt’s needs go, depending on build options etc. Qt might expect a newer version than is available. That becomes an issue in combination with the following point.
(Some?) Android systems ship OpenSSL, depending on the API level in different versions, not all of them usable, but nevertheless being visible when searching for libraries.
Until Qt 5.13.0 all you needed to do was making sure regularly built OpenSSL libraries were in the APK package, either by building that yourself, or by taking pre-built binaries from a sufficiently trusted source.^
In order to avoid the interference from incompatible OpenSSL provided by Android, Qt 5.13.1 changed what it expects to be the name of the OpenSSL libraries when dlopen’ing them. Obviously this breaks existing setups if you don’t adapt your OpenSSL build accordingly. And annoyingly that breakage will only show up at runtime in form of failing network access.
Unfortunately the Qt 5.13.1 release notes don’t seem to mention the implications of this change, so a bit of digging through the code
was required. The relevant change is this commit
and it provides an indication on how we need to adjust the OpenSSL libraries, namely by adding a “_1_1” suffix before the file extension. Adding
SHLIB_EXT=1_1.so as make argument to the OpenSSL build accomplishes this for example. If you are deploying OpenSSL to the APK by just
linking your application to it, that’s already all that needs to be changed.
Hopefully this saves someone from spending needless time on debugging this again :)