Android: Jamulus.pro relies on git and Linux

[pljones]

Describe the bug

When building the Android version of Jamulus, Jamulus.pro currently relies on the git commit count to generate the ANDROID_VERSION_CODE.

Currently, the | wc -l used to generate the count limits the build to running on a Linux-based machine. This command fails on Windows (hence #3083).

The git log --oneline introduces a dependency on

• git being installed
• the build being run against the git repo rather than the source tarball

To Reproduce

1. Working example using git repo and Linux:

git checkout main
# Switched to branch 'main'
# Your branch is up-to-date with 'origin/main'.
qmake Jamulus.pro -spec android-clang ANDROID_ABIS="armeabi-v7a arm64-v8a x86 x86_64"
# Project MESSAGE: building version "3.9.1dev-f47b6a7a" (intermediate in git repository)
# Project MESSAGE: Setting ANDROID_VERSION_NAME=3.9.1dev-f47b6a7a ANDROID_VERSION_CODE=5471

where 5471 is the result of git log --oneline | wc -l.

2. Failure case no. 1

• Use the source tarball on Linux
• Run the qmake command as above
• The git log --oneline will fail, causing the qmake to error out

3. Failure case no. 2

• Use the git repo on a Windows machine
• Run the qmake command as above
• The wc -l command will fail, causing the qmake to error out

Expected behavior

The ANDROID_VERSION_CODE is used by Google Play Store to distinguish versions of an application. Each version should have a higher number than any it is intended to supercede, hence:

• any build intended to be distributed via Google Play Store should be able to be built from any supported build platform
• other versions should also be able to be built on any supported build platform.

From #3083 (comment)

The VERSION variable should be independent of a git install if possible

That is, any environment Android Qt build environment should be able to build Jamulus, either for Google Play Store or not, from the source tarball.

[ann0see]

... this means we need to find a way to generate an unique per build/release increasing number.

I suggested two ways:

1. Use the unix timestamp -> needs system() call and probably some PowerShell magic on windows
2. Use the VERSION variable directly and remove all dots/pre/suffixes.

[pljones]

... this means we need to find a way to generate an unique per build/release increasing number.

Via the Qt qmake Variables manual page, Google's explanation for the value.

It's important that any build of <commit-id + no local changes> gives the same ANDROID_VERION_NUMBER regardless of platform; ideally any uncommitted local changes would invalidate the ANDROID_VERION_NUMBER, I suppose...

I suggested two ways:

1. Use the unix timestamp -> needs system() call and probably some PowerShell magic on windows

... which means making the version number differently ... potentially leading to non-sequential numbering.

I wonder if qmake has a formattable date built-in that supports unix-like values, e.g. date +%s (1687088024).

The problem is:

Note: The greatest value Google Play allows for versionCode is 2100000000.

• 1687088024
• 2100000000

which in seconds-from-epoch is

Friday, 18 July 2036 14:20:00 (BST)

I'm hoping the end of the world hasn't happened by then.

2. Use the VERSION variable directly and remove all dots/pre/suffixes.

You'd need padding. 3.1.99 is less than 3.11.9, so just stripping dots wouldn't do (3199 vs 3119), you'd need to parse "intelligently". Doable but fiddly. <major>||<minor zero pad to four>||<fix zero pad to four> maybe: 300010099 vs 300110009. The problem here is that the ANDROID_VERION_NUMBER wouldn't bump for beta or pre-release builds, which would make installation harder, I guess. (Although I don't know if installing from an apk really bothers about the value - I've always needed to uninstall.)

[pljones]

So, requirements:

1. An integer value in the range 0 to 2100000000.
2. The value is shared by all developers able to submit a release to Google Play Store.
3. The value should increase for each build potentially for release to Google Play Store.
4. Any such released build shares the same value for the same commit with no local changes when rebuilt.
5. Similarly, builds of that commit from the source tarball should use the same number.
6. Builds on any platform should use the same number.

[pljones]

3. The value should increase for each build potentially for release to Google Play Store.

If we presume this means a build performed by the Github build actions, then the value could be edited in place, committed to git and then built.

That would then meet requirements 2, 4, 5 and 6. All we'd need to do is start the number at git log --oneline | wc -l in the file by hand and write the automation...

and write the automation

being the tricky bit.

[pljones]

That would then meet requirements 2, 4, 5 and 6.

Actually, not 4. We'd still have no way to know if there were local changes without git. So we're back relying on git.

I think I'd prefer the number to be zero for any release not built by the Github build chain - set to zero in Jamulus.pro unless overridden. It doesn't prevent abuse but it reduces the likelihood of accidental release to Google of a "bad" build.

[pljones]

I'm going to put this into Triage. It needs more thought. I don't know enough about Github automation or the Qt build process, really.