Automated build for Android APK

[nefarius2001]

Requesting and working on an automated build for Android, to enable non-techie choire members to install the APK.
This issue is to consolidate the discussions in #832 and #83 to one place.

My current efforts are in https://github.com/nefarius2001/jamulus/tree/feature/andro_build
As suggested by @pljones

• I added a yml file
  -- https://dev.to/arifikhsan/how-to-use-github-actions-to-build-android-app-1il7
• I copied the gradle-related files from my windows-build into the repo.
  -- https://dev.to/arifikhsan/how-to-use-github-actions-to-build-android-app-1il7
  => it executes, but does not succeed

I make some built APKs accessible on http://116.203.80.188:8000/ until this can be done through the projects websites (github most likely)

[ann0see]

Great! This could and should be added to the autobuild.yml file.

[nefarius2001]

can someone point out where the actual building is done in the current automation?

[ann0see]

Sure: The building starts here: https://github.com/corrados/jamulus/blob/1246dc6956a056aff16620e87f378d0fa80c7953/.github/workflows/autobuild.yml#L73
the if: checks on which OS you are building.

I'd suggest to first use your workflow and test everything and then afterwards add your commands to this file. It seems a bit complicated since the release process is also described in autobuild.yml

[pljones]

@ann0see -- by the way, why is installing Qt separate for Linux and Windows but brew install qt5; brew link qt5 --force forms part of the "build" step for MacOS? Seems a bit messy...

[ann0see]

Yes, it is. The problem with that was that on Windows I didn't find a way to install it via CLI --> separate actions needed. On macOS I didn't want to edit the deploy script and on Linux it was still the old one from the previous action.

Let's open a new issue on this topic.

[nefarius2001]

Thanks.
I found a good looking Ressource, but have to Stop working on it for today
https://www.vikingsoftware.com/docker-image-for-qt-android-builds/

[nefarius2001]

getting closer: https://gitlab.com/nefarius2001/qt5.12.4androiddocker/-/tree/jamulusbuild

[pljones]

Interesting -- https://docs.gitlab.com/ee/ci/ -- nice that they do this by default, it seems.

[nefarius2001]

Just curiosity:
Has anyone else successfully built APKs for Android already? If so, on which host system? I used Windows.

[nefarius2001]

Docker builds now successful

[nefarius2001]

I saw @ann0see rework the yml file. Would it be possible to have a talk about how this structure works & including android?

Is it intentional to not have an automated published build of the latest master (overwritten every time)?

[ann0see]

Would it be possible to have a talk about how this structure works & including android?

Yes, sure. This evening should work for me (= in 2 hours)

Is it intentional to not have an automated published build of the latest master

This wasn't planned but could be added.

[ann0see]

By the way: would you also provide APKs for devices with Intel processor?

[nefarius2001]

I think it's all in one apk now. Did you test and it failed?

[ann0see]

I installed it on my Android 4.4.4 intel device and it failed (error: parsing failed). But that could also be due to a new apk format my device doesn't understand.

[ann0see]

@nefarius2001 I now got windows working with aqt: https://github.com/miurahr/aqtinstall without using docker. Maybe this helps you somehow?

See #853

[pljones]

At least one of the Android builds should be added to the CodeQL check, too.

[nefarius2001]

At least one of the Android builds should be added to the CodeQL check, too.

Agreed, but I am not that familiar with CodeQL.
CodeQL has different build commands than autobuild. Why is that, is it necessary? If possible there should not be two dirrerent ways of automated building.

[pljones]

CodeQL has different build commands than autobuild. Why is that, is it necessary? If possible there should not be two dirrerent ways of automated building.

I've sort of mentioned this elsewhere. The autobuild needs splitting up everything up to "qmake; make" (or platform equivalent) is handled in just one place and then any packaging of the built artefact for deployment is done in per-target ways. Then the Code-QL could just use the same build part.

Code QL needn't run against each different deployment target, of course - but it also doesn't need to run against every build target: Windows 32 and 64 aren't significantly different; the various Android hardware environments similarly don't differ in code vulnerabilities significantly.

So perhaps we need a "build" script that takes "os" and "cpu" and a "package" script that takes "os" and "package format"?

[nefarius2001]

Sounds good to me. I would be interested to have a call with you, if you could give me some insight how codeql works and to discuss an efficient solution. What do you think, @pljones ?

[pljones]

how codeql works

I've no idea on that - it's just a few lines of yml that Github understands:

    - name: Initialize CodeQL
      uses: github/codeql-action/init@v1
      with:
        languages: cpp

    - name: Perform CodeQL Analysis
      uses: github/codeql-action/analyze@v1

Nothing else need to get it to run. If there's a build in the default place, it'll run against it and produce the report.

[pljones]

In terms of getting the different build strategies aligned, an issue here is probably the best approach.

[nefarius2001]

lets continue the strategy / code quality in #854
this issue is just about building for Andriod

[stweil]

Did you also consider publishing the APK in the F-Droid store?