[QBS] Android and Qbs profiles

[Ch'Gans]

Hi all,

As highlighted recently on the list, there seems to be a problem with
android profiles when trying to build applications.

The Qbs Application item infers the "profiles" property. I'm
copy/pasting the documentation here for convenience:
----
The profiles for which the product should be built. For each profile
listed here, one instance of the product will be built according to
the properties set in the respective profile. This property is only
relevant for projects that require products being built for different
architectures. Otherwise it can be left at its default value.
----

There are a couple of problems with this:
- Only ARMv5 and ARMv7 are supported by defaults (no x86-32/64, no ARM-64)
- This makes qbs try to build for profiles that don't always exist,
without telling the user what is the problem (eg, ERROR: ... The
profile 'qt57-and49_x86-armv5te' does not exist.)
- This works only if you tell qbs to build using the "android" base
profile, and you have used qbs-setup-android to create your android
profiles (which will be automatically named "android-$arch")
- Combination of the above: doesn't work with Qt profiles or any
custom profile unless a strict naming convention is used. And it's not
Qbs business to tell user how to name their profiles or is it?
- I couldn't find anything about all of these in Qbs documentation

Now what is the rational behind all of these? I'm not an Android
expert, but after looking on the net, I have the feeling that it is
related to multi-arch per APK vs multi-APK for an application relying
on native code. And Qbs seems to take the multi-arch per APK approach,
that's why it needs to infer the per-arch profiles based on a list of
supported architectures.

Shouldn't qbs, at least, allow the user to create an APK for a single
architecture of his/her choice?

Finally, is it really worth all the hassle, for a final result of
supporting only two arm architectures, one of each being outdated?
Android 4.4+ requires ARMV7 [1], [2] (although, custom builds exists
for ARMv6 (aka ARM11) [3]). As of late 2016, 4.4+ mean 4.4, 5.0, 5.1,
6.0 and 7.0

According to [4]: "...uploading an APK with armeabi native code will
target 12 more devices than uploading an APK containing armeabi-v7a
native code. The reason for this is that all devices running the
armeabi-v7a are also able to execute the armeabi native code."

To relate this "12 more devices", the actual numbers of supported
devices are: 7998 for armeabi vs 7986 for armeabi-v7a. Which actually
means that out of 7998 ARM/32 based devices in the Google Play Store
Device database, only 12 don't support armeabi-v7, 12 out of 7998 =
0.15%, and this number will only go down with time.

Now, you may argue that removing support for ARMv5 won't solve the
problem, since multi-arch APK are still useful for supporting both
ARMv7 and ARMv8 at the same time... And you would definitely be right!
:)

As a solution, what about letting the user specify the muli-arch
profiles in a master profile?
For example, one has to "qbs config profiles.MyProfile.baseProfile
MyBaseProfile", what about then: "qbs config
profiles.MyProfile.apkProfiles
MyQtProfileArmv7,MyQtProfileArmv8,MyQtProfileX86" with
MyProfile.apkProfiles defaulting to [MyProfile.baseProfile]

This could be complimentary to the current approach:
1. The responsibility of specifying profile association is shifted to
the user (or qbs-setup-android + qbs-setup-qt)
2. No hard-coding (even partial) is needed in Qbs support files
3. Application.profiles could be deduced from both
Application.architectures and project.profile (I don't know if it's
possible in this context to access the "apkProfiles" property of a Qbs
profile given it's name)

Does that make sense?

Chris

[1] http://source.android.com/compatibility/cdd.html
[2] http://source.android.com/compatibility/4.4/android-4.4-cdd.xhtml#section-3.3
[3] http://stackoverflow.com/questions/28926101/is-it-safe-to-support-only-armeabi-v7a-for-android-4-and-above
[4] https://androidbycode.wordpress.com/tag/armeabi-v7a/